Lade Inhalt...

Agiles Projektmanagement mit Scrum

Mit Blick auf herkömmliche Managementmethoden

von Holger Staudacher (Autor) Tobias Langenbacher (Autor)

Seminararbeit 2008 38 Seiten

BWL - Unternehmensführung, Management, Organisation

Leseprobe

Inhaltsverzeichnis

1 Einleitung
1.1 Was ist Scrum?
1.2 Was ist agil?
1.3 Warum Scrum?

2 Scrum im Detail
2.1 Scrum Charakteristik
2.2 Anforderungen
2.3 Product Backlog
2.4 Userstorys
2.5 Sprints
2.5.1 Sprint Planning Meeting
2.5.2 Sprint Planning Meeting
2.5.3 Sprint Backlog
2.5.4 Daily Scrum
2.5.5 Sprint Review Meeting
2.5.6 Sprint Retrospektive
2.6 Werkzeuge
2.6.1 Sprint Burndown Chart
2.6.2 Product Burndown Chart
2.6.3 Kapazitätsdiagramm
2.6.4 Velocity

3 Scrum Rollen
3.1 Product Owner
3.2 Team
3.3 Scrum Master
3.4 Kunden

4 Scrum Regeln zusammengefasst
4.1 Allgemein
4.2 Sprintablauf
4.2.1 Planning Meeting
4.2.2 Planning Meeting
4.2.3 Während des Sprints
4.2.4 Sprint Review Meeting
4.2.5 Sprint Retrospektive
4.3 Rollen
4.3.1 Scrum Master
4.3.2 Product Owner
4.3.3 Team

5 Vergleich mit Softwareengineering Modellen
5.1 Wasserfallmodell
5.1.1 Funktion
5.1.2 Wasserfallmodell gegenüber Scrum
5.2 Rational Unified Process
5.2.1 Funktion
5.2.2 RUP gegenüber Scrum
5.3 Extreme Programming
5.3.1 Was ist Extreme Programming?
5.3.2 Extreme Programming und Scrum

6 Vergleich mit herkömmlichem Projektmanagement
6.1 Projektplanung
6.1.1 Planung in Scrum
6.1.2 Projektstrukturplan
6.1.3 Releaseplan gegenüber Projektstrukturplan
6.2 Projektkontrolle und Projektsteuerung
6.2.1 Projektkontrolle und Projektsteuerung in Scrum
6.2.2 Herkömmliche Kontroll- und Steuermöglichkeiten
6.2.3 Herkömmliche Methoden gegenüber Scrum
6.3 Projektmanagementwerkzeuge
6.4 Teammanagement

7 Ausblick

1 Einleitung

Der Begriff Scrum stammt ursprünglich aus der Sportart Rugby und beschreibt einen Spiel- zug. Auf deutsch bedeutet der Begriff so etwas wie „Gedränge“. Bei einem Rugby-Gedränge stehen sich acht Spieler jeder Mannschaft engumschlungen gegenüber und versuchen der gegnerischen Mannschaft stand zu halten. Bei dem Rugby-Spielzug kommt es vor allem auf die Teamfähigkeit an, ob der Spielzug funktioniert oder scheitert. Ähnlich ist es auch bei der Projektmanagementmethode Scrum, von der dieses Dokument handelt.

1.1 Was ist Scrum?

Das Entstehen von Scrum begann Mitte der 1980er Jahre, als es Tendenzen gab, die gängigen Managementmethoden in Frage zu stellen. Zu diesem Zeitpunkt wurden erste agile Konzepte ausgearbeitet, von denen Scrum ein Ergebnis darstellt. Wenn es Scrumerfinder geben sollte, so sind diese Jeff Sutherland und Ken Schwaber. Jeff Sutherland leitete bereits 1993 einige Scrums bei Firmen, jedoch wurde erst 1996, bei der OOPSLA 961 eine erste Definition von Scrum erstellt. Ken Schwaber und Jeff Sutherland arbeiteten diese gemeinsam aus.

