Agiler Software-Entwicklung nach Scrum

Dieser Artikel beschreibt die wichtigsten Aspekte der agilen Software-Entwicklung, einschließlich Epics, User Storys und Scrum Events. Er dient als Orientierung und Referenz für unsere Teams und Kunden, um gemeinsam die agilen Methodiken effektiv umzusetzen unter Verwendung des Scrum-Frameworks.

Der Lasten- und Pflichtenheftansatz ist ein traditioneller Ansatz für die Softwareentwicklung, der in vielen Unternehmen und Projekten angewendet wird. Er basiert auf einer detaillierten und umfassenden Spezifikation der Anforderungen an die Software und legt den Schwerpunkt auf eine umfassende Planung und Dokumentation.

Lastenheft (Requirements Specification): Im Lastenheft werden die Anforderungen an die Software aus Sicht des Kunden oder Auftraggebers festgehalten. Es beschreibt die gewünschten Funktionen, Leistungsmerkmale und Qualitätsanforderungen. Das Lastenheft bildet die Grundlage für die weitere Planung und Entwicklung der Software.

Pflichtenheft (Functional Specification): Das Pflichtenheft wird auf Basis des Lastenhefts erstellt und enthält eine detaillierte Spezifikation der funktionalen und nicht-funktionalen Anforderungen an die Software. Es definiert, wie die Anforderungen umgesetzt werden sollen, und beschreibt die Funktionsweise der Software aus technischer Sicht.

Sequenzieller Entwicklungsprozess: Der Lasten- und Pflichtenheftansatz folgt einem sequenziellen Entwicklungsprozess, bei dem die Phasen der Entwicklung nacheinander abgearbeitet werden. Dies bedeutet, dass jede Phase abgeschlossen sein muss, bevor die nächste begonnen wird. Typischerweise umfasst dieser Ansatz die Phasen der Anforderungsanalyse, der Systementwurf, die Implementierung, das Testen und die Inbetriebnahme.

Umfangreiche Planung und Dokumentation: Ein wesentliches Merkmal des Lasten- und Pflichtenheftansatzes ist eine umfangreiche Planung und Dokumentation. Es werden detaillierte Spezifikationen, Entwürfe, Testpläne und Dokumentationen erstellt, um den gesamten Entwicklungsprozess zu unterstützen und sicherzustellen, dass die Anforderungen erfüllt werden.

Die Waterfall-Methode ist eine spezifische Umsetzung des Lasten- und Pflichtenheftansatzes und folgt einem strikt linearen und sequenziellen Vorgehensmodell. 

Hier sind die Hauptphasen des Waterfall-Ansatzes:

Anforderungsdefinition: In dieser Phase werden die Anforderungen in Form eines Lastenhefts erfasst und spezifiziert. Es werden alle funktionalen und nicht-funktionalen Anforderungen des Kunden identifiziert.

Systementwurf: Im Systementwurf werden detaillierte technische Spezifikationen und Architekturpläne erstellt. Es werden Entscheidungen bezüglich der Softwarearchitektur, der Datenbankstruktur und der Schnittstellen getroffen.

Implementierung: In dieser Phase wird die Software gemäß den Spezifikationen und Plänen entwickelt. Der Code wird geschrieben und die Komponenten werden integriert.

Testen: Nach der Implementierung wird die Software umfassend getestet, um sicherzustellen, dass sie den Anforderungen entspricht und fehlerfrei funktioniert

Bei komplexen Softwareprojekten bedeutet dies häufig eine ausführliche, teilweise monatelange Spezifikationsphase, die aktuellen Anforderungen (z.B. durch Änderungswünschen des Marktes und / oder Stakeholdern) kaum gerecht werden konnte. Hinzu kommt, dass aufgrund der langen Planungsphasen, häufig die eingesetzte und spezifizierte Software bereits zum Erscheinen erster Versionen schon veraltet war.

Scrum ist eine agile Projektmanagement-Methode, die sich stark von traditionellen Ansätzen wie dem Lasten-/Pflichtenheft und dem Waterfall-Ansatz unterscheidet und auf das sogenannte "Agile Manifesto" zurückgeht.  Hier sind die Hauptunterschiede zwischen ihnen:

