Wie man Scrum und das V-Modell kombiniert

Nicht jedes Scrum-Team darf seinen eigenen Softwareentwicklungsprozess definieren. Die Gründe dafür sind oft regulatorische Vorgaben der jeweiligen Branche, Kundenanforderungen oder bestehende, über Jahre gewachsene Prozesse in Unternehmen. In diesem Umfeld sind V-Modell orientierte Entwicklungsprozesse besonders häufig anzutreffen. Dies stellt Agile Coaches und Scrum Master vor die Herausforderung, die bestehenden V-Modell-Prozesse in das Scrum-Framework zu integrieren. Dieser Artikel zeigt, wie sich Scrum und das V-Modell der Softwareentwicklung kombinieren lassen.

Inhaltsverzeichnis

Motivation und Hintergrund

Die Scrum Theorie definiert und beschreibt keinen Entwicklungsprozess, nach dem das Scrum Team arbeiten soll oder muss. Sie definiert mit den Scrum Events lediglich einen Rahmen für die Ablauforganisation, sowie Werte, Artefakte, Säulen und Rollen innerhalb eines Scrum Teams. Theoretisch ist jedes Scrum Team frei, seinen eigenen Entwicklungsprozess zu wählen und zu definieren.

Leider sieht die Praxis ein wenig anders aus und ist oft sehr viel komplizierter. Eine nicht unerhebliche Anzahl von Scrum-Teams, vor allem in etablierten Branchen, ist nicht völlig frei in der Wahl ihrer Entwicklungsprozesse. Diese Einschränkungen resultieren oft aus regulatorischen Vorgaben der Branche oder expliziten Anforderungen der Kunden an die anzuwendenden Prozesse. Häufig wird in diesen Organisationen das V-Modell der Softwareentwicklung eingesetzt. Dieses wird insbesondere dann eingesetzt, wenn hohe Anforderungen an die Rückverfolgbarkeit der Anforderungen durch den Code, die gewählte Implementierung und die entsprechenden Tests bestehen.

Wenn Unternehmen eine agile Transition von klassischen Projektmodellen auf agile Methoden durchführen, kollidieren die neuen Methoden mit den gewachsenen, etablierten Prozessen entlang des V-Modells. Da die Anforderungen an Nachvollziehbarkeit und Dokumentation auch beim Einsatz agiler Methoden bestehen bleiben, ist es sinnvoll, die bestehenden Prozesse mit Scrum zu integrieren. Dieser Artikel zeigt, warum dies kein Widerspruch ist und wie bestehende Prozesse des V-Modells mit Scrum kombiniert werden können.

Das V-Modell der Softwareentwicklung

Lassen Sie uns nun einen Blick auf das V-Modell der Softwareentwicklung werfen. Das V-Modell ist ein Prozessmodell, das ursprünglich für die Softwareentwicklung konzipiert wurde, aber inzwischen auch in vielen anderen Disziplinen eingesetzt wird. Es stellt eine Weiterentwicklung des klassischen Wasserfallmodells dar. Bei einer Entwicklung nach dem Wasserfallmodell ist eine Rückmeldung über gefundene Fehler und Probleme erst ganz am Ende der Prozesskette möglich. Bei der Anwendung des V-Modells erfolgt die Rückmeldung viel früher.

Der Name V-Modell leitet sich von der klassischen Darstellung in Form eines V ab. Die linke Seite des V repräsentiert die Prozessschritte des Requirements Engineering und der Implementierung, während die rechte Seite des V die Prozessschritte der Validierung enthält. Dabei stehen sich jeweils Implementierungs- und Validierungsschritte der gleichen Abstraktionsebene gegenüber. Daraus lässt sich auch ableiten, in welcher Detailstufe der Implementierung ein aufgetretener Fehler zu finden ist. Die folgende Abbildung zeigt eine mögliche Darstellung des V-Modells und der darin enthaltenen Prozessschritte.

display of the process steps within the v-model of software development
Abb. 1 - Die Prozessschritte im V-Modell der Software-Entwicklung

Wie man sieht, erstreckt sich das V-Modell über zwei Dimensionen. Zum einen wird die zeitliche Abfolge der Entwicklung vom ersten bis zum letzten Entwicklungsschritt dargestellt, zum anderen wird auch die Detailtiefe in Bezug auf die einzelnen Prozessschritte abgebildet. Auch die Rückkopplungsschleifen der einzelnen Validierungsschritte zu den zugehörigen Entwicklungsschritten sind deutlich zu erkennen.

Prozessschritte im V-Modell

