Vom Aussterben der Dinosaurier und Projektehen am Abgrund

Schätz mich!

Seit nunmehr fast 7 Jahren arbeite ich in einem agilen Softwareprojekt. Das ist eine lange Zeit – länger als manch eine Ehe hält. Vieles hat sich in den Jahren verändert. Was sich aber nicht verändert hat, ist die Tatsache, dass wir als Auftragnehmer neue Anforderungen des Kunden schätzen und (leider) als Festpreis anbieten müssen. So ist unsere Projektehe schon so manches Mal an ihre Grenzen geraten! Dabei spielt das Schätzen eine wichtige Rolle, sodass wir als Entwicklungsteam unser Schätzverfahren über die Jahre ständig verbessert haben.

Seit nunmehr fast 7 Jahren arbeite ich in einem agilen Softwareprojekt. Das ist eine lange Zeit – länger als manch eine Ehe hält. Vieles hat sich in den Jahren verändert. Was sich aber nicht verändert hat, ist die Tatsache, dass wir als Auftragnehmer neue Anforderungen des Kunden schätzen

und (leider) als Festpreis anbieten müssen. So ist unsere Projektehe schon so manches Mal an ihre Grenzen geraten! Dabei spielt das Schätzen eine wichtige Rolle, sodass wir als Entwicklungsteam unser Schätzverfahren über die Jahre ständig verbessert haben. Zunächst sind wir im Projekt der traditionellen Idee der Expertenschätzung gefolgt. „Experte“ klingt erst einmal so, als seien daran die guten, richtigen Leute beteiligt. Leider stellt sich oft heraus, dass der Experte sich zwar in der Softwareentwicklung gut auskennt, aber weniger ein Experte im Schätzen ist. Denn diese Art der Schätzung legt keine konkrete Vorgehensweise fest. Natürlich hat jeder schon mal von Function Points gehört und vielleicht sogar von CoCoMo (II). Offen gesagt sieht man diese Dinge nur im Studium, selten wird man ihnen in der freien Wildbahn eines Festpreises begegnen. Allerdings helfen sie mit ihren grundsätzlichen Ideen weiter, ein eigenes Schätzverfahren zu etablieren: Anforderungen abstrakt in ihrer Größe zu bewerten (FP) und die Abarbeitungsgeschwindigkeit getrennt zu betrachten (CoCoMo), sind zwei enorm wichtige Punkte. In Anlehnung an das Darwin-Jahr 2009 stelle ich nun unsere kleine Evolution der Schätzverfahren vor.

Anforderung auf Zuruf

Zu Projektbeginn sollte mit 5 Leuten in einem halben Jahr ein Prototyp entwickelt werden und – wie herrlich – es gab kaum ein Dokument dazu. Allerdings hatten wir einen Product Owner, der eine gute Vision im Kopf hatte und noch dazu mal Anwender war. Der Zeitrahmen war fest (Timebox), und es ging darum, möglichst viele sinnvolle Einsatzgebiete der Software aufzuzeigen. Die Software wurde regelmäßig begutachtet und daraus wurden neue Anforderungen ermittelt. Diese wurden kurz geschätzt, eingeplant und erledigt, um sie danach wieder schnell zu begutachten usw. Der Product Owner wird später immer wieder auf diese gute alte Zeit verweisen, denn hier konnte er die Entwicklung noch optimal steuern. Da die Größe der Anforderungen übersichtlich war, blieben wir in der geschätzten Zeit. Bald stand der erste große Evolutionssprung bevor, denn der zahlende Kunde (IT-Abteilung) wollte zukünftig Festpreise machen.

Die gigantische Excel-Liste

Durch den Prototyp war uns allen einigermaßen klar, was die Anwendung unterstützen sollte. Nun trug der Kunde in einer sehr großen Excel-Liste „Anforderungen“ ein, die sehr, sehr kurz beschrieben waren. Diese Anforderungen (eigentlich sollte man sie besser „Ideen“ nennen) sollten später in der bewährten agilen Entwicklungsweise ausgestaltet werden. Jetzt musste noch schnell ein Festpreis her. Die Zeit war knapp, die Ressourcen zum Schätzen begrenzt, und so wurde der erste Festpreis schnell von ein paar Entwicklern zusammengezimmert. Im Nachhinein muss man sagen, dass wir hier agile Softwareentwicklung falsch verstanden haben: Kurz Visionen aufzuschreiben, einen Festpreis dran zu kleben und den Umfang „agil viel“ werden zu lassen, funktioniert so nicht! Die Kosten galoppierten davon. Der Product Owner hat immer wieder auf Dinge hingewiesen, die ihm noch fehlten, die wir aber nicht berücksichtigt hatten. Das führte oft zu belastenden Diskussionen: Was kann man aus den groben Anforderungen herauslesen und was nicht? Wäre anderswo wohl ein Fall für den Eheberater geworden! Die meisten strittigen Dinge haben wir kostenlos realisiert, weil wir gute Software abliefern wollten. Dadurch hatten wir eine hohe Akzeptanz der Software, weshalb die Evolution auch weitergeht.

Der Projektleiter würfelt

