Kombination aus V-Modell und Scrum
Als nachteilig erweist sich dabei allerdings, dass der Endtermin für die Freigabe sowie der genaue Funktionsumfang nicht vorhersagbar sind. Dies erfüllt gerade in einer größeren Organisation nicht alle Erwartungen in Bezug auf Verbindlichkeit. Auf Basis der mehrjährigen Erfahrung mit beiden Entwicklungsabläufen haben die Mitarbeiter von Phoenix Contact und KW-Software daher damit begonnen, die Verfahren zu verbinden: Aus der Kombination agiler Entwicklungsmethoden mit einem gemeinsam verantworteten, verbindlichen Ergebnis auf Basis des V-Modells ist ein eigenständiger Ansatz entstanden. Nach der Anforderungsanalyse werden hier die im Projekt umzusetzenden Anforderungen festgelegt, grob abgeschätzt und ein Abnahmetermin vereinbart. Die Anforderungen müssen jedoch weniger detailliert als im V-Modell aufgeschlüsselt sein. Pflichtenheft und Spezifikation entfallen. Die Entwicklung erfolgt nun nach dem Scrum-Prozess, wobei die Beteiligten die Einhaltung des Endtermins und der zu realisierenden Anforderungen als Team-Ziel für die Marketing- und Entwicklungsabteilung im Auge behalten. Zur Abnahme und Freigabe werden Quality Gates herangezogen. Die Mitarbeiter des Bereichs Software-Qualitätssicherung sind ebenfalls Teil des Teams, werden aber separat organisiert, um ihre Aufgabe als ‚unabhängige‘ Instanz zu erfüllen. Sie erarbeiten Tests parallel zu den einzelnen Sprints. Das kombinierte Entwicklungsverfahren verzichtet auf umfangreiche technische Spezifikationen. Stattdessen werden die Anforderungen während des Entwicklungsprozesses gepflegt, sodass sie am Ende die tatsächliche Software in einer ‚Außenansicht‘ beschreiben. Dies ist sowohl für einen abgestimmten Test als auch den weiteren Lebenszyklus des Produkts wichtig. Die technische Dokumentation der Software-Architektur und der Komponenten geschieht in dem Maße, wie es für die Entwicklung und Pflege notwendig ist. Hier gibt es unabhängig vom Prozess gesonderte Festlegungen.
Vorteile für das Change-Management
Das beschriebene Manko des V-Modells resultiert aus starren Verantwortlichkeiten und Abläufen. Dabei werden Lastenhefte erstellt und Projektergebnisse zum Projektende abgeholt. In diesen Fällen entspricht das Ergebnis oft nicht den Erwartungen des Auftraggebers, weil die Zwischenergebnisse nicht frühzeitig gemeinsam betrachtet und Entscheidungen zusammen getroffen wurden. In anderen Fällen wird der Planungstermin so lange verzögert, bis nahezu die gesamte Software umgesetzt und damit alle Entwicklungsrisiken minimiert sind. Damit erfolgt die Freigabe fast unmittelbar auf den Planungstermin, was den eigentlichen Sinn einer Projektplanung zuwider läuft. Das gemeinschaftlich konzipierte agile V-Modell trägt zur Lösung des Konflikts bei, indem die Zusammenarbeit zwischen Marketing-, Entwicklungs- und Testabteilung gestärkt wird – denn die Projektergebnisse hinsichtlich Funktion, Termin und Qualität werden gemeinsam verantwortet. Dieses Vorgehen basiert auch darauf, das sämtliche Parteien das Projekt über den Entwicklungszyklus hinweg beeinflussen können. Dennoch müssen einzelnen Personen Rollen und Verantwortungen zugeordnet werden. Des Weiteren wird eine Zertifizierung des Entwicklungsprozesses gegenüber einem rein agilen Prozess erleichtert. Diesem Aspekt kommt insbesondere aus Sicht von Großkunden eine immer höhere Bedeutung zu. Die Erfahrung der Mitarbeiter beider Unternehmen zeigt, dass der Prozess durch ein Application Lifecycle Management-Werkzeug (ALM) unterstützt werden sollte. So lassen sich später Entscheidungen, Erweiterungen und Veränderungen nachvollziehen. Das betrifft auf lange Sicht die gesamte Software und ihren Lebenszyklus. Zudem konnte infolge der engen Zusammenarbeit in den Teams und des hohen Maßes an Selbstorganisation eine gestiegene Motivation der Mitglieder sowie deren Identifikation mit dem Produkt beobachtet werden.
