Auf die Gefahr hin, dass ich doch nie weitere Teile bloggen werde, habe ich riskiert einen Blogeintrag mit “(Teil 1)” im Titel zu schreiben. Statt wie sonst über reine Technologie/Code zu bloggen, möchte ich zur Abwechslung über meine Erfahrungen mit einem Vorgehensmodell – in diesem Fall Scrum – bloggen. Eine Warnung vorweg: Da es um mein erstes Projekt mit Scrum geht muss nicht alles unbedingt 100%ig korrekt sein, was ich hier zu Scrum blogge.
Im Moment arbeite ich als Trainer/Entwickler/Architekt/Berater (im Prinzip ein klein wenig von Allem 
) in einem Webentwicklungsprojekt hier in Paderborn. Das ist eine nette Abwechslung zu den vielen Trainings in den letzten Monaten. So ein “echtes” Projekt ist halt doch immer etwas anderes als reine Technologiedemos zu schreiben.
Unser Team besteht aus 7 Entwicklern, wobei viele davon zum ersten Mal zusammenarbeiten. Bisher gab es in der Firma deshalb auch noch keinen richtigen Entwicklungsprozess für solche Projekte. Ich habe am Anfang länger hin und her überlegt, welche Vorgehensweise wir am besten einsetzen sollten. Da das Team sowieso in der Form noch nicht zusammengearbeitet hat und noch nicht alle Teammitglieder richtig viel Erfahrung in .NET haben sollte es nicht zu kompliziert und umfangreich werden. Eine neue Technologie, ein neues Team, und dann auch noch eine komplizierte neue Vorgehensweise, das wäre sicher zuviel auf einmal. Es sollte also etwas kleines, agiles sein, dass keine größere Einarbeitung und komplizierte Prozesse und Dokumente erfordert.
Ich bin schon sehr früh dabei auf Scrum gekommen, habe aber dann doch eine Weile gebraucht, um mich dafür zu entscheiden. Wir haben nicht die Möglichkeit, es wirklich “wie im Lehrbuch” umzusetzen, deshalb hatte ich erst noch weiter nach Alternativen gesucht. Mangels geeigneterer Alternativen habe ich mich dann doch für Scrum entschieden, bzw. dafür, das aus Scrum zu verwenden, was mir für unser Projekt sinnvoll erscheint.
Scrum ist eine agile Projektmanagement-Methode. Im Vergleich zu anderen, vor allem im Vergleich zu nicht agilen Vorgehensweisen wie Unified Process, V-Modell usw. ist es sehr simpel und einfach und besteht im Prinzip nur aus wenigen einfachen Regeln. Da Alexander – der mir am Anfang netterweise meine ersten Fragen zu Scrum beantwortet hat – auf seiner Seite Scrum-Master.de Scrum sehr schön erklärt, verweise ich einfach mal auf seine Scrum-Einführung für eine ausführlichere Erklärung.
Um das Team aufeinander einzustimmen und quasi zum “warm werden” haben wir nicht gleich mit dem “echten” Projekt angefangen, sondern als Testlauf zunächst eine Software entwickelt, die wir intern zur Erfassung unserer Arbeitszeiten nutzen möchten. Dabei setzen wir nach und nach immer mehr Techniken aus Scrum ein. Eine davon möchte ich heute erklären: Sprints.
Bei Scrum wird die Software in mehreren Iterationen, sogenannten Sprints entwickelt. In einem Sprint wird ein Teil der Anforderungen an die Software (bei uns definiert durch User Stories) vollständig umgesetzt. Die einzelnen Stories sind also komplett implementiert, und vor allem auch getestet und dokumentiert, quasi so, dass die Software danach schon (mit den bis dahin implementierten Anforderungen) ausgeliefert und verwendet werden könnte.
Das hat verschiedene Vorteile: Bei anderen Vorgehensweisen kommt z.B. die Testphase erst am Schluss, und auch andere “unangenehme” Aufgaben wie Dokumentation oder Aufräumen/Refactorn des Codes wird gerne mal aufgeschoben. Plötzlich ist dann das Projektende erreicht, und die für die aufgeschobene Arbeit nicht mehr genug Zeit übrig, um z.B. wirklich gründlich zu testen. Entweder bekommt der Kunde dann schlecht getestete Software, es werden schon halb implementiere Features wieder gestrichen oder der Zeitplan muss verlängert werden.
Da man bei Scrum aber schon am Ende eines Sprints einen quasi fertigen Stand der Software erreicht, ist das Risiko dass es zu solchen Problemen kommt viel geringer. Außerdem erhält man schon sehr früh Software, die zumindest schon einen Teil der geplanten Anforderungen umsetzt und damit auch schon eingesetzt werden könnte.
In unserem Testprojekt dauert ein Sprint genau zwei Wochen. Das Ergebnis des 1. Sprints wird inzwischen von uns schon “richtig” genutzt, um unsere Arbeitszeiten zu protokollieren. Die Qualität unserer Software erscheint mir – insbesondere für so ein neues Team – schon sehr hoch. Wir haben viele Unit Tests mit annehmbarer Code Coverage, der Code ist fast zu 100% kommentiert, und die Software macht einen “runden” Eindruck.
Das war jetzt eigentlich schon zuviel für einen einzelnen Blogeintrag 
. Auch wenn ich noch lange nicht alles zu Scrum geschrieben habe was ich gerne dazu schreiben würde höre ich deshalb für heute damit auf – mehr dazu dann hoffentlich später.
Wie sind eure Erfahrungen mit Scrum? Habt ihr es schon eingesetzt? Was für Methoden/Vorgehensweisen setzt ihr ansonsten in euren Projekten ein?