Neben dem Hickhack um die bestehenden Anforderungen gab es bald die ersten neuen Anforderungen. DIE Chance für ein besseres Schätzverfahren. Noch ließen wir uns von der Idee leiten, möglichst wenig Aufwand in die Schätzung zu stecken. Allerdings sollten die Anforderungen nun besser beschrieben sein. So hat meist der mitentwickelnde Projektleiter allein geschätzt. Der musste sich doch am besten mit der Materie auskennen, denn schließlich hatte er die Anforderungen ja zusammen mit dem Product Owner konkretisiert. Gleichzeitig entstanden die ersten größeren Software-Lebensformen, deren Entwicklungsdauer über Burndown-Charts bewertet werden konnten. Da wir die Tasks unterschiedlich groß geschnitten haben, war unsere Tracking nicht so stabil wie gedacht. Somit hat der Projektleiter dann eher nach seinem Bauchgefühl geschätzt – ebenso gut hätte er würfeln können. Dass eine einzelne Person immer mal etwas übersieht und die Geschwindigkeit einer einzelnen Person nicht der des Teamdurchschnitts entspricht, hat das Würfeln nicht besser gemacht.

Die Wette um das Monatsgehalt

Aus Sicht des Teams hatte der Projektleiter häufig schlechte und unrealistische Schätzungen abgegeben. Aus Sicht des Projektleiters hatte das Team seine realistischen Schätzungen einfach ignoriert und war jedes Mal aufs Neue zu langsam gewesen. Damit sollte nun Schluss sein! Ab sofort schätzten wir alle zusammen. Gemeinsame Schätzungen sind zwar teuer, reduzieren aber das Risiko von späteren, deutlich teureren Überraschungen. Schaut der Kunde auf höhere Schätzkosten, wittert er natürlich Verschwendung und meckert auch mal darüber. Jetzt wird‘s psychologisch: Dadurch, dass alle schätzen, stehen auch alle in der Verantwortung. Durch das Mehr an Verantwortung zerpflückt das Team die Anforderungen genau, wodurch Lücken vor der Preisauskunft vom Team entdeckt werden. Das ist ein Gewinn für den Kunden, denn dadurch kann er frühzeitig zu besseren Anforderungen kommen. Zusätzlich ist es hilfreich, alle Teammitglieder einen (selbst gewählten) Betrag auf das Einhalten der Schätzung wetten zu lassen. Das Wetten vermittelt ein Gefühl, ob jeder tatsächlich hinter der gemeinsamen Schätzung steht.

Das Dinosaurierdilemma

Zuerst hatten wir in klassischer agiler Manier jede Task Card mit 1 bis 5 Aufwandspunkten versehen. Jedoch waren wir dabei der Unsitte verfallen, unklare Aufgaben in eine 5-Punkte-Karte abzuschieben. Eine solche Karte hatte damit nie den gleichen Aufwand wie fünf Karten mit einem Punkt. Diese Dinosaurierkarten sollten aussterben. Also haben wir uns fortan bei jeder Brachiosaurus-Karte gefragt, ob wir sie in kleinere Säugetierkarten aufspalten können. Die Realisierung jeder einzelnen Anforderung wurde jetzt durch einzelne Features beschrieben, von denen (nach unserer Schätzung) jedes innerhalb eines Personentages erledigt werden konnte. Und siehe da: Die Unsicherheit verschwand durch die Featurelisten. Während der Entwicklung haben wir sie selten verändert, weil vorher etwas übersehen worden wäre. Der Preis für diese Genauigkeit war erneut eine aufwändigere Schätzung. Im Fall einer zeitnahen Realisierung hatte sich diese genaue Aufspaltung jedoch wiederum gelohnt, da die Aufgaben jedem klar waren. Übrigens: Wir haben später im Schnitt 1,8 Personentage pro Feature gebraucht, denn die zahlreichen Aufgaben neben der Entwicklung haben uns hinreichend abgelenkt.

Das Dinosaurierdilemma

Das Ende der Evolution? Sind die Anforderungen, das Team und die Geschwindigkeit stabil, kann man mit der richtigen Technik gute Schätzungen für die nahe Zukunft abliefern. Ändere ich etwas an der Teamzusammensetzung, Technologie etc., so zerbröselt die Schätzung schnell wieder. Die oben genannten Fehler lassen sich zwar vermeiden, trotzdem bleibt eine Festpreisschätzung immer ein schwer kalkulierbares Geschäftsrisiko. Ich kann viel in eine bessere Schätzung investieren, aber wenn ich den Auftrag nicht bekomme, dann ist der Aufwand für die Katz. Und falls ich den Auftrag bekomme, zahlt der Auftraggeber die Schätzung letztlich mit. Auch aus der agilen Perspektive betrachtet lässt sich das Dilemma einer Festpreiskonstellation kaum lösen: Genaue Beschreibungen ergeben bessere Schätzungen aber starre (und somit häufig unpassende) Software. Ungenaue Beschreibungen lassen zwar Raum für Anpassungen und Steuerung der Entwicklung, aber die Schätzung wird zum unkalkulierbaren Risiko. Um zum Anfang zurückzukehren – vielleicht ist es wie mit der Ehe: „Männer und Frauen passen einfach nicht zusammen“ (Loriot).

Holger Bohlmann ist Senior-Softwareentwickler bei der it-agile GmbH. Er verfügt über langjährige Erfahrung als Entwickler und Projektleiter in agilen Projekten (XP, Scrum) und beschäftigt sich intensiv mit (agilen) Schätzverfahren.
Geschrieben von
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.