Montag, 12. August 2013

Scrum for One - Scrum alleine einsetzen Teil 1

Scrum ist eine sehr gute Sache. Ideal für Teams ab 3 Personen. Was machen Freelancer und Entwickler die für sich selbst arbeiten?

ScrumForOne nenne ich die Scrum-Prinzipien auf eine Person umgewandelt. Dabei kann man die Zyklen eines Scrum-Ablaufs auch alleine machen. In meinen nächsten Posts beschreiben ich die einzelnen Teile und wie man Scrum auch alleine machen kann.

Scrum Zyklen

Am Anfang ist der Projektauftrag. Der Produkt-Owner formuliert diesen mittels Userstories. Die Sortierten Userstories stellen das Produkt Backlog dar. Pro Iteration werden einige Einträge aus dem Produkt Backlog in einem Sprint abgearbeitet. Der Sprint hat eine fest Dauer von 2-4 Wochen. Nach dem Sprint wird das erstellte Werk begutachtet und die Planung für den nächsten Sprint kann beginnen. 

Vor der Planung wird die Retrospektive gemacht. Das Team reflektiert den vergangenen Sprint und seine eigene Arbeitsweise. Was war gut, was war weniger gut, was machen wir nun damit wir uns verbessern?
Die weiteren Zwischenschritte und die Umsetzung, wenn man ScrumForOne macht folgen in den nächsten Beiträgen.

Scrum Team besteht aus mehreren Rollen

Product Owner (Produktbesteller, der entscheidet was das Produkt demnächst braucht)
Scrum Master (Moderator und Coach für das Vorgehen im Scrum)
Scrum Team (die Umsetzer)

Alle Scrum Rollen in Einer

In der Regel sollte keine Rolle mit der gleichen Person mehrfach belegt sein. Bei ScrumForOne ist das genau umgekehrt. In der Regel sind alle Rollen mit dem Freelancer besetzt. Idealerweise hat setzt der Freelancer Kundenanfragen um, dann ist er ProductOwner der Auftraggeber. Bei eigenen Projekten ist man alles.

Ohne Disziplin geht Scrum nicht

Diese Art der Umsetzung von Scrum erfordert etwas Disziplin. Man muss sich einen Plan erstellen. Man muss sich an den Plan halten. Man muss so sich selbst reflektieren und verbessern. Ja, man muss sich selbst verbessern wollen.

Anforderungen einsammeln bevor Scrum beginnt

Egal ob im Team oder nicht, man braucht einen Plan. Schreiben Sie die Anforderungen an die Software als Userstories. Bringen Sie die Userstories in eine Reihenfolge. Versuchen Sie die Userstories unabhängig voneinander zu gestalten. Userstories sollten nicht von anderen Userstories abhängig sein. Setzen Sie die wichtigsten Userstories an den Anfang. Die wichtigsten Userstories sind diejenigen, welche das Produkt in der einfachsten Version benötigt und Ihnen eine erste Veröffentlichung ermöglichen könnte.

Wie erstellt man Userstories?

Jede Userstory enthält eine Anforderung mit Nennung des Grundes und von wem diese Anforderung stammt. Der Aufbau folgt:

  • Wer möchte welches Feature, damit Was erreicht wird
  • Als Nutzer will ich Ziel/Wunsch damit Nutzen entsteht
Beispiele:
  • Als User benötige ich eine Kontoübersicht, damit ich meinen Kontostand einsehen kann
  • Als Administrator benötige ich eine Liste mit geblockten Accounts, um schneller einen Überlick zu erhalten
  • Der Service benötigt eine Backup-Option, um Datensicherungen von Kunden erstellen zu können
Halten Sie den Aufbau kurz und präzise. Man kann die Userstories schrittweise verfeinern und in detailiertere Userstories aufsplitten.

Die Userstory erklärt auch den Grund für das Bedürfnis.

Damit kann der Entwickler besser verstehen, was mit diesem Feature erreicht werden soll. So ist er in der Lage die erwartete Funktionalität optimaler umzusetzen. Es entstehen weniger Missverständnisse.

Product Backlog von Scrum

Alle Elemente in Form von Userstories stellen das Product Backlog dar. Diese Elemente sind nach Wichtigkeit für den Product Owner sortiert. Sie beschreiben das ganze Produkt. Anpassungen an der Reihenfolge wird durch den Product Owner immer wieder vorgenommen. Wenn neue Anforderungen entstehen oder gar wegfallen, wird das Product Backlog durch den Product Owner angepasst.

Product RoadMap bietet Übersicht des kompletten Produkts

