Im vierten Teil der Blogserie beschreiben wir zwei „agile Zwischenstufen“ im Kontinuum vom wasserfallartigen zum vollkommen agilen Prozess. Beide Varianten ermöglichen im Vergleich zum hybriden Prozess höhere Flexibilität und mehr Spielraum zum Experimentieren, erfordern aber auch mehr Einsatz von den Beteiligten.
In beiden Varianten wird mit zwei Teams gearbeitet:
– dem Product Owner oder Product Owner-Team, das den Kontakt zu Stakeholdern aufbaut und pflegt, die Weiterentwicklung der Produktvision zum fertigen Produkt kontrolliert und darauf achtet, für den Auftraggeber den höchstmöglichen Return of Investment (ROI) zu erzielen, und
– dem Developer Team, das für die Realisierung des Produktes verantwortlich ist.
Traditionelle Spezifikationen wie das Lastenheft und das Pflichtenheft dienen weiterhin als Vertragsgrundlage, während für die Entwicklungssprints ein Product Backlog und Sprint Backlogs verwendet werden. Sowohl in der Entwicklung als auch im Requirements Engineering wird iterativ-inkrementell gearbeitet. Die Spezifikationssprints und die Entwicklungssprints werden dabei zeitlich passend aufeinander abgestimmt.
In der initialen Phase, dem „Sprint 0“ des Projektes, wird das zu erstellende Produkt oder System nicht vollständig spezifiziert, sondern ein gemeinsames Verständnis des Systems und der Zielsetzung des Projekts erzeugt: die Produktvision, die nur in sehr groben Anforderungen beschrieben wird. Verfeinerung und Ergänzung der Anforderungen erfolgen dann während der Projektlaufzeit.
Variante 1 – Trennung von Requirements Engineering und Entwicklung
In Variante 1 ist das Product Owner-Team für das komplette Requirements Engineering verantwortlich. Es übernimmt die gesamte Interaktion mit den Stakeholdern und erstellt in Spezifikationssprints das Lastenheft, das Pflichtenheft und das Product Backlog. In einem Auftraggeber-Auftragnehmer-Verhältnis entspricht das Produkt Owner-Team der Auftraggeberseite. Das Developer Team, die Auftragnehmerseite, wird in diesem Szenario zugunsten von höherer Produktivität von Spezifikationsaufgaben befreit.
Für die Inhalte des Pflichtenhefts ist das Product Owner-Team auf Kommunikation mit dem Developer Team angewiesen, da die Umsetzungsvorschläge erst während der Entwicklungssprints entstehen. Diese Kommunikation stellt sicher, dass die Feedbackzyklen kurz sind und neue Erkenntnisse aus der Entwicklung auch für die weitere Spezifikationsarbeit genutzt werden können. Das Entwicklungsteam kann sich ganz auf die Realisierung konzentrieren und hat keinen direkten Kontakt zu den Stakeholdern. Unklare Anforderungen werden mit dem Product Owner-Team geklärt.
Bei dieser Variante ist es wichtig, die Spezifikations- und Entwicklungssprints zeitlich so aufeinander abzustimmen, dass dem Product Owner-Team neben der Kommunikation mit den Stakeholdern und mit dem Developer Team genug Zeit bleibt, um das Product Backlog Items für den folgenden Sprint zu detaillieren und die Ergebnisse aus dem vorangegangenen Sprint zu dokumentieren.
Variante 2 – Geteilte Verantwortung für das Requirements Engineering
Auch in Variante 2 trägt das Product Owner-Team die Verantwortung für alle Auftraggeber- Artefakte im Projekt – das Lastenheft und das Product Backlog. Das Pflichtenheft wird parallel zur Entwicklung von der Auftragnehmerseite, dem Developer Team, spezifiziert und detailliert.
Zwischen den Stakeholdern und dem Developer Team besteht weiterhin kein direkter Kontakt. Unklare Anforderungen werden mit dem Product Owner-Team geklärt, so dass für das Developer Team kein gesonderter Aufwand z. B. für Anforderungskonsolidierung anfällt. Dennoch können sich die zusätzlichen Dokumentationsaufgaben nachteilig auf die Geschwindigkeit der Entwicklung auswirken.
Neben der zeitlichen Abstimmung zwischen den Spezifikations- und Entwicklungssprints ist zur Pflege der Traceability zwischen Lastenheft und Pflichtenheft und zur optimalen Nutzung von Erkenntnissen aus der Entwicklung für die Spezifikationsarbeit auch in dieser Variante gute Kommunikation zwischen den Teams notwendig.
Im fünften und letzten Teil der Blogserie schließen wir mit dem vollkommen agilen Prozess, der alle Aktivitäten in einem Team bündelt.
———————————————————-
Teil 1: Mehr Agilität wagen! – Teil 1: Grundüberlegungen zur Einführung von Agilität
Teil 2: Mehr Agilität wagen! – Teil 2: Personalfragen
Teil 3: Mehr Agilität wagen! – Teil 3: Wasserfall und Scrum kombinieren
Teil 5: Mehr Agilität wagen! – Teil 5 : Leichter geht’s nicht
———————————————————-