Werkzeuge und Methoden
In dieser Lerneinheit lernst du wichtige Werkzeuge für das professionelle Anforderungsmanagement wie DOORS und Jira kennen. Du verstehst die grundlegenden Funktionen dieser Tools und wie sie dir bei der systematischen Erfassung, Verwaltung und Nachverfolgung von Softwareanforderungen helfen. Die praktischen Kenntnisse dieser weit verbreiteten Tools ermöglichen dir eine effiziente und strukturierte Arbeit mit Anforderungen in realen Entwicklungsprojekten.
Einführung
Stell dir vor, dein Team entwickelt eine neue App. Die Deadline rückt näher, aber die Anforderungen ändern sich ständig. Gestern wollte der Kunde noch Feature A, heute ist Feature B wichtiger. Klassische Projektplanung mit starren Phasen und langen Planungszyklen stößt hier an ihre Grenzen.
Wie kannst du in einer Welt ständiger Veränderungen trotzdem qualitativ hochwertige Software liefern?
Die Antwort liegt in agilen Methoden. Sie wurden entwickelt, um genau diese Herausforderung zu meistern: Flexibilität bei gleichzeitig hoher Qualität. Scrum und Extreme Programming (XP) sind dabei die bekanntesten Vertreter.
In dieser Lerneinheit lernst du, wie diese Methoden funktionieren, welche Praktiken sie für Qualitätssicherung einsetzen und wann du welchen Ansatz wählen solltest.
Lernziele
Nach dieser Lerneinheit kannst du:
- die Grundprinzipien agiler Softwareentwicklung erklären und von klassischen Vorgehensmodellen abgrenzen
- die Rollen, Artefakte und Events in Scrum beschreiben und ihre Funktion für die Qualitätssicherung erläutern
- die Kernpraktiken von Extreme Programming (TDD, Pair Programming, CI) benennen und ihren Beitrag zur Softwarequalität bewerten
- entscheiden, wann Scrum, XP oder eine Kombination beider Methoden sinnvoll ist
Überleitung
Klassische Vorgehensmodelle wie das Wasserfallmodell setzen auf detaillierte Vorabplanung und sequenzielle Phasen. Das funktioniert gut, wenn Anforderungen von Anfang an klar sind und sich nicht ändern.
In der Realität sieht es oft anders aus: Kunden entdecken neue Wünsche, Märkte verändern sich, technische Erkenntnisse erfordern Anpassungen.
Agile Methoden begegnen dieser Realität mit kurzen Iterationen, kontinuierlichem Feedback und der Bereitschaft, auf Veränderungen zu reagieren. Schauen wir uns zunächst Scrum an, das am weitesten verbreitete agile Framework.
Was macht agile Methoden aus?
Agile Softwareentwicklung basiert auf vier zentralen Werten, die 2001 im Agilen Manifest festgehalten wurden:
- Individuen und Interaktionen über Prozesse und Werkzeuge
- Funktionierende Software über umfassende Dokumentation
- Zusammenarbeit mit dem Kunden über Vertragsverhandlung
- Reagieren auf Veränderung über das Befolgen eines Plans
Das bedeutet nicht, dass Dokumentation oder Planung unwichtig sind. Es bedeutet, dass die Elemente auf der linken Seite höher gewichtet werden.
In der Praxis führt das zu kurzen Entwicklungszyklen (Iterationen), regelmäßigem Kundenfeedback und der Fähigkeit, auch spät im Projekt noch auf neue Anforderungen zu reagieren.
Scrum: Ein Framework für agile Teams
Scrum ist das am weitesten verbreitete agile Framework. Es gibt Teams eine klare Struktur, ohne den Entwicklungsprozess bis ins Detail vorzuschreiben.
Der Name stammt aus dem Rugby: Beim “Scrum” (Gedränge) arbeitet das Team eng zusammen, um den Ball nach vorne zu bringen. Genau so funktioniert auch Scrum in der Softwareentwicklung.
Scrum definiert drei Rollen, drei Artefakte und fünf Events. Diese Elemente bilden zusammen ein Rahmenwerk, das Transparenz, Überprüfung und Anpassung ermöglicht.
Scrum eignet sich besonders für Projekte mit komplexen Anforderungen und sich ändernden Rahmenbedingungen.
Die drei Rollen in Scrum
Scrum definiert drei klar abgegrenzte Rollen. Jede Rolle hat spezifische Verantwortlichkeiten:
| Rolle | Verantwortung | Fokus |
|---|---|---|
| Product Owner | Vertritt die Interessen der Stakeholder, priorisiert das Product Backlog | Was wird entwickelt? |
| Scrum Master | Sorgt für die Einhaltung von Scrum, beseitigt Hindernisse, coacht das Team | Wie wird zusammengearbeitet? |
| Development Team | Entwickelt das Produkt, organisiert sich selbst, liefert am Ende jedes Sprints ein fertiges Inkrement | Wie wird entwickelt? |
Das Development Team besteht typischerweise aus 3-9 Personen. Es ist cross-funktional, das heißt, es vereint alle Fähigkeiten, die zur Umsetzung der Anforderungen nötig sind.
Die drei Artefakte in Scrum
Artefakte in Scrum dienen der Transparenz und schaffen ein gemeinsames Verständnis:
Product Backlog
Eine priorisierte Liste aller gewünschten Funktionen, Verbesserungen und Fehlerbehebungen. Der Product Owner ist für die Pflege verantwortlich. Einträge oben sind detaillierter als Einträge weiter unten.
Sprint Backlog
Die Auswahl von Product-Backlog-Einträgen, die das Team im aktuellen Sprint umsetzen will, plus ein Plan zur Erreichung des Sprint-Ziels. Das Team aktualisiert es täglich.
Increment
Die Summe aller fertigen Product-Backlog-Einträge am Ende eines Sprints. Es muss der Definition of Done entsprechen und in einem nutzbaren Zustand sein.
Die fünf Events in Scrum
Scrum strukturiert die Arbeit durch fünf Events, die alle einem festen Zeitrahmen (Timebox) unterliegen:
| Event | Dauer | Zweck |
|---|---|---|
| Sprint | 1-4 Wochen | Container für alle anderen Events; am Ende steht ein fertiges Increment |
| Sprint Planning | max. 8h (für 4-Wochen-Sprint) | Team plant, was im Sprint umgesetzt wird und wie |
| Daily Scrum | max. 15 Min. | Tägliche Synchronisation: Was wurde erreicht? Was ist geplant? Gibt es Hindernisse? |
| Sprint Review | max. 4h | Vorstellung des Increments an Stakeholder, Feedback einholen |
| Sprint Retrospective | max. 3h | Team reflektiert den Sprint und identifiziert Verbesserungen |
Die Events schaffen regelmäßige Gelegenheiten zur Überprüfung und Anpassung.
Scrum in der Praxis: Ein Sprint-Beispiel
So könnte ein zweiwöchiger Sprint in einem E-Commerce-Projekt aussehen:
Sprint Planning (Montag, 9:00-12:00)
- Team: 5 Entwickler, 1 Product Owner, 1 Scrum Master
- Sprint-Ziel: “Benutzer können sich registrieren und einloggen”
- Velocity (basierend auf vergangenen Sprints): 30 Story Points
- Ausgewählt: 6 User Stories (28 Story Points)
Daily Scrum (täglich, 9:00, 15 Minuten)
- Entwickler A: “Gestern: Login-Formular fertig. Heute: Backend-Anbindung. Kein Blocker.”
- Entwickler B: “Gestern: Passwort-Validierung. Heute: Unit-Tests. Blocker: API-Dokumentation fehlt.”
- Scrum Master notiert Blocker und kümmert sich darum.
Sprint Review (Freitag der 2. Woche, 14:00-16:00)
- Live-Demo von Registrierung und Login
- Stakeholder-Feedback: “Passwort-Stärke-Anzeige wäre hilfreich”
- 5 von 6 Stories akzeptiert (25 Story Points)
Sprint Retrospective (16:00-17:00)
- Was lief gut: “Pair Programming bei komplexen Features hat geholfen”
- Was verbessern: “API-Dokumentation früher einfordern”
- Action Item: “Definition of Ready um API-Doku ergänzen”
Extreme Programming: Qualität durch technische Exzellenz
Extreme Programming (XP) wurde Ende der 1990er Jahre von Kent Beck entwickelt. Während Scrum den organisatorischen Rahmen vorgibt, fokussiert sich XP auf die technischen Praktiken der Softwareentwicklung.
Der Name “Extreme” kommt daher, dass bewährte Praktiken auf die Spitze getrieben werden:
- Code Reviews sind gut? Dann machen wir Pair Programming und reviewen kontinuierlich.
- Testen ist wichtig? Dann schreiben wir Tests vor dem Code (Test-Driven Development).
- Integration sollte häufig sein? Dann integrieren wir mehrmals täglich (Continuous Integration).
XP eignet sich besonders für Teams, die technische Schulden vermeiden und hohe Codequalität sicherstellen wollen.
Test-Driven Development (TDD)
Test-Driven Development ist eine der wichtigsten XP-Praktiken. Der Ablauf folgt einem einfachen Zyklus:
- Red: Schreibe einen Test für eine neue Funktion. Der Test schlägt fehl (rot), weil die Funktion noch nicht existiert.
- Green: Schreibe gerade genug Code, damit der Test besteht (grün).
- Refactor: Verbessere den Code, ohne das Verhalten zu ändern. Die Tests stellen sicher, dass nichts kaputt geht.
Warum funktioniert das?
Durch TDD entstehen automatisch Tests für jeden Teil des Codes. Du kannst Änderungen vornehmen und sofort sehen, ob etwas nicht mehr funktioniert. Das gibt Sicherheit beim Refactoring und reduziert die Angst vor Änderungen.
TDD führt oft zu besserem Design: Wenn Code schwer zu testen ist, ist er meist auch schlecht strukturiert. TDD zwingt dich, von Anfang an testbaren (und damit oft besseren) Code zu schreiben.
Pair Programming
Beim Pair Programming arbeiten zwei Entwickler gemeinsam an einem Computer:
- Der Driver schreibt den Code und konzentriert sich auf die Details.
- Der Navigator denkt strategisch, überprüft den Code und plant die nächsten Schritte.
Die Rollen werden regelmäßig getauscht.
Vorteile für die Qualität:
- Kontinuierlicher Review: Fehler werden sofort erkannt, nicht erst Tage später im Code Review.
- Wissenstransfer: Erfahrene Entwickler können ihr Wissen direkt weitergeben.
- Bessere Lösungen: Zwei Perspektiven führen oft zu durchdachteren Ansätzen.
- Weniger Ablenkung: Die Hemmschwelle, “mal kurz” E-Mails zu checken, ist zu zweit höher.
Pair Programming kostet zwar kurzfristig mehr Zeit, führt aber langfristig zu weniger Fehlern und besserem Code.
Continuous Integration und Refactoring
Continuous Integration (CI)
Continuous Integration bedeutet, dass alle Entwickler ihre Änderungen mehrmals täglich in einen gemeinsamen Branch integrieren. Jede Integration löst automatisch einen Build und Testlauf aus.
Dadurch werden Integrationsprobleme früh erkannt, wenn sie noch klein und einfach zu beheben sind.
Refactoring
Refactoring ist die Verbesserung der internen Codestruktur, ohne das externe Verhalten zu ändern. XP ermutigt dazu, kontinuierlich zu refaktorieren, statt “technische Schulden” anzuhäufen.
Typische Refactorings:
- Methoden mit sprechenden Namen versehen
- Duplizierter Code in gemeinsame Funktionen auslagern
- Komplexe Bedingungen vereinfachen
- Große Klassen in kleinere aufteilen
Die automatisierten Tests aus TDD geben die Sicherheit, dass beim Refactoring nichts kaputt geht.
Qualitätssicherung in agilen Methoden
Agile Methoden integrieren Qualitätssicherung in den gesamten Entwicklungsprozess:
User Stories und Akzeptanzkriterien
Anforderungen werden als User Stories formuliert, die klare Akzeptanzkriterien enthalten. Dadurch weiß das Team genau, wann eine Anforderung erfüllt ist.
Beispiel:
Als Benutzer möchte ich mein Passwort zurücksetzen können, damit ich wieder Zugang erhalte.
Akzeptanzkriterien:
- Link “Passwort vergessen” auf Login-Seite
- E-Mail mit Reset-Link wird innerhalb von 2 Minuten gesendet
- Link ist 24 Stunden gültig
Definition of Done
Die Definition of Done legt fest, wann eine User Story als “fertig” gilt. Sie enthält typischerweise:
- Code geschrieben und auf Feature-Branch committed
- Unit-Tests geschrieben und bestanden
- Code Review durchgeführt
- In Test-Umgebung deployed und getestet
- Dokumentation aktualisiert
Scrum oder XP? Oder beides?
Scrum und XP sind keine Konkurrenten, sondern ergänzen sich:
| Aspekt | Scrum | XP |
|---|---|---|
| Fokus | Organisation, Prozess | Technische Praktiken |
| Iteration | Sprint (1-4 Wochen) | Iteration (1-2 Wochen) |
| Änderungen im Sprint | Nicht vorgesehen | Erlaubt, wenn Prioritäten sich ändern |
| Technische Vorgaben | Keine | TDD, Pair Programming, CI, etc. |
In der Praxis kombinieren viele Teams beides:
- Scrum für die Struktur: Sprints, Rollen, Events
- XP-Praktiken für die technische Umsetzung: TDD, Pair Programming, CI
Diese Kombination bietet sowohl organisatorische Klarheit als auch technische Exzellenz.
Tipp: Starte mit Scrum für die Grundstruktur und führe XP-Praktiken schrittweise ein, beginnend mit Continuous Integration und automatisierten Tests.
Zusammenfassung
Zusammenfassung
Agile Methoden haben die Softwareentwicklung grundlegend verändert. Statt starrer Phasen und langer Planungszyklen setzen sie auf kurze Iterationen, kontinuierliches Feedback und die Bereitschaft, auf Veränderungen zu reagieren. Das Agile Manifest von 2001 bildet die Grundlage mit seinen vier zentralen Werten: Individuen über Prozesse, funktionierende Software über Dokumentation, Kundenzusammenarbeit über Vertragsverhandlung und Reagieren auf Veränderung über starre Pläne.
Scrum bietet einen organisatorischen Rahmen mit klaren Strukturen:
| Element | Beschreibung |
|---|---|
| Rollen | Product Owner (Was?), Scrum Master (Wie arbeiten wir zusammen?), Development Team (Wie bauen wir es?) |
| Artefakte | Product Backlog, Sprint Backlog, Increment |
| Events | Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective |
Die regelmäßigen Events schaffen Transparenz und ermöglichen kontinuierliche Verbesserung. Die Definition of Done stellt sicher, dass “fertig” für alle das Gleiche bedeutet.
Extreme Programming (XP) ergänzt Scrum mit technischen Praktiken, die hohe Codequalität sicherstellen:
- Test-Driven Development (TDD) führt zu automatisch getesteten Code und besserem Design durch den Red-Green-Refactor-Zyklus.
- Pair Programming bietet kontinuierlichen Code Review und fördert Wissenstransfer im Team.
- Continuous Integration erkennt Integrationsprobleme früh, wenn sie noch einfach zu beheben sind.
- Refactoring hält den Code sauber und wartbar, ohne das Verhalten zu ändern.
In der Praxis kombinieren viele Teams Scrum und XP: Scrum für die Prozessstruktur, XP-Praktiken für die technische Umsetzung. Diese Kombination bietet sowohl organisatorische Klarheit als auch technische Exzellenz.
Die Qualitätssicherung ist dabei kein nachgelagerter Schritt, sondern integraler Bestandteil des gesamten Entwicklungsprozesses. User Stories mit klaren Akzeptanzkriterien, automatisierte Tests und die Definition of Done stellen sicher, dass Qualität von Anfang an eingebaut wird.
Ausblick
In der nächsten Lerneinheit Praxisbeispiele siehst du, wie die Konzepte aus diesem Modul in realen Projekten zusammenspielen. Du lernst anhand konkreter Fallbeispiele, wie Teams Qualitätssicherung in verschiedenen Projektphasen umsetzen und welche Herausforderungen dabei auftreten können.