Die Product RoadMap enthält das Product Backlog. Die Backlog Einträge werden hier in Pakete gepackt. Diese Packet entsprechen den Versionen des Products. Jedes Packet kann in mehrere Bereiche unterteilt werden. In diese Bereiche kommen die Product Backlog Einträge. Damit kann man schnell erkennen, was das Produkt wann können wird. Dabei zeichnet man am Besten eine Kreuztabelle.

Beispiel:

Nutzerverwaltung Verkauf ...
Skeleton Kunden erstellen, Löschen, Bearbeiten
Kunden listen
...
Version 1 Kunden sperren Newsletter erfassen
Newsletter versenden
Shop verlinken, Affiliate tracken
...
...

Scrum Sprint

Die Dauer für einen Sprint wird für das Projekt komplett festgelegt. Sollte zwischen 2 und 4 Wochen sein. In einem Sprint werden Backlog Einträge umgesetzt. Am Ende des Sprints werden die Ergebnisse übergeben.

Das Sprint beginnt mit einer Sprint Planung 1 und Sprint Planung 2. Anschließend werden die abgeleiteten Task aus dem Sprintziel umgesetzt. Jeden Tag wird ein Daily Scrum durchgeführt. Dabei werden die geschafften Tasks erwähnt und die nächsten Tasks genannt. Probleme werden ebenfalls in den Problemspeicher notiert. Der Problemspeicher enthält Störungen und andere Probleme, die beseitigt werden müssen, damit die Umsetzung nicht gestört wird.

Wenn der Sprint fertig ist, werden die erstellten Teile präsentiert. Nicht erstellte Teile oder unfertige Tasks und Produckt Backlog Einträge werden nicht präsentiert. Diese wandern wieder in den Produkt Backlog und werden in der Sprint Planung 1 vom Produkt Owner neu priorisiert.

Scrum Sprint Planung 1

Der ProduktOwner stellt seine Produkt Backlog.Einträge vor. Hier wird die gesamte Produktvision und Story nochmal als Ganzes gesehen. Wenn es Änderungen an den Einträgen gab oder diese umsortiert wurden, wird hier nochmal besprochen ob es Auswirkungen auf das gesamte Produkt gibt.

Die Abhängigkeiten und das eigentliche Produktziel soll im Hinterkopf behalten werden, damit während der Entwicklung entsprechend programmiert wird. Mit diesem Hintergrundwissen kann man leichter Entscheidungen für eine bestimmte Variante oder Vorgehensweise treffen.

Nun werden die umzusetzenden Einträge festgelegt. Dabei werden in Abhängigkeit von der Sprintdauer, die Produkt Backlog-Einträge als Sprintziel definiert. Diese müssen in ein Sprint realisiert werden und ergeben das Sprint Backlog.

Scrum Sprint Backlog

Das Sprint Backlog besteht aus den Produkt Backlog Einträgen, die der Produkt Owner umgesetzt haben möchte und die Entwicklung realistisch in der Zeit eines Sprints umsetzen kann. Die Bewertung der Dauer pro Backlog Eintrag wird durch die Entwickler geschätzt. Bei ScrumForOne sollte man sich bewusst die Einträge ansehen und nur nach der Schätzung auswählen. Nicht nach dem eigenen Wunsch was man alles realisieren will. Das sollte über die Priorisierung geklärt werden.

Scrum Sprint Ziel

Beschreibt was am Ende des Sprints realisiert werden soll. Dabei ist es das Ziel alle Sprint Backlog-Einträge umzusetzen. Das Sprint Ziel kann aber nochmal als Satz formuliert werden. Was wird in dieser Iteration erreicht? Das hilft den Focus zu behalten und kann auch für die Aussenkommunikation genutzt werden. Beispiel: Wir arbeiten gerade an der Realisierung der Bestellabwicklung.

Scrum Sprint Planung 2

Die Einträge aus dem Sprint Backlog werden in kleinere Tasks umgeschrieben und entsprechend in der Umsetzungsreihenfolge erfasst. Durch diese Übersicht, verliert man das Ziel nicht aus den Augen und verhindert, dass man sich in kleine Aufgaben verzettelt. Auch werden so nicht immer wieder neue Baustellen begonnen. Die Vorbereitung der umzusetzenden Aufgaben ist sehr wichtig.

Im Teil 2 folgt:

Definition of Done
Daily Scrum
Sprint Burndown
Inkrement
Sprint Review
Sprint Retrospektive
Grooming
Release Burndown


Keine Kommentare:

Kommentar veröffentlichen