Wie bei fast allem, was in den USA erfunden wird, hält auch Scrum nur langsam Einzug in die deutsche Wirtschaft. Vor knapp fünf Jahren gab es eine Präsentation bei der Karlsruher Firma „andrena Objects“, die Scrum in Deutschland vorstellte. 2008 jährte sich diese im Objektforum2 Karlsruhe, in dem Joseph Pelrine eine Bilanz der ersten fünf Jahre Scrum in Deutschland zog. So steigt, laut Joseph Pelrine, die Zahl der zertifizierten Scrum Master, siehe Kap. 3.3, in Deutschland stetig an. Ebenfalls ist Scrum mittlerweile ein echtes Buzz- word3 und gesellschaftsfähig geworden. So werben IT Unternehmen mittlerweile aktiv mit dem Einsatz von Scrum, ein Beispiel hierfür ist die CAS Software AG aus Karlsruhe.

Um die Funktionsweise, den Sinn und die Philosophie von Scrum zu verstehen, werden zertifizierte Scrum Master Kurse von diversen Firmen angeboten. Diese stehen unter der Schirmherrschaft der „Agile Alliance4 “, welche eine Art Qualitätssicherung der Agilen Managementmethoden darstellt. Auch der deutsche Literaturmarkt wird von Scrum erobert, während es im Juni 2007 keine deutsche Puplikation über Scrum gab, existieren bereits im März 2008 vier deutsche Titel über das Thema.

Dieses Dokument soll Scrum als Managementmethoden näher beleuchten und einen Vergleich zu bestehenden Softwareengineering- und Projekmanagementmethoden ziehen.

1.2 Was ist agil?

Das Wort „agil“ oder „Agilität“ ist kein neu erfundenes und bedeutet soviel wie:

„Positive Anpassung auf erforderliche Veränderungen“. Das Hauptmerkmal von Scrum ist al- so die Agilität. Im Scrum Kontext bedeutet dies, dass ein mit Scrum geführtes Projekt nicht durch Veränderungen scheitert, sondern vielmehr daraus positive Resonanz zieht. Scrum ist ein iterativer Prozess. D.h. ein Projekt wird, grob gesagt, in mehrere Stücke zerbrochen und über verschiedene, feste Zeiträume hinweg abgearbeitet. Da die Zeiträume feste Perioden bilden und vor allem nicht parallel ablaufen, kann bei auftretenden Problemen ein rechtzei- tiges Einschreiten das Projekt in eine andere Richtung lenken. Der Stand jedes Projektes wird nach solch einem Zeitraum abgeprüft und kann somit kontrolliert werden, was in eini- gen anderen Methoden nicht der Fall ist.

Diese flexible Vorgehensweise beschreibt man als „empirischen Prozess“. Solch ein Prozess findet in jeder agilen Managementform Platz, da er den Grundstein für Agilität legt. Eine agile Managementmethode zur Softwareentwicklung hält sich an die agilen Prinzipien, diese sind:

-vorhandene Ressourcen mehrfach verwenden
-einfach
-zweckmäßig
-kundennah
-gemeinsamer Code Besitz

Im Februar 2001 wurde das Agile Manifest5 von verschiedenen Software-Engineering-Experten verabschiedet. Dieses besagt, dass agile Managementmethoden vier Grundsatzregeln befolgen müssen, die frei übersetzt, die folgenden sind:

-Individuen und Interaktionen sind wichtiger als Prozesse und Tools
-Funktionierende Software ist wichtiger als ausführliche Dokumentation
-Stetige Kundenkommunikation ist wichtiger als Verträge
-Die Offenheit für Veränderungen ist wichtiger als der strikte Plan

Zusammengefasst kann man sagen, dass agile Prozesse wie Scrum oder Extreme Program- ming eine Sammlung von agilen Methoden wie Pairprogramming, Testdriven Architecture, Refactoring etc. darstellen. Agile Methoden sind Teilverfahren, welche das Agile Manifest nicht verletzen.

1.3 Warum Scrum?

Die Einsatzgebiete von Scrum sind vielseitig, so wurde Scrum als Prozess zur Softwareentwicklung erfunden, jedoch zählt es mittlerweile zu den Projektmanagementmethoden. D.h. um Scrum zu verwenden, muss eine Entwicklungsabteilung komplette Strukturen umstellen. Wie Scrum im Detail funktioniert ist in Kap. 2 beschrieben.

Scrum kommt überall dort zum Einsatz, wo herkömmliche Managementmethoden versagen oder nicht effektiv sind. So bergen klassische Projekte die Gefahr einen Teufelskreis zu bil- den.

