Agilität vor Qualität? – Wie agile Methoden die Softwarequalität beeinträchtigen
Applause
Heute muss immer alles schnell gehen – auch in der Softwareentwicklung. Um mit dem Innovationsdruck mithalten und schneller sowie effizienter agieren und Software entwickeln zu können, haben in den vergangenen Jahren mehr und mehr Unternehmen auf die sogenannten “Agile Methods” wie Scrum, DevOps, Kanban gesetzt. Doch mittlerweile mehren sich die Agile-kritischen Stimmen.
von Julia Wiencirz, Senior Solution Engineer bei Applause
Irgendwie scheint ein wenig Sand in das agile Getriebe vieler Unternehmen geraten zu sein. Unter anderem, weil so manches Agile-getriebene Product Team in die “Build Trap” gerät, indem es sich vor allem auf einen hohen Ausstoß von Feature-Releases und das regelmäßige Befüllen und Entleeren seines Backlogs konzentriert.Angetrieben von den Sprints und einer übervollen Product Roadmap sind Entwickler dazu angehalten, mehr Code in kürzester Zeit in immer kleineren Builds zu produzieren.”
Für QA-Teams hingegen geht es aufgrund mangelnder Zeit und nötigen Testressourcen häufig nur darum, lediglich “funktionierende” Software für jedes Release sicherzustellen. Für die Softwarequalität kann das alles tödlich sein.
Ein neues, stärker nutzerzentriertes Verständnis von Software-Qualität ist erforderlich
Wirft man einen Blick in das Agile Manifest, so heißt es dort, “Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen. Weiter heißt es, dass “Funktionierende Software […] das wichtigste Fortschrittsmaß” sei.
Reicht es aber aus, lediglich “funktionierende” Software auszuliefern?”
In den verschiedenen agilen Methoden wird zwar immer wieder auf Qualität verwiesen und der Kern von Agile besteht auch darin, dass Software in eng integrierten Teams aus Software-Architekten, Entwicklern und Testern entstehen soll. “Funktionierende” Software aber mit qualitativ hochwertiger Software gleichzusetzen, deutet auf ein Verständnis aus der unternehmensinternen Sichtweise hin, das sich an Agile-geprägten Leitbildern wie Geschwindigkeit, Continuous Delivery und Funktionalität orientiert. Denn auch wenn in einzelnen agilen Teams und nach den Sprints die Software innerhalb des verantwortlichen Teams getestet wird, so geschieht dies meist ausschließlich unter Berücksichtigung unternehmensinterner KPIs, nicht aber unter Berücksichtigung der Interessen und Präferenzen der eigentlichen Endanwender und Nutzer. Schlussendlich geht es für viele Unternehmen im Sinne der agilen Methodologien darum, dass die Software lediglich funktioniert und intern definierte Bedingungen erfüllt.
Julia Wiencirz arbeitete in den letzten 10 Jahren als Solution Engineering und Industry Specialist. Ihre Aufgabe ist es, die Testing-Lösung so aufzusetzen, dass die jeweilige Software letztendlich überall und für jeden Endanwender einwandfrei funktioniert.Das Problem: Weder die interne QA/Testing- oder Product-Abteilung vieler Unternehmen noch manche Off-Shore-Lösungen sind imstande, Qualität von Software in den Dimensionen der realen Nutzerwelt mit der Vielfalt von unterschiedlichen Nutzerprofilen, Devices, Locations und Nutzerumgebungen her- bzw. sicherzustellen.”
Doch wie können agile Teams es schaffen, statt nur “funktionierender” qualitativ hochwertige Software auszuliefern, die einen Mehrwert für die Nutzer schafft? Zugegebenermaßen ist “Qualität”, vor allem aus Nutzersicht sehr subjektiv, was es agilen Teams schier unmöglich macht, ihren Nutzern aus eigenen internen Möglichkeiten gerechter zu werden.
Wie reale Nutzer aktiv in die Produktentwicklung eingebunden werden
Insgesamt werden sowohl die digitalen Kanäle persönlicher als auch die persönlichen Kanäle digitaler. Es kommt immer mehr darauf an, dass Kunden im Wechselspiel der verschiedenen Kanäle keine Dissonanzen spüren, weil sie nicht in verschiedenen Kanälen denken, sondern konsistente, persönliche Produkterlebnisse erwarten. Für Unternehmen, die sich in einer frühen Produktphase von neuen Multichannel-Services befinden, ist es daher wichtig zu verstehen, wo bisherige Online- und Offline-Angebote nicht miteinander korrelieren und wie neue Angebote eine verbesserte und konsistentere Customer Journey bieten können.
Der “Design Thinking Ansatz” und der Einbezug von Feedback durch reale Nutzer aus einer Crowdtesting-Community kann ein sinnvoller und agiler Ansatz sein, qualitativ hochwertige Software auszuliefern.”
Mithilfe dieses Ansatzes ermittelt das Product/UX-Team in einem Workshop zunächst die Haupt-Nutzergruppen des neuen Features oder der Software und fragt sich u. a.:
1. Welchen Mehrwert/Nutzen soll das neue Feature/Software/Service leisten? 2. Wie sieht die übliche User Journey aus und welche Probleme treten auf?Für die potenziellen Haupt-Nutzergruppen werden dann hypothetische Szenarien als Storyboards entwickelt und anschließend in einzelne User Stories aufgefächert. Diese User Stories werden dann als Feature Descriptions für die Anwendung genutzt. Eine Priorisierung der einzelnen Funktionen in Haupt- und Nebenfunktionen hilft, eine erste Vorstellung davon zu bekommen, wie der Prototyp aussehen kann.
Applause (Website) hat sich der Qualitätssicherung von Apps mittels Crowdtesting über alle gängigen Geräte hinweg verschrieben – von Web- über Mobile- bis hin zu Wearable-Anwendungen. Getestet werden nach Aussage des Unternehmens die Apps für Kunden wie Google, Amazon, Ebay, Bertelsmann oder Axel Springer rund um den Globus von mehr als 400.000 professionellen Testern auf echten Geräten unter realen Bedingungen. Applause verfügt damit über das weltweit größte Crowdtesting-Netzwerk. Das Unternehmen mit Hauptsitz in Boston, USA wurde 2008 von Doron Reuveni und Roy Solomon als uTest gegründet. Im Mai 2014 wurde mit testhub der größte europäische Crowdtesting-Anbieter akquiriert. Seitdem firmieren beide Unternehmen gemeinsam unter dem Namen Applause. Das ehemalige Testhub-Team leitet als Applause EU von Berlin aus das operative Europa-Geschäft des Unternehmens.Nach der Erstellung des Prototyps und verschiedener Click-Dummies kann mithilfe von externen Crowdtestern aus einer Tester-Community erstes Nutzerfeedback eingeholt werden. Die Crowdtester sind aufgrund ihrer Profile (z. B. Alter, Interessen, verfügbare Testgeräte) nahezu identisch mit echten Kunden und testen die Prototypen in der Regel auf der Grundlage eines Fragenkatalogs (z.B. “Verstehst Du die App?” oder “Ist die Navigation intuitiv?”). Die Erkenntnisse aus der Feedback-Runde mit den Testern können dann genutzt werden, um den Prototypen zu überarbeiten. Auf diesem Wege wird die Grundlage für ein bedarfsgerechtes Software-Design entwickelt, noch bevor aktiv erster Code geschrieben wird.
Das User Feedback kann bei Bedarf in jedem Sprint und sowohl in der Konzeptions-, Entwicklungs- als auch in der Release-Phase einbezogen werden, indem nicht nur Prototypen, sondern auch auch Beta-Versionen und fertiger Code getestet wird.
Somit kann wertvolle Zeit und vor allem auch Geld gespart werden, indem neue Features erst dann entwickelt werden, wenn diese auch aus Nutzersicht den wichtigsten Kriterien von qualitativ hochwertiger Software (u. a. Mehrwert, Bedienbarkeit) entsprechen.
User Feedback als Katalysator für nutzerzentrierte Software
Auf dem Weg hin zu einem schnelleren und agileren Zustand sollte immer bedacht werden, dass User Feedback für die agile Entwicklung kein Hindernis oder nötiges Übel ist. Stattdessen sollte es ein Katalysator sein, um qualitativ hochwertige (und nicht nur funktionierende) Software an die Nutzer auszuliefern. Dies bedarf aber einerseits der aktive Einbindung der Nutzer mit ihrem Feedback in den (gesamten) Verlauf des Software Development Life Cycle. Andererseits braucht es ein Umdenken darüber, welche Grenzen und Möglichkeiten interne QA/Testing-Teams innerhalb agiler Unternehmen aufweisen und wie diese erweitert werden können.
Jedes Unternehmen, das sich zu sehr auf operative, unternehmensorientierte Ziele wie Geschwindigkeit, Autonomie oder die “Einhaltung der Regeln eines agilen Frameworks” konzentriert, läuft Gefahr, sich weiter von seinen Kunden zu entfernen.
Agile mag zwar die internen Prozesse beschleunigen, doch keinem Unternehmen ist geholfen, wenn die Software nur aus interner Sicht funktioniert und sinnvoll erscheint, aber aus Nutzersicht keinen Mehrwert schafft.”Julia Wiencirz, Applause
Sie finden diesen Artikel im Internet auf der Website:
https://itfm.link/92938
Schreiben Sie einen Kommentar