Warum objektive Schätzungen in der Softwareentwicklung nicht funktionieren

Kann man den Aufwand eines Softwareprojekts objektiv schätzen? Solche Zahlen als Ergebnis würden klären, wie lange die Implementierung einer Funktionalität dauert und was sie kostet. Das könnte bei der Beauftragung von Entwicklungsdienstleistungen helfen.

Bei agilen Methoden kann der Aufwand einer Funktionalität als Story in Planungsmeetings abgeschätzt werden, um zu entscheiden, ob eine Story implementiert werden soll. Das ist optional: Das Schlagwort NoEstimates beschreibt Projekte ganz ohne Aufwandsschätzungen. Vorteil davon: Der Aufwand für die Schätzungen entfällt und kann in die Entwicklung von Storys fließen. Es reicht aus, wenn alle im Team gerade am wertvollsten Feature arbeiten. Woody Zuill ist ein Pionier auf diesem Gebiet und hat noch nie anders gearbeitet.

Eine Abschätzung von Storys basiert meistens auf einer Referenz-Story oder einer Funktionalität, der die Größe eins zugewiesen wird. Andere Storys werden relativ zu dieser Referenz abgeschätzt, und zwar durch und für das Team, das die Storys abschätzt. Hinzu kommt die Velocity (Geschwindigkeit) des Teams. Sie wird in implementierten Story Points pro Iteration gemessen und kann sich über den Projektverlauf ändern.

Objektive Schätzungen?

Also ist die Schätzung nicht objektiv, weil sie das jeweilige Team einbezieht und sich zudem die Velocity mit der Zeit ändert. Die Schätzungsmethodik erreicht aber das Ziel: Sie erlaubt eine Planung der Arbeit für Teams. Durch die Analogieschätzung zur Referenz-Story und die Velocity ist auch eine relativ gute Schätzung dazu möglich, was das Team leisten kann.

Natürlich kann man versuchen, diese Messungen zu objektivieren. Beispielsweise kann man eine einheitliche Referenz-Story wählen. Es gibt Ansätze, die noch deutlich weitergehen. Das Function-Point-Verfahren versucht, eine objektive Komplexität einer fachlichen Anforderung in Function Points zu messen. Auch diese Verfahren haben aber eine Streuung in der Abschätzung. Außerdem erfordern sie Erfahrung beim Schätzen und sind aufwendig. Verfahren wie COCOMO warnen sogar davor, dass die Ergebnisse nur grobe Richtungen und keine präzisen Schätzungen sind.

Die Nützlichkeit dieser Abschätzungen ist fragwürdig: Projekte ändern immer den Scope. Wenn Software in der Praxis genutzt wird, ergeben sich neue Wünsche. Softwareentwicklung ist ein Prozess, bei dem Technikerinnen und Nutzer gemeinsam lernen, wie man die Geschäftsprozesse am besten mit Software unterstützt. Wenn man etwas Neues lernt, wird man den Scope ändern. Dann sind präzise Abschätzungen über den ursprünglichen Scope nicht mehr viel wert und der Aufwand für die zusätzliche Präzision ist nicht sinnvoll investiert. Vielleicht ist das der Grund, warum man in der Praxis zwar agiles Schätzen genutzt wird, aber kaum ausgefeiltere Methoden.

Überhaupt ist der Fokus auf die Aufwandsseite bei Projekten oft übertrieben. Wie jedes Investment muss auch ein Investment in Software einen Wert erzeugen, der höher ist als das Investment – idealerweise um ein Vielfaches. Das Abschätzen des Werts scheint jedoch oft gegenüber dem Aufwand stiefmütterlich betrachtet zu werden.

Start-up

Es gibt sehr kleine Teams, die extreme erfolgreiche Software entwickelt haben. Solche Ausreißer werfen die Frage auf, ob eine objektive Schätzung überhaupt machbar ist. Instagram war vor der Akquisition eine Milliarde Dollar wert, betrieb ein weltweit skaliertes System und das mit nur 13 Mitarbeitern und Mitarbeiterinnen. WhatsApp hatte vor der Akquisition 900 Millionen User; 50 Engineers haben dieses System entwickelt und betrieben. Das ist ein Bruchteil dessen, was viele IT-Projekte in etablierten Unternehmen an Personal hat.

