Vorgehensmodelle in der Entwicklung: Scrum, Kanban, XP

Vorgehensmodelle: Scrum, Kanban, XP

In den ersten Lektionen ging es um Werkzeuge: IDEs, Build-Tools, Linter. Diese Lektion macht einen Schritt zurück und fragt: wie organisiert man eigentlich die Arbeit eines Entwicklungs-Teams? Wer entscheidet, was als Nächstes gebaut wird? Wie viele Features pro Woche sind realistisch? Was passiert, wenn der Kunde plötzlich seine Meinung ändert?

Diese Lektion behandelt agile Vorgehensmodelle – Scrum (Sprint-basiert, mit Rollen und Events), Kanban (Fluss-basiert, kontinuierlich), und Extreme Programming (XP). Du lernst das Agile Manifest und siehst, wie die drei Modelle zusammen oder einzeln eingesetzt werden. IHK-Rahmenplan B1a.

1) Warum agile Methoden?

Klassische Vorgehensmodelle wie das Wasserfall-Modell oder das V-Modell (vgl. K52 L1) gehen davon aus: erst plant man alles durch, dann setzt man es um. Das funktioniert bei vorhersagbaren Aufgaben wie Brückenbau. Bei Software klappt es selten, weil:

Anforderungen ändern sich während des Projekts.
Beim Bauen lernt man, was wirklich nützlich ist.
Märkte und Konkurrenz erzwingen schnelle Reaktion.
Software ist „weicher" als physische Produkte – schnelle Iteration möglich.

2001 formulierten 17 Software-Entwickler das Agile Manifest: vier Werte und 12 Prinzipien, die agile Methoden eint. Bis heute Bezugspunkt.

2) Das Agile Manifest – die vier Werte

Die vier Werte des Agile Manifest (2001)

Individuen und Interaktionenüber Prozesse und Werkzeuge

Funktionierende Softwareüber umfassende Dokumentation

Zusammenarbeit mit dem Kundenüber Vertragsverhandlungen

Reagieren auf Veränderungüber das Befolgen eines Plans

Wichtige Pointe: „über" heißt nicht „statt". Die rechten Werte (Prozesse, Doku, Verträge, Pläne) bleiben wichtig – aber bei Konflikten gewinnen die linken. Wer das Manifest „in Reinform" lebt, ist meistens dogmatisch unterwegs. In der Praxis: pragmatischer Mix.

3) Scrum – das verbreitetste agile Framework

Scrum (von Jeff Sutherland und Ken Schwaber, formalisiert 1995) ist heute das dominante agile Framework. Es organisiert Arbeit in Sprints – feste Zeitfenster (typisch 2 Wochen), in denen ein nutzbares Produkt-Inkrement entsteht.

4) Der Sprint-Zyklus – klick durch

So läuft ein Scrum-Sprint ab. Klick auf die Phasen, um Details zu sehen:

Der Scrum-Sprint-Zyklus

Product Backlog: Eine priorisierte Liste aller Features, Bugfixes und technischer Schulden. Der Product Owner pflegt sie. Oben stehen die wichtigsten Dinge – sie kommen als Nächstes dran. Unten experimentelle Ideen.

Ein Sprint dauert typisch 2 Wochen (kann 1-4 sein, aber 2 ist Standard). Ergebnis jedes Sprints: ein potentially shippable increment – etwas, das man wirklich ausliefern könnte. Auch wenn nicht jeder Sprint live geht, muss das Produkt bei Sprint-Ende production-fähig sein.

5) Scrum-Rollen

Scrum kennt nur drei Rollen – kompakt und klar definiert:

Die drei Scrum-Rollen

Product Owner (PO)

Verantwortlich für das Was. Pflegt das Backlog, priorisiert, definiert Akzeptanzkriterien. Schnittstelle zu Stakeholdern und Kunden. Eine Person, nicht ein Komitee.

Scrum Master

Verantwortlich für den Prozess. Servant Leader: räumt Hindernisse aus dem Weg, coacht das Team, schützt vor Störungen von außen. Kein Chef, eher Coach.

Entwicklungs-Team

Verantwortlich für das Wie. 3-9 Personen, cross-funktional (Backend, Frontend, Tester, Designer). Selbstorganisiert – entscheidet selbst, wer was macht.

Wichtig: das Entwicklungsteam ist cross-funktional. Es sollte alles können, was zum Liefern nötig ist. Kein „erst geht's an die Tester-Abteilung" – Tester sind im Team. Größere Organisationen nutzen Skaliertes Scrum: SAFe, LeSS, Nexus – mehrere Scrum-Teams koordinieren.

6) Kanban – Fluss statt Sprints

