Worin unterscheiden sich das Wasserfall-Modell und die Agile Entwicklung?

Die fachliche Konzeption von Individualsoftware ist ein kreativer Prozess, bei dem während der Entstehung der Lösung neue Anforderungen aufkommen. Gründe hierfür können Feedback seitens der Anwender, sich entwickelnde Geschäftsprozesse oder neue technologische Möglichkeiten sein. Je größer der Planungshorizont eines Projekts ist, desto geringer ist die  Wahrscheinlichkeit, dass man die Lösung am Reißbrett vollständig ideal entwirft.

Das Agile Vorgehensmodell baut auf dieser These der beschränkten Planbarkeit
auf und ersetzt lange Planungs-, Umsetzungs- und Testzyklen durch sehr kurze. Die Software entsteht so Stück für Stück in sogenannten „Iterationen“ oder „Sprints“. Dies erhöht die Transparenz, führt zu mehr Kollaboration zwischen Kunde und Umsetzungsteam und verringert das Risiko. Daher hat sich die Agile Entwicklung als mentales Modell durchgesetzt. Entscheidend ist jedoch auch die Ausgestaltung des Entwicklungsprozesses, da das agile Prinzip nur den Grundtenor der Zusammenarbeit vorgibt.

Wasserfall-Modell vs. Agile Entwicklung

"Die Notwendigkeit, einen sehr hohen Detailgrad zu liefern, führt dazu, dass die Zusammenstellung aller Anforderungen, bspw. in Form eines Pflichtenhefts, sehr aufwändig und kostenintensiv ist. Dadurch verlagert sich der Beginn der tatsächlichen Umsetzung im Projekt stark nach hinten."

Klassisches Projektvorgehen nach dem Wasserfall-Modell beginnt mit der vollständigen Spezifizierung aller Anforderungen mit maximalem Detailgrad. Die Grundlage bildet dabei der zum aktuellen Zeitpunkt geplante Funktionsumfang. Die Notwendigkeit, einen sehr hohen Detailgrad zu liefern, führt dazu, dass die Zusammenstellung aller Anforderungen, bspw. in Form eines Pflichtenhefts, sehr aufwändig und kostenintensiv ist. Dadurch verlagert sich der Beginn der tatsächlichen Umsetzung im Projekt stark nach hinten. Weiterhin wird dabei angenommen, dass der gewünschte Funktionsumfang der Software zu Projektbeginn klar und umfassend definiert werden kann und bis zum Projektabschluss weitgehend unverändert bleibt. Nachträgliche Änderungen an den Anforderungen führen zu meist überproportional aufwändigen Change Requests. Bei komplexen Softwareprojekten sind solche Änderungen jedoch kaum zu vermeiden.

"Auch bei der Agilen Entwicklung existiert eine langfristige Planung, die sich jedoch eher auf die strategischen Ziele und den betriebswirtschaftlichen Rahmen bezieht."

Auch bei der Agilen Entwicklung existiert eine langfristige Planung, die sich jedoch eher auf die strategischen Ziele und den betriebswirtschaftlichen Rahmen bezieht. Auf inhaltlicher Ebene werden jedoch nur die Funktionen detailliert geplant, die unmittelbar umsetzbar sind und damit eine hohe Planungssicherheit aufweisen. Dadurch kann mit der Implementierung dieser Funktionen im Projekt deutlich früher begonnen werden.

Im Projektverlauf wird die Planung permanent anhand des aktuellen Stands und der Rahmenbedingungen geprüft und bei Bedarf angepasst. Da sich Anforderungen im Zeitverlauf üblicherweise ändern, trägt dieses Vorgehen deutlich stärker zum Wertbeitrag des Projekts bei. So wird vermieden, dass hohe Aufwände für potenziell obsolete Features entstehen, welche nachträglich durch kostenintensive Change Requests anzupassen sind.

Agile Entwicklung

Rollen

Bei der Agilen Entwicklung gibt es fest definierte Rollen, die unterschiedliche Aufgaben im Projekt wahrnehmen:

