Wie werden Requirements entwickelt, so dass die Lösung auch zum Problem passt?

Transkript

1 Effizient vom Start zum richtigen Ziel! Wie werden Requirements entwickelt, so dass die Lösung auch zum Problem passt? So habe ich das nicht gemeint!. Eine sonst unkritische Aussage, die für das Team vernichtend ist, wenn sie erst während des -Reviews vom Product Owner ausgesprochen wird. Und das, obwohl das Team agil unterwegs ist. Aber was helfen die besten qualitätssichernden Maßnahmen und effizienzsteigernden Methoden, wenn am Ende das Falsche entwickelt wurde? Was ist die Ursache, dass solche Fälle in der Praxis immer wieder auftreten? Und wie kann man frühzeitig und systematisch dafür sorgen, dass die Lösung später passt?

2 Effizient vom Start zum richtigen Ziel! Was bringt die perfekt programmierte und bestdokumentierte Software, wenn sie am Ende das Falsche macht? Falsch kann sich dabei auf die Anforderungen des Stakeholders oder aber auch auf die Erwartungen des Endanwenders beziehen. Agile Methoden, vor allem Scrum, helfen uns, mit den vorgegebenen kurzen Entwicklungszyklen und den regelmäßigen Retroperspektiven solche Falschentwicklungen um einiges früher zu erkennen als mit klassischen Vorgehensmodellen. Nichtsdestotrotz bedeutet jedes falsch umgesetzte Feature verlorene Arbeit und Zeit, die nicht nur das Projektbudget vergeuden, sondern erfahrungsgemäß zur Demotivation des Teams beitragen. Das Ergebnis ist eine sinkende Gesamtperformance der Teams. Ist es nicht möglich, diese Missverständnisse schon vor der Umsetzung zu erkennen und zu beseitigen? Die meisten agilen Methoden sind grundsätzlich als Frameworks konzipiert, die per Definition nur einen abstrakten Rahmen festlegen. Konkrete Vorgaben für Detailfragen - wie der Umgang mit Anforderungen oder mit der Dokumentation - sucht man dort vergebens. Das ist hauptsächlich der Tatsache geschuldet, dass diese Detailfragen kontextabhängig sind. Sie können aus diesem Grund mit einheitlichen Mitteln bzw. Best Practices nicht angegangen werden. Getrieben durch den Erfolg und die Verbreitung der Agilität ist aus diesem Grund eine Fülle von Methoden entstanden, die versuchen, die Lücken der agilen Methoden zu füllen. Dazu gehören Specification By Example, Exploratory Testing, Feedback-Based Testing und viele andere. Die größte Herausforderung bleibt aber noch, diese Konzepte effizient in den eigenen Entwicklungsprozess zu integrieren, um die angesprochenen Ziele zu erreichen. Die Ursachen Missverstandene Anforderungen und Falschentwicklungen sind Stolpersteine, die wir oft in Projekten aus dem Weg räumen mussten. Dabei war es zunächst wichtig, die eigentlichen Ursachen für diese Probleme zu erkennen und zu analysieren, um geeignete Gegenmaßnahmen zu finden. Im Kern konnten folgende Hauptprobleme ausgemacht werden: Eine fehlende oder schwache Teamidentifikation: Meistens haben die Teammitglieder einzeln agiert und nicht zusammen an einem Strang gezogen. Zwischen den einzelnen Expertengruppen (Fachbereich, Tester, Entwickler, Architekten,...) waren Mauern vorhanden, die sowohl physikalischer Natur waren wie im Falle einer räumlichen Trennung oder auch zwischenmenschlich aufgebaut waren. Die Falle des Offensichtlichen: Hier verzichtet das Product Owner Team bzw. der Fachbereich auf eine Detaillierung der Spezifikation, weil sie annehmen, dass das, was sie spezifiziert haben, offensichtlich und selbsterklärend ist. Die Begrifflichkeiten: Missverständnisse entstehen, wenn die involvierten Teammitglieder (Product Owner, Entwickler, Architekten, Tester,...) entweder unterschiedliche Begriffe für das Gleiche oder aber auch einen Begriff für unterschiedliche Sachverhalte verwenden. Unterschiedliche Ablageorte für die spezifikationsrelevanten Artefakte: Probleme entstehen auch, wenn die einzelnen Rollen verschiedene Ablageorte und -formate verwenden. So werden Anforderungen und Testfälle getrennt verwaltet. Gleiches gilt für die Produktdokumentation. Methodenkiste Aufgrund der Vielfältigkeit müssen die Ursachen mit unterschiedlichen Mitteln angegangen werden. In den vergangenen Jahren entwickelte sich eine Fülle von Methoden, welche die einzelnen Problematiken ansprechen. Diese Methoden werden aus diesem Grund auf den Folgeseiten kurz vorgestellt. Impact Mapping Impact Mapping wurde von Gojko Adzic auf der Basis von verschiedenen Konzepten wie Effect Mapping, Impact Maps und Feature Injection entwickelt (Adzic, 2012). Es bietet Werkzeuge zur Ermittlung der effizientesten Lösungsalternativen, die den erwünschten und im Fokus stehenden Mehrwert (Impact) für den Endkunden generieren. Der erste Schritt ist die Ermittlung und die Ausformulierung des eigentlichen Geschäftsziels. Dann werden kollaborativ Lösungswege skizziert, indem folgende Fragen nacheinanderbeantwortet werden: Ermittlung der Akteure: Wer kann bei der Erreichung des erwünschten Mehrwerts unterstützen bzw. hinderlich sein? Ermittlung der erwünschten Effekte: Wie soll das Verhalten der ermittelten Akteure beeinflusst werden? Wie können sie uns dabei helfen, die erwünschten Ziele zu erreichen? Ermittlung des Umfangs bzw. der Liefergegenstände: Was kann den erwünschten Effekt generieren? Abb.1: Impact Map User Story Mapping User Story Mapping ist eine von Jeff Patton entwickelte Technik, um User Stories aus einem Produktbacklog zu priorisieren und in Releases zu gruppieren. Ziel ist die Generierung des maximalen Mehrwerts und der maximalen Akzeptanz beim Endanwender (Patton, 2005). Abb. 2: Story Maps Die Aktivität findet in sogenannten Story Mapping Workshops statt, zu denen alle notwendigen Experten eingeladen werden (Fachbereich, Tester, Entwickler, Architekten). In einem ersten Schritt werden die User Stories auf kleinen Karten erfasst, die nur wenige Grundinformationen beinhalten: Kurze Beschreibung der Story, zugehörige Anwenderrolle, Frequenz der Nutzung und Kritikalität. Danach werden die User Stories auf einer großen Wand nach Prozessschrittreihenfolge und Wichtigkeit für den Anwender sortiert. Wichtig für den Erfolg ist die Diskussion zwischen den Teilnehmern, die motiviert werden sollen, Fragen zu stellen und ein gemeinsames Verständnis zu schaffen. In einem abschließenden Schritt sollen horizontale Scheiben aus der entstandenen Story Landkarte identifiziertwerden. Diese Scheiben beinhalten Stories, die kritisch sind und mehrere Benutzungsbereiche abdecken. Sie bieten dadurch einen zusammenhängenden Satz an Funktionalitäten für den Endanwender und eignen sich deswegen als Releases.

