Klassisch und agil – wie passt das zusammen?

In IT-Projekten der öffentlichen Verwaltung treffen wir immer wieder auf das V-Modell XT. Dieses klassische Vorgehensmodell gilt als sehr mächtig und allein die Dokumentation umfasst 439 Seiten. Dagegen haben sich in der Softwareentwicklung agile Vorgehensweisen längst durchgesetzt, die vergleichsweise leichtgewichtig daherkommen – der Scrum-Guide umfasst beispielsweise gerade einmal 19 Seiten. Wie diese beiden Welten, die auf den ersten Blick widersprüchlich erscheinen, kombiniert werden können, zeige ich euch im Folgenden.

Das V-Modell XT

Euer Grundwissen zu Scrum vorausgesetzt, möchte ich euch für die spätere Einordnung zunächst auf das V-Modell XT einstimmen. Dieses Vorgehensmodell wird vor allem für Systementwicklungen eingesetzt. Der schwergewichtige Charakter kommt nicht zuletzt in der dokumentenzentrierten und ausführlichen Vorabspezifikation von Anforderungen zum Ausdruck. Dies ist im traditionell geprägten Behördenumfeld üblich, in dem eine Vielzahl von formalen Vorgaben zu beachten sind.

Beim klassischen Vorgehen in der Softwareentwicklung denkt ihr wahrscheinlich zuerst an das Wasserfall-Modell. Das V-Modell XT durchläuft die Phasen der klassischen Entwicklungsdisziplinen (Analyse, Design, Entwicklung, Test) ebenfalls sequenziell, und zwar innerhalb der namensgebenden V-Form. Der Ablauf verteilt sich allerdings auf mehrere sogenannte Vorgehensbausteine – beispielsweise die Systemerstellung. Dabei sind Entscheidungspunkte (Meilensteine) in einer bestimmten Abfolge zu erreichen. Weitere Kernelemente sind definierte Rollen, die relevante Aktivitäten ausführen und dabei Produkte erstellen. Produkte können sowohl Software als auch Dokumente sein.

Der erste sperrige Eindruck vom V-Modell XT relativiert sich im Zusatz XT. Dieser steht nämlich für eXtreme Tailoring und bedeutet, dass das Modell im Baukastenprinzip auf die jeweilige Projektsituation zugeschnitten werden kann.

Auftraggeber, Auftragnehmer und das V-Modell XT

Das V-Modell XT verfolgt den Ansatz, dass ein Projekt für den Auftraggeber (AG) und Auftragnehmer (AN) weitgehend getrennt voneinander abläuft. Dies ist vor dem Hintergrund sinnvoll, dass öffentliche AG bei der Suche nach privatwirtschaftlichen Partnern zu Ausschreibungen verpflichtet sind. So ist die Ausschreibung ein wichtiger Bestandteil im AG-Projekt. Darin wird nicht selten gefordert, das V-Modell XT im AN-Projekt verbindlich einzusetzen. Für uns als Dienstleister heißt das, bei einer Teilnahme an Ausschreibungen auf alle möglichen Konstellationen zu reagieren. Eine geeignete Skalierung unseres Vorgehens auf die Vorgaben zu V-Modell XT ist ein wichtiger Bestandteil in unserem Beratungsformat aREp (adesso Requirements Engineering in public).

AG- und AN-Projekt kommen als Gesamtvorhaben natürlich nicht ohne Kommunikation aus. Für den Austausch ist eine AG-/AN-Schnittstelle im V-Modell XT vorgesehen. Auf beiden Seiten der Schnittstelle sind Tätigkeiten wie Projektmanagement und Qualitätssicherung zu finden, was mit einer Dopplung der entsprechenden Rollen einhergeht. Daher existieren auch zwei Rollen für das Anforderungsmanagement: der Anforderungsanalytiker für den AG und der Anforderungsanalytiker für den AN. Sie verantworten die Produkte „Lastenheft“ und „Pflichtenheft“, die euch sicherlich auch über die Grenzen des V-Modells hinaus bekannt sind.

Im Lastenheft werden die Anforderungen durch den AG strukturiert erfasst, auf dessen Basis der AN im Pflichtenheft das Gesamtsystem entwirft. Nach der Spezifikation und Entwicklung erfolgt die Prüfung (Test) und Lieferung des Systems. Dieser Entwicklungszyklus kann für Zwischenlieferungen auch in mehreren Iterationen durchlaufen werden. Bei komplexen Systemen können somit einzelne Bestandteile inkrementell entwickelt und schließlich zu einem Gesamtsystem zusammengefügt werden.

Hier kommt das agile Vorgehen ins Spiel