• Product Owner: Vertritt die fachliche Sicht, stellt und priorisiert Anforderungen und beurteilt die Funktionalität, Benutzbarkeit (Usability), Performanz und Qualität der Software. In der Regel wird diese Rolle durch einen Mitarbeiterin unserer Kunden besetzt. Eine intensive Beschäftigung mit dem Produkt und eine regelmäßige Beteiligung im Prozess ist unabdingbar für den Projekterfolg.
• Product Architect: Unterstützt dieden Product Ownerin, unter anderem durch die Detaillierung der Anforderungen in Form von User Stories (siehe unten), steuert das Projekt und Team von Zweitag-Seite und stellt über das Projekt-Controlling sicher, dass das die Anforderungen an Zeit, Budget und Qualität eingehalten werden.
• Team: Zweitag stellt für die konkrete Umsetzung des Produkts ein erfahrenes Team zusammen, dass für die Dauer des Projektes fest zusammenarbeitet. Dies kann bspw. aus Designern, UX-Experten, Entwicklern, Software-Testern und Infrastruktur-Spezialisten bestehen. Das Team kann während des Projektes bei Bedarf um spezielle Experten ergänzt werden.

Tool-Unterstützung

Die Projektarbeit wird unter anderem durch eine Projektmanagement-Software unterstützt, auf die alle Beteiligten Zugriff erhalten. So herrscht stets volle Transparenz. Sofern kundenseitig nicht anders gewünscht, wird diese Software von Zweitag bereitgestellt. Je nach Zusammenarbeitsmodus können über das Werkzeug zuordenbare Umsetzungsaufwände für die einzelnen Projekt-Elemente (User Stories, Tasks) in unserem Tool direkt eingesehen werden.

User Stories

Die Anforderungen im Rahmen der Agilen Entwicklung werden in sogenannten User Stories festgehalten. Wir legen dabei sehr großen Wert auf eine präzise Definition der Anforderungen, um Unterbrechungen und Zeitverluste durch Rückfragen während der Umsetzung weitestgehend zu vermeiden.

Aus diesem Grund setzten wir ein erprobtes Template für User Stories ein, dass folgende Abschnitte enthält:

• eindeutiger Titel
• Definition der Problemstellung
• Zusammenfassung der Lösung
• Auflistung abzugrenzender User Stories
• Beschreibung des zentralen Prozessablaufs
• Beschreibung von fachlichen, gestalterischen und technischen Details

Titel

Der Titel einer User Story hat den grundsätzlichen Aufbau:

Beispiel:

• Kunde setzt sein Passwort per E-Mail zurück

Problemstellung

In der Problemstellung wird die Motivation wiedergegeben, aufgrund derer eine User Story aufgenommen wird und welchen Zweck diese erfüllt.

Die Problemstellung beinhaltet noch nicht die Lösung. Dadurch wird insbesondere die Freiheit erhalten, sich alternative Lösungsansätze zu überlegen.

Zusammenfassung

In der Zusammenfassung wird die Lösung, die die User Story liefert, in ein bis zwei Sätzen beschrieben.

Abzugrenzende Stories

Dieser Abschnitt kann genutzt werden, um auf User Stories hinzuweisen, die in enger Relation zu der vorliegenden Story stehen. Das können Stories sein, die inhaltlich stark zusammenhängen und erst in Kombination den angedachten Kundennutzen herstellen. Die Erwähnung verhindert zum einen, dass Dinge in dieser User Story gesehen werden, die in einer anderen vorgesehen sind. Zum anderen ergibt sich ggf. erst durch Betrachtung aller miteinander verbundenen Stories das richtige Gesamtbild.

Ablauf

Im Ablauf wird in prozeduraler Form aufgelistet, welche Rollen mit welchen Schritten ihre Aufgabe erledigen und wie sich die Anwendung dabei verhält. Eine Vorbedingung kann angegeben werden, um zu verdeutlichen, wo die Story in einem größeren Prozess einhakt bzw. unter welchen Umständen diese Story überhaupt zum Tragen kommt. Ein Ergebnis kann angegeben werden, um einen Zustand nach erfolgtem Ablauf zu definieren, sollte das nicht direkt aus dem Ablauf ersichtlich werden.

Format:

• Vorbedingung: {Rolle} hat etwas gemacht oder etwas ist in einem bestimmten Zustand

1. {Rolle} macht etwas in der Anwendung
2. ...

• Ergebnis: Zustand von etwas ist jetzt x

