Exemplarischer Projektverlauf

Dieser Beitrag befindet sich noch in Bearbeitung!

Scrum ist der Rahmen, Scrumcess der Prozess

Ein 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 erklärungsbedürftig.

[Vorlauf]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 vertreten werden) das Requirement-Engineering, also die Anforderungsanalyse, um zunächst einen Überblick über die Ziele des Projektes herauszuarbeiten und erste Anforderungen konkret zu formulieren. Darüber hinaus erarbeitet er ebenfalls gemeinsam mit den Stakeholdern die Sprint-Vision, die ein wesentliches Element des Kickoff-Meetings 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. Da in Scrum das Kickoff-Meeting nicht definiert wird, liegt es außerhalb des eigentlichen Projektes und wird einmalig im Vorwege des Projektes durchgeführt.

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]

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]

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 sogenannten Tasks. Ist auch diese Phase abgeschlossen, beginnt das Schreiben des Quellcodes. Einmal pro Tag führen darüber hinaus die Entwickler das Daily-Scrum durch.

[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]

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]

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.

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.

[zurück zum Seitenanfang]


No comments yet.

Schreibe einen Kommentar

V1710260636DE