Die Integration eines agilen Vorgehens bietet sich innerhalb des AN-Projekts an. Hier haben wir als Dienstleister relativ viel Spielraum und können diesen unabhängig von der definierten AG-/AN-Schnittstelle nutzen. Die V-Modell-XT-Dokumentation öffnet sogar die Tür zu Scrum: Agile Vorgehensweisen wie Scrum lassen sich gut mit dem V-Modell XT kombinieren. Aber wie und wo genau soll das gehen?

Nehmen wir an, dass der AN die Anforderungen im Pflichtenheft spezifiziert hat. Dieses überführt er nun in das Product Backlog. Der Übergang von einem dokumentenbasierten Pflichtenheft in ein elektronisches Scrum Board stellt erfahrungsgemäß keine große Hürde dar, wenn das Dokument bereits eine geeignete Inhaltsstruktur besitzt. So werden aus Features im Pflichtenheft Epics im Backlog. Anwendungsfälle und Anforderungen werden in User Stories und Akzeptanzkriterien überführt beziehungsweise weiter verfeinert. Auf dieser Basis wird sukzessive das Sprint Backlog befüllt und die Entwicklung in Sprints kann beginnen.

In der Scrum-Praxis sollte das gesamte Backlog vom Product Owner verantwortet werden, der im Idealfall vom AG gestellt wird. Ressourcenengpässe der öffentlichen Verwaltung führen aber häufig dazu, dass die Rolle stellvertretend vom AN besetzt wird.

Es kommen weitere Elemente aus Scrum zum Einsatz - etwa Planning, Sprint-Review oder Retrospektive. Nach jeder Iteration eines Sprints wird ein Inkrement erzeugt, das im Review mit dem AG abgestimmt wird. Das Besondere ist: Die Inkremente werden sukzessive im AN-Projekt in das System integriert, das nach klassischer Release-Planung erst am Ende über die eigentliche AG-/AN-Schnittstelle ausgeliefert wird. Hier findet wieder der Wechsel zu einem sequenziellen Vorgehen statt, indem das Release durch den AG abgenommen und in den Betrieb überführt wird.

Die Vorteile eines hybriden Vorgehens

Die agile Entwicklung profitiert von klaren und abgestimmten Anforderungen. Der aus meiner Sicht größte Nutzen für das „agilisierte“ klassische Vorgehen ist: Die Stakeholder des AG werden regelmäßig in die Sprint-Reviews einbezogen und nehmen dabei entscheidenden Einfluss auf die laufende Entwicklung. Dies führt in der Regel zu einem System mit höherer Akzeptanz, als es bei einem klassischen Vorgehen der Fall ist. Hier würden Stakeholder nämlich nach der Lastenhefterstellung erst wieder bei der Abnahme der fertigen Software beteiligt werden und hätten dann kaum noch Gestaltungsmöglichkeiten für ihre Bedürfnisse.

Ein weiterer Mehrwert der agilen Entwicklung innerhalb des V-Modells XT ist der Umgang mit Änderungen von Anforderungen. Hier kann durch die enge Kommunikation zwischen AG und AN schnell reagiert werden. Erfahrungsgemäß ergeben sich die meisten Änderungen auf der Ebene von User Stories. Für einen leistbaren Aufwand empfiehlt sich eine Dokumentation von relevanten Änderungen auf einer höheren Abstraktionsebene, nämlich über eine laufende Fortschreibung des Lasten- oder Pflichtenhefts. Im Idealfall fließen die Inhalte am Ende nahtlos in die fachliche Dokumentation der fertigen Software ein. Es sollte jedoch beachtet werden, dass das Lasten- und Pflichtenheft die vertragliche Grundlage für den Entwicklungsauftrag bilden und im Grundsatz nicht so einfach geändert werden können.

Ein großer Vorteil eines kombinierten Vorgehens liegt zudem auch darin, dass das Anforderungsmanagement nicht nur vorab, sondern begleitend stattfindet. Der AG wird in der Praxis nicht selten durch den AN operativ unterstützt und damit entlastet.

Fazit

Wie ihr gesehen habt, handelt es sich bei der Integration von agilen Vorgehensweisen im V-Modell XT lediglich um agile Ansätze aus Scrum. Im stark hierarchisch geprägten Umfeld der öffentlichen Verwaltung kann dadurch immerhin ein Spielraum im etablierten klassischen Vorgehensmodell genutzt werden. Unsere bisherigen Erfahrungen zeigen, dass in der Kombination der beiden Welten die jeweiligen Vorteile zielführend genutzt werden können. Das wirkt sich dann auch erfolgreich auf die Qualität der Software und die Akzeptanz der User aus. Vor allem in den Sprint-Reviews spielt die intensive Kommunikation der Beteiligten weit über die eigentliche AG-/AN-Schnittstelle hinaus eine hervorgehobene Rolle.

Ihr möchtet mehr über spannende Themen aus dem Public-Bereich bei adesso erfahren? Dann werft auch einen Blick in unsere bisher erschienenen Blog-Beiträge.