Abbildung 1 zeigt einen Teufelskreislauf, wie er häufig in Projekten auftritt. Am Anfang sind die Ziele in Gefahr. D.h. die im Vorfeld geplanten Projektziele können nicht wie gewünscht, nach Zeit oder Qualität, erfüllt werden. Dies zieht die Konsequenz nach sich, dass zum Er- reichen der Ziele mehr Mitarbeiter benötigt werden oder die vorhandenen länger arbeiten müssen. Wenn Mitarbeiter länger arbeiten, arbeiten sie des öfteren unkonzentriert und sind frustriert. Somit sind die Konsequenzen eine schlechtere Qualität der Produkte und unmo- tivierte Mitarbeiter. Da Projekte einen gewissen Qualitätsstandard erfüllen sollten, zieht der letzte Schritt mehr Kontrollen hinter sich her. Bei Kontrollen werden Fehler natürlich entdeckt und müssen korrigiert werden, somit sind die Projektziele wieder in Gefahr. In der Realität zieht dieser Kreislauf natürlich nicht endlose Kreise, Projekte werden vorzeitig be- endet oder nur halbfertig abgeschlossen. Dies bringt bei Kundenprojekten selbstverständlich

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Ein Teufelskreislauf, Quelle 1

eine negative Resonanz mit sich, was konkreten finanziellen Schaden bedeutet.

Da Scrum ein iterativer Prozess ist, der nicht von vorne herein perfekt durchgeplant wird, ist bei richtiger Durchführung solch ein Kreislauf wie in Abbildung 1 unmöglich.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Der Scrum-Kreislauf, Quelle 1

Abbildung 2 zeigt den Kreislauf eines Scrum Projektes, wobei zu beachten ist, dass die Pro- jektplanung auf dem tatsächlichen Fortschritt des Projektes aufbaut. Am Ende einer Itera- tion werden Produktinkremente überprüft. Mit diesen planmäßigen Überprüfungen werden Hindernisse und Probleme frühzeitig erkannt. Ursachen können somit rechtzeitig erkannt und mit den richtigen Maßnahmen, können die Probleme beseitigt werden. Richtige Maß- nahmen sind z.B. Bevollmächtigungen von Mitarbeitern oder Freiheit zur Selbstorganisation, dies führt selbstverständlich zu motivierteren Mitarbeitern.

Ein weiterer Vorteil von Scrum ist die Kundennähe. Kunden bzw. Auftraggeber werden aktiv in verschiedene Teile des Projektablaufs integriert. Hier kann wieder durch Iterationen frühzeitig auf Kundenbedürfnisse reagiert werden. Befriedigte Kundenbedürfnisse haben zufriedene Kunden zur Konsequenz.

Des Weiteren bietet Scrum einen nicht zu vernachlässigenden Vorteil, das Geld. Durch eine Priorisierung von Anforderungen und den iterationsgetriebenen Prozess, ist es möglich, funktionierende Produktinkremente frühzeitig auszuliefern. Dies nennt man „time to market“. Zudem steigt die Produktqualität durch geplante Überprüfung der Ergebnisses und das iterative Planen von Produktinkrementen. Nicht zuletzt wird die Produktivität eines Projektteams gesteigert. Dies geschieht durch das Fokussieren auf wichtige Anforderungen, Bevollmächtigungen oder die Selbstorganisation.

In den nachfolgenden Kapiteln werden die Funktionsweise und Methoden von Scrum näher betrachtet. Anschließend wird ein Vergleich zu herkömmlichen Softwareengineering- und Projektmanagementmethoden gezogen.

2 Scrum im Detail

Der Prozess Scrum besitzt, wie in den voran gegangenen Kapiteln erwähnt, einige Methoden, die diesen definieren. Erwähnt wurde bisher, dass Scrum ein iterativer Prozess ist. Iterationen werden in Scrum “Sprints“ genannt. Sprints sind Zeiträume in denen vordefinierte Anforde- rungen abgearbeitet werden. Des Weiteren gibt es in Scrum nur wenige Rollen, diese wären: Der Product Owner, das Team und den Scrum Master. Weitere Methoden sind spezielle Meetings wie das Daily Scrum Meeting, die Sprint Retrospektive oder diverse Sprint Plan- ning Meetings. Als Analysewerkzeuge stehen dem Scrum Master verschiedene Werkzeuge wie das Burn Down Diagramm, das Team Kapazitätsdiagramm oder einfache Kapazitäts- diagramme zur Verfügung.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Der Scrum Prozess, Quelle 3