Der erste Prozessschritt des V-Modells ist die Spezifikation der Anforderungen in Zusammenarbeit mit dem Kunden. Anschließend werden aus diesen Kundenanforderungen die funktionalen Anforderungen an das Produkt abgeleitet. Diese beiden Schritte bilden das Requirement Engineering im V-Modell der Softwareentwicklung. Die nächsten beiden Schritte dienen der Erstellung der Softwarearchitektur und, daraus abgeleitet, dem Softwaredesign der einzelnen Softwarekomponenten.

In der Mitte des V-Modells, am unteren Ende des Vs, befindet sich der eigentliche Implementierungsschritt. Hier werden die definierten Softwarekomponenten entsprechend dem definierten Softwaredesign entwickelt. Dieser Schritt hat von allen Prozessschritten den mit Abstand höchsten Detaillierungsgrad.

Die implementierte Lösung wird in einem Test der einzelnen Komponenten validiert, was einer Validierung der Spezifikation des Softwaredesigns der jeweiligen Komponente gleichkommt. Im Integrationstest wird das Zusammenspiel der verschiedenen Komponenten und damit die Softwarearchitektur als solche getestet. Es folgt ein Systemtest, bei dem geprüft wird, ob die funktionalen Anforderungen der Lösung korrekt umgesetzt wurden. Schließlich folgt ein Abnahmetest. Dieser dient der Validierung, ob das fertige Produkt das vom Kunden gestellte Problem / die vom Kunden gestellten Anforderungen zufriedenstellend und vollständig löst. Wird in einem der Validierungsschritte ein Fehler festgestellt, ist die Ursache dieses Fehlers im äquivalenten Prozessschritt der linken Seite des V zu finden.

Das V-Modell der Softwareentwicklung definiert also die grundlegenden Schritte des Softwareentwicklungsprozesses. Es beschreibt die verschiedenen Schritte des Requirements Engineering, der Implementierung und der Validierung. Entlang dieser Prozessschritte kann in jeder Organisation eine spezifische Umsetzung des V-Modells in Anpassung an die Bedürfnisse der Organisation erfolgen. Das V-Modell definiert jedoch weder einen zeitlichen Rahmen für die Abfolge dieser Prozesse noch wie und wann die verschiedenen Entwicklungsschritte erfolgen sollen.

Produktentwicklung mit Scrum

Im Gegensatz zum V-Modell ist Scrum keine Meta-Beschreibung eines Entwicklungsprozesses, sondern ein Framework, das neben vielen anderen Aspekten die zeitliche Strukturierung der Prozesse einer Organisation ermöglicht. So heißt es im Scrum Guide 2020:

Scrum ist ein leichtgewichtiges Framework, das Menschen, Teams und Organisationen hilft, durch adaptive Lösungen für komplexe Probleme Werte zu schaffen.

Scrum spezifiziert hier Dinge wie die eigenen drei Säulen, die Rollen innerhalb eines Entwicklungsteams, die von einem Team durchzuführenden Events, die zu bearbeitenden und zu produzierenden Artefakte sowie die in einem Team zu etablierenden und zu lebenden Werte.

Requirement Engineering mit Scrum

Das grundlegende Ereignis in Scrum ist der Sprint. Dieser ist ein Container für alle anderen Aktivitäten in Scrum. Die Dauer eines Sprints kann bis zu vier Wochen betragen, sollte idealerweise konstant sein und kann vom Team selbst gewählt werden. Innerhalb eines Sprints setzt das Team das Sprint Backlog in eine neue Iteration des Inkrements um. Darüber hinaus ist das Team kontinuierlich an der Entwicklung, Abstimmung und Klärung neuer Anforderungen beteiligt. Dieser Prozess wird als Refinement bezeichnet und beschreibt das Requirement Engineering in einem Scrum-Team. Dieser kontinuierliche Prozess beginnt und endet ausdrücklich nicht an den Grenzen eines einzelnen Sprints. Er wird sprintübergreifend betrieben und dient der inhaltlichen und technischen Klärung von zukünftigen Anforderungen/Aufgaben.

Product Backlog Refinement ist der Akt des Herunterbrechens und der weiteren Definition von Product Backlog-Elementen in kleinere, präzisere Elemente. Dies ist eine fortlaufende Aktivität, um Details hinzuzufügen, wie z. B. eine Beschreibung, Reihenfolge und Größe. Die Attribute variieren oft mit der Domäne der Arbeit.

 

refinement activities within a single Scrum Sprint
Abb. 2 - Der kontinuierliche Refinement-Prozess während eines Sprints

 

Zusammenfassend definiert Scrum das Sprint Backlog als eine Sammlung von Anforderungen/Aufgaben, die innerhalb des Sprints umgesetzt werden sollen. Das Inkrement beschreibt die daraus resultierende neue Version des Produkts. Da Sprints inkrementell aufeinander aufbauen, wächst auch das Produkt inkrementell. Das wesentliche Merkmal dieses Sprint Backlogs ist, dass jede Aufgabe, die fertiggestellt wird, an den Kunden ausgeliefert werden kann. Ein Sprint ist also ein geschlossener Zyklus, in dem Anforderungen in eine auslieferbare Version des Inkrements umgewandelt werden.