Kanban (japanisch für „Signalkarte") stammt aus Toyota's Produktionssystem. In der Software-Welt populär gemacht durch David Anderson. Im Gegensatz zu Scrum: kein fester Sprint, keine Rollen, kein Backlog-Refinement. Stattdessen ein kontinuierlicher Arbeitsfluss über ein Board:

Kanban-Board: WIP-Limits begrenzen den Fluss

To Do ∞

Search-API

i18n DE

In Progress 3

Profil-Page

Pwd-Reset

Review 2

CI-Setup

Done ∞

DB-Migration

Logo-Update

Das Schlüssel-Konzept sind WIP-Limits (Work in Progress): pro Spalte nur eine maximale Anzahl Karten. Wer mit „in Progress = 3" anfängt, darf erst was Neues anfangen, wenn etwas anderes raus ist. Das verhindert „alles parallel angefangen, nichts fertig". Kanban-Tools: Trello, Jira, GitHub Projects, Azure Boards.

7) Extreme Programming (XP)

Extreme Programming (Kent Beck, 1996) ist weniger ein Management-Framework als eine technische Praxis-Sammlung. XP fokussiert auf das, was Entwickler täglich tun:

Pair Programming: zwei Entwickler an einem Bildschirm – einer schreibt, einer denkt.
Test-Driven Development (TDD): erst Test, dann Code – vgl. K52 L5.
Continuous Integration: Code mehrmals täglich in den Hauptzweig (vgl. K54).
Refactoring: Code permanent verbessern (vgl. L5).
Collective Code Ownership: jeder darf jeden Teil ändern.
Small Releases: häufig auslieferbare Versionen.
On-Site Customer: Kunden-Vertreter im Team.
Sustainable Pace: keine Überstunden auf Dauer.

XP-Begriffe wie TDD und CI sind heute Allgemeingut – auch außerhalb von XP-Teams. Wenig Teams nennen sich heute „XP", aber viele Praktiken sind Standard geworden.

8) Direktvergleich: Scrum vs. Kanban vs. XP

Die drei Modelle im Direktvergleich

Aspekt	Scrum	Kanban	XP
Iteration	2-Wochen-Sprint	kontinuierlich	1-3-Wochen-Sprint
Rollen	PO, SM, Team	frei	frei
Planung	Sprint Planning	just-in-time	Planning Game
Backlog	priorisierte Liste	To-Do-Spalte	User Stories
Events	Daily, Review, Retro	nur optional	Daily Standup
WIP-Limits	indirekt (Sprint)	explizit (zentral!)	indirekt
Änderung mitten drin	nicht ohne Aufwand	jederzeit	schwierig
Fokus	Management	Fluss-Optimierung	technische Praktiken

Viele Teams nutzen Scrumban – eine Mischform mit Scrum-Events und Kanban-Flexibilität. Kanban ist besonders gut für Support-Teams und Operations (eingehende Bugs, Tickets). Scrum für Produktentwicklung mit klarer Roadmap. XP-Praktiken kombinieren sich mit allem.

9) Vor- und Nachteile agiler Methoden

Pro: schnelles Feedback, anpassungsfähig, transparenter Fortschritt, motivierte Teams.
Pro: Risiken werden früh sichtbar (in jedem Sprint).
Pro: Kunden sehen früh echte Software, nicht nur Dokumente.
Contra: erfordert disziplinierte Teams – nicht „Anarchie".
Contra: langfristige Planung schwieriger – wann ist Projekt X fertig?
Contra: Festpreis-Verträge passen schlecht zu agilen Methoden.
Contra: ohne erfahrenen Scrum Master verkommt Scrum schnell zu „Mini-Wasserfällen".

10) User Stories und Schätzungen

Ein Mini-Glossar, das in IHK-Klausuren oft auftaucht:

User Story: kurze Beschreibung aus Sicht des Nutzers. Format: „Als <Rolle> möchte ich <Funktion>, um <Nutzen>."
Akzeptanzkriterien: konkrete Bedingungen, die erfüllt sein müssen, damit die Story als fertig gilt.
Story Points: relative Komplexitäts-Einschätzung (1, 2, 3, 5, 8, 13 …). Keine Stunden!
Planning Poker: spielerische Schätzmethode – jeder zeigt verdeckt seine Karte, dann diskutieren.
Velocity: wie viele Story Points schafft das Team pro Sprint? Wird über Zeit gemessen.
Definition of Done (DoD): Team-weite Kriterien, was „fertig" bedeutet (z.B. „Code reviewt, Tests grün, dokumentiert").

Zusammenfassung

Agile Methoden reagieren schnell auf Änderungen. Das Agile Manifest (2001) priorisiert Menschen über Prozesse, funktionierende Software über Doku, Zusammenarbeit über Verträge. Scrum: Sprints (2 Wochen), 3 Rollen (PO, Scrum Master, Team), Events (Planning, Daily, Review, Retro). Kanban: Fluss-basiert, WIP-Limits, kein Sprint. XP: Praktiken wie Pair Programming, TDD, Continuous Integration. User Stories + Story Points + Velocity. Nächste Lektion: Code-Dokumentation.