Agiles Scrum-Modell
Alternativ stehen eine Reihe von agilen Entwicklungsprozessen und -methoden zur Verfügung. Sie gehen davon aus, dass sich die Anforderungen während des Projektverlaufs inhaltlich sowie in ihrer Priorität verändern können. Ein Beispiel hierfür ist die Scrum-Methode. Der Scrum-Prozess gründet sich auf ein zentrales Lastenheft, dem Product Backlog. Hier sind alle Anforderungen an die Software – auch als User Stories bezeichnet – aufgeführt und mit eindeutigen Prioritäten versehen. Jede Story wird hinsichtlich ihres Umsetzungsaufwands und Kundennutzens bewertet. Anforderungen mit hohem Nutzen und geringem Aufwand bekommen normalerweise eine hohe Priorität. Die Verantwortung für das Product Backlog ist dem Product Owner zugeordnet, der mit den Kunden – den Stakeholdern – kommuniziert. Die Realisierung der Software erfolgt in sogenannten Sprints. Das können 30-Tage-Inkremente sein, in denen das Team die Anforderungen gemäß ihrer Priorität abarbeitet. Die Verantwortung für die Zuweisung der Arbeitspakete und deren Ausführung liegt beim Team. Am Ende des Sprints wird dem Product Owner und unter Umständen auch den Stakeholdern das Ergebnis vorgestellt. Der Product Owner fügt das schriftlich festgehaltene Feedback wieder in den Product Backlog ein und priorisiert es entsprechend. Die Inhalte und Prioritäten der Anforderungen können sich also zu jedem Sprint ändern. So wird sich dem Software-Release in enger Abstimmung zwischen den Kunden und der Entwicklung genähert. Ist ein Sprint begonnen, bleiben die in Bearbeitung befindlichen Anforderungen jedoch bis zum nächsten Review unverändert.
Das V-Scrum-Modell kombiniert die Vorteile von V-Modell und Scrum-Methode, sodass die jeweiligen Nachteile entkräftet werden. (Bild: Phoenix Contact Deutschland GmbH)
Automatisierte Systemtests
Während des Sprints setzt sich das Projektteam täglich zu einer festen Zeit zum Daily Scrum zusammen, um den Arbeitsfortschritt anhand eines Sprint-Burndown-Diagramms auszuwerten. Bei idealem Verlauf sinkt die Kurve der offenen Arbeitspakete bis zum Sprint-Ende linear auf null. Als Teil des Sprints werden Qualitätssicherungs-Maßnahmen im Team erarbeitet. Dazu sind ein Test-Manager und -Ingenieure direkt in das Team integriert. Die durch die Entwickler umgesetzten Unit-Tests bilden eine wichtige Voraussetzung, damit durch weitgehend automatisierte Tests sichergestellt werden kann, dass die Anzahl der realisierten Stories – Velocity genannt – über die Zeit nicht absinkt. Nach jedem Sprint sollte die Software als ’nearly shippable code‘ zur Verfügung stehen, das heißt installierbar, funktionsfähig und bis zu einem vereinbarten Grad getestet sein. Dies beinhaltet erfahrungsgemäß einen automatisierten System-, aber noch keinen Akzeptanztest. In der Knowledge-Focus-Phase werden die grundlegenden Entscheidungen hinsichtlich des Software-Aufbaus getroffen sowie Konzepte ausprobiert und wieder verworfen. Anschließend beginnt die Implementierung der großen Arbeitspakete, die den wesentlichen Funktionsumfang der Software darstellen. Regelmäßige Reviews mit den Stakeholdern sorgen dafür, dass die umgesetzten Funktionen den Kundenwünschen entsprechen. Die sogenannten Bonus-Features werden in die letzte Phase verschoben, wenn die Software schon funktionsfähig und mit allen wichtigen Eigenschaften ausgestattet ist. Jetzt können der Product Owner und die Stakeholder jederzeit entscheiden, keine zusätzlichen Features mehr zu implementieren und die Software freizugeben. Daher wird die Phase auch als ‚Trim the tail‘ bezeichnet.
Kombinierte Vorteile
Der Vorteil klassischer Entwicklungsprozesse wie V-Modell oder Quality Gate liegt in einer durchgängigen Dokumentation des Projektfortschritts und der Terminplanung sowie klaren Rollen und Verantwortlichkeiten. Zum Start des Projekts müssen allerdings sämtliche relevanten Anforderungen vollständig bekannt und die Rahmenbedingungen fest definiert sein. Bei Änderungen sind die inhaltlichen Adaptionen in den einzelnen Stufen zu realisieren und die Quality Gates erneut zu durchlaufen. Trotz dieses Aufwands lassen sich Termine oft nicht einhalten. Außerdem spiegeln die Ergebnisse unter Umständen nicht die Wünsche der Stakeholder wider. Deshalb gehen agile Entwicklungsprozesse wie Scrum generell davon aus, dass sich Anforderungen über den Projektverlauf sowohl inhaltlich ebenso wie in ihrer Priorität verändern können. Gleichwohl ist Scrum kein Allheilmittel. Denn bei der Methode handelt es sich eher um ein Framework für das Projektmanagement, das sich in vielen Teilen als zu unspezifisch erweist. Beispielsweise verpflichten sich Industrieunternehmen aufgrund verschiedener Zertifizierungen zur Einhaltung der entsprechenden Normen, wie der DIN EN ISO9001. Dies ist in Entwicklungshandbüchern festgeschrieben und gründet sich häufig auf den Hardware-basierten Entwicklungsprozessen. Scrum hier zu verankern ist schwierig. Daher hat Phoenix Contact die Vorteile beider Prozesse – V-Modell und Quality Gate auf der einen sowie Scrum auf der anderen Seite – kombiniert: V-Scrum. So lassen sich die Nachteile der einzelnen Modelle entkräften.
