Menü
Ein Beitrag von Adacor

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.

, ,

Die besten IT-News per E-Mail

Immer als Erster über brandaktuelle IT-Themen informiert sein!

Datenschutzhinweise


Weitere Artikel zum Thema lesen

Markt für IT-Sicherheit 2013

Biz & Trends

Markt für IT-Sicherheit 2013

Die Nachfrage nach Technologien und Lösungen zur Verbesserung der IT-Sicherheit wächst. Der Umsatz mit Software und Services bei Virenscannern, Firewalls, Zugriffsverwaltung und Co. steigt...

weiter lesen

Biz & Trends, IT Security

Standardisierte Protokollerstellung mit intranetbasierter Softwarelösung

Die Erstellung von Protokollen mittels webbasierten Software erlaubt es Arbeitsabläufe zu vereinfachen.

weiter lesen

Der magische Stundenplan mit Python

IT-News

Der magische Stundenplan mit Python

Als Azubi hat man es nicht leicht. Allein das Überprüfen des Stundenplans nach gewissen Vorfällen kostet gefühlt viel Zeit. Einmal Zeit investieren, dabei etwas...

weiter lesen


Neueste Nachrichten von Adacor

Biz & Trends

„Recruit a Friend“ – Mitarbeiterempfehlungen als Recruitingmaßnahme

Eine Win-Win-Situation für Mitarbeiter, Bewerber und Arbeitgeber.

weiter lesen

Cloud

Adacor Experten auf IT-Leiter-Kongress treffen

Treffen Sie die Cloud-Experten der Adacor Group auf dem Deutschen IT-Leiter-Kongress. Wir laden Sie ein. Weitere Infos jetzt im Blog lesen.

weiter lesen

Cloud, Hosting

Sichere Migration in die Cloud

Wie erkennt man frühzeitig die Herausforderungen beim Umzug in die Cloud und was muss man tun, um sie erfolgreich zu bewältigen?

weiter lesen