Vor zwei Monaten habe ich einen ersten Scrum Erfahrungsbericht geschrieben. Damals standen wir noch am Anfang des Projektes. Jetzt zwei Monate später stehen wir mehr oder weniger am Ende. Ein guter Zeitpunkt, um ein kleines (oder grösseres) Fazit zu ziehen.
Wer nicht weiss, was Scrum ist, soll doch am Besten mal bei Wikipedia vorbeischauen. Dort gibt es eine ausführliche Erklärung
Zuerst einige Randbedingungen:
- Als Backlog dient Jira. Eine ältere Version ohne Agile/Scrum Unterstützung
- Sprintdauer sind zwei Wochen.
- Teamgrösse: 4 Entwickler und 1 Designer
- Das Projekt basiert auf Drupal. Es ist eine Tageszeitung mit diversen Schnittstellen an Redaktionssysteme und SDA.
Der Prozess sah ungefähr wie folgt aus:
- Retrospektive. Dazu musste jedes Teammitglied zu den folgenden 4 Punkten Auskunft geben:
- Teamgeist
- Zufriedenheit mit den Tasks
- Ablenkung von Aussen
- Kommunikation im Team
- Backlog schätzen. Wir haben es mit sog. Scrum-Pokerkarten gemacht. Ich persönlich fand diese Methode extrem nützlich.
- Sprint erstmals grob zusammenstellen
- Dem Kunden als ganzes Team zeigen, was wir gemacht haben
- Sprint definitiv festlegen
- Fragen und Details im kleinen Rahmen mit dem Kunden diskutieren
- … sprinten… daily scrum … sprinten … daily scrum… und dann fängts wieder von vorne an
Für die Sprintplanung haben wir ein einfaches Flipchart verwendet, das ungefähr so aussah:
Die blauen Zettel stellen User Stories dar. Die gelben Zettel die daraus resultierenden Tasks. Die Tafel stand in unserem Büro und so hatte jeder stets im Blick, was noch offen ist.
Von der technischen Umsetzung gingen wir grob gesagt wie folgt vor:
- Design kam geliefert als Photoshop Datei
- Drupal Grundinstallation, diverse Grundinhaltstypen
- Zentrale Elemente für die Zugriffsberechtigung auf Artikel
- Implementation der diversen Schnittstellen
- Erstellung der Übersichtsseiten
- Aufräumarbeiten und der ganze Rest
Die ganzen Entwicklungen haben wir in Features gepackt und dann via SVN regelmässig (1x pro Stunde) auf den Entwicklungsserver gestellt. Dadurch hat jeder Entwickler laufend die Änderungen von den anderen Teammitgliedern auch bei sich gehabt und ist zu jederzeit aufgefordert, Bugs in Jira als solches festzuhalten. Kleinere Bugs haben wir daher nicht immer gleich sofort gesammelt, sondern sog. "Bugdays" geplant, an denen sich das Team ausschliesslich Bugs widmet. In diesem Projekt hielt sich die Anzahl an Bugs massiv in Grenzen (oder kommen noch 😉 daher hatten wir auch keine wirklichen "Bugdays".
Damit sind jetzt auch die Randbedingungen klar. Um diesen Eintrag nicht noch weiter in die Länge zu ziehen, werde ich die daraus gezogenen Erfahrungen in einem nächsten Blogpost schildern, denn es gibt doch die eine oder andere Lehre.