Projektmanagement in der Praxis: SCRUM

am 29 Apr 2011 in Allgemein von

Nachdem in den vorherigen Beiträgen über das klassische Projektmanagement berichtet wurde, möchte ich in diesem Artikel auf eine etwas andere Form des Projektmanagements eingehen. Vielmehr handelt es sich eigentlich um eine Vorgehensmodell und kommt bei der agilen Softwareentwicklung zum Einsatz: SCRUM.

Vor etwa einem halben Jahr sind auch wir in unserer Firma auf SCRUM umgestiegen. Zu Anfang ist es für alle Beteiligten eine große Umstellung, besonders für das Projektmanagement bzw. Produktmanagement. Setzt man es konsequent um bzw. hält sich an die Vorgehensweisen, so stellt man nach einiger Zeit fest, dass es sehr effektiv ist und auch Spaß macht.

Was ist SCRUM?

Im Gegensatz zum klassischen Projektmanagement liegt der Fokus viel stärker auf dem Team. Zu einem vollwertigem SCRUM-Team gehört:

Product Owner
Er ist hauptverantwortlich für das Produkt, welches entwickelt wird. Dazu gehört die Planung und Konzipierung von neuen Features.

Scrum Master
Der Scrummaster ist vorrangig für die Kommunikation und Planung der Ressourcen zuständig.

Entwicklerteam
Schlussendlich benötigt es Entwickler, die zusammen ein Team von optimalterweise 6 bis maximal 8 Personen bilden.

Der Prozess sieht dann wie folgt aus:
Der erste Punkt ist, dass es feste Releasezyklen gibt. Diese können je nach Unternehmen variieren. Gebräuchlich sind 14 Tage, welche einen Sprint darstellen. Das bedeutet, dass alle 14 Tage eine neue Version der Software veröffentlicht wird. Zwischendrin werden lediglich schwerwiegende Fehler behoben.

Scrum Prozess

Diese Grafik stellt den Scrum Prozess mit 14 tägigem Releasezyklus dar. Der obere Kreis (24h) stellt das Daily Scrum dar (siehe weiter unten). Quelle: Wikipedia (http://de.wikipedia.org/wiki/Scrum)

Vom Produktmanagement kommen statt umfangreicher Konzepte sogenannte Userstories, welche lediglich die Funktionalität des Features beschreiben. Dabei ist darauf zu achten, dass eine Story auch wirklich nur eine Anforderung bzw. Funktionalität beinhaltet. Diese Userstories werden vorerst im sogenannten Product Backlog priorisiert gesammelt.

Einmal pro Woche setzt sich dann das komplette Team zusammen und schätzt den Aufwand der Userstories beim Estimation Meeting (natürlich nicht alle, dafür hat das Produktmanagement in der Regel zu viele). Jeder Entwickler bekommt Karten mit aufgedruckten Werten, welche den Aufwand widerspiegeln. Nachdem jedem klar ist, um was es sich bei dieser Story handelt, wird geschätzt und jeder Entwickler hebt eine Karte mit dem Programmieraufwand, den er für diese Story schätzt. Sollte Uneinigkeit herrschen – selten sind sich alle einig -, wird diskutiert, warum wer wieviel geschätzt hat und der Vorgang wird wiederholt, bis jeder dasselbe hat. Das nennt sich übrigens Planning Poker.

Quelle: Wikipedia (http://en.wikipedia.org/wiki/Planning_poker)

Zu Beginn eines jeden Sprints findet das sogenannte Sprintplanning statt. Das hat zum Ziel, sich auf eine Menge von Userstories festzulegen, oder wie es richtig heißt: sich zu committen. Die Anzahl richtet sich schlussendlich an die zur Verfügung stehenden Ressourcen, also in dem Fall wie viel Zeit hat das Team und wieviel schafft es? Diese Stories kommen nun in den Selected Backlog. Anschließend werden die Stories gegebenenfalls noch auf Tasks runtergebrochen, bei dem keiner länger als einen Tag dauern sollte. Die Tasks werden dann in den Sprint Backlog geschoben.
Ab jetzt wird entwickelt. Jeder Entwickler nimmt sich nach Bedarf einen Task und setzt diesen um.

Es gibt noch weitere fest definierte Meetings. Zum einen trifft sich jeden Tag das Entwicklerteam mit dem Scrummaster und reflektiert das zuletzt Geschehene und das noch Kommende. Beim Daily Scrum geht es darum, die anderen Teammitglieder zu informieren, an welchen Aufgaben man gerade dran ist und was für Probleme eventuell die Arbeit behindern. Die Dauer sollte 15 Minuten nicht überschreiten.

Nach einem jeden Sprint folgen noch weitere Meetings, um den Sprint zu resümieren sowie die Ergebnisse dem Product Owner zu präsentieren. Auf Grund der Fülle möchte ich an dieser Stelle aber Schluss machen. Wer sich weiter informieren möchte, der findet im Netz viele Informationsquellen. Dieser Beitrag soll nur einen kurzen Abriss darstellen.

Um aber noch die Frage zu beantworten, warum das ganze Spaß macht: Wie man sieht, ist das Team an sich viel mehr gefordert, was Planung usw. angeht. Die Kommunikation innerhalb des Teams ist wesentlich höher. Das Wichtigste ist: Das Team arbeitet eben als Team. Und genau deswegen, wenn alle dem Modell folgen, ist SCRUM auch sehr effektiv.

Verwendete Schlagwörter: ,

Keine Kommentare vorhanden, schreibe doch einen.

Schreibe ein Kommentar