Abbildung 3 stellt den Scrum Prozess als Diagramm dar. Am Anfang eines jeden Scrum Projektes wird ein Product Backlog initial gefüllt. Das Product Backlog stellt eine Sammlung von priorisierten Anforderungen dar. Diese werden vom Kunden oder Auftraggeber zusammen mit dem Product Owner definiert. Für jedes Scrum Projekt gibt es eine feste Sprintlänge, d.h. jede Iteration ist z.B. 30 Tage lang. Die Länge von 30 Tagen nicht zu überschreiten, hat sich im Laufe der Jahre, laut Quelle 2 und 1, bewährt.

Vor Beginn eines Sprints, werden zwei Planning Meetings abgehalten. Teilnehmer dieser Meetings sind der Product Owner, der Scrum Master und das Team. Diese suchen in den Meetings aus dem Product Backlog verschiedene Anforderungen heraus (nach Priorität sor- tiert) und brechen diese in kleinere Aufgaben herunter. Hier sollte eine Aufgabe nicht länger als zwei Manntage Kapazität verbrauchen. Die komplette Anzahl der Manntage darf die Kapazität des Teams für den anstehenden Sprint nicht überschreiten. Die herausgesuchten Anforderungen und die daraus erzeugten Aufgaben bilden das Sprint Backlog. Nun startet der Sprint mit einem Daily Scrum Meeting. Wie der Name des Meetings schon sagt, findet dieses täglich statt. In diesem Treffen werden Aufgaben von den Team Mitgliedern ausge- wählt und anschließend bearbeitet. Der Scrum Master moderiert das Meeting und behält Überblick über den Sprintverlauf. Am Ende jedes Sprints soll ein potenziell, auslieferbares Produkt entstehen. D.h. während eines Sprints werden keine Halbfunktionalitäten imple- mentiert. Was die Aufgaben, Rechte und Pflichten der einzelnen Scrum Rollen zu bedeuten haben, wird in Kap. 3 gesondert behandelt. Die nachfolgenden Unterkapitel gehen auf die eben erwähnten Begriffe genauer ein und erklären diese im Detail.

2.1 Scrum Charakteristik

Wie bereits erwähnt, erfüllt Scrum das Agile Manifest. D.h. das agile Manifest ist ein Teil der Philosophie von Scrum, jedoch sind die Punkte des Manifestes nicht die einzigen Charakteristik Merkmale von Scrum.

Scrum beinhaltet nur wenige Rollen, diese sind, wie bereits erwähnt, der Scrum Master, der Product Owner und das Team. Diese drei Rollen sind die einzigen Rollen eines internen Teams, welches aktiv an einem Scrum Projekt arbeitet. Wie dieses Dokument vermittelt, enthält Scrum wenige, aber klare Regeln, die in Kap. 4 kompakt zusammengefasst werden. Des Weiteren gibt es in Scrum, wie in Kap. 2 erwähnt, mehrere Meetings, die alle einem bestimmten Zweck dienen, dieser wird in Kap. 2.5 genauer erklärt. Weitere Charakteristik Merkmale sind laut Quelle 3:

-Einige Schlüssel-Artefakte, deren Pflege Overhead vermeidet und die maximale Transparenz auf einfache Weise bieten
-Pragmatismus statt Dogmatik
-Iteratives Vorgehen
-Selbstorganisation und Eigenverantwortung in interdisziplinären Teams Konzentration auf hochqualitative Arbeit anstatt auf eine Papierflut bei der Spezifi- kation
-Änderungen der Kundenanforderungen während des Projekts gelten als normal, nicht als Störfaktor (es gibt keine „fertige“ Spezifikation)

