Die Standish Group, die seit 1985 weltweit Projekte auswertet, stellt in ihrem jährlich erscheinenden Chaos Manifesto fest, dass 2012 nur 39% aller Entwicklungsprojekte erfolgreich abgeschlossen wurden. In den Jahren davor war die Anzahl der erfolgreichen Projekte noch geringer. Die Auswertung der erfolgreichen Projekte hat ergeben, dass direkte Anwenderbeteiligung, die Einführung von agilen Prozessen und die Nutzung von User Stories als Kommunikationsmittel und Anforderungs-Items einen maßgeblichen Anteil für den Erfolg hatten [StG13].

Agile Frameworks verändern das Requirements Engineering nachhaltig. Während in dokumentengetriebenen oder in phasenorientierten Vorgehensmodellen schriftlich verfasste Spezifikationen einen hohen Stellenwert aufweisen, konzentriert sich im agilen Umfeld die Arbeit an und mit den Anforderungen i. d. R auf User Stories nach dem Konzept von Mike Cohn [Coh10] oder Use Cases 2.0 nach Ivar Jacobson [JSB11]. Mit beiden Ansätzen kann den Prinzipien des Agile Manifest gerecht zu werden, das eine direkte Kommunikation von Angesicht zu Angesicht als effizienteste und effektivste Art der Zusammenarbeit fordert [AMa01].

Für zahlreiche Entwicklungsteams ist es nicht ausreichend, wenn der PO seine User Stories erstmalig im Sprint Planning Event vorstellt und diese im unmittelbar anstehenden Sprint umgesetzt werden müssen. Häufig treten noch Fragestellungen auf, die weder der PO noch Mitglieder des Entwicklungsteams beantworten können. Aus diesem Grunde haben viele Scrum-Teams ihr Framework um ein weiteres Event erweitert und nennen es Story Time, Backlog Refinement oder Grooming Meeting. In diesem Event werden User Stories durch den Product Owner vorgestellt und Akzeptanzkriterien besprochen, um ein gemeinsames Verständnis sicherzustellen und gleichzeitig die Schätzung der Stories durchzuführen. Dabei werden nur User Stories besprochen, die in den unmittelbar anstehenden 1-2 folgenden Sprints umgesetzt werden sollen oder für die der Product Owner eine Einschätzung des Aufwands von seinem Entwicklungsteam für eine User Story oder ein Epic möchte, um eine weitere Entscheidungsgrundlage für die Eingruppierung im Backlog zu erhalten. Der Product Owner nutzt diesen Event um das Entwicklungsteam frühzeitig einzubinden und die vorhandenen Team-Kompetenzen zu nutzen.

Ich bin immer wieder überrascht, wie schnell die Frage nach Tools gestellt wird, wenn über Requirements Engineering, Produktentwicklung oder über erfolgreiche Projekte diskutiert wird. Der spezifische Einsatz von Tools hat nach Auswertung der Standish Group in keinem ihrer erfolgreich ausgewerteten Projekte entscheidend für den Projekterfolg beigetragen. Der Einsatz von Tools zum Projekterfolg wird häufig überbewertet, denn Know-how, direkte Kommunikation und Managementunterstützung sind für den Projekterfolg wesentlich ausschlaggebender [StG13].

Trotzdem ist ein Tooleinsatz für das Backlog-Refinement in vielen Entwicklungsprojekten sinnvoll, wenn dadurch die direkte Kommunikation nicht beeinträchtigt wird. So ist es beispielsweise in regulierten Umfeldern zwingend erforderlich, die Anforderungen nachverfolgbar zu halten. Es muss z. B. für eine Zertifizierungsorganisation nachvollzogen werden können, wer die Anforderungen gestellt hat und wie deren Umsetzungsweg war, um eine Marktzulassung (z. B. für Medizinprodukte) zu erhalten. Darüber hinaus lassen sich Anforderungen versionieren, gruppieren oder suchen und mit weiteren Attributen (z. B. Quelle der Anforderung) ergänzen und wenn nötig eine Traceability von der Anforderungsquelle bis zur Codeumsetzung sicherstellen.

Diese Maßnahmen haben aber keinen Selbstzweck, sondern sie sind nur durchzuführen, wenn sie einen tatsächlichen Mehrwert für die Entwicklungsorganisation darstellen. Für kleine Unternehmen, die für einen Kunden ein Produkt mit einem Entwicklungsteam umsetzen, kann es durchaus ausreichend sein, ausschließlich Karteikarten für die Anforderungen zu verwenden und damit eine Backlog Refinement durchzuführen.

Zusammenfassend kann man die Aufgabe eines Requirements Engineers oder Product Owners auch folgendermaßen ausdrücken: Anforderungen sind in einer angemessenen Detailierung, zum benötigten Zeitpunkt und für die zu erwartenden Beteiligten verständlich darzustellen. Um dies sicherzustellen lassen sich RE-Aktivitäten im Scrum-Framework an zahlreichen Stellen identifizieren. Die Anwendung findet im Gegensatz zu einem phasen- oder dokumentengetriebenen Entwicklungsansatz aber kontinuierlich während der gesamten Entwicklungszeit statt. Die Kommunikation zwischen Fachseite und Entwicklern muss im Mittelpunkt stehen und reine Übergaben von Dokumenten sind zu vermeiden. Zudem werden die zu erstellenden Artefakte nur so umfassend wie nötig und parallel zur Entwicklung oder unmittelbar vor der Umsetzung erstellt. Die Aktivitäten des Requirements Engineerings sollten niemals als Selbstzweck durchgeführt werden, sondern einen deutlichen Mehrwert bieten, um die Bedürfnisse und Ziele der Kunden erfolgreich im Produkte oder Systems umzusetzen.

[AMa01]
„Prinzipien hinter dem Agilen Manifest“, 2001, siehe
http://agilemanifesto.org/iso/de/principles.html

[Coh10]
“User Stories: für die agile Software-Entwicklung mit Scrum, XP”, Mike Cohn,
mitp, 2010

[SS13]
“The Definitive Guide to Scrum: The Rules of the Game”, Ken Schwaber, Jeff
Sutherland, Juli 2013, scrum.org

[StG13]
„CHAOS MANIFESTO 2013 - Think Big, Act Small”, The Standish Group International, 2013, Boston

[JSB11]
“Use-Case 2.0”, Ivar Jacobson, Ian Spence, Kurt Bittner, 2011, siehe http://www.ivarjacobson.com/Use_Case2.0_ebook

zur Ausgabe