„Scrum“ nach Ken Schwaber
Scrum vermeidet ein Mikro-Management der Arbeit und definiert wenige Instrumente (wie etwa Gantt-Berichte), schreibt aber den Arbeitsablauf und Spielregeln recht genau vor. Die Arbeit wird in so genannte „Sprints“ oder Arbeitseinheiten von 30 Tagen aufgeteilt. In jedem Arbeitstakt wird eine für die Business-Einheit nützliche Funktionalität produziert, welche produktiv eingesetzt werden könnte.
Die Arbeit läuft folgenderweise ab:
Vorbereitung bzw. Review: Mit Hilfe des Scrum-Leiters bestimmt der Product Owner (Auftraggeber) die funktionelle Spezifikation und setzt die Prioritäten für die Realisierung.
Die Sprint-Planungssitzung: Im ersten Teil kommuniziert der Produktverantwortliche seine Wünsche und Prioritäten und handelt mit dem Team aus, was während dem Sprint zu machen ist. In der zweiten Phase entscheidet das Team, wie diese Funktionalität während dem Sprint zu realisieren ist. Das Team verpflichtet sich zu diesen Zielen.
Der Sprint: 30 Tage lang wird gearbeitet. Am Ende des Sprints soll eine fertige („release“-fähige) Funktionalität bereit stehen. Während des Sprints werden keine Änderungen der Ziele bzw. Aufgabenteilung vorgenommen, es sei denn, der ganze Sprint wird vom Product Owner abgebrochen.
Das tägliche „Scrum“: Jeden Tag 15 Minuten. Jeder Mitarbeiter wird vom Scrum-Leiter gefragt, was er/sie gestern gemacht hat, was heute zu tun ist und ob etwas im Weg steht. Allfällige Hindernisse bzw. Abweichungen zwischen SOLL und IST werden aufgenommen und anschliessend untersucht bzw. behoben.
Die Vorführung: Am letzten Tag des Sprints wird die fertige Funktionalität dem Product Owner und anderen Stakeholdern vorgeführt.
Review/weitere Planung: Auf allen Ebenen werden die Ergebnisse des Sprints evaluiert und die Ergebnisse fliessen in die Planung für den nächsten Sprint ein. Allfällige Änderungen der Spezifikation bzw. Prioritäten können vom Product Owner vorgenommen werden.
Anschliessend folgen weiteren Sprints nach dem gleichen Muster, bis das Projekt abgeschlossen ist.
Die Hauptvorteile dieser Methodik liegen darin, dass:
- Man nach einer ersten Aufbauphase nie mehr als 30 Tage von einer potentiell einsetzbaren Version entfernt ist – ein Gesamtversagen ist fast ausgeschlossen.
- Jeder Arbeitsschritt ein wirtschaftlich nutzbares Ergebnis bringt: Funktionalität, welche eingesetzt werden könnte.
Team und Auftraggeber sind bestens positioniert, um auf neue Information sowie ändernde Prioritäten und funktionale Änderungen zu reagieren. Probleme werden rasch erkannt und aus dem Weg geräumt.
Keine Kommentare:
Kommentar veröffentlichen