Planning Poker im Einsatz bei der Softwareentwicklung

Kann Planning Poker helfen, durch die Bündelung des Know-hows von mehreren Team-Mitgliedern zu fundierten Aufwandsschätzungen für Projekte zu gelangen?

Aufwandschätzung mit Planning PokerJedes Entwicklerteam kennt das: Neben der Bewältigung der reinen Programmierungs- und Entwickleraufgaben in den verschiedenen Projekten ist es ebenfalls wichtig, die für die einzelnen Aufgaben benötigten Zeitaufwände möglichst exakt einschätzen zu können. Zahlreiche Methoden und Tools wurden hierfür bereits entwickelt. Unter ihnen auch Planning Poker. Wir Entwickler bei der ADACOR haben Planning Poker testweise eingesetzt. In meinem Artikel gebe ich einen Einblick in die Methode und ziehe ein erstes Fazit zum Potenzial des Tools, aber auch zu dessen Grenzen.

Schätzungen von Anforderungen innerhalb eines Entwicklungsteams sind gar nicht so einfach. Vor allem mit zunehmender Komplexität der Entwicklungstasks. „Spontane“ Änderungsanforderungen und die Dynamik des Entwicklungsprozesses an sich kommen erschwerend hinzu. Planning Poker verspricht hier Abhilfe. Die agile Vorgehensweise soll Entwicklerteams dabei unterstützen, zu realistischen Einschätzungen darüber zu gelangen, wie viel Zeit einzelne Entwicklungs- und Projektaufgaben voraussichtlich in Anspruch nehmen werden. Aber wie funktioniert das genau?

Das Problem mit der Komplexität

Eigentlich könnte man meinen, ein erfahrener Softwareentwickler sollte in der Lage sein abzuschätzen, mit welchem Aufwand bei der Entwicklung eines angeforderten Softwareprojekts zu rechnen ist, wenn die Anforderungen genau genug definiert wurden. Schließlich geht es dabei um seine hauptberufliche Tätigkeit. Doch weit gefehlt: Selbst die erfahrensten Softwareentwickler verschätzen sich mitunter um Faktor zwei, wenn es um ein größeres Projekt geht. Der Grund hierfür liegt in der unberechenbaren Komplexität von Softwareprojekten. Die Lösung einer Teilaufgabe, die man in 30 Minuten zu erledigen glaubte, kann sich durch unvorhersehbare Probleme mitunter über mehrere Tage erstrecken. Leider ist in großen Softwareprojekten genau das keine Ausnahme, sondern eher die Regel.

Die Grundidee: Erfahrung aller Teammitglieder bündeln

Das einzige brauchbare Mittel gegen diese Ungenauigkeit ist viel Erfahrung. Die Idee beim Planning Poker ist es, die Erfahrung mehrerer Softwareentwickler zu bündeln, um zu einer besseren Schätzung zu kommen. Theoretisch könnte man hierzu auch einfach drei Softwareentwickler mit den Anforderungsdokumenten in einen Raum setzen und die Schätzung gemeinsam erarbeiten lassen. Praktisch gibt es dabei aber leider ein allzu menschliches Problem. Und zwar entwickelt sich in jeder Gruppe innerhalb kürzester Zeit automatisch ein Mitglied zum Wortführer. Dieser gruppendynamische Aspekt gründet sich auf den verschiedenen Persönlichkeiten innerhalb der Gruppe. Der Wortführer koordiniert die gemeinsame Arbeit an der Schätzung und beeinflusst dadurch die anderen Gruppenmitglieder. Weiterhin wird der erste, der seine Schätzung zu einem Teilproblem in der Runde nennt, automatisch die Schätzung der anderen Gruppenmitglieder beeinflussen. Von einer echten Bündelung der verschiedenen Erfahrungen kann also nur bedingt die Rede sein.

Gruppendynamik im Griff

Genau an dieser Problematik setzt die Methodik des Planning Poker an. Beim Planning Poker versammeln sich alle Softwareentwickler zusammen mit einem Moderator und idealerweise auch dem Product Owner an einem Tisch. Jeder Entwickler erhält ein Poker Deck mit den Schätzungen 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100. Diese Folge soll die Eigenschaft von Entwicklungstasks abbilden, mit zunehmender Größe und Komplexität ungenauer schätzbar zu sein. Im Zweifel wird stets die höhere Karte gezogen. Die Einheit, in der geschätzt wird, ist erst mal zweitrangig. Neben einer direkten Schätzung in Mannstunden (so machen wir es bei ADACOR) gibt es auch die Möglichkeit der Schätzung in Storypoints. Hierauf werde ich in diesem Artikel jedoch nicht näher eingehen. Moderator und/oder Product Owner erklären also nun die zuvor in Userstories oder Teilprobleme zerlegte Anforderung. Die Entwickler dürfen Rückfragen stellen, bis die Anforderung klar verstanden ist. Daraufhin legt jeder Entwickler verdeckt eine Karte mit seiner Schätzung auf den Tisch. Hierdurch beeinflussen sich die Entwickler nicht gegenseitig und jeder überlegt erst mal für sich. Anschließend werden die Karten umgedreht und eine Diskussion unter den Entwicklern beginnt. Insbesondere die Entwickler mit der höchsten und niedrigsten Schätzung sollten die Gründe für die Schätzung darlegen. Anschließend geht es in die nächste Runde. Wieder legen alle Entwickler verdeckt eine Karte auf den Tisch. Wieder werden die Karten umgedreht. Wieder wird diskutiert. Es wird so viele Runden gepokert, bis nur noch maximal zwei unterschiedliche Werte als Karten auf dem Tisch liegen. Von diesen beiden Werten wird dann gemäß dem Motto „im Zweifel ist der Aufwand höher“ der höhere Wert genommen.

Ohne gezielte Moderation geht es nicht

Lässt man die Entwickler ganz ohne Moderation diskutieren und Runde um Runde Karten legen, kann sich die Schätzung als sehr zeitintensiv herausstellen. Die Schätzung eines Teilproblems kann so leicht zehn Minuten in Anspruch nehmen und damit teuer werden. Wenn beispielsweise insgesamt 20 Teilprobleme zu schätzen sind, kann die Schätzung ohne Moderation ohne Weiteres mehrere Stunden dauern. Daher ist es wichtig, als Moderator frühzeitig in die Diskussion einzugreifen und diese abzubrechen, wenn das Problem genau genug verstanden wurde, um eine fundierte Schätzung abgeben zu können. Nicht jedes kleinste technische Umsetzungsdetail spielt für die Schätzung eine Rolle. Weiterhin verhärten sich in manchen Fällen auch die Fronten unter den Entwicklern, sodass kein Konsens entsteht und daher der Moderator für einen raschen Kompromiss sorgen muss. In einem solchen Fall ist es ratsam, trotz Uneinigkeit die höchste Schätzung zu verwenden. Der Moderator ist ein sehr wichtiges Element beim Planning Poker und hat die Aufgabe, den Aufwand für die Schätzung im vertretbaren Rahmen zu halten. Er sollte selbst erfahrener Entwickler sein. So kann er am besten dafür sorgen, dass die Runde möglichst zügig vorankommt.

Für Initialschätzung großer Projekte ungeeignet

Hat man einige Zeit mit dieser Methode Aufwände von Anpassungen/Erweiterungen und kleinen Tools geschätzt, so fällt schnell auf, dass selbst bei diesen kleineren Entwicklungsaufgaben Disziplin und Moderation notwendig sind, um den zeitlichen Rahmen nicht zu sprengen. Geht es um die Anfrage eines Kunden, wie teuer ein etwas komplexeres Projekt werden wird, so nimmt diese Methode zu viel Zeit in Anspruch. Betrachtet man die zu erwartende Ungenauigkeit der Schätzung großer Projekte, so stimmt das Verhältnis von Aufwand zu Nutzen nicht. Da vor der Schätzung alles in Teilprobleme oder Userstories zerlegt werden muss, schleichen sich naturgemäß viele Unbekannte in die Schätzung mit ein. Man kommt nicht darum herum zu akzeptieren, dass große Softwareprojekte nur sehr ungenau abschätzbar sind. Daher eignen sich hierfür eher andere Schätzmethoden, die ungenauer, aber schneller durchführbar sind. Als Beispiel sei an dieser Stelle das sogenannte „Team Estimation Game“ erwähnt. Bei einem unserer nächsten großen Entwicklungsprojekte werden wir die Schätzung mit dieser Methode durchführen und über unsere Erfahrungen berichten.

Fazit

Planning Poker ist eine sehr gute Methode, um überschaubare Entwicklungsaufwände relativ gut zu schätzen. Innerhalb heterogener Gruppen mit ruhigen introvertierten und extrovertierten Gruppenmitgliedern kommt man durch die Schätzung innerhalb des Pokerspiels mit verdeckten Karten zu guten Ergebnissen, da jedes Gruppenmitglied sich aktiv und unbefangen an der Schätzung beteiligen und sein spezifisches Wissen einbringen kann.

Durch die gebündelte Erfahrung aller Teammitglieder sind unsere Schätzungen besser geworden und wir überziehen seltener Budgets. Jedoch hat die Methode ihren Preis. Zehn Minuten Diskussion bei fünf Entwicklern mit Moderator entsprechen einer Mannstunde. So summiert sich eine Planning-Poker-Session leicht auf einen Manntag Aufwand. Dennoch lohnt sich diese Investition, wenn man mit Kunden arbeitet, die für jede Anpassung einen Festpreis wünschen. Das Entwicklerteam gerät weniger unter Druck und hat es schlussendlich auch selbst in der Hand, wie viel Zeit hinterher für die Umsetzung zur Verfügung steht.

, ,


Weitere Artikel zum Thema lesen

Vorteile des Cloud-Computings – Auswahlkriterien im Überblick

Biz & Trends, Cloud

Vorteile des Cloud-Computings – Auswahlkriterien im Überblick

Der Trend ist eindeutig: Cloud-Computing wird immer beliebter, da es viele Vorteile bietet. Immer mehr Unternehmen verzichten ganz oder teilweise auf eigene Infrastruktur, um...

weiter lesen

Intrusion Detection System – System und Netzwerke richtig absichern

Cloud, Hosting, IT Security, IT-News

Intrusion Detection System – System und Netzwerke richtig absichern

Bei der Entwicklung von Webseiten ist die Absicherung des Systems vor Hacking-Attacken wichtig. So unterstützt ein Intrusion Detection System die frühzeitige Erkennung von Angriffen...

weiter lesen

Erfahrungsbericht - Refactoring eines großen Softwareprojekts

Hosting, IT-News

Erfahrungsbericht – Refactoring eines großen Softwareprojekts

Für einen Kunden haben wir die groß angelegte Umbauaktion eines Intranet Systems mit 4,5 Mio. Zeilen Code umgesetzt. In diesem Beitrag dokumentieren wir für...

weiter lesen


Neueste Nachrichten von ADACOR

IT Security

Hintergründe und aktuelle Informationen zur WannaCry-Attacke

Zum Heulen - wie die bislang größte Malware-Attacke ihren Ausgang nahm und welche Gegenmaßnahmen möglich sind.

weiter lesen

Hosting

Pflege und Aufbau eines Datennetzwerks im Rechenzentrum

Konzeptionelle Vorarbeit inklusive der Planung von Redundanzen beim Aufbau eines Datennetzwerks spart im Betrieb Zeit und Kosten.

weiter lesen

Vulnerability Management

Hosting

Mit Vulnerability Management Sicherheitslücken schließen

Durch regelmäßiges Scannen werden Schwachstellen in Systemen und Applikationen erkannt und beseitigt.

weiter lesen

Diese Seite verwendet Cookies, welche uns helfen, unsere Services anzubieten und zu verbessern.
Erfahren Sie mehr über unsere Cookie-Richtlinien. Durch die Nutzung dieser Website erklären Sie sich mit der Nutzung von Cookies einverstanden.