Agile Software Development

Das Agile Manifest (4 Werte):

1. Individuen und Interaktionen mehr als Prozesse und Werkzeuge.
2. Funktionierende Software mehr als umfassende Dokumentation.
3. Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung.
4. Reagieren auf Veränderung mehr als das Befolgen eines Plans.

1. MVP (Minimum Viable Product)

Baue nicht das ganze Auto. Baue erst ein Skateboard. (Kann man damit fahren? Ja). Dann einen Roller. Dann ein Fahrrad. Dann das Auto. In jedem Schritt hat der Kunde einen Nutzen. Gegenteil: Erst 4 Räder bauen (nutzlos), dann Fahrgestell (nutzlos), dann Motor... erst am Ende nutzbar.

2. Cross-Functional Teams

Keine "Abteilung für Datenbank" und "Abteilung für Frontend". Ein Team besteht aus Backend, Frontend, Tester und Designer. Sie sitzen zusammen und können ein Feature komplett fertigstellen ("End-to-End"). Das eliminiert Wartezeiten ("Ich warte auf die API vom Backend-Team").

3. Scrum vs. Kanban

Agil ist die Philosophie. Scrum/Kanban sind die Frameworks (die Regeln), wie man es umsetzt. Man kann agil sein ohne Scrum, aber nicht Scrum machen ohne agil zu sein.

1. Agiles Estimation (Planning Poker)

Wie schätzt man ab, wie lange eine Aufgabe dauert, wenn alles flexibel ist? Man schätzt nicht in Stunden (absolute Zeit ist extrem schwer), sondern in relativer Komplexität (oft mit der Fibonacci-Folge: 1, 2, 3, 5, 8, 13) in Form von Story Points. Beim Planning Poker schätzen alle Entwickler gleichzeitig verdeckt, damit der Senior die Junioren nicht beeinflusst ("Anchoring Effect"). Schätzt der Senior eine 3 (trivial, weil er den Code gestern geschrieben hat) und der Junior eine 13 (extrem komplex, völlig unklar), zwingt das Team zur Diskussion. Der Wert an sich ist zweitrangig, die Kommunikation klärt aber Missverständnisse bevor programmiert wird.

2. Technologische Vorbedingungen (Microservices und CI/CD)

Ein oft verschwiegenes Problem: Agilität stoppt fast immer an der Technik ( Conway’s Law). Wenn man einen monolithischen, eng gekoppelten Code hat, können 10 autonome agile Squads nicht gleichzeitig an der Codebase arbeiten, ohne sich bei jedem Merge-Request wütend zu blockieren. Richtige Agilität erfordert eine extrem lockere Kopplung: Microservices. Erst wenn ein Team das Payment-Modul unabhängig deployen kann, ohne das Login-Team zu fragen, funktioniert der agile Traum. Dazu braucht es zwingend vollautomatisierte CI/CD-Pipelines. Wenn Deployments manuell passieren, ist der Sprint tot.

3. Velocity und Burndown Charts

Manager lieben Zahlen, aber Story Points sind keine Währung, die man abteilungsübergreifend vergleichen darf. Ein Team misst seine eigene Velocity (Geschwindigkeit) über mehrere Sprints – also den Durchschnitt an geschafften Story Points. So weiß man: "Wir schaffen meist 40 Punkte pro Sprint". In einem Burndown Chart wird grafisch visualisiert, wie die verbleibende Arbeit über den 2-Wochen-Sprint abnimmt. Bleibt die Kurve lange flach und fällt erst am letzten Tag panisch ab ("Hockey-Stick-Effekt"), nennt man das klassisches "Waterfall im Sprint", oft weil QA erst zum Schluss testet.