Was Scrum jedoch ausdrücklich nicht festlegt, ist die Art und Weise, wie ein Team das Sprint Backlog in das Inkrement umwandeln sollte. Dieser „Weg“ ist das, was wir als Entwicklungsprozess kennen. Dieser Prozess wird vom Scrum-Framework nicht explizit hervorgehoben, da er normalerweise branchen-, organisations- und oft sogar teamspezifisch ist. In einem Scrum-Team beinhaltet dieser Prozess die Aufgaben der Implementierung und Validierung, während das Requirements Engineering durch das Refinement abgedeckt wird. Auch hier ist nicht beschrieben, wie das Refinement durchzuführen ist, sondern nur, dass es zu erfolgen hat. Im Gegensatz zum V-Modell bildet Scrum das Requirement Engineering in einem eigenen Prozess ab, der neben dem Entwicklungsprozess steht.

Die Kombination von Scrum und dem V-Model der Softwareentwicklung

Schauen wir uns nun an, wie der Metaprozess des V-Modells mit Scrum kombiniert werden kann. Wie wir bereits gesehen haben, stehen vor allem Unternehmen mit etablierten, klassischen Prozessen, die einen agilen Übergang beginnen, vor diesem Problem. Auf der einen Seite haben wir den im V-Modell beschriebenen Entwicklungsprozess, auf der anderen Seite die von Scrum definierten Regeln zur Strukturierung der Projektorganisation.

Wie im letzten Abschnitt beschrieben, gibt es in Scrum eine Trennung zwischen dem eigentlichen Entwicklungsprozess (Implementierung und Validierung) und dem Requirements Engineering Prozess. Diese Trennung gibt es im V-Modell der Softwareentwicklung nicht. Doch genau an dieser Stelle können wir das V-Modell aufspalten, um es mit den Anforderungen von Scrum kompatibel zu machen.

Klassische Organisationen und Entwicklungsprojekte arbeiten mit Lastenheften und Pflichtenheften. Die Lastenhefte beschreiben die Anforderungen des Kunden, während das Pflichtenheft die beabsichtigte Umsetzung dieser Anforderungen einschließlich aller Abweichungen beschreibt. In den meisten Fällen findet die Diskussion und Klärung dieser Dokumente zu Beginn des Projekts statt. Spätere Änderungen werden dann durch Änderungsanträge in komplexen Änderungsprozessen beauftragt und verursachen nicht nur zusätzlichen Aufwand, sondern auch zusätzliche Kosten.

Aufspaltung des V-Models

Die Kombination von Scrum und dem V-Modell der Softwareentwicklung wird dadurch ermöglicht, dass sich das Requirements Engineering über die gesamte Projektlaufzeit erstreckt. Der klassische Ansatz des V-Modells wird also in den kontinuierlichen Verfeinerungsprozess von Scrum überführt. Dies setzt natürlich eine Priorisierung der Anforderungen durch den Kunden voraus, denn nur so können die wichtigsten Anforderungen zuerst diskutiert, verfeinert und umgesetzt werden. Dies ermöglicht es, Anforderungen immer zwei bis drei Sprints vor der eigentlichen Umsetzung zu verfeinern, agile Prioritäten anzupassen und somit Scrum in einem klassisch geprägten Umfeld einzuführen.

 

a combination of v-model and Scrum
Abb. 3 - Die Kombination von V-Modell und Scrum

 

Alle Anforderungen an ein mit Scrum entwickeltes Produkt, einschließlich der verfeinerten und vereinbarten Anforderungen, finden sich im Product Backlog. Aus diesem Product Backlog wählt das Scrum-Team im Rahmen des Sprint Planning Events die Anforderungen aus, die im nächsten Sprint umgesetzt werden sollen. Diese bilden dann das Artefakt des Sprint Backlogs. Hier kommt nun der entscheidende Teil. Wie bereits erwähnt, beschreibt Scrum keinen Entwicklungsprozess. Wie das Sprint Backlog in das Inkrement überführt wird, liegt also allein in der Hand des Entwicklungsteams oder ggf. der Entwicklungsorganisation.

