Agile Scrum Entwickler Guide
Agile & Scrum: Praktischer Guide für Entwickler
Scrum ist das beliebteste agile Framework. Lernen Sie die wichtigsten Konzepte aus Entwickler-Perspektive.
Agile Prinzipien (Kurzform)
1. Menschen über Prozesse 2. Funktionierende Software über Dokumentation 3. Zusammenarbeit über Vertragsverhandlung 4. Auf Änderungen reagieren über Plan befolgen
Scrum Rollen
| Rolle | Verantwortung |
|---|---|
| Product Owner | Was gebaut wird, Priorisierung |
| Scrum Master | Prozess, Hindernisse beseitigen |
| Development Team | Wie gebaut wird, Umsetzung |
Sprint-Zyklus
┌─────────────────────────────────────────────────────────────┐
│ Sprint (2 Wochen) │
│ │
│ Planning ──► Daily ──► Daily ──► ... ──► Review ──► Retro │
│ ↓ ↓ ↓ ↓ ↓ │
│ Was machen? Stand Stand Demo Besser │
│ Wie viel? werden│
└─────────────────────────────────────────────────────────────┘
↓
Sprint Backlog
↓
Increment (Lieferbares Produkt)
User Stories
# Format Als [Rolle] möchte ich [Funktion], damit [Nutzen] # Beispiele Als Benutzer möchte ich mich einloggen können, damit ich auf meine Daten zugreifen kann. Als Admin möchte ich Benutzer deaktivieren können, damit ich kompromittierte Konten sperren kann. # Akzeptanzkriterien ✓ Email und Passwort erforderlich ✓ Nach 3 Fehlversuchen Account temporär gesperrt ✓ "Passwort vergessen" Link vorhanden ✓ Redirect zu Dashboard nach erfolgreichem Login
Story Points & Estimation
# Fibonacci: 1, 2, 3, 5, 8, 13, 21 1 Point = Trivial (Config-Änderung) 2 Points = Klein (Einfache Funktion) 3 Points = Mittel (Standard-Feature) 5 Points = Groß (Komplexeres Feature) 8 Points = Sehr groß (Sollte aufgeteilt werden) 13+ = Zu groß (Muss aufgeteilt werden!) # Planning Poker 1. Story vorstellen 2. Fragen klären 3. Jeder schätzt verdeckt 4. Aufdecken 5. Bei großen Differenzen: Diskutieren 6. Neu schätzen
Daily Standup
# 15 Minuten, jeden Tag, gleiche Zeit Jeder beantwortet: 1. Was habe ich gestern gemacht? 2. Was mache ich heute? 3. Gibt es Hindernisse? # ❌ Nicht: - Technische Diskussionen - Problem-Lösung - Status-Report an Manager # ✅ Stattdessen: - Kurz und fokussiert - Hindernisse identifizieren - Synchronisation im Team
Definition of Done
# Wann ist eine Story "fertig"? ☐ Code geschrieben ☐ Code reviewed ☐ Unit Tests geschrieben (Coverage > 80%) ☐ Integrationstests bestanden ☐ Dokumentation aktualisiert ☐ Keine kritischen Bugs ☐ Auf Staging deployed ☐ PO hat abgenommen
Sprint Planning
# Teil 1: Was? - PO stellt priorisierte Stories vor - Team stellt Fragen - Team committed sich zu Stories # Teil 2: Wie? - Stories in Tasks aufteilen - Technische Diskussion - Tasks schätzen # Ergebnis: Sprint Backlog ┌──────────────────────────────────────────┐ │ Sprint Backlog │ ├──────────────────────────────────────────┤ │ Story: Login-Funktion (5 SP) │ │ ☐ API Endpoint erstellen (2h) │ │ ☐ Frontend Form (3h) │ │ ☐ Validierung (2h) │ │ ☐ Tests (3h) │ ├──────────────────────────────────────────┤ │ Story: Password Reset (3 SP) │ │ ☐ Email-Template (1h) │ │ ☐ Reset-Token Logik (2h) │ │ ☐ ... │ └──────────────────────────────────────────┘
Kanban Board
┌─────────┬──────────┬───────────┬─────────┐ │ To Do │ In Prog │ Review │ Done │ ├─────────┼──────────┼───────────┼─────────┤ │ Story C │ Story B │ Story A │ Story X │ │ │ [Max] │ [Anna] │ │ │ Story D │ │ │ Story Y │ │ │ │ │ │ └─────────┴──────────┴───────────┴─────────┘ WIP Limit: Max 2 Stories "In Progress"
Sprint Review & Retrospektive
# Review (Demo)
- Team zeigt fertige Features
- PO gibt Feedback
- Stakeholder stellen Fragen
- PO akzeptiert oder lehnt ab
# Retrospektive
Was lief gut? Was lief schlecht? Verbesserungen?
+ - →
─────────────────────────────────────────────────────
Team half sich Zu viele Meetings Meetings kürzen
gegenseitig
Unklare Requirements Refinement verbessern
Tests sind gut
Deployment manuell CI/CD priorisieren
Velocity
# Story Points pro Sprint Sprint 1: 20 SP Sprint 2: 25 SP Sprint 3: 22 SP Sprint 4: 24 SP ───────────────── Durchschnitt: ~23 SP # Für Planung nutzen: # "Wir schaffen ca. 23 Story Points pro Sprint" # ❌ Nicht für Vergleich zwischen Teams!
💡 Für Entwickler:
- Schätzen Sie ehrlich, nicht optimistisch
- Fragen Sie bei unklaren Requirements nach
- Kommunizieren Sie Hindernisse früh
- Committen Sie nur, was Sie schaffen können