Flexibilität und Anpassungsfähigkeit: Scrum zeichnet sich durch seine Flexibilität und Anpassungsfähigkeit aus. Es ermöglicht es, dass Anforderungen und Prioritäten während des Projekts geändert werden können. Im Gegensatz dazu basieren das Lasten- und Pflichtenheft sowie der Waterfall-Ansatz auf einer starren und vordefinierten Planung, bei der Änderungen nur schwer umzusetzen sind.

Iterative und inkrementelle Entwicklung: Scrum folgt einem iterativen und inkrementellen Ansatz, bei dem das Projekt in kurzen Zeiträumen, den sogenannten Sprints, entwickelt wird. Jeder Sprint liefert ein inkrementelles Ergebnis. Im Waterfall-Ansatz hingegen wird das Projekt in festen Phasen sequenziell entwickelt, wobei jede Phase abgeschlossen sein muss, bevor die nächste beginnen kann.

Zusammenarbeit und Selbstorganisation: Scrum betont die enge Zusammenarbeit und Kommunikation innerhalb des Entwicklungsteams sowie die Selbstorganisation der Teammitglieder. Das Lasten- und Pflichtenheft sowie der Waterfall-Ansatz setzen hingegen eine hierarchische Struktur und eine strikte Trennung der Verantwortlichkeiten zwischen den Teammitgliedern voraus.

Kundenorientierung: Scrum legt großen Wert auf die Einbeziehung des Kunden während des gesamten Entwicklungsprozesses. Der Kunde wird aktiv in die Planung, das Review und die Priorisierung der Anforderungen einbezogen. Im Gegensatz dazu werden im Lasten-/Pflichtenheft und im Waterfall-Ansatz die Anforderungen im Voraus festgelegt und der Kunde hat begrenzte Möglichkeiten zur Mitgestaltung.

Kontinuierliche Verbesserung: Scrum basiert auf dem Prinzip der kontinuierlichen Verbesserung. Das Team reflektiert regelmäßig und passt seine Arbeitsweise an, um Effizienz und Qualität zu steigern. Das Lasten-/Pflichtenheft und der Waterfall-Ansatz hingegen setzen auf eine vordefinierte Planung, bei der Verbesserungen während des Projekts nur begrenzt berücksichtigt werden können.

Zusammenfassend kann gesagt werden, dass Scrum im Vergleich zum Lasten-/Pflichtenheft und dem Waterfall-Ansatz flexibler, kundenorientierter, iterativer und teamzentrierter ist. Es bietet eine agile Alternative für Projekte, bei denen Anforderungen und Prioritäten sich häufig ändern oder eine enge Zusammenarbeit mit dem Kunden erforderlich ist.

Eines der Grundprinzipien von Scrum ist, dass das Entwicklungsteam und die Projektleitung (Product Owner) im ständigen Austausch stehen und gemeinsam die Anforderungen für die zu entwickelnde Software spezifizieren. Der Product Owner übernimmt hierbei kommunikative Schnittstelle zu den Stakeholdern und vermittelt die Anforderungen, Prioritäten und Business Values an das Entwicklungsteam.

Der Product Owner ist für ein effektives Product Backlog Management verantwortlich, das Folgendes umfasst

• Entwicklung und explizite Kommunikation des Produktziels
• Erstellung und klare Kommunikation von Product Backlog Items
• Anordnen von Product Backlog Items
• Sicherstellen, dass das Product Backlog transparent, sichtbar und verständlich ist

Der Product Owner kann diese Arbeit übernehmen oder die Verantwortung an andere Mitglieder des Scrum-Teams delegieren. Unabhängig davon, wer die Arbeit erledigt, bleibt der Product Owner dafür verantwortlich, dass sie durchgeführt wird und dass der Wert geliefert wird.

Große, noch unspezifische Themen werden hierbei im Product Backlog als Epic geführt. Epics sind große, übergeordnete Anforderungen oder Funktionalitäten, die in kleinere, handhabbare Einheiten aufgeteilt werden können. Sie repräsentieren umfassende Geschäftsziele oder Kundenwünsche. Epics sollten spezifiziert, priorisiert und in User Storys aufgeteilt werden, um einen schrittweisen Entwicklungsprozess zu ermöglichen.