Als ersten Schritt hin zu mehr Agilität stellen wir Ihnen in Teil drei der Blogserie den hybriden Ansatz vor, in dem ein traditioneller Gesamtprozess als Hülle für einen agilen Prozess in der Entwicklungsphase dient.
Wie im traditionellen Prozess wird in einer Analyse- und Designphase vom Auftraggeber eine Gesamtspezifikation des zu entwickelnden Produkts oder System erstellt, z. B. im V-Modell XT das Lastenheft. Der Auftragnehmer erstellt auf Basis dieser Gesamtspezifikation einen Umsetzungsvorschlag, im V-Modell XT das Pflichtenheft. Diese beiden Spezifikationen bilden die Vertragsgrundlage. Zusätzlich wird ein Product Backlog aus der Gesamtspezifikation abgeleitet, das in der agilen Phase die Entwicklung treibt. Die nachgelagerten Phasen Abnahme, Vertrieb, Inbetriebnahme und Wartung bleiben vom agilen Prozess weitgehend unberührt.
Die Entwicklungsphase verläuft in Sprints. Aus dem Product Backlog werden Sprint-Backlogs für die einzelnen Sprints abgeleitet und im jeweiligen Sprint umgesetzt. Modul- und Integrationstests werden bereits in die Entwicklung integriert, wodurch später die Phase der Abnahmetests deutlich verkürzt werden kann.
Da zu Beginn des Projekts bereits eine Spezifikation als Basis für das Product Backlog vorausgesetzt wird, eignet sich der hybride Ansatz auch für wiederverwendungsorientierte Projekte, z. B. Produktlinienansätze. Da alle auftraggeberseitigen Spezifikationen in einer Hand liegen, muss nur ein zentrales Spezifikationsteam über Kenntnisse darüber verfügen, wie die Anforderungen am besten wiederverwendet werden können.
Im Gegensatz zum wasserfallartigen Prozess kommen also für die Projektbeteiligten folgende neue Verantwortlichkeiten hinzu:
– Rechtzeitige Detaillierung von Anforderungen vor dem Sprint
Der Auftraggeber muss dafür sorgen, dass die Inhalte des Lastenhefts rechtzeitig aufbereitet und in das Product Backlog übertragen werden, so dass die Anforderungen für den Auftragnehmer in ausreichendem Detailgrad für die Planung und Bearbeitung in den Sprints zur Verfügung stehen.
– Aufbau und Pflege der Traceability zwischen Lastenheft, Product Backlog und Pflichtenheft
Der Auftraggeber muss bei der Abnahme nachvollziehen können, welche Product Backlog-Einträge die Anforderungen des Lastenhefts abbilden, um prüfen zu können, ob die geforderten Funktionalitäten in ausreichendem Maß umgesetzt wurden. Daher liegt es in seiner Verantwortung, Nachvollziehbarkeit zwischen Lastenheft und Product Backlog aufzubauen.
Der Auftragnehmer muss im Gegenzug die Umsetzung der Anforderungen nachweisen und somit für Nachvollziehbarkeit zwischen Pflichtenheft und Product Backlog und zwischen dem Pflichtenheft und dem Lastenheft sorgen.
– Pflege der Inhalte des Product Backlogs und des Pflichtenhefts
Zu den großen Vorteilen einer agilen Entwicklung gehören die niedrigeren Kosten für Lernprozesse und die Möglichkeit, schnell auf veränderte Anforderungen zu reagieren. Um davon profitieren zu können, sollten Product Backlog und Pflichtenheft auf Basis der Ergebnisse aus den Entwicklungssprints aktualisiert werden. Das Lastenheft muss nur in Ausnahmefällen angepasst werden, muss aber einen entsprechend hohen Abstraktionsgrad besitzen. Die Verantwortlichkeit für die Pflege des Product Backlogs liegt auf Auftraggeberseite, während der Auftragnehmer für die Pflege des von ihm erstellten Pflichtenhefts zuständig ist.
– Verstärkte Kommunikation mit dem Entwicklungsteam
Zu den Schwächen der wasserfallartigen Prozesse gehört das „Arbeiten in Silos“, bei dem kaum Kommunikation zwischen Fachseite und Entwicklern stattfindet. Im hybriden Prozess ist es notwendig, dass der Auftraggeber dem Entwicklungsteam einen Ansprechpartner für problematische oder unklare Anforderungen zur Verfügung stellt. Diese Aufgabe kann je nach Projektsituation z. B. ein Kunde oder der Product Owner als Kundenvertreter übernehmen.
Im Idealfall vereint der hybride Ansatz die Vorteile von agiler Entwicklung, nämlich hohe Transparenz durch regelmäßige Inspektion und hohe Anpassungsfähigkeit durch kurze Entwicklungszyklen, mit der Strukturiertheit und Steuerbarkeit eines nicht-agilen Prozesses und eignet sich somit auch für das „teilagile“ Arbeiten im regulierten Umfeld. Im Gegensatz zum traditionellen Prozess ist jedoch kontinuierliche Beteiligung des Auftraggebers gefragt, um die Feedbackzyklen an den geeigneten Stellen zu verkürzen.
Im vierten Teil der Blogserie geht es um „agile Zwischenstufen“, zwei Varianten von agilem RE und agiler Entwicklung.
———————————————————-
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 4: Mehr Agilität wagen! – Teil 4: Die Agilen Zwischenstufen
Teil 5: Mehr Agilität wagen! – Teil 5 : Leichter geht’s nicht
———————————————————-
Quellen:
Chris Rupp und die SOPHISTen. Requirements-Engineering und –Management, 5. Auflage. Hanser, 2009
Joseph Flahiff. Integrating Agile in a Waterfall World.