Agile Entwicklung

Früher (Wasserfall-Modell) hat man Software gebaut wie ein Haus:

Planen (3 Monate)
Bauen (1 Jahr)
Testen (3 Monate)
Fertig! (Und hoffen, dass der Kunde es noch will).

Agile ist anders. Man baut Software eher wie Lego. Man baut kleine, funktionierende Teile in kurzen Abständen (Sprints). Alle 2 Wochen zeigt man dem Kunden etwas Neues: "Hier ist die Login-Seite. Gefällt sie dir?" Kunde: "Nein, mach sie blau." Team: "Okay, ändern wir im nächsten Sprint." Man kann den Kurs ständig korrigieren.

Merksatz: Eine flexible Arbeitsweise, bei der Software in kleinen Schritten entwickelt und ständig verbessert wird.

Das "Agile Manifest" (2001) hat 4 Werte, z. B.:

"Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans."

Die bekanntesten Methoden sind:

Scrum: Feste Regeln. Es gibt "Sprints" (meist 2 Wochen). Jeden Morgen ein 15-Minuten-Meeting ("Daily"). Einen Chef-Organisator ("Scrum Master").
Kanban: Weniger Regeln. Ein Board mit Spalten (To Do -> Doing -> Done). Man zieht Aufgaben durch, so schnell es geht.

1. MVP (Minimum Viable Product)

Das Ziel von Agile ist oft ein MVP. Nicht das perfekte Auto bauen. Sondern erst ein Skateboard (es fährt!). Dann einen Roller (Lenker dazu!). Dann ein Fahrrad. Dann ein Auto. Der Kunde hat sofort einen Nutzen, auch wenn es am Anfang nur basic ist.

2. User Stories

Statt dicken Lastenheften schreibt man "User Stories": "Als Kunde möchte ich mich einloggen können, damit ich meine Bestellungen sehe." Das erklärt das Warum, nicht das technische Wie.

1. Continuous Integration & Epics

Agile funktioniert nur, wenn die Software-Architektur es zulässt. Ein 2-Wochen-Sprint ist wertlos, wenn das Kompilieren und Testen des App-Monolithen 3 Wochen dauert. Deshalb ist CI/CD (Continuous Integration) zwingend: Jedes Code-Stück wird in Minuten vollautomatisch getestet. Dabei hilft die Strukturierung von Aufgaben: Ganz oben steht ein Epic ("Neues Zahlungssystem"). Das wird in User Stories zerteilt ("Kreditkarte hinterlegen"). Diese wiederum zersprengen Entwickler in technische Tasks ("Stripe API Key integrieren"), die klein genug sind, um in 2 Tagen programmiert zu werden.

2. Scrumban und die WIP-Limits

Gereines Scrum zwingt Teams in starre Timeboxen (Sprints). Das ist oft schlecht für IT-Support oder Maintenance-Teams, wo stündlich kritische Bugs einfliegen. Hier nutzt man Scrumban (eine Mischung). Man behält Daily Standups und Retrospektiven, kippt aber Sprints weg. Das wichtigste Instrument ist das WIP-Limit (Work In Progress). Man definiert hart: "In der Spalte 'Testing' dürfen maximal 3 Tickets sein". Ist das Limit voll, muss das gesamte Team als Swarm das Testing unterstützen, bevor neue Aufgaben aus dem Backlog gezogen werden dürfen. Das bricht Flaschenhälse auf ("Stop starting, start finishing").

3. Das Spotify-Modell (Scaling Agile)

Wie skaliert man Agilität auf tausende Entwickler, ohne in Matrix-Organisationen zu ersticken? Spotify wurde berühmt für ihr (theoretisches) Organisationsmodell: Anstatt Abteilungen gibt es Squads (autonome End-to-End Teams wie Mini-Startups für z.B. "Die Suche"). Mehrere Squads, die am gleichen Themenkomplex arbeiten, bilden eine Tribe. Damit die Frontend-Entwickler aus den verschiedenen autonomen Squads nicht völlig verschiedene Tech-Stacks bauen, treffen sie sich quer zur Struktur in horizontalen Chapters (Frontend-Gilde) zum Wissensaustausch.