Agiles Vorgehensmodell SCRUM

Klassisch oder agiles Vorgehensmodell

Als klassisches Vorgehensmodell gibt es zum Beispiel das Wasserfallmodell und auf der anderen Seite gibt es bei den agilen Vorgehensmodellen z.B. SCRUM.

Wir bei COUNTIT verwenden agile Vorgehensmodelle wie etwa SCRUM.

Was ist SCRUM?

SCRUM ist eine Vorgehensweise in der Projektplanung und dessen Durchführung.

Hierbei steht eine funktionierende Software über einer umfangreichen Dokumentation.

Die Zusammenarbeit mit dem Kunden ist wichtiger als die Verhandlung von Verträgen und das Reagieren auf Veränderungen steht über dem Befolgen eines Planes.

Verwendung von SCRUM:

Um von einer Vision auf das fertige Produkt zu kommen, erstellt man Anforderungen an das gewünschte Programm, die das Product Backlog bilden.

Nach der Erstellung eines Product Backlog kommen die Sprints, wo diese Anforderungen in Iterationen von zwei bis vier Wochen umgesetzt werden.

Das Ergebnis dieser Sprints ist die lauffähige, inkrementell verbesserte Software.

Rollen in SCRUM:

In SCRUM gibt es mehrere Rollen. Folgende Rollen gibt es:

  • Der (Certified) Product Owner ist eine Person, die den Kunden vertritt und ist somit eine Schnittstelle zum Kunden.
    • Zusätzlich priorisiert der Product Owner die Anforderungen des Projekts.
  • Der (Certified) Scrum Master ist dafür verantwortlich, dass Scrum gelingt und arbeitet mit den Teammitgliedern, gehört aber nicht zu ihnen.
  • Die Team members sind zum Beispiel die Programmierer von dem Projekt.
  • Die Users sind die zukünftigen Benutzer des Programmes.
  • Die Stakeholder sind Rollen außerhalb von Scrum.

Certified Scram Master Certified Scrum Product Owner


Auch in COUNTIT gibt es Certified Scrum Masters und Certified Product Owners.

Product Backlog:

Es werden Anforderungen, sogenannte User Stories, gesucht, die das Programm im fertigen Zustand besitzen sollte.

User Stories bestehen aus einem Satz mit dem Aufbau:    Als [Benutzerrolle] will ich [verlangte Anforderung] sodass ich [Grund].

Gute User-Stories besitzen folgende Eigenschaften:

I Independent Die User Story ist unabhängig von anderen User Stories
N Negotiable Die User Story ist verhandelbar
V Valuable Sie hat einen Wert für den Kunden
E Estimable Sie ist einschätzbar
S Small Sie sollte klein sein
T Testable Die User Story sollte testbar sein



Diese User Stories werden priorisiert in 'MUST HAVE', 'SHOULD HAVE' und 'NICE TO HAVE'.

Auf der Rückseite dieser User Story Karten stehen die Akzeptanzkriterien. Diese Kriterien müssen erfüllt sein, sodass die User-Story abgeschlossen ist.



Definitionen von User Stories

Definition von READY:

Eine User Story ist nur dann "bereit", wenn jedes Team Mitglied das Ziel der Aufgabe versteht, die Aufwandszeit einschätzen kann und die Definition von "DONE" versteht und was dafür getan werden muss.

Definition von DONE:

Sie variiert von Team zu Team. Bei einem Programmierteam wäre sie zum Beispiel: standard gecodet, überarbeitet, Unit-Test (Test-Driven-Development) erstellt, eingebunden und dokumentiert.

SCRUM-Framework

Sprint-Planung

Im Beginn des Sprints wird ein Sprint-Planungsmeeting abgehalten, indem ein Sprint-Ziel festgelegt wird.

Das Ergebnis des Sprint-Ziels ist ein "sinnvolles Ganzes", also ein auslieferbares Produktinkrement.

Daily Scrum:

An jedem Arbeitstag sitzt sich das Entwicklerteam für eine kurze Zeitdauer zusammen um über den derzeitigen Standpunkt zu reden.

Hierbei werden keine Probleme im Projekt gelöst. Bei diesem Daily Scrum sind der Scrum Master und der Product Owner häufig anwesend, sind aber nicht am Gespräch aktiv beteiligt.

Bei diesem Daily Scrum redet jeder Mitarbeiter über die erledigten Tasks und welche Tasks bis zum nächsten Task geplant sind, welche Problem im Weg stehen und ob ein Task länger dauert.

Dauert ein Task länger als gedacht, wird er in Teilbereiche aufgeteilt, die andere Mitarbeiten übernehmen und helfen.

Sprint-Review

Hierbei wird das Produktinkrement von den Stakeholdern analysiert.

Die Software wird dabei in einer Umgebung, ähnlich der wirklichen Produktionsumgebung, mit realen Daten den Kunden, Stakeholdern, Benutzern etc. vorgeführt.

Hierbei werden Erkenntnisse gewonnen, ob Änderungen erfolgen sollen oder dass Anforderungen nicht richtig umgesetzt wurden.

Hierbei können sich sämtliche Beteiligte ein Bild machen, wie weit die Entwicklung voranschreitet.

Sprint Retrospektive

Hierbei wird, anders als bei der Sprint Planung, immer der letzte Sprint fokussiert.

Das Ergebnis einer Sprint Retrospektive ist die Prozessverbesserung.

Planning Poker:

Das Ziel von Planning Poker ist es, gemeinsam effizient zu ermitteln wie lange die Fertigstellung einer User Story dauert. Dabei ist es jedem Teilnehmer jeder Zeit möglich eine kurze Pause einzufordern um konzentriert zu bleiben.

Jedem Teilnehmer steht ein Kartenset zur Verfügung. Dieses besteht je nach Ausführung aus leicht unterschiedlichen Karten, meist setzt sich ein Set aus Null, den Fibonacci-Zahlen bis 13, 20, 50, 100 und einigen Spezialkarten wie Unendlich, Fragezeichen, und Kaffeepause zusammen. Die Werte können als Stunden aber auch als Story-Points verwendet werden, wobei Story-Points, genau wie die meisten Spezialkarten, je nach Situation anders definiert werden können. Nur Kaffeepause sollte eine kurze Pause signalisieren falls sich Teilnehmer kurz sammeln möchten.

Eine User Story wird ohne technische Details erklärt, anschließen sollte jedes Mitglied den Zeitaufwand abschätzen und die Karte verdeckt vor sich legen. Wenn jeder eine Karte abgelegt hat werden sie aufgedeckt. Die Person mit der kleinsten Zeitaufwandeinschätzung und die Person mit der größten Zeitaufwandeinschätzung sollten nun ihre Standpunkte vertreten um dem Zielwert näher zu kommen.

Dieser Vorgang wird bis zu dreimal wiederholt. Am Ende der dritten Runden wird die höchste Zeiteinschätzung als Wert für die User Story verwendet.



Sprint Backlog:

Eine User Story wird in Tasks (Aufgaben) unterteilt.

Diese Aufgaben können entweder "To Do", "In Process", "To Verify" oder "Done" sein.

Der Sprint Backlog wird durch ein Taskboard visualisiert, dass diese Unterteilungen wie "To Do" als Spalten darstellt.

Bei uns in der COUNTIT sieht ein Taskboard folgendermaßen aus:

Taskboard in SCRUM

Ende der Arbeit am Projekt:

Der Product Owner beendet die Arbeit am Projekt.

Dies ist der Fall, wenn genügend Aufgaben, die zur Erfüllung des Zieles gestellt wurden, erreicht sind.