Diese Anwendungen waren scheinbar aber nur eine einfache Foto-Sharing-App bzw. Messaging-App. Erklärt das den niedrigen Personalaufwand? Auch eine Versicherung oder ein Sparvertrag sind einfach: Man zahlt Geld ein und unter bestimmten Bedingungen bekommt man Geld zurück. Suchmaschinen sind auch einfach: Es gibt sogar Software von der Stange, mit der man Dokumente indizieren und durchsuchen kann.

Auf der oberflächlichen Ebene erscheint alles einfach. Die Komplexität des Problems wird erst klar, wenn man die Details betrachtet und das Problem wirklich versteht.

Unabhängig von der Komplexität: Der ökonomische Erfolg eines Projekts ist das eigentlich wichtigste Ergebnis. In diesem Bereich überzeugen Instagram und WhatsApp wirklich: Sie haben Milliarden an Werten geschaffen. Das ist fast nur für erfolgreiche Start-ups möglich. Auf jedes erfolgreiche Start-up kommen zahlreiche, die nicht erfolgreich sind.

Etablierte Unternehmen

Nehmen wir an, ein etabliertes Unternehmen würde eine Foto-Sharing-App oder Messaging-App bauen. Sie würde es mit ihren typischen Mechanismen bauen: potenziell Hundertschaften an Developern, ausgefeiltes Projektmanagement und Projektpläne. 13 Menschen, die ein zentrales System für den Durchbruch am Markt entwickeln, würden eher als ein Risiko wahrgenommen werden. Große Teams und Projekte führen außerdem zu viel Prestige – für alle Beteiligten, für Manager, aber auch Technikerinnen. Und schließlich haben etablierte Unternehmen meist viele Softwareprojekte und meist hängt von keinem das Überleben der Firma ab – anders als bei einem Start-up. Der Druck ist also objektiv geringer.

Es gibt also genügend Mechanismen, die zu einem ganz anderen Aufwand führen. Ein etabliertes Unternehmen wird also ein Softwaresystem mit den Mechanismen entwickeln, die es typischerweise nutzt, und findet sich in einer anderen Wettbewerbssituation als ein Start-up. In einem Start-up sind die wirtschaftlichen Bedingungen hingegen so, dass möglichst schnell irgendwas live gehen muss – mit den entsprechenden Konsequenzen.

Probleme unterschiedlich lösen

Es ist außerdem unwahrscheinlich, dass ein etabliertes Unternehmen genau dieselbe Anwendung für ein Problem wie Foto-Sharing oder Messaging bauen würde. Die IT-Landschaft, in die sich die Anwendungen integrieren müssen, ist anders. Die Anforderungen können erweitert werden, was ein Start-up wegen der wirtschaftlichen Rahmenbedingungen nicht kann.

Ein Start-up würde daher vermutlich auch in Bereichen, die klassisch mit komplexen Softwaresystemen implementiert werden, eine viel einfachere Lösung entwickeln – weil sie eben schnell auf den Markt kommen müssen und ein sehr begrenztes Budget haben.

Den objektiven Aufwand bewerten zu wollen, ist dann noch weniger sinnvoll: Software löst ein Problem, das eine Organisation hat. Beispielsweise will die Organisation ein neues Produkt etablieren. Dazu greift es auf soziale Prozesse zurück, wie sie in der Organisation verankert sind. Für ein Start-up ist das Vorgehen eines etablierten Unternehmens genauso fremdartig, wie das Vorgehen eines Start-ups fremdartig für ein etabliertes Unternehmen ist. Das umfasst nicht nur das Vorgehen bei der Entwicklung, sondern auch das Produkt.

Am Ende sollte uns das auch nicht interessieren. Es geht nur darum, wie wir in der jeweiligen Situation bessere Software entwickeln können. Und dafür gibt es immer zahlreiche, spannende Möglichkeiten.

tl;dr

Objektiv den Aufwand für ein Feature festzustellen, ist vielleicht mit viel Aufwand möglich. Da es jedoch für die Planung unnötig und aufwendig ist, nutzen die meisten Projekte solche Techniken gar nicht erst. Software ist außerdem „nur“ eine Implementierung der Lösung eines Businessproblems. Organisationen gehen Probleme anders an, sodass alleine schon deswegen die Lösung und der Aufwand unterschiedlich sein werden. Dennoch kann und sollte man die Frage nach der Produktivität und einem besseren Vorgehen stellen.

(rme)