Die Umsetzung des Sprint Backlogs, d.h. die Erstellung des Inkrements, kann nun gemäß der im V-Modell beschriebenen Umsetzungs- und Validierungsschritten erfolgen. Eine Einschränkung ist dabei, dass alle Anforderungen, die den Abnahmetest erfolgreich bestanden haben, die Definition von Done erfüllen müssen. Das Inkrement muss sich also zu jedem Zeitpunkt in einem lieferbaren Zustand befinden. Die Trennung des V-Modells in eine Requirements-Engineering-Phase und eine Entwicklungs- und Validierungsphase macht es also möglich, Scrum und das V-Modell für die Softwareentwicklung zu kombinieren.

Abschließende Gedanken

In diesem Artikel haben wir uns angesehen, wie man das klassische V-Modell der Softwareentwicklung mit dem agilen Framework Scrum kombinieren kann. Wir haben gesehen, dass dazu der Entwicklungsprozess nach dem V-Modell aufgebrochen werden muss. Die Überführung des Requirements Engineering in den von Scrum-Teams gelebten Verfeinerungsprozess ermöglicht die Kombination von etablierten Prozessen mit agilen Methoden. Allerdings ist es notwendig, den Kunden für die Zusammenarbeit nach diesem Modell zu gewinnen. Nur wenn der Kunde bereit ist, seine Anforderungen entsprechend zu priorisieren und in einem kontinuierlichen Prozess zu koordinieren, kann die Kombination von Scrum und klassischen Entwicklungsprozessen nach dem V-Modell der Softwareentwicklung gelingen.

Zurück zum Blog

Von der Theorie in die Praxis? Besuchen Sie agile Trainings bei AgileSkills!

1 von 4
  • Lead Time und Cycle Time in Kanban Systemen

    Lead Time und Cycle Time in Kanban Systemen

    Bei der Diskussion von Kanban-Systemen tauchen oft die Begriffe "Lead Time" und "Cycle Time" auf. Allerdings verwenden verschiedene Leute diese Begriffe unterschiedlich, und manchmal werden sie sogar synonym verwendet. Dieser...

    Lead Time und Cycle Time in Kanban Systemen

    Bei der Diskussion von Kanban-Systemen tauchen oft die Begriffe "Lead Time" und "Cycle Time" auf. Allerdings verwenden verschiedene Leute diese Begriffe unterschiedlich, und manchmal werden sie sogar synonym verwendet. Dieser...

  • Throughput und Delivery Rate in Kanban Systemen

    Throughput und Delivery Rate in Kanban Systemen

    Obwohl die Begriffe Throughput (Durchsatz) und Delivery Rate (Lieferfrequenz) oft synonym verwendet werden, gibt es feine Unterschiede zwischen ihnen. Dieser Artikel erklärt den genauen Unterschied zwischen Throughput und Delivery Rate...

    Throughput und Delivery Rate in Kanban Systemen

    Obwohl die Begriffe Throughput (Durchsatz) und Delivery Rate (Lieferfrequenz) oft synonym verwendet werden, gibt es feine Unterschiede zwischen ihnen. Dieser Artikel erklärt den genauen Unterschied zwischen Throughput und Delivery Rate...

  • Ein kurzer Leitfaden über Objectives und Key Results

    Ein kurzer Leitfaden über Objectives und Key Re...

    Objectives and Key Results (OKRs) ist ein Zielsetzungsframework, welches Organisationen hilft, klare, messbare Ziele zu setzen. Dieser Artikel zeigt die Definition von OKRs sowie gute Beispiele, die Ihnen helfen könnten,...

    Ein kurzer Leitfaden über Objectives und Key Re...

    Objectives and Key Results (OKRs) ist ein Zielsetzungsframework, welches Organisationen hilft, klare, messbare Ziele zu setzen. Dieser Artikel zeigt die Definition von OKRs sowie gute Beispiele, die Ihnen helfen könnten,...

  • A Beginners Guide to Kanban Metrics

    Ein kurzer Leitfaden über Kanban Metriken

    Kanban-Boards werden von Teams verwendet, um ihren Workflow und aktuellen Aufgaben abzubilden. Leider fehlt vielen Teams das Wissen und die Fähigkeit, die Leistung ihres Workflows zu bewerten. Wie schnell werden...

    Ein kurzer Leitfaden über Kanban Metriken

    Kanban-Boards werden von Teams verwendet, um ihren Workflow und aktuellen Aufgaben abzubilden. Leider fehlt vielen Teams das Wissen und die Fähigkeit, die Leistung ihres Workflows zu bewerten. Wie schnell werden...

1 von 4
Dr.-Ing. Stefan Döbrich

Fragen und Antworten

Sie haben offene Fragen zu Agilität?

Sie haben noch offene Fragen zum Artikel, zu agilen Methoden, oder Probleme bei der Umsetzung von Agilität in der Praxis?

Schreiben Sie mir, und wir vereinbaren ein Erstgespräch! Wir machen uns gemeinsam auf den Weg. Versprochen!

Jetzt Kontakt Aufnehmen