Dabei können neben der prozessualen Sicht auch schon inhaltliche Details genannt werden, z. B. eine exakt zu übernehmende Beschriftung.

Details

Alle inhaltlichen und ggf. gestalterischen oder technischen Aspekte einer User Story werden im Abschnitt „Details“ näher ausgeführt. Diese Inhalte können insbesondere umfassen:

• Mockups, d. h. prototypische visuelle Gestaltung der Nutzerschnittstelle
• Wireframes zur Erläuterung des Seitenaufbaus (nur relevant, wenn nicht durch Mockups ersichtlich)
• Anzeigetexte
• Formularspezifikationen mit Feldnamen, Definition von Pflichtfeldern, Wertebereichen – also gewünschte Validierungen und Optionslisten –, Standardwerten, Hilfetexten etc.
• E-Mail-Spezifikationen mit Betreff, Empfänger (To:/CC:/BCC:), ggf. Absender, Body, ggf. Anhang
• Detaillierte Spezifikation zur Struktur von API-Antworten oder Export-Dokumenten
• Detailspezifikationen wie Sortierreihenfolge von Listen etc.

Die Details werden durch Überschriften gegliedert.

Weitere technische Details

Die Dokumentation tiefergehender technischer Details wird, sofern von der Projektmanagement-Software unterstützt, in Sub-Aufgaben zur User Story abgebildet. Die Benennung der Aufgaben erfolgt einheitlich, bspw. nach Technologien, Verantwortungsbereichen o. ä.

Sprints in der Agilen Entwicklung

Im Rahmen der Agilen Entwicklung wird das Projekt in einzelne Iterationen, sogenannte Sprints, unterteilt. Sprints haben eine definierte Länge, in der Regel zwei Wochen. Je näher der Start eines Sprints rückt, desto detaillierter wird der darin umzusetzende Funktionsumfang definiert. Innerhalb eines Sprints werden drei Phasen unterschieden.

Planung

Bei der Sprint-Planung unterscheiden wir die vorbereitende Phase, in der der
Product Owner und der Product Architect einzelne User Stories

• neu aufnehmen,
• priorisieren,
• ggf. tauschen und
• spezifizieren.

Dabei sind stets die Auswirkungen auf Zeit und Budget zu beachten.

Danach werden die für die jeweilige User Story relevanten Team-Mitglieder um Prüfung und ggf. um Ergänzung von Details gebeten. Die User Stories selbst werden dabei im sogenannten Product Backlog festgehalten. Dabei handelt es sich um eine priorisierte Liste aller User Stories, die noch nicht in einen Sprint eingeplant oder abgeschlossen sind. Dieser Prozess erfolgt laufend und parallel zum aktuellen Sprint.

In der konkreten Planung des nächsten Sprints einigen sich alle Beteiligten gemeinsam auf die User Stories, die innerhalb des Sprints umgesetzt werden sollen. Diese werden in das sogenannte Sprint Backlog aufgenommen. Das Team trifft damit eine verbindliche Zusage, dass dieser Umfang innerhalb des Sprints umgesetzt wird, sofern es keine außergewöhnlichen Umstände gibt, die dies verhindern.

Umsetzung

Die Länge des Sprints steht dem Team vollständig zur Verfügung, um die
definierten User Stories eigenständig umzusetzen. Zur Abstimmung im Team findet jeden Tag ein kurzes, üblicherweise maximal 15-minütiges Daily Scrum statt. Der aktuelle Status wird laufend in unserer Projektmanagement-Software abgebildet.

Fertige User Stories werden zudem kontinuierlich auf unserem Staging-System (Testsystem) allen Beteiligten bereitgestellt, so dass ein frühes Testen und direktes Feedback ermöglicht werden.

Review

Die im Sprint fertiggestellten User Stories unterliegen einem Review-Prozess. Dieser kann sowohl kontinuierlich (siehe Umsetzung) als auch zum Ende des Sprints hin erfolgen. Dieder Product Ownerin prüft dabei, ob die User Stories den definierten Anforderungen entsprechend umgesetzt wurden.

Sollten sich dabei Abweichungen ergeben, kann eine entsprechende Korrektur eingefordert werden, um die sich das Team zeitnah kümmern wird, um den Sprint abschließen zu können. Durch eine kontinuierliche, zeitnahe Abnahme fertiger User Stories im laufenden Sprint wird der Produktionsfluss beschleunigt und das Lieferrisiko reduziert.