3 Specification By Example genauso wichtige Voraussetzung, die durch geeignete Specification By Example (SBE) wurde durch Gojko Adzic auf der Basis von anderen Konzepten wie Behaviour Driven Development (BDD) und Acceptance Test Driven Development (ATDD) entwickelt (Adzic, 2011). SBE definiert eine Reihe von Patterns mit dem Ziel, Verständnisprobleme bei der Spezifikation von gewünschten Änderungen so früh wie möglich zu erkennen und zu vermeiden. Maßnahmen wie Transparenz erfüllt werden kann. Deswegen muss viel in die Teambildung investiert werden. Qualität muss darüber hinaus Teamverantwortung sein. Sie kann nicht vorgeschrieben werden. Exploratory Testing James Bach definiert Exploratory Testing wie folgt (Bach, 2003): Exploratory Testing ist simultanes Lernen, Testdesign und -ausführung. Es ist eine wichtige Testdisziplin mit dem Ziel, die Grenzen des Systems zu erkunden. Sie lebt von der Kreativität und den Talenten des Testers und kann deswegen per Definition nicht automatisiert werden. Sie stellt aber eine notwendige Ergänzung zur Testautomatisierung dar. Die Voraussetzungen 1. Agile Prinzipien Agile Prinzipien und Werkzeuge sind die Rahmenbedingungen für die erfolgreiche Umsetzung der vorgestellten Methoden & Techniken. Dazu gehören vor allem: kurze Entwicklungszyklen: Um ein schnelles Feedback über den aktuellen Stand der Implementierung zu erhalten und schnell auf Änderungen der Anforderungen reagieren zu können regelmäßige Kommunikation zwischen den Beteiligten sinnvolle und von allen Beteiligten abgesegnete Definitions Of Done, die auch eingehalten werden Akzeptanz und Bereitschaft für Änderungen 2. Das Team Der Mensch steht nicht ohne Grund im Zentrum der agilen Philosophie. Teammitglieder sind der eigentliche Garant für den Erfolg. Sie müssen engagiert und motiviert sein und sie müssen natürlich über die notwendigen Skills verfügen. Das Interesse am Erfolg ist eine weitere und mindestens Agile Quality LifeCycle: Unser Lösungskonzept Unsere Erfahrungen haben gezeigt, dass die erwünschten Ziele am besten durch die richtige Mischung der vorgestellten Techniken und Methoden und deren sinnvolle Integration in den zugrundeliegenden Entwicklungsprozess erreicht werden. Plan Implement Specification Workshop Refine Story Business Expert Automate test examples Product Owner Impact Analysis Planning ATDD Finalize Product Develop Acceptance Test Driven Development UTDD Unit Test Driven Development Enduser Living Documentation Tester Observe & Learn Continuous Validation Review Developer Das Modell Die rechts dargestellte Abbildung zeigt eine ausgereifte Scrum-Implementierung, die wir in unseren Projekten entwickelt haben und ständig optimieren und anpassen. Sie vereint alle hier zuvor aufgezeigten Techniken und Methoden und bildet diese zu den geeigneten Phasen und Rollen ab. Deutlich erkennbar ist die Verzahnung der Planungsaktivitäten (im linken Kreis) mit der Implementierung der erwünschten Änderungen (im rechten Kreis). Das gilt nicht nur für die behandelten Artefakte, sondern auch für die Einbindung der verschiedenen Experten in den meisten Phasen. So sind Entwickler und Tester in die Planung und der Product Owner beziehungsweise die Business Experten in die Implementierung involviert. Im Folgenden werden die einzelnen Phasen detailliert beschrieben: Impact Analysis (Umfanganalyse) Specification Workshop Planning (planungsmeeting) User Story Lifecycle Continuous Validation (Regelmäßige Validierung) Life Documentation Session Based Testing Go Live! Observe and Learn (Validierung) Go Live! Session Based Testing Abb. 3: Der Agile Quality LifeCycle Impact Analysis (Umfanganalyse) Jede Arbeitsminute, die für die Entwicklung einer für den Endanwender ungeeigneten oder unerwünschten Funktionalität investiert wurde, ist verlorene Zeit. Dies gilt sowohl für die Spezifikation als auch für die Umsetzung der betroffenen Änderungen. Deswegen muss die Ausarbeitung des optimalen Produktumfangs sehr gut durchdacht und umgesetzt werden. Auf der anderen Seite muss die Spezifikation so leichtgewichtig sein, dass sie eine schnelle Umsetzung und Auslieferung des Produkts ermöglicht. Monate- oder gar jahrelange Analysen und Untersuchungen sind weder tragbar noch zeitgemäß. Ein gutes Werkzeug zur Entschärfung dieser Problematik sind Impact Maps. Sie fördern die Skizzierung von verschiedenen Lösungsalternativen und bieten eine einfache, aber effiziente Möglichkeit zur Visualisierung der zugrundeliegenden Annahmen sowie der betroffenen Akteure und möglichen Liefergegenstände. Danach werden die ausgearbeiteten Lösungen als User Stories definiert und priorisiert. Hierbei soll die Sicht der Endanwender stets berücksichtigt werden. Eine reine geschäftszielbasierte Priorisierung könnte die Akzeptanz beim Endanwender beeinträchtigen. So kann eine auf den ersten Blick unwichtige Funktionalität ein wichtiges Bindeglied zweier anderer sein und ihr Fehlen könnte die Bedienbarkeit stören. Aus diesem Grund ist es hilfreich, das Gesamtbild (Big Picture) ständig im Auge zu behalten. Dabei können sogenannte User Story Maps helfen, die sowohl den Nutzen für den Anwender als auch die geschäftliche Kritikalität sichtbar machen. Beste Ergebnisse werden hierbei durch die Einbindung aller notwendigen Experten erreicht. Product Manager kennen den Markt und seine Entwicklung. Tester und Fachbereichsexperten kennen die Fachlichkeit. Architekten und Entwickler können gut einschätzen, wie aufwändig die Umsetzung sein kann. Es ist wichtig, darauf zu achten, dass die User Stories zu diesem Zeitpunkt nur grob definiert werden müssen. Ausreichend ist meistens ein Satz pro User Story, in dem Ziel, Rolle(n) und Lösungsidee zusammengefasst sind.

