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.