Am Ende eines Sprints bzw. zum Start des nächsten Sprints bietet sich an, den Status des Projekts zu reviewen und das Projekt im Zielkorridor zu verorten (s. Kapitel Projekt-Controlling).

Neben den durch den Zeitplan des Sprints fest termininierten Meetings Planning und Review am ersten bzw. letzten Tag des Sprints entstehen ad hoc Vorstellungen von Zwischenergebnissen. Darüberhinaus stehen Product Ownerin und Produkt-Architektin in engem Austausch zur Vorbereitung der nächsten Sprints. Hierdurch entstehen weitere, individuell und bedarfsorientiert vereinbarte Abstimmungs- und
Konzeptionstermine.

Projekt-Controlling in der Agilen Entwicklung

Das Projekt-Controlling in der Agilen Entwicklung unterscheidet sich maßgeblich von klassischen Projekten in der Art, wie sich die Einzelbudgets zu einem Gesamtbudget addieren und sich diese Zusammensetzung im Projektverlauf ändert.

Die Planungsphase eines klassischen Wasserfall-Projekts stützt sich auf die Annahme, die notwendigen Features vollständig erfassen und für deren Umsetzung entsprechende Aufwände schätzen zu können. Diese stellen in Summe („bottom-up“) das Gesamtbudget dar. Die Unschärfe und damit das langfristige Projektrisiko entsteht dadurch hauptsächlich durch mögliche Budgetüberschreitungen, die sich im Verlauf aufsummieren und zu extremen Überschreitungen des Gesamtbudgets führen können. Üblicherweise wird versucht, diese Eventualitäten durch Risikopuffer im Budget zu berücksichtigen.

Da es in klassischen Projekten jedoch sehr spät zur Evaluation des Produkts kommt, kann dessen Tauglichkeit (oder in ungünstigen Fall Untauglichkeit) für den Einsatzzweck erst nach dem Anfallen des größten Teils der Projektaufwände festgestellt werden. Dies kann zu ungeplanten, kostenintensiven Change Requests führen oder das Projekt sogar in Gänze betriebswirtschaftlich scheitern lassen.

Im agilen Projekt wird das Gesamtbudget den betriebswirtschaftlichen Zielen des Softwareprodukts unterstellt. Zwar wird auch hier eine Budgetempfehlung auf Basis des zu Projektbeginn bekannten groben Umfangs der Software gegeben, jedoch erfolgt keine umfassende Detailschätzung der Features, da diese zu Beginn des Projekts noch nicht als definierbar angesehen werden.

Die Priorisierung der Umsetzung von Features erfolgt in der Regel nach dem Wertbeitrag für das Gesamtziel. So werden zentrale Funktionalitäten zuerst umgesetzt und damit möglichst früh die Tauglichkeit des Projektziels unter Beweis gestellt ("Minimum Viable Product"). Weniger zentrale Features werden niedrig priorisiert und deren Definition und Umsetzung in den späteren Projektverlauf verschoben. Die Unschärfe in agilen Projekten entsteht somit eher im Feature-Set als im Gesamtbudget.

Der Projekt-Scope wird also laufend im Auge behalten und den aktuellen Gegebenheiten angepasst. Müssen ursprüngliche Schätzungen für einzelne Features korrigiert werden, werden potenzielle Auswirkungen auf das (Gesamt-)Budget sofort kommuniziert und quantifiziert. Dadurch ist dieder Product Ownerin über den gesamten Projektverlauf in der Lage, informierte Entscheidungen zu treffen. Steuerungsmöglichkeiten bestehen beispielsweise darin, weniger relevante Features zu streichen, eine aufwändige Lösung durch eine einfachere zu ersetzen oder das Budget zu erhöhen.

Um die Steuerung zu ermöglichen, erstellen wir am Ende eines jeden Sprints eine Übersicht über den Budget-Verlauf bereit. Sollten sich potenziell Änderungen am Gesamt-Budget ergeben, bspw. eine Erhöhung durch zusätzliche Anforderungen, werden diese ebenfalls transparent gemacht. Die Entscheidungshoheit obliegt stets dem Kunden.