4 Specification Workshop Bevor User Stories für die Umsetzung eingeplant werden, müssen sie um weitere Details angereichert werden. Wichtig dabei sind die Akzeptanzkriterien, die anhand von Schlüsselbeispielen oder -szenarien konkretisiert werden. Diese erweiterten User Stories sollen dann von ausgesuchten Experten mit den notwendigen Skills in zeitbegrenzten Meetings besprochen und bei Bedarf um weitere Details ergänzt werden. In Scrum eignen sich dazu die Anforderungsverfeinerungsmeetings (früher Groomings genannt). Es hat sich bewährt, diese Meetings am Anfang des s vor der Umsetzung durchzuführen. Sollten irgendwelche Punkte unbeantwortet bleiben, dann werden die User Stories zur Klärung aus der Planung entfernt. Planning (planungsmeeting) In diesem Meeting werden, wie in Scrum üblich, die User Stories für den neuen eingeplant und in Tasks aufgeteilt. Wichtig ist im Zusammenhang mit diesem Lösungskonzept die Einplanung von Tasks für die Abstimmung und Automatisierung der bereits spezifizierten Akzeptanztestszenarien und -beispiele. Für jede User Story wird außerdem ein Finalisierungstask angelegt. User Story LifeCycle Es ist wichtig, zu erkennen, dass eine User Story nur dann abgeschlossen ist, wenn alle zugehörigen Tasks fertig sind. Dies gilt sowohl für die eigentliche Implementierung der Änderungen als auch für die Automatisierung der Es hat sich bei uns bewährt, einen letzten Quality-GateTask (Finalisierungstask) anzulegen, in dem ein letztes Review mit dem Product Owner bezüglich des Umfangs sowie der notwendigen Testszenarien und -beispiele und der Art deren Umsetzung (UI, API oder manuell) stattfindet. Für die Spezifikation der Tests orientieren wir uns an Behaviour Driven Development, indem wir eine menschenlesbare Syntax verwenden und die Dokumente zentral zur Verfügung stellen. So werden für das Verständnis der Tests keine besonderen Tools oder technischen Kenntnisse benötigt. Dadurch kann jeder jederzeit erfahren, welche Akzeptanztests zur Abnahme der Story eingesetzt werden. Zur Herstellung eines gemeinsamen Verständnisses innerhalb des Teams sowie zur Förderung des Know-how Austauschs zwischen den Teammitgliedern hat sich das relativ neue Verfahren Feedback-Based Development bewährt (Bouillet & Maucher, 2014). Die Grundidee ist einfach, aber sehr mächtig. Eine Änderung am Produktivoder Testcode darf nur dann ins Code-Repository integriert werden, wenn eine zweite Person sie nach der geltenden Definition Of Done geprüft hat. Die Abnahme der Story findet statt, sobald alle zugehörigen Tasks abgeschlossen wurden. Das erfolgt auch im Rahmen des Finalisierungstasks, indem die Umsetzung bzw. der Fertigstellungsstand der Story zusammen mit dem Product Owner geprüft wird. Zur Abnahme gehört selbstverständlich ein explorativer Test. Implement Specification Workshop Refine Automate test examples Planning ATDD Story Develop Acceptance Test Driven Development Finalize Product UTDD Unit Test Driven Development Abb. 4: User Story LifeCycle Living Documentation Review Continuous Validation (Regelmäßige Validierung) Die im Rahmen der Umsetzung der User Story automatisierten Akzeptanztests haben eine weitere wichtige Rolle: Sie dienen als Regressionstests, die prüfen, ob Änderungen in bereits getesteten Teilen der Software keine neuen Fehler verursachen. Damit dieses Feedback zeitnah erfolgt, werden diese Tests in die zentrale Continuous Integration Umgebung eingebunden. Living Documentation Spezifikationen, die nach dem vorgestellten Muster entstehen, weisen folgende Eigenschaften auf: Sie beschreiben den aktuellen Stand der umgesetzten Features in einer für alle verständlichen Sprache. Sie beinhalten alle abnahmerelevanten Informationen zu den umgesetzten Features einschließlich Akzeptanzkriterien und -tests. Sie werden im Rahmen der Umsetzung von Änderungen aktualisiert beziehungsweise erweitert. Sie werden zentral zur Verfügung gestellt. Sie werden regelmäßig automatisiert geprüft. Continuous Validation für das Scrum Team. Protokolliert werden dabei nur die auftretenden Fehler. Go-Live! Das beste Feedback können Sie nur von echten Endanwendern unter realistischen Bedingungen erhalten. Aus diesem Grund empfiehlt es sich, die Releasezyklen soweit wie möglich zu kürzen. Continuous Delivery ist bereits bei vielen Firmen Realität und bringt enorme Vorteile für die Unternehmen. So können neue Features viel schneller an den Kunden gebracht werden, was einen Marktvorteil bedeutet. Die Kundenbindung wird dadurch ebenfalls erhöht. Observe & Learn (Validierung) Diese Phase spielt eine zentrale Rolle im geschäftlichen Erfolg des Produkts. Denn hier wird der wertvolle Input für die Gestaltung der Zukunft des Produkts aufgebaut. Dazu muss Feedback aus den Erfahrungen der Endanwender mit dem produktiven System gesammelt und ausgewertet werden. Sehr wichtig ist auch die Validierung der während der Impact Analyse getroffenen Annahmen. Fazit Dadurch eignen sich diese Spezifikationen als Dokumentation des Systems, die nachweisbar aktuell und vollständig ist. In Specification By Example wird sie deswegen zurecht als Living Documentation bezeichnet. Session Based Testing Plan mpact Analysis Observe & Learn definierten Tests und die Bereitstellung der benötigten Testdaten und -artefakte. Session Based Testing ist eine Vorgehensweise, die es erlaubt, innerhalb einer kurzen Zeit eine Anwendung ausführlich zu testen. Die Idee ist genauso einfach wie effizient. Sie schreibt vor, dass sich das gesamte Team für einen festen Zeitraum (Timebox), am besten ein oder zwei Tage vor ende, zusammensetzt und einen aktuellen Stand der Anwendung gleichzeitig explorativ testet. Bewährt hat sich bei uns eine Timebox von 2 Stunden für einen zweiwöchigen. Teilnehmen kann grundsätzlich jede interessierte Person. Verpflichtend ist es vor allem Durch die geeignete Mischung aus den vorgestellten Methoden und ihre durchdachte Integration in den Entwicklungszyklus entstand eine Scrum-Implementierung, die Entwicklungsteams dabei unterstützt, die richtigen Features mit dem erhofften Mehrwert für die Stakeholder effizient und möglichst ohne Falschentwicklungen umzusetzen. Diese Implementierung zielt auf die frühzeitige Herstellung eines gemeinsamen Verständnisses der Ziele und Anforderungen ab und lebt aus diesem Grund von einer sinnvollen Kommunikation zwischen allen Experten und ihrer frühzeitigen Einbindung in den Entwicklungsprozess. Wichtige Voraussetzungen für den Erfolg sind aber grundsätzlich Disziplin, Mut zum Neuen und die ständige Lernbereitschaft. Denn alle Praktiken müssen von allen Beteiligten angewandt und regelmäßig geprüft und bei Bedarf angepasst werden. Dann steht dem Ziel nichts mehr im Wege, Endanwender und Stakeholder zufrieden zu stellen!

