scrum

Scrum ist ein agiler Entwicklungsprozess. Er setzt den Schwerpunkt auf direkte Kommunikation, ermöglich aber trotzdem gute Planung und Dokumentation.

Er setzt das Agile Manifesto um:

  • Individuen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen
  • Funktionsfähige Produkte haben Vorrang vor ausgedehnter Dokumentation
  • Zusammenarbeit mit dem Kunden haben Vorrang vor Vertragsverhandlungen
  • Eingehen auf Änderungen haben Vorrang vor strikter Planverfolgung

Um dies zu erreichen werden zuerst alle Beteiligten in zwei Gruppen aufgeteilt: pigs & chickens.
So sind die pigs die, die unmittelbar zum Erfolg des Produktes beitragen (wie zum Beispiel die Programmierer), alle anderen sind Chickens (wie zum Beispiel die Geschäftsleitung).

Die Gruppenzuordnung bestimmt, wie häufig die entsprechende Person in den Entwicklungsprozess eingreiffen darf. So stehen die Pigs täglich untereinander im Austausch, die Chickens besprechen ihre Anliegen lediglich mit einer Ansprechsperson der Pigs.

pigs

Die pigs sind ein Team von bis maximal 10 Personen. Darin enthalten sind alle Experten, die zur Programmentwicklung benötigt werden.

Sie tauschen sich täglich untereinander über die Projektsfortschritte aus, und sind alle gleichberechtigt, verteilen die Aufgaben untereinander und helfen sich bei auftretenden Problemen. Das Team trägt gemeinsam die Verantwortung für den Projekterfolg.

Zwei Mitglieder des Teams haben zusätzlich spezielle Aufgaben (sie bleiben aber trotzdem gleichberechtigt):

  • der Scrum Master ist der Moderator der Meetings. Er ist damit dafür verantwortlich, dass der Scrum Prozess korrekt ausgeführt wird, und dass alle Impediments (Störfaktoren), die die Teameffizienz beeinträchtigen, aus der Welt geschafft werden.
  • der Produkt Owner priorisiert und bewertet die Arbeit des Teams, er ist die Ansprechsperson falls Fragen betreffend der konkreten Gestaltung des Programmes auftreten. Er geniesst sowohl das Vertrauen des Arbeitgebers als auch das des Teams.

Die Planung

Anforderungen des Projektes werden mittels User Stories und Use Cases formuliert.
User Stories: Als <USER> möchte ich zum
Use Cases: Der <USER> möchte <RESULTAT>

Die so erstellten Anforderungen werden im Product Backlog hinterlegt, und danach vom Arbeitsgeber evaluiert und priorisiert. Anhand dieser Vorgaben wird nun ein Sprint Backlog erstellt: die Vorgaben werden in individuelle Aufgaben unterteilt, deren Aufwand vom Team geschätzt wird.

Nun wird anhand der Entwicklungsgeschwindigkeit des Teams ein Project-Burndown Chart auf Iteration und Release Ebene erstellt.
Die Entwicklung kann beginnen.

Der Sprint

Ein Sprint ist etwa 30 Tage lang. Er ist ein in sich abgeschlossener Prozess an dessen Anfang die Planung des Sprints steht. Während dem Sprint selber werden die konkreten Aufgaben umgesetzt. Am Schluss jedes Sprintes ist eine funktionierende, in sich abgeschlossene Version des Programmes verfügbar.

Planung eines Sprints

Die derzeit wichtigsten Aufgaben werden ausgewählt, und es wird ein Sprint geplant, sodass alle ausgewählten Aufgaben fertig werden.

Wenn die Planung abgeschlossen wurde, wird ein Sprintvertrag zwischen dem Team und dem Arbeitgeber unterzeichnet. Der Vertrag garantiert dem Team, das keine Änderungen an den Anforderungen während dem Sprint gemacht werden. Im Gegenzug garantiert das Team die Ausführung der im Vertrag enthaltenen Aufgaben.

Es wird nun ein Sprint Burndown Char erstellt, der die Sprint Anforderungen visualisiert. Die x Achse ist die Zeit, die y Achse zeigt der geschätzte Arbeitsaufwand der noch zu erledigenden Arbeiten. Gestartet wird bei (0, max(y))

Entwicklungsprozess

Jeden Tag findet ein Daily Scrum statt, ein kurzes Meeting des Teams (5-10min). Jeder schildert knapp, was er gestern gemacht hat und was er heute machen wird. Er meldet sich hier, falls er sich mit jemandem aus dem Team koordinieren muss, oder falls er Hilfe bei einem Problem braucht.

Bei grossen Programmen findet wöchentlich ein Weekly Scrum statt: Ein Delegierter vom Team geht an das sogenannte Scrum of Scrums. Er fasst dort die Ergnisse seines Scrums zusammen und koordiniert mit andern Scrums falls nötig. Bei sehr grossen Programmen kann es sogar ein Meta Scrum geben. Jedes Scrum of Scrums entsendet einen Delegierten, dann geschieht im Prinzip das selbe wie im Weekly Scrum, einfach im grösseren Rahmen.

Ende des Sprints

Nach dem Ende des Sprints ist der y-Wert auf dem Sprint BurndownChart auf 0.

Das Ergebnis des Sprints wird Product Increment genannt, und ist eine funktionierende Version des Programmes. Der umgesetzte Funktionsumfang ist in sich abgeschlossen, und der Product Owner könnte das Programm nun veröffentlichen.

Der vergangene Sprint wird nun vom Team analysiert, positive und negative Aspekte werden gesammelt. Der Scrum Master wertet die Ergebnisse aus, und unternimmt Änderungen am Workflow falls nötig.

Im Sprint Review schliesslich werden die Ergebnisse des Sprints vom Arbeitgeber abgenommen.

Ist das Programm noch nicht fertig, ist nun der Zeitpunkt, um mit der Planung des nächsten Sprints zu beginnen.

Diese Zusammenfassung wurde aus Material von ti8m erstellt, und durch eigene Erfahrungen ergänzt.

Leave a Reply

Your email address will not be published. Required fields are marked *