Zusammengefasst zeigt sich durch die Charakeristik von Scrum, dass es sich um einen schlan- ken Prozess handelt. D.h. Scrum legt mehr Wert auf Effizienz als auf komplexe Regeln und Vorgehensweisen. Scrum ist laut Quelle 1 leicht zu erlernen, aber schwer zu beherrschen. Es bedarf harter Arbeit, um Scrum erfolgreich in einem Unternehmen zu implementieren und anzuwenden, da Scrum starke Gegensätze zu bisherigen Methoden aufweist. In den Kapiteln 5 und 6 werden die Unterschiede zu anderen Verfahren genauer aufgeführt.

2.2 Anforderungen

Anforderungen werden im Scrum Prozess vom Product Owner erstellt. Dieser arbeitet diese in Zusammenarbeit mit dem Kunden, dem Team oder anderen Interessensvertretern aus. Im Gegensatz zu herkömmlichen Projektmanagementmethoden werden Anforderungen nicht vollständig zu Beginn eines Projektes erfasst und anschließend abgearbeitet. Dies sorgt dafür, dass es nicht länger eine separate Definitions- und Umsetzungsphase gibt. In Scrum geschieht die Definition von Anforderungen zeitnah und überlappend mit der Umsetzung.

Bevor ein Scrum Projekt beginnt, werden initiale Anforderungen erstellt. Zu dieser Zeit kann natürlich noch nichts umgesetzt werden. Wenn die initiale Definition abgeschlossen ist, wird der erste Sprint mit den beiden Sprint Planning Meetings begonnen. Das Team und der Scrum Master sind in der Sprintlaufzeit mit der Umsetzung beschäftigt. In dieser Zeit kann der Product Owner zusammen mit dem Kunden oder anderen Interessensvertretern neue Anforderungen erstellen.

2.3 Product Backlog

Die in Kap. 2.2 beschriebenen Anforderungen werden zentral in einem sog. Product Backlog abgelegt. Dieser stellt eine Sammlung von Anforderungen für ein bestimmtes Projekt dar. Das Product Backlog kann neben den Anforderungen noch Ergebnisse, wie z.B. Bugfixes oder Testergebnisse enthalten. Allerdings werden in dem Backlog keine Aktivitäten, sprich Aufgaben, abgelegt. Diese finden im Sprint Backlog Platz, siehe Kap. 2.5.3. Das Besondere am Product Backlog ist, wie Abb. 3 zeigt, dass dieses ständig im Fluss ist. D.h. hier werden Anforderungen etc. angelegt und entfernt. Im Laufe verschiedener Sprints werden diese Anforderungen abgearbeitet und können aus dem Product Backlog gestrichen oder abgehakt werden. Product Backlog Einträge werden priorisiert, wobei der Prioritäts- indikator frei gewählt werden kann, z.B. 1-10 oder A bis D. Hochpriore Anforderungen werden möglichst zu einem frühen Projektzeitraum, sprich in den ersten Sprints, umgesetzt. So wird erreicht, dass die wichtigsten Produktinkremente schnell erledigt sind. Die Form des Product Backlogs kann beliebig gewählt werden, allerdings bieten sich wegen der ständigen Veränderungen digitale Lösungen an, wie z.B. Excel6 Tabellen.

2.4 Userstorys

Userstorys oder Benutzergeschichten sind streng an Anforderungen gekoppelt. D.h. sie beschreiben eine Anforderung. Userstorys bestehen aus einem Namen und einer Beschreibung, wobei die Beschreibung eine Funktionalität aus Endanwendersicht darstellt. Zusätzlich bekommt jede Userstory Akzeptanzkriterien, die als Maß für die Vollständigkeit genommen werden. D.h. wenn eine Anforderung bearbeit wird, so wird gleichzeitig auch die Userstory bearbeitet. Um eine Userstory erfolgreich abzuschließen, müssen alle Akzeptanzkriterien erfüllt sein. Laut Quelle 1 bieten sich für Usertories Karteikarten an, da auf der Vorderseite der Name und die Beschreibung stehen kann und auf der Rückseite die Akzeptanzkriterien. Jedoch ist die Form der Benutzergeschichten frei wählbar.

2.5 Sprints