5 Über den Autor: Anis Ben Hamidene Anis Ben Hamidene ist Senior Managing Consultant und Competence Area Manager in der NovaTec Consulting GmbH. Er beschäftigt sich seit über 12 Jahren vornehmlich mit den Themen JEE-Architektur sowie Agile Quality Engineering (AQE) in den Branchen egovernment, Versicherungen und Automotive. Anis Ben Hamidene ist zudem als Coach und Trainer in den Themen Agile Testing, Specification By Example bzw. Agile Requirement Engineering tätig. Web: aqe.novatec-gmbh.de Literaturverzeichnis Adzic, G., Specification By Example - How Successful Teams Deliver The Right Software. s.l., Manning Adzic, G., Impact Mapping: Making a big impact with software products and projects. s.l.: Provoking Thoughts Bach, J., Exploratory Testing Explained. [Online], Available at: Bouillet, P. & Maucher, D., Feedback-Based Development. OBJEKTSpektrum, Band 1. Hendrickson, E., Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing. s.l., Pragmatic Bookshelf Patton, J., It s All in How You Slice It. Better Software Magazin NovaTec Consulting GmbH NovaTec ist ein inhabergeführtes, unabhängiges IT Unternehmen, das Kunden verschiedenster Branchen bei der erfolgreichen Durchführung von Vorhaben im IT Umfeld unterstützt. Seit 1996 stehen wir für Innovation, Kundenorientierung und Projekterfolg. Zentrale Dieselstraße 18/1 D Leinfelden-Echterdingen Tel.: Mail: info@novatec-gmbh.de Web: Niederlassung Berlin Potsdamer Platz Berlin Niederlassung Frankfurt am Main Friedrich-Ebert-Anlage Frankfurt am Main Niederlassung München Landshuter Allee München Sämtliche Bilder, Marken und Texte dürfen nur mit ausdrücklicher Genehmigung des jeweiligen Rechteinhabers verwendet werden. Version 1.4 (Juli 2015)