Funktionen, Kosten und Termine einhalten

Produzierende Industrieunternehmen reichern ihre Produkte immer häufiger mit Software-Funktionen an. Um diese innovativ und erfolgreich erarbeiten zu können, müssen Unternehmens- und Entwicklungsprozesse angepasst und weiterentwickelt werden. Nur so können die Unternehmen den veränderten Anforderungen Rechnung tragen sowie sich Vorteile im globalen Wettbewerb sichern.

Doch aufgrund ihrer Historie sind viele Hersteller industrieller Produkte keine typischen Software-Entwickler und -Lieferanten. Ihre Entwicklungsprozesse basieren oftmals auf den Hardware-technischen Anforderungen. Damit sie wettbewerbsfähig bleiben, müssen die Unternehmen daher ihre Software-relevanten Entwicklungsprozesse verbessern. Während das in kleinem Maßstab noch gut beherrschbar ist, steigt die Komplexität bei größeren Software-Produkten deutlich, die meist in mehreren Teams konzipiert werden. Den verschiedenen Entwicklungsprozessen liegen jedoch gemeinsame Ziele zugrunde: Kosten reduzieren, Projektrisiken managen und hohe Qualität erreichen.

Phasenorganisiertes V-Modell

In der klassischen Software-Entwicklung wird heute vielfach nach dem V-Modell gearbeitet, das mit der Analyse und Definition der Anforderungen beginnt. Sie werden als Produkt(-version) zusammengefasst und als Entwicklungsauftrag formuliert. Bereits an dieser Stelle sollte die Qualitätssicherung integriert sein, sodass die Anforderungen vollständig, konsistent und prüfbar sind. Im nächsten Schritt erfolgt die Entwicklungsplanung, die auf dem Grobentwurf der Software basiert. Deren Eigenschaften werden dabei in funktionalen Spezifikationen festgeschrieben. Auf der Grundlage der Ergebnisse startet auch die Erstellung der System- und Integrationstests. Die Umsetzung der Implementierung kann in einem Schritt oder mehreren Inkrementen durchgeführt werden. In diesem Zusammenhang entstehen der Feinentwurf der Software sowie der Programmcode. Die Ergebnisse werden in einer technischen Spezifikation festgehalten. Unit-Tests, die Teil der Entwicklung sind, dienen der Validation.

Freigabebasierter Quality-Gate-Prozess

Die unterschiedlichen Entwicklungsmodelle werden in der Regel von einem Quality-Gate-Prozess überlagert, in dem die einzelnen Projekt-Meilensteine definiert sind. Der Beginn der nächsten Projektphase hängt hier vom Abschluss der vorherigen Phase ab. Als Teil der Projektplanung wird jeder Meilenstein zuvor zeitlich geplant, weshalb seine termingerechte Realisierung ebenfalls Auskunft über den Projektstatus gibt. Bei jedem Meilenstein findet eine Prüfung statt, ob vorher festgelegte Ziele erreicht worden sind. Nur dann kann die folgende Projektphase starten. Der Vorteil dieser Vorgehensweise liegt somit in der Reduzierung von Fehlentwicklungen sowie im Projekt-Controlling. Die einzelnen Projektphasen werden bewusst voneinander getrennt, damit die verschiedenen Projektabschnitte aufeinander aufbauen können. Sind mehrere Entwicklungsdisziplinen beteiligt – z.B. Hard-, Soft- und Firmware -, lassen sich die Meilensteine zur Synchronisation der Teilprojekte nutzen.

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.

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.

Verbindliche Aussagen

Nach der klassischen Anforderungsanalyse werden bei V-Scrum die im Projekt umzusetzenden Stories definiert. Dabei liegt der Fokus auf einem gemeinsamen Verständnis von Auftraggeber und -nehmer. Im Unterschied zum V-Modell müssen die jeweiligen Anforderungen in dieser Phase noch nicht vollständig beschrieben und mit eindeutigen Testkriterien versehen werden. Auch eine Spezifikation der Eigenschaften ist zunächst nicht notwendig. Im Unterschied zu Scrum wird jedoch der wesentliche Funktionsumfang der Software festgelegt. Dazu ist eine Bewertung der Anforderungen hinsichtlich ihres Aufwands erforderlich, um die Einhaltung von Zeit, Ressource und Budgetvorgaben zu kontrollieren. Hier hat sich das sogenannte Planning Poker aus dem Scrum-Umfeld bewährt, bei dem die Anforderungen inklusive Test im Team diskutiert werden. Danach schätzt jeder Mitarbeiter seinen Aufwand. Treten deutliche Abweichungen nach oben oder unten auf, werden sie besprochen und die gemeinsam abgestimmten Schätzwerte festgehalten. Das reduziert das Risiko, das einzelne Aspekte einer Anforderung nicht berücksichtigt sind. Gemäß V-Modell werden die Anforderungen anschließend vereinbart und nach außen kommuniziert. Die Marketing- und Vertriebsorganisationen können also verbindliche Aussagen für ihre Kunden ableiten. Im Unterschied zur klassischen Entwicklung ist eine Änderung der Anforderungen über die Projektlaufzeit mit jedem Sprint möglich. Dabei muss der geplante Zeit- und Budgetaufwand allerdings befolgt werden. Gleiches gilt für die geplanten Hauptanforderungen, damit die Verbindlichkeit nach außen gewahrt ist.

Funktionsbegrenztes Projektrisiko

Die Entwicklung wird nach dem Scrum-Prozess durchgeführt, wobei alle Parteien die Erfüllung des Endtermins und die zu realisierenden Anforderungen beachten. Abnahme und Freigabe finden wieder mit den bekannten Quality Gates statt. Die Mitarbeiter der Qualitätssicherung sind Teil des Teams, werden aber separat organisiert, sodass sie ihre Aufgabe als unabhängige Instanz wahrnehmen können. Die Entwicklung der Tests erfolgt parallel zu den jeweiligen Sprints. In diesem Prozess wird auf umfangreiche technische Spezifikationen verzichtet. Stattdessen pflegen die Mitarbeiter die Anforderungen während der Entwicklung weiter, weshalb sie am Ende die tatsächliche Software in ihrer Funktion beschreiben. Dieses Vorgehen ist sowohl für einen abgestimmten Test als auch den weiteren Lebenszyklus des Produkts wichtig. Die technische Dokumentation der Software-Architektur und Komponenten geschieht im für die Entwicklung und Pflege notwendigen Umfang. Unabhängig vom Prozess gibt es hier gesonderte Festlegungen. Die Ergebnisse werden gemeinsam in Sprint Reviews bewertet und das Feedback gegebenenfalls in folgenden Sprints umgesetzt. Das hat den Vorteil, dass das Projektrisiko nicht über die Laufzeit und damit die Kosten kompensiert wird, sondern über die Funktion. Sollten sich folglich unvorhergesehene Schwierigkeiten oder zusätzliche Aufwände ergeben, skaliert das Team zunächst die Software-Funktion. Der Zeitrahmen und die Kosten bleiben stabil. Dabei ist darauf zu achten, dass die zugesagten Hauptanforderungen trotzdem ausgeführt werden.

Enge Zusammenarbeit

Im Rahmen der Software-Entwicklung hat Phoenix Contact über viele Jahre sowohl mit dem V-Modell und V-Scrum gearbeitet. Beide Modelle haben Vor- und Nachteile. Der größte Nutzen, der sich nun aus dem integrierten V-Scrum ergibt, ist die enge Zusammenarbeit zwischen Produktmarketing, Entwicklung und Test. Die Projektergebnisse hinsichtlich Funktion, Termin und Qualität werden gemeinsam verantwortet. Letzteres funktioniert, weil sämtliche Beteiligten den weiteren Verlauf über den Entwicklungszyklus mit beeinflussen können. Dennoch müssen den verschiedenen Personen einzelne Rollen und Verantwortungen zugeordnet sein. In großen Organisationen ist es zudem erforderlich, an den Schnittstellen zu den außerhalb der Entwicklung stehenden Einheiten verbindliche Ergebnisse und Termine zu kommunizieren. Bei einer rein agilen Vorgehensweise lässt sich das Endergebnis in Funktion und Termin oft schwer vorhersehen. Der V-Scrum-Prozess erlaubt eine solche Prognose, sodass Marketing-Kampagnen und Vertriebsaktivitäten abgestimmt parallel starten können.