TopMenue

Exemplarischer Projektverlauf

Scrum ist der Rahmen, Scrumcess der Prozess

Ein Teil dieser Seiten wurde ursprünglich für doktor-scrum.de geschrieben und ziehen nun hierher nach scrumcess.de um; leider sind sie aber inhaltlich noch nicht vollständig auf scrumcess.de umgearbeitet. Zudem ist es durchaus möglich, dass die enthaltenen Links noch ins Leere zeigen, bzw. noch auf doktor-scrum.de verweisen.
Ich bitte Sie, das zu entschuldigen.

Exemplarischer Projektablauf eines Scrum-Projektes

[Projektverlauf Scrum]

Die Darstellung ist im Grunde nicht ganz vollständig (es fehlen z.B. als Vereinfachung die Releases) und sieht aufgrund der vielen Pfeile recht kompliziert aus. Im Grunde ist sie jedoch weniger kompliziert, als vielmehr etwas erläuterungsbedürftig.

Pregame (Projektvorlauf)

[Pregame]

Kickoff-Meeting
Der Erste, der in einem konkreten Scrum-Projekt aktiv wird, ist der Product-Owner. Er beginnt bereits im Vorwege des initialen Kickoffs (das in Scrum selbst nicht definiert wird) damit, gemeinsam mit den Stakeholdern (die in diesem Bild nicht genannt werden, da sie vom Product-Owner repräsentiert werden) das Requirement-Engineering, also die Anforderungsanalyse, um zunächst einen Überblick über die Ziele des Projektes herauszuarbeiten und erste Anforderungen konkret zu formulieren. Er erarbeitet darüber hinaus gemeinsam mit den Stakeholdern die Sprint-Vision, die ein wesentliches Element des Kickoff-Meetings und des Projektes sein wird. Ist das Kickoff-Meeting in diesem Sinne ausreichend vorbereitet, wird es gemeinsam mit den Entwicklern und gegebenenfalls weiteren Gästen (z.B. den Stakeholdern) durchgeführt. Diese Vorarbeit und das Kickoff-Meeting werden in Scrum selbst nicht näher definiert und liegen daher außerhalb des Scrum-Projektes. Das Kickoff-Meeting wird einmalig im Vorwege des Projektes als Initiation aller weiterer Beteiligter durchgeführt.

Game (Projekt)

Nach der Durchführung des Kickoff-Meetings begeben sich Product-Owner und Entwicklungsteam erstmalig in das Sprint-Planning; zu diesem Zeitpunkt (genauer gesagt, am Beginn dieses ersten Sprints und jeder einzelne Sprint beginnt immer mit dem Sprint-Planning, Phase 1) befindet sich damit das gesamte Projekt-Team im Projekt.

[Sprint-Planning-1]

Sprint-Planning I
Im Sprint-Planning Phase 1 gehen der Product-Owner und das Entwicklungsteam die Anforderungen, die der Product-Owner für die Realisation im Sprint vorgesehen hat gemeinsam durch, bestimmen den Aufwand jeder einzelnen Anforderung und legen fest, wie viele und welche der Anforderungen im kommenden Sprint zu realisieren sind.

[Sprint-Planning-2]

Sprint-Planning II
Ist diese Phase abgeschlossen, führen die Entwickler die Phase 2 des Sprint-Plannings durch an, der der Product-Owner nur auf Aufforderung der Entwickler zeitweise teilnimmt. Der Product-Owner kann sich in dieser Zeit anderen Aufgaben widmen, zum Beispiel der Weiterführung des Requirement-Engineering.

In der Phase 2 des Sprint-Plannings zerlegen die Entwickler die Anforderungen in einzelne Arbeitspakete, die Tasks.

[Daily-Scrum]

Daily-Scrum
Ist die Phase 2 des Sprint-Plannings abgeschlossen, beginnt das Coding, also das Schreiben des Quellcodes. Ab dem nächsten Arbeitstag führen die Entwickler und der Scrum-Master einmal täglich öffentlich das Daily-Scrum durch, das das Coding für maximal 15 Minuten unterbricht, in dem die Entwickler einander über ihre Aktivitäten des vorangegangenen Tages, die geplanten Aktivitäten des aktuellen Tages und eventuelle Hindernisse informieren.

[Estimation-Meeting]

Estimation-Meeting
Ca. in der Mitte der zweiten Hälfte des Sprints führen der Product-Owner und das Entwicklungsteam dass Estimation-Meeting durch. Im Estimation-Meeting stellt der Product-Owner dem Entwicklungsteam die in naher Zukunft zu realisierenden Anforderungen vor. Im Gegenzug gibt das Entwicklungsteam eine erste Aufwandsschätzung für die vorgestellten Anforderungen ab.

[Review]

Review-Meeting
Neigt sich der Sprint dem Ende zu findet am letzten Tag des Sprints das Review-Meeting statt. Im Review Meeting präsentiert das Entwicklungsteam dem Product-Owner die vollständig fertig realisierten Anforderungen, der sie dann begutachtet und abnimmt oder für eine erneute Bearbeitung zurückweist.

[Check]

Ist das Review-Meeting beendet, beurteilt der Product-Owner ob das Ende des Projektes erreicht ist.

[Retrospective]

Retrospektive-Meeting
Ist das das Ende des Projektes noch nicht erreicht, begibt sich das Entwicklungsteam in das Retrospektive-Meeting. In diesem Meeting spricht das Entwicklungsteam den abgelaufenen Sprint durch beurteilt, was gut, und was nicht so gut abgelaufen ist, identifiziert Verbesserungspotenziale und fast konkrete Beschlüsse zur Verbesserung des Ablaufs, die zeitnah (idealerweise im folgenden Sprint) umzusetzen sind.

Der nächste Sprint
Nun beginnt der nächste Sprint und Product-Owner und Entwicklungsteam treffen sich zur Durchführung des Sprint-Plannings Phase 1.

Dieser Ablauf wiederholt sich so lange, bis das Projekt beendet werden kann. Das Ende des Projektes ist dann erreicht, wenn entweder ein Realisationsfortschritt erreicht wurde, der die Stakeholder die Entscheidung treffen lässt, das Projekt zu beenden, oder wenn andere Ereignisse oder Vorgänge das Ende des Projektes nahe legen.

Postgame (Projektnachlauf)

[zurück zum Seitenanfang]


No comments yet.

Schreibe einen Kommentar

V1503130747DE