Wie schätzt man in agilen Projekten

Literatur  –  0 Kommentare
Anzeige

Boris Gloger
Wie schätzt man in agilen Projekten
– oder wieso Scrum-Projekte erfolgreicher sind

Hanser, 2014
XII + 142 Seiten
€ 29,99
ISBN 978-3-446-43910-8

Wer erwartet, in vorliegendem Buch ein Rezept zum Schätzen von Aufwendungen in agilen Projekten zu erhalten, der wird diese Erwartungshaltung korrigieren müssen. Boris Gloger vertritt die Meinung, das lasse sich nicht vernünftig schätzen. Dennoch stellt er Methoden vor, speziell in agilen Projekten die Dauer vorherzusagen, und zwar als Ableitung der individuellen Teamgeschwindigkeit. Doch das kommt beinahe erst zum Schluss des Buchs. Davor erklärt er, warum seiner Meinung nach traditionelle Schätzverfahren mit schöner Regelmäßigkeit daneben liegen und man den Aufwand am besten gar nicht schätze. Und nach diesem Statement liefert er dem Leser erst einmal wertvolle Informationen zur Durchführung agiler Projekte. Dabei komme dem (technischen) Produktmanager, in der Scrum-Terminologie Product Owner genannt, eine Schlüsselrolle zu. Und diesen spricht der Autor in seinem Buch auch in erster Linie an.

Aufgabe des Product Owner sei nicht nur – wie meist aus Scrum-Büchern zu erfahren –, die Rolle des Kunden im Projekt zu vertreten. Vielmehr müsse er das Produkt mit seinen Visionen in all seinen Phasen vorantreiben. Aber nicht, indem vorgegebenen Anforderungen wie beschrieben umgesetzt werden, sondern indem die Bedürfnisse des Kunden erkannt und eine maßgeschneiderte Lösung erarbeitet werde, mit allen Änderungen, die sich mit wachsenden Erkenntnissen ergeben. Hier gehört auch der Mut, unter Umständen nicht das umzusetzen, was der Kunde will, sondern was er braucht. Und das kann durchaus etwas anderes sein.

Statt lange das gesamte Produkt durchzuplanen, heißt es, frühzeitig zu starten. Das bringt bereits Ergebnisse, während klassische Methoden sich noch in der Schätz- und Findungsphase befinden. So beschreibt er die ersten Phasen agiler Softwareentwicklung, mit den entsprechenden Tools und Techniken, wie sie im Scrum-Umfeld eingesetzt werden, seien es User Stories, Backlog und anderes mehr. Anders als ein typisches Scrum-Buch steht hier nicht das Team, sondern der Produktmanager im Vordergrund – und es ist auf andere agile Methoden übertragbar, die der Autor teilweise auch benennt.

Doch wozu das Ganze, wenn es laut Titel doch um das Schätzen geht? Nun, Gloger schlägt vor, nicht Aufwendungen zu schätzen, sondern Funktionalitäten. Das sei nicht vor Beginn des Projekts möglich, sondern erst zu einem späteren Zeitpunkt, also dann, wenn bereits einige Iterationen mit den zuvor beschriebenen Techniken durchgeführt wurden. Aufgrund des raschen Starts muss dieser Zeitpunkt jedoch nicht unbedingt deutlich nach Schätzzeitpunkten traditioneller Verfahren liegen.

Funktionalitäten werden im Rahmen der vorgestellten Magic Estimation und anderer Schätzverfahren grob als klein, mittel oder groß bewertet, wobei Einteilungen wie 1, 2, 3, 5, 8, 13, 20, 40, 100 möglich sind. Deutlich zu erkennen ist bei einer solchen Skala, das größere Funktionsblöcke nur grob abschätzbar sind. Hier gilt es, umfangreiche Funktionen oder User Stories in eine Reihe kleinerer aufzuteilen, die sich dann entsprechend genauer bewerten lassen. Aber nicht zu Beginn, sondern dann, wenn diese jeweils vor ihrer Realisierung stehen. Zum Schätzzeitpunkt liegen dann bereits erste Erfahrungen des umsetzenden Teams zur Umsetzungsgeschwindigkeit (Velocity) vor. Aus der Anzahl der Funktionen und der individuellen Velocity lässt sich dann leicht eine Dauer hochrechnen. Auch wenn der Autor hier von einer Berechnung spricht, so ist diese natürlich nicht genau, da sie auf einer Schätzung basiert. Diese Berechnungen werden jedoch im Laufe des Projekts immer genauer.

Zum Schluss des Buchs bespricht der Autor die Planung und Durchführung größerer Projekte. Und er schließt mit dem Hinweis, dass die vorgestellte schöne neue Welt für Projektmanager und Vorgesetzte kaum vorstellbar sei. Dennoch, auszuprobieren lohne.

Direkt vom Schätzen in agilen Projekten handelt also nur ein kleiner Teil des Buchs. Wurde damit, gemessen am Titel, das Thema verfehlt? Mitnichten. Die gelungenen Ausführungen zur Projektdurchführung arbeiten auf das Ziel hin, Grundlagen zu schaffen, um im Laufe des Projekts mit einem überschaubaren Schätzanteil recht gute Vorhersagen zu erstellen. So beantwortet das Buch nicht nur die Frage des Titels, sondern bietet deutlich mehr. Empfehlenswert für alle Produktmanager, pardon!, Product Owner. (ane)

Michael Müller
ist als Bereichsleiter Softwareentwicklung der InEK GmbH verantwortlich für Projekte im Web-, Java- und .NET-Umfeld. Daneben betätigt er sich als freier Autor und verfasst Fachartikel zu diversen Entwicklungsthemen sowie Buchrezensionen.

Anzeige