Viel Spielraum für den Auftraggeber
Der auf die beschriebene Weise entstandene integrierte Prozess bietet dem Auftraggeber - sozusagen als "Erbschaft" von Scrum und vom V-Modell XT - erheblichen Spielraum, sich in das Auftragnehmerprojekt einzubringen. Das beginnt bei der Planung: Je nachdem, wie intensiv der Auftraggeber mitwirken will, kann er sich entweder nur an der Festlegung der Anforderungen auf Release-Ebene oder auch an der regelmäßigen Sprint-Planung beteiligen. Und die Möglichkeiten zur Auftraggeberbeteiligung setzen sich bei der Projektkontrolle fort: Dem Entscheidungspunkt "Sprint abgeschlossen" geht die Abnahme der Sprint-Ergebnisse voraus. Sie findet im Rahmen von Sprint-Reviews statt. Formal ist der so genannte Product Owner beim Auftragnehmer für die Abnahme verantwortlich.
Die Zusammenarbeit zwischen Auftraggeber und Auftragnehmer kann jedoch davon profitieren, wenn der Auftraggeber an den Sprint-Reviews teilnimmt und sich einen Eindruck vom Entwicklungsstand des Systems verschafft. Für eine kontinuierliche Fortschrittskontrolle sieht das V-Modell XT im Auftraggeberprojekt den Entscheidungspunkt "Projektfortschritt überprüft" vor, der mit dem Auftragnehmerprojekt zu synchronisieren ist. Es empfiehlt sich also, den Entscheidungspunkt "Projektfortschritt überprüft" des Auftraggebers mit den Sprint-Enden zu synchronisieren.
Im Rahmen der Sprint-Reviews können Fragen geklärt und Änderungswünsche aufgenommen werden, um sie gegebenenfalls bereits im nachfolgenden Sprint zu berücksichtigen. Das ist vertraglich unproblematisch, solange die Änderungswünsche des Auftraggebers Details betreffen (was die Regel ist) und sich nicht auf dem Abstraktionsniveau des Lastenhefts bewegen, das Bestandteil des Vertrags zwischen Auftraggeber und Auftragnehmer ist.
Zugeständnisse auf beiden Seiten
Die Verbindung der beiden Prozesse geht, obwohl sie sich im Wesentlichen auf verschiedenen Steuerungsebenen abspielt, nicht ohne Einschränkungen in Bezug auf die V-Model-XT-Mechanismen und das agile Vorgehen nach Scrum ab. So entfällt bei dieser Lösung zum Beispiel die klassische aktivitätenbasierende Planung, wie sie das V-Modell XT kennt, samt dem üblichen und von Entscheidern oft erwarteten Balkendiagramm. Andererseits sind die Entwickler, wie oben dargestellt, damit konfrontiert, die für das V-Modell XT relevanten Dokumente zu erstellen - eine Herausforderung für agile Teams, die bekanntlich funktionierender Software Vorrang vor Dokumenten geben.
In der Praxis stellt sich aber gerade dieser Punkt als wenig kritisch heraus. Zu den für das V-Modell XT relevanten Produkten gehört zum Beispiel die "Gesamtsystemspezifikation" (Pflichtenheft). Teile dieses Dokuments können mit einem entsprechenden Werkzeug aus dem Product Backlog generiert werden. Entsprechendes gilt für die vom V-Modell XT geforderte Prüfspezifikation für das zu erstellende Gesamtsystem. Sie kann zumindest teilweise aus dem Backlog automatisch erzeugt werden, wenn dort zu jeder Anforderung Abnahmekriterien beziehungsweise Akzeptanztests erfasst sind.
Probe bestanden
Die vorgestellte Integration von Scrum in das V-Modell XT kann so, wie sie hier beschrieben wurde, in allen Projekten, die keine Teilprojekte und keine Unterauftragnehmer besitzen, direkt eingesetzt werden. Die Lösung hat dafür ihre Praxistauglichkeit bereits bewiesen. Für große Projekte mit Teilprojekten müssen in der Regel mehr V-Modell-XT-Produkte erstellt und weitere Entscheidungspunkte durchlaufen werden. Die Lösung ist flexibel angelegt und lässt sich an einen höheren "Bedarf an V-Modell XT" anpassen. (ue)
(Bilder/Grafiken: Fotolia, clabert , Microtool GmbH)