Wie bereits in den vorangegangenen Kapiteln erwähnt, werden die Iterationen in Scrum Sprints genannt. Sprints haben während der Laufzeit eines Projektes eine feste Länge und sollten nicht unterschiedlich lang sein. Die maximale Länge eines Sprints sollte 30 Tage nicht überschreiten. Ein Sprint ist also ein Arbeitszyklus, in dem Anforderungen vom Scrum Team abgearbeitet werden. Anders als beim gleichklingenden Kurzstreckenlauf, sollten die Mitar- beiter nach einem Sprint nicht erschöpft sein, sondern frisch in einen neuen Sprint starten können.

Eine der wichtigsten Eigenschaften eines Sprints ist seine Unantastbarkeit. D.h. ein Sprintziel darf nicht in einem laufenden Sprint geändert werden. Dies gilt besonders für Entscheidungs- träger, die gerne ihre Meinung ändern. Ein Sprint kann jedoch frühzeitig beendet werden, wenn das Sprintziel nicht erreicht werden kann, oder es z.B. zu einem Projektabbruch kommt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Der Sprint Ablauf, Quelle 1

Abbildung 4 zeigt den Ablauf eines Sprintes. Am Anfang werden in der Sprint Planung, welche in Kap. 2.5.1 und 2.5.2 genauer betrachtet werden, Anforderungen einem Sprint zu- geordnet. Wobei zu beachten ist, dass die Kapazität eines Scrum Teams nicht überschritten wird. In der Umsetzungsphase arbeitet das Team an den Aufgaben der einzelnen Anforde- rungen und trifft sich täglich in einem Daily Scrum Meeting, welches in Kap. 2.5.4 genauer beschrieben ist. Wenn der Sprint sich seinem Ende neigt, d.h. die Periode fast vorbei ist, werden das Sprint Review Meeting und die Sprint Retrospektive abgehalten, siehe Kap. 2.5.5 und 2.5.6. Die Ergebnisse dieser Meetings werden für die nachfolgenden Sprints berücksichtigt und fließen in die nächste Planung mit ein.

Das Wichtigste eines Sprints, ist allerdings sein Ziel. Wie Abb. 3 bereits zeigt, steht am Ende eines jeden Sprints ein potentiell auslieferbares Produkt. Dies kann z.B. in der Soft- wareentwicklung ein separates Modul sein, welches direkt beim Kunden eingesetzt werden könnte. Selbstverständlich kann die Funktionalität eines Produktes nicht nach einem Sprint vollständig implementiert sein, jedoch werden durch die Priorisierung wichtige Inkremen- te schnell realisiert. Das führt zu Kundenzufriedenheit und einem schnellen Erreichen des ROI7.

2.5.1 Sprint Planning Meeting 1

Das Sprint Planning Meeting 1 findet vor jedem Sprint statt. Teilnehmer sind der Product Owner, der Scrum Master und das Team. In diesem Meeting werden Anforderungen aus dem Product Backlog gewählt, die während des anstehenden Sprints bearbeitet werden. Das Planning Meeting 1 dauert mehrere Stunden, denn hier hat das Team die Möglichkeit, auf alle Anforderungen im Detail einzugehen. Der technische Aspekt einer Anforderung wird dabei außer acht gelassen und findet erst im Planning Meeting 2, siehe Kap. 2.5.2, Beachtung.

2.5.2 Sprint Planning Meeting 2

Im Sprint Planning Meeting 2 werden die Anforderungen, welche im Planning Meeting 1 ausgewählt wurden, in einzelnen Aufgaben zerbrochen. Jede Aufgabe wird abgeschätzt, d.h. der benötigte Aufwand für eine Aufgabe wird in Manntagen festgehalten. Laut Quelle 2 sollten Aufgaben die Kapazität von zwei Manntagen nicht überschreiten. Zum Zerlegen von Anforderungen und das Abschätzen von Aufwänden gibt es mehrere Techniken, einige wer- den nachstehend erläutert.

Karteikarten

Jede Anforderung wird auf eine einzelne Karteikarte geschrieben, d.h. der Titel und die Beschreibung der Anforderung. Nun kann jedes Teammitglied einzelne Aufgaben auf eine Karteikarte schreiben. So ergeben sich Aufgabensammlungen, die eine Anforderung vollstän- dig beschreiben. Anschließend werden die Aufwände für die einzelnen Aufgaben von jedem Teammitglied geschätzt, wobei der Mittelwert aller Schätzungen den angesetzten Aufwand darstellt. Die Aufwände aller Aufgaben wird nun summiert. Die Summe stellt den Aufwand der Anforderung dar.

Planning Poker

Planning Poker stellt eine Technik zur Aufwandabschätzung dar. Sind Anforderungen einmal in Aufgaben zerlegt, so lässt sich mit dieser Methode der Aufwand jeder Aufgabe bestimmen. Jedes Teammitglied erhält einen Satz von speziellen Karten. Auf jeder Karte ist eine Zahl notiert, die eine der folgenden ist: 0, 1/2, 1, 2, 3, 4 ,5, 8, 13, 20, 40, 100. Laut Quelle 5 eignen sich diese Zahlen besonders gut und haben sich bewährt. Des Weiteren gibt es Karten mit einem „?“ und mit einer „Kaffeetasse“. Das Fragezeichen steht für einen Joker. D.h. dass damit der Aufwand nicht eindeutig ist. Mit der Kaffeetassenkarte kann eine Pause eingelegt werden.

Nun wird jede Aufgabe einzeln durchgegangen. Jeder Teilnehmer des Meetings schätzt für sich selbst den Aufwand der Aufgabe ab und zieht eine Karte mit entsprechendem Wert. Diese Karte wird verdeckt gehalten. Haben alle Mitglieder eine Karte gezogen, werden alle Karten parallel aufgedeckt. Unterscheiden sich die Werte stark, sind die Teammitglieder mit dem größten und dem kleinsten Aufwand, den anderen Mitgliedern eine Erklärung schuldig. Anschließend wird erneut geschätzt. Dieses Spiel wird dreimal wiederholt. Sollte sich das Team früher einigen, jedoch spätestens nach den drei Durchläufen, wird der Mittelwert aller Karten gebildet und als Aufwand für die Aufgabe eingetragen. Sollte einem Mitglied wäh- rend der Schätzung langweilig werden, kann dieser die Kaffeetassenkarte ziehen und eine kleine Pause machen, dies sollte jedoch nicht zur Regel werden.

Whitechart

Ähnlich wie die Karteikartentechnik wird hier jedes Teammitgleid gefordert. Die verschie- denen Anforderungen werden jeweils auf einem Post-it notiert und untereinander an einem Whitechart befestigt. Anschließend erhält jedes Teammitglied einen Block mit Klebezetteln und notiert dort pro Zettel eine Aufgabe. Anschließend wird die Aufgabe neben die An- forderung als Reihe aufgehängt. Der Erzeuger der Aufgabe sagt jeweils ein paar Sätze zur Aufgabe, damit ihm die anderen Teilnehmer folgen können. Sollten Aufgaben doppelt auf- gehängt werden, wird die doppelte Aufgabe nicht abgerissen. Diese doppelte Aufgabe wird über ihr Äquivalent geklebt, da keine geistige Arbeit verschwendet ist.

Da ein Planning Meeting 2 sehr lange dauern kann, laut Quelle 2 mehr als fünf Stunden, bietet es sich an, regelmäßig Pausen einzulegen. Zeitpunkte für Pausen zeigen sich anhand „toter Punkte“. D.h., wenn die Schätzung ins Stocken gerät und von den Teilnehmern keine neuen Aufgaben erstellt werden. Bei mehrfachem Auftreten dieser Punkte kann man davon ausgehen, dass sich das Meeting dem Ende neigt und alle Aufgaben und Aufwände geschätzt wurden.

[...]


1 The Eleventh Annual ACM Conference on Object-Oriented Programming Systems, Languages and Ap- plications.

2 http://www.andrena.de/ObjektForum/Veranstaltungen/83.html

3 Schlagwort in der IT.

4 http://www.agilealliance.org/

5 http://agilemanifesto.org/

6 Microsoft Excel, Tabellenkalkulations Software

7 Return on Investment

Details

Seiten
38
Jahr
2008
ISBN (eBook)
9783640099573
ISBN (Buch)
9783640133963
Dateigröße
1022 KB
Sprache
Deutsch
Katalognummer
v93614
Institution / Hochschule
Hochschule Furtwangen – CEE
Note
Schlagworte
Agiles Projektmanagement Scrum Managementmethoden

Autoren

Teilen

Zurück

Titel: Agiles Projektmanagement mit Scrum