Suche
Agiles Anforderungsmanagement mit Impact Mapping

Software that matters

Nils Wloka
©iStockfoto.com/santi0103

In den letzten Jahren ist viel Energie in die Aufgabe investiert worden, die Effizienz von Softwareentwicklungsteams zu steigern. Bessere Werkzeuge und Praktiken lagen im Fokus unserer Bemühungen. Die Herausforderung ist nun, unser Wissen und Können so einzusetzen, dass nachhaltig erfolgreiche Software – „Software that matters“ – entstehen kann: Auf Effizienz muss Effektivität folgen.

Softwareentwicklung ist eine in vieler Hinsicht ungewöhnliche Disziplin. Um zu verstehen, warum neue Methoden des Anforderungsmanagements – oder gar ein neuer Anforderungsbegriff – nötig sind, sollten wir zunächst den Blick auf einige Besonderheiten unseres Handwerks richten.

Software und Komplexität

Wikipedia beschreibt Ingenieure als Menschen, die sich damit beschäftigen, „naturwissenschaftliche Erkenntnisse zum praktischen Nutzen der Menschheit [anzuwenden]“. In seinem Fachgebiet löst der Ingenieur neue Probleme, indem er auf Forschungsergebnisse, aber auch auf übermitteltes Wissen, bewährte Methoden und vorhandene Lösungskomponenten zurückgreift. In dem Objekt seiner Tätigkeit ist er in der Regel durch die Grenzen seines Fachgebiets, in der Wahl seiner Lösungsstrategien durch Naturgesetze eingeschränkt. Betrachten wir die Disziplin der Softwareentwicklung, fallen mehrere Unterschiede auf. Ein Blick auf die unterschiedlichen Anforderungen, die an Softwareentwickler herangetragen werden, macht das deutlich:

• Mache alles Wissen der Welt frei verfügbar
• Versetze einen PKW in die Lage, selbstständig einzuparken
• Vertreibe meine Langeweile
• Hilf mir bei der Genehmigung von Urlaubsanträgen

Eine fachlich-inhaltliche Spezialisierung findet häufig nicht statt und ist in Anbetracht des ständig wachsenden Problemraums möglicherweise auch nicht realisierbar. In der Praxis bedeutet das, regelmäßig mit unbekannten Problemdomänen konfrontiert zu werden. Auf der anderen Seite unterliegt Software nahezu keinen Naturgesetzen. Konstante Rahmenbedingungen und Einschränkungen, die uns bei der Suche nach einer Lösung als Leitplanken dienen könnten, gibt es nicht. Diese Kombination aus unbekanntem Problem und beliebiger Lösung führt dazu, dass wir als Softwareentwickler häufig mit Komplexität konfrontiert werden: Wirkungszusammenhänge sind nicht a priori identifizierbar, reproduzierbare Lösungswege oder gar Musterlösungen nicht verfügbar. In Anbetracht dieser Konstellation haben sich in den vergangenen Jahren Verhaltensstrategien entwickelt, die heute gerne unter dem Schlagwort „agile Softwareentwicklung“ zusammengefasst werden.

Agilität als Handlungsstrategie für die komplexe Domäne

Agile Softwareentwicklung ist ein zunehmend mit Bedeutung überfrachteter Begriff. Ausgehend von dem Manifest für agile Softwareentwicklung setzt wohl jeder Praktizierende seine eigenen Schwerpunkte. Im Kontext dieses Artikels und der Auseinandersetzung mit Verfahren für Anforderunganalyse und Anforderungsmanagement ist dieser Schwerpunkt für mich der Umgang mit komplexen Problemstellungen. Wenn wir akzeptieren, dass die ideale, oder auch nur eine beliebige, aber effektive Lösung unserer Probleme nicht auf dem Reißbrett planbar ist, bleibt uns als Alternative letztlich nur eine Handlungsstrategie, die auf die Überprüfung von Annahmen ausgerichtet ist. Mit Prinzipien wie „Working Software“, „Responding to Change“ und kontinuierlicher Reflexion schafft die agile Softwareentwicklung aus meiner Sicht diesen Handlungsrahmen – wenn man sie lässt. In der Realität der Softwareentwicklungsprojekte dominiert dennoch eine von dem Wunsch nach Planbarkeit und Garantien getriebene Form der Projektinitialisierung: An erster Stelle, letztlich sogar im verwendeten Begriff des „Projekts“ verankert, steht die Abgrenzung von Inhalten, die Festlegung so genannter Anforderungen. „Agile“ Projekte zeichnen sich häufig nur dadurch aus, dass das Change-Request-Verfahren leichtgewichtiger ist und der Beobachtung Rechnung trägt, dass wir uns bei der Formulierung der Anforderungen geirrt haben könnten. „Agile“ Projekte verzichten vielleicht auf die Ausformulierung aller Anforderungsdetails. Dennoch liegt häufig der Fokus darauf, einen sich geringfügig verändernden Satz von Anforderungen – üblicherweise Funktionsbausteine des zu erstellenden Systems – so effizient wie möglich herzustellen. Hier ist meiner Meinung nach ein Paradigmenwechsel nötig: Ich glaube, dass wir uns insbesondere hinsichtlich komplexer Probleme von diesem Anforderungsbegriff lösen müssen. Das Bedürfnis nach Planbarkeit und Fortschrittskontrolle ist verständlich, muss aber in solchen Fällen mit der Erkenntnis übereingebracht werden, dass wir in Bezug auf Softwarelösungen weitestgehend mit Annahmen arbeiten.

Agile Anforderungsanalyse mit Impact Mapping

Auf der Suche nach einem Anforderungsanalyseverfahren, das unter diesen Rahmenbedingungen bestehen kann, bin ich 2011 über ein Papier von Gojko Adzic mit dem Titel „Agile Product Management using Effect Maps“ gestoßen. Die darin beschriebene Methode, die heute unter dem Namen Impact Mapping bekannt ist, hat das Potenzial, den scheinbaren Widerspruch zwischen Plan und Unsicherheit auf elegante Weise aufzulösen. Wie Impact Mapping funktioniert, möchte ich am Beispiel eines fiktiven Softwareentwicklungsvorhabens (Kasten „Beispiel: Die Ausgangssituation“) erläutern.

Beispiel: Die Ausgangssituation
Stellen Sie sich ein Telekommunikationsunternehmen vor, das sich durch seine herausragende Kundenbetreuung von seinen Marktbegleitern differenziert. Als Verantwortlicher für den Kundendienst beauftragen Sie unter anderem ein externes Callcenter mit der Abwicklung des First-Level-Supports. Die nachweislich hohe Servicequalität schlägt sich auch in entsprechend hohen jährlichen Kosten nieder. Im Zuge allgemeiner Budgetkürzungen muss auch Ihre Abteilung sparen. Es entsteht die Idee, ein Serviceportal zu implementieren, durch das Teile der Anrufe im Callcenter vermieden werden können. Hier beginnt unsere Geschichte.

Zuvor jedoch noch einige generelle Worte zur Anwendbarkeit des Verfahrens: Impact Mapping – wie auch agile Softwareentwicklung im Allgemeinen – eignet sich meiner Meinung nach insbesondere zum Navigieren in komplexen Problemdomänen. Es ist nicht ausgeschlossen, dass man Wartungsarbeiten, vorgegebene Spezifikationen oder triviale Probleme als Impact Map abbilden kann – der Nutzen hingegen ist fraglich. In „Estimating Complexity“ geht Liz Keogh auf dieses Thema ausführlicher ein. Auch ist Impact Mapping inklusiv: Es erlaubt nicht nur, sondern erfordert aus meiner Sicht die Mitwirkung aller am Softwareentwicklungsvorhaben beteiligten Rollen. Die besten Ergebnisse lassen sich erzielen, wenn alle, die Wissen über das Problem oder zu potenziellen Lösungen beitragen können, gemeinsam an der Impact Map arbeiten. Sind diese Rahmenbedingungen gegeben, können wir mit der Erstellung unserer Impact Map beginnen.

Im Zentrum steht das „Warum?“

Wenn Impact Mapping ein Verfahren sein soll, das uns dabei hilft, effektive – also wirksame – Software zu erstellen, dann muss am Anfang die Frage nach dem Ziel stehen. In einem initialen Workshop identifizieren wir zunächst den gewünschten Nutzen. In der Regel hat die Antwort auf die in dieser Phase gestellte Warum-Frage einen direkten Bezug zum Daseinszweck der Organisation. Im Fall eines Unternehmens wird das Erreichen des Ziels häufig eine direkte Auswirkung auf Kosten oder Einnahmen haben. Ist dieser Zusammenhang nicht ersichtlich, kommen Werkzeuge zur Ursachenanalyse zum Einsatz (beispielsweise „Five Whys“). Eine gute Antwort bezieht sich direkt auf Unternehmensziele, ist aber noch konkret genug, um operationalisierbar zu sein. Das führt uns zum zweiten Schritt, der Quantifizierung des Ziels. Soll die Impact Map der Fortschrittskontrolle und der Projektsteuerung dienen, brauchen wir einen verlässlichen Indikator für die Wirksamkeit der entstehenden Software. Zugleich trägt die Auseinandersetzung mit möglichen Messgrößen zum Verständnis der Problemdomäne bei. Der erste Schritt zur Impact Map ist erfolgreich getan, wenn wir eine Antwort auf die Frage „Warum sollten wir in Software investieren?“ haben und messen können, ob das Ziel unserer Investition erreicht ist. Als Plausibilitätsprüfung schlägt Gojko Adzic vor, dass wir uns die Frage stellen, ob wir erfolgreich waren, wenn wir die Zielwerte hinsichtlich der identifizierten Metriken erreicht haben, unabhängig davon, welchen Funktionsumfang die realisierte Software zu diesem Zeitpunkt hat (siehe dazu Adzic: Impact Mapping, S. 44-45). Nur wenn wir mit „Ja“ antworten können, haben wir das eigentliche Projektziel identifiziert.

Beispiel: Warum
Im unserem fiktiven Beispiel lässt sich das Ziel wie folgt formulieren:
• Reduzierung der Callcenterkosten für den First-Level-Support um 100 000 Euro pro Jahr (gemessen und hochgerechnet aus den monatlichen Rechnungen)
Wie jede Metrik kann auch diese missbraucht werden. Um dieser Gefahr vorzubeugen und eindeutiger zu kommunizieren, ergänzen wir: • Bei gleichbleibender Kundenzufriedenheit (laut monatlicher Kundenbefragung)
• Ohne Erhöhung der Arbeitslast im Second-Level-Support (in diesem Fall gemessen an der Anzahl schlecht qualifizierter Supportanfragen)
Ein formaleres Modell für diese Art von Metriken bietet zum Beispiel Tom Gilbs Planguage.

[ header = Seite 2: Wer spielt eine Rolle? ]

Wer spielt eine Rolle?

Steht unsere Antwort auf die Warum-Frage fest, widmen wir uns der nächsten Ebene der Impact Map. Um ein möglichst detailliertes Bild von denjenigen zu erhalten, die mit der zukünftigen Software zu tun haben, stellen wir Wer-Fragen in unterschiedlichen Ausprägungen, zum Beispiel:

• Wer kann uns helfen, unser Ziel zu erreichen?
• Wer kann uns daran hindern?
• Wer kann von der Software profitieren?

Um möglichst viele Ansatzpunkte für die folgende Ebene der Impact Map zu erhalten, ist es sinnvoll, hier konkret zu werden. Gojko Adzic empfiehlt, vom Spezifischen zum Allgemeinen vorzugehen: Falls relevant, beginnen wir mit einzelnen Personen. Es folgen Personae, Rollen und Gruppen. Je mehr wir über diese Akteure wissen, desto leichter werden uns die nächsten Schritte des Impact Mappings fallen (Kasten: „Beispiel: Wer“). Letztlich können in dieser Phase alle Methoden der Stakeholder-Analyse zum Einsatz kommen. Gute Erfahrungen habe ich mit dem auch im User Experience Design verwendeten Werkzeug der „Empathy Map“ gemacht.

Beispiel: Wer
Mittels einer Analyse der vom Callcenter bereitgestellten Unterlagen sowie in Diskussionen mit dem Supportpersonal haben wir die folgenden vielversprechenden Akteure identifiziert:
• Endkunden, die von einer Flächenstörung betroffen sind
• Endkunden, die bereits eine Störung gemeldet haben
• Großkunden, die über eigenes technisches Personal verfügen
Im Laufe des Impact Mappings ist es durchaus möglich und üblich, diese Liste zu ergänzen. In vielen Fällen werden erst durch die folgenden Ebenen der Impact Map die Unterschiede zwischen Zielgruppen deutlich: Im gegebenen Fall könnte es sein, dass wir über den Umweg „Endkunden (Wer) rufen nicht mehr im Callcenter an, wenn sie von einer Flächenstörung betroffen sind (Wie)“ auf die Persona „Endkunden, die von einer Flächenstörung betroffen sind“ stoßen. Diese Konkretisierung erlaubt es uns, ein besseres Bild unserer Zielgruppe und damit eine bessere Vorstellung möglicher Lösungen zu erlangen.

Einen Eindruck hinterlassen

Die nächste Ebene der Impact Map gibt dem Verfahren seinen Namen: Sie zeigt, welchen Eindruck die Software hinterlassen soll. Für jeden identifizierten Akteur stellen wir die Frage „Wie soll sich das Verhalten ändern?“. Wichtig sind an dieser Stelle Verhaltens- und Denkweisen, die hinsichtlich unseres Projektziels relevant sind. Wir begeben uns hier ausdrücklich noch nicht in den Lösungsraum. „Der Benutzer soll das Anmeldeformular ausfüllen“ hat auf dieser Ebene der Impact Map nichts zu suchen. Einfacher wird dieser Schritt, wenn wir die Betonung auf die Veränderung im Verhalten des entsprechenden Akteurs legen. Im Idealfall ergibt die Aneinanderreihung von Akteur und Verhaltensänderung einen ganzen Satz (Kasten: „Beispiel: Wie“). Um die Wirksamkeit unserer Software messen oder zumindest abschätzen zu können, quantifizieren wir auf dieser Ebene der Impact Map erneut. Häufig können wir sinnvolle Messgrößen direkt vom übergeordneten Projektziel ableiten. Mit dieser und der vorherigen Ebene der Impact Map verbringen wir in unseren Workshops die meiste Zeit. Hier finden die wichtigsten Diskussionen statt und hier lernen wir am meisten über unsere Problemdomäne. Wenn wir die initiale Impact Map in mehreren Sitzungen erstellen, ist es sinnvoll, die Fragen nach dem „Wer“ und dem „Wie“ zusammen zu beantworten. Häufig verändert sich mit dem Identifizieren wünschenswerter Effekte auch unser Bild von den Akteuren (vergleiche Kasten: „Beispiel: Wer“).

Beispiel: Wie
In unserem Beispiel haben wir für die verschiedenen Zielgruppen jeweils eine Verhaltensänderung (und die entsprechende Messgröße) identifiziert, die eine positive Auswirkung auf unser Projektziel hat:
1. Endkunden, die von einer Flächenstörung betroffen sind, melden diese nicht mehr im Callcenter (Reduzierung der entsprechenden Anrufe laut Callcenterstatistik um 90 Prozent)
2. Endkunden, die bereits eine Störung gemeldet haben, rufen nicht mehr im Callcenter an, um den Bearbeitungsstatus zu erfragen (Reduzierung der Folgeanrufe laut Callcenterstatistik um 90 Prozent)
3. Großkunden, die über eigenes technisches Personal verfügen, veranlassen notwendige Entstörungsmaßnahmen selbstständig (Reduzierung der Anrufe, in deren Folge eine Entstörung ausgelöst wird, um 60 Prozent)
Zur Quantifizierung können wir dieselben Modelle verwenden, die auch schon auf der Warum-Ebene zum Einsatz kamen.

Die Lösungen kommen zum Schluss

Erst wenn wir den Problemraum auf diese Weise beleuchtet haben – eventuell sogar in einer eigenen Sitzung – widmen wir uns dem Teil der Impact Map, der dem herkömmlichen Anforderungsbegriff am nächsten kommt. Die vierte Ebene unserer Landkarte beantwortet die Frage „Was können wir als ausführende Organisation tun, um diese Verhaltensänderungen zu begünstigen oder zu ermöglichen?“. Wenn wir hier Softwarefeatures, aber auch sonstige Aktivitäten aufzählen, dann sind wir uns der Tatsache bewusst, dass ihre Wirksamkeit hinsichtlich der oberen Ebenen der Impact Map auf Annahmen basieren. Entsprechend streben wir während der Entwicklung nicht danach, alle „Blätter“ der Impact Map vollständig zu implementieren. Ganz im Gegenteil geht es darum, durch gezielte Experimente unsere Annahmen zu überprüfen und auf diesem Wege mit möglichst geringem Aufwand das auf der ersten Ebene formulierte Ziel zu erreichen. Ebenso ist es während des Impact Mapping noch nicht nötig, bereits ins Lösungsdesign beziehungsweise in die Spezifikation abzusteigen. Andernfalls bestünde die Gefahr, Zeit in die Ausgestaltung von Funktionen zu investieren, die am Ende niemals ihren Weg in die Entwicklung finden. Ziel ist es, genug Informationen festzuhalten, um eine sinnvolle Priorisierung zu ermöglichen.

Abb. 1: Beispiel für die gesamte Impact Map

Das Ergebnis der bisherigen Schritte ist die initiale Version einer Impact Map für ein Softwareentwicklungsvorhaben (Abb. 1). Sie beinhaltet – ähnlich dem Product Backlog im Scrum – mögliche Funktionen. Wichtiger aber: Durch die Visualisierung der Zusammenhänge zwischen Features, Projektzielen und Metriken kommuniziert sie unsere Hypothesen auf allen Ebenen der Wirkungszusammenhänge. Die Kante zwischen „Was“ und „Wie“ spiegelt die Annahme wider, dass eine bestimmte Funktion eine bestimmte Wirkung entfalten wird, wenn sie in Betrieb genommen wird. Die Kante zwischen „Wer“ und „Warum“ spiegelt unsere Annahmen hinsichtlich der Stakeholder in unserem Projekt wider.

Die Tatsache, dass jedem Projektbeteiligten nun das Gesamtbild zur Verfügung steht, bietet in der Praxis schon einen erheblichen Vorteil gegenüber herkömmlichen Anforderungsdokumentationen. Zum Beispiel können Entwickler all ihre Lösungskompetenz nutzen und alternative Funktionen vorschlagen, wenn sie wissen, welche Auswirkung angestrebt wird. Kennen sie die Annahmen, die hinter einem „Was“ stecken, fällt es ihnen leichter, die einfachste Version eines Features zu implementieren, die noch geeignet ist, diese Annahmen zu überprüfen: Echte iterative Entwicklung wird möglich.

Im Sinne von „Software that matters“ stellt die Impact Map ein hervorragendes Steuerungsinstrument dar. Lag der Fokus bisher darauf, etwa im Sprint Review zu überprüfen, ob ein Feature den Akzeptanzkriterien genügt („build it right“), so können wir nun überprüfen, ob das Feature wirksam im Sinne unserer Ziele ist („build the right thing“). Je nach Ausgang unserer Experimente können wir die Entwicklungsbemühungen in einem Zweig der Impact Map verstärken, ganze Bereiche entfernen, wenn die Annahmen, auf denen sie beruhen, nicht länger haltbar sind oder die Entwicklungstätigkeiten in genau dem Moment einstellen, in dem wir das Projektziel erreicht haben. Das Kernprinzip agiler Methoden, „inspect and adapt“, bleibt nicht länger auf unseren Arbeitsprozess beschränkt, sondern steuert den Inhalt unserer Entwicklungstätigkeiten. Jede Iteration bringt uns nun tatsächlich gezielt entweder der Lösung oder dem Verständnis des Problems einen Schritt näher – um es mit den Worten von Gojko Adzic zu sagen: „Earn or learn“ (siehe dazu S. 37).

Geschrieben von
Nils Wloka
Nils Wloka
Nils Wloka arbeitet als Berater, Coach und Trainer mit den Schwerpunkten „Agile Methoden“ und „Software Craftsmanship“ bei der codecentric AG. In diesen Rollen begleitet er dort Kunden und Entwicklungsteams auf ihrem Weg zu effizienter und effektiver Softwareentwicklung.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.