Warum Aufwandsschätzungen nicht funktionieren

Die meisten Aufwandsschätzungen für die Softwareentwicklung sind Makulatur. Das liegt nicht unbedingt daran, dass die Unternehmen die falschen Methoden oder Tools verwenden. Das Problem liegt vielmehr darin, dass solche Schätzungen auf einem grundlegend falschen Verständnis davon beruhen, wie qualitativ hochwertige Software entwickelt wird.

Die Auswirkungen von falschen Annahmen gehen weit über gesprengte Budgets und verpasste Deadlines hinaus. Das eigentliche Problem sind die resultierenden Fehlsteuerungen: Oft führen Aufwandsschätzungen zu verändertem Verhalten und haben zur Folge, dass der Business Value gegenüber irgendwelchen vorzeigbare Metriken in den Hintergrund gedrängt wird.

Unsicherheiten gehören zur Softwareentwicklung

In agilen Umgebungen basieren Aufwandsschätzungen oft auf Story Points und Geschwindigkeit. Dabei spielen Fragen eine Rolle wie:

• Wie "komplex" wird es sein, ein Teilstück einer Lösung zu erstellen?

• Wie lange brauchen wir in der Regel, um ein Projekt solcher Komplexität abzuschließen?

Wenn wir auf diese Weise schätzen, sind wir uns darüber im Klaren, dass nicht alles nach Plan verlaufen wird. Den meisten Kalkulationen liegt jedoch die gefährliche Annahme zugrunde, dass auch diese Unsicherheiten quantifiziert werden können. Weil wir wissen, dass unsere optimistischen Entwickler dazu neigen, die Zeit, die sie für eine bestimmte Aufgabe brauchen, um durchschnittlich 15 Prozent zu unterschätzen, schlagen wir diese 15 Prozent eben drauf, um eine genauere Vorhersage zu erhalten.

Diese Besessenheit, den gesamten Entwicklungsprozess vorab spezifizieren und messen zu wollen, degradiert Entwickler zu Maschinen, die vorhersagbare Ergebnisse am Fließband durch eine Pipeline schieben sollen. Doch mathematische Berechnungen sind hier nur begrenzt möglich. Menschen sind keine Maschinen. Zu glauben, man könne die Komplexität einer nicht-trivialen Softwareentwicklungsaufgabe im Voraus exakt einschätzen, ist ein Trugschluss.

Software Development ist ein Gebiet, auf dem sich ständig vieles schnell verändert. Etliche Herausforderungen, mit denen Entwickler konfrontiert werden, sind neu und unbekannt. Und selbst die bekannten Herausforderungen unterliegen einem Wandel. Soll heißen: Die Performance der letzten Woche ist ein schlechter Indikator für die der nächsten Woche.

Nehmen wir ein triviales Beispiel: die Implementierung einer Anmeldeseite. Jeder erfahrene Softwareentwickler hat das schon Dutzende oder Hunderte Male erledigt. Das Lösungsmuster ist bekannt, und es lässt sich vorhersagen, wie lange die Task in Anspruch nehmen wird. Plötzlich kommt jedoch eine neue, wesentlich sicherere Authentifizierungsmethode auf, was zur Folge hat, dass die Aufgabe grundlegend überdacht werden muss.

Die meisten softwaretechnischen Herausforderungen sind deutlich komplizierter als das Implementieren einer Login-Page. Immerhin geht es ja auch darum, komplexe Probleme zu lösen und Mehrwerte zu schaffen. Softwareentwickler betreten oft Neuland, sie erledigen Aufgaben, die nie zuvor - oder auf andere Weise - angegangen wurden. Sie sind bestenfalls mit einem Kompass ausgestattet, aber nicht mit einer Landkarte. Es gilt, Arbeiten in Angriff zu nehmen, die sinnvoll und lohnend sind. Die schlechte Vorhersehbarkeit ist für die Entwickler auch nicht das Problem, wohl aber die oft willkürlichen Schätzungen.

Aufwandsschätzung auf Abwegen

Unzureichende Aufwandsschätzungen im Bereich der Softwareentwicklung entmenschlichen die Entwickler und implizieren, dass lediglich das System und seine Prozesse zählen. Das führt zu schlechtem Verhalten und damit wiederum zu:

• minderwertigem Engineering,

• dem Verlust von Talenten und

• weniger werthaltigen Lösungen.

Willkürliche Aufwandsschätzungen sind zudem Kennzeichen einer dysfunktionalen Kultur: Entwickler werden unter Zwang gesetzt zu produzieren, sie sollen sich weder für ihre Arbeit noch für ihr Unternehmen interessieren. Schlimmer noch: Wenn Sie das allzu grob kalkulierte Ergebnis nicht in der vorgesehen Zeit liefern, dürfen sie sich von der Work-Life-Balance verabschieden und einen Nachtschicht-Marathon einlegen.

Schädlich wird das Ganze, wenn die Entwickler unter Druck ihre Herangehensweise ändern, nach dem Motto: Sie können in der Ihnen zugewiesenen Zeit keine qualitativ hochwertige Lösung programmieren? Dann nehmen Sie doch eine Abkürzung, damit Sie das Ticket möglichst schnell schließen können. Die nachgelagerten Probleme, die dadurch entstehen, geraten dann aus dem Blickfeld. Automatisiertes Testing? Das kann wegfallen. Das gilt auch für die kreative Idee, wie diese Software besser als ursprünglich geplant hätte entwickelt werden können. Entwickler behalten sie lieber für sich, um den Zeitplan nicht zu gefährden.

Hinzu kommt, dass Entwickler, denen man solche Aufwandsschätzungen unter die Nase hält, irgendwann Wege finden werden, dieses System zu untergraben. Sie werden die Komplexität der Aufgaben absichtlich überschätzen, um Zeit zu gewinnen. Und sie werden langsamer arbeiten, um künftige Erwartungen niedrig zu halten.

"Individuen und Interaktionen sind wertvoller als Prozesse und Tools" - das ist eine der zentralen Aussagen des Agilen Manifests. Eine gesunde Software-Engineering-Kultur sollte auf einem Fundament des Vertrauens aufbauen und von menschlichen Beziehungen getragen werden. Es handelt sich um ein soziales Netzwerk, bestehend aus Menschen, die gemeinsam darauf hinarbeiten, qualitativ hochwertige Lösungen zu entwickeln, wichtige Probleme zu lösen oder bedeutende Chancen zu realisieren. In einer solchen Kultur sollten solche "Spielchen" keinen Platz haben. Die gemeinsame Sache sollte die Beteiligten inspirieren, ihr Bestes zu geben.

Fortschritte sollte an realisierten Werten gemessen werden, nicht an abgeschlossenen Tickets. Wenn sich während der Arbeit ein besserer Alternativansatz mit langfristgen Vorteilen findet, sollten die Entwickler das mitteilen könnne. Das geht nur, wenn alle wissen, dass eine qualitativ hochwertige Lösung das Maß für Erfolg ist, nicht eine willkürliche Schätzung.

Nur wenn wir auf Individuen und Interaktionen statt auf Prozesse und Tools fokussieren, kommt der Wert jedes Einzelnen zur Geltung - was dem Gesamtergebnis der Teamarbeit enorm zuträglich ist. Das mag nicht gut für die Vorhersehbarkeit sein, erschließt aber unterm Strich mehr Wert, als Entwickler mit detaillierten Aufwandsschätzungen für ein vollständig spezifiziertes Produkt zu maßregeln.

Roadmaps, Ranges, Relationships

Wie könnte es also anders laufen? In der idealen Welt würde man sich auf eine gemeinsame Aufgabe einigen, sich die gemeinsame Vision zueigen machen und dann im Team Qualitätssoftware entwickeln - ohne vorher sagen zu müssen, wie lange es dauern und wie viel es kosten wird. Ein solcher Ansatz ist in einem Business-Umfeld allerdings kaum praktikabel, da es Budgets und Zeitpläne gibt.

Die Antwort liegt also nicht darin, Aufwandsschätzungen vollständig abzuschaffen. Vielmehr sollten sie als Gesprächsgrundlage in einer Kultur des gegenseitigen Vertrauens dienen. Produkt- und Entwicklungsteams sollten zu Beginn - und über den gesamten Lebenszyklus der Softwareentwicklung hinweg - offene und ehrliche Gespräche führen. Diese sollten auf der Annahme fußen, dass allen Beteiligten das Projekt am Herzen liegt und sie ihr jeweils Möglichstes tun, um die wichtigen Probleme rechtzeitig und im Rahmen des Budgets zu lösen. Dabei sollten folgende Fragen eine Rolle spielen:

• Was glauben wir, mit den verfügbaren Ressourcen erreichen zu können?

• Was können wir liefern und wann?

• Wie sieht Plan B aus, wenn Zeit oder Ressourcen knapp werden?

Diese Gespräche führen zu vorläufigen Roadmaps und Ranges. Sie werden auch fortgesetzt, während der Entwicklungsprozess voranschreitet. Dazu gilt es, folgende Grundsatzfragen zu beantworten:

• Wenn sich einige Aspekte des Projekts als schwieriger erweisen als erwartet, schieben wir dann die Arbeit an einer Funktion auf oder wählen wir eine einfachere Lösung?

• Herrscht Konsens darüber, den Zeitplan entsprechend zu ändern?

• Wenn wir während des Entwicklungsprozesses auf eine wertvolle Idee stoßen, ändern wir dann den Zeitplan oder sparen wir diese für die nächste Runde auf?

Wenn die Beziehungen zwischen und innerhalb der Teams gesund sind, finden diese Gespräche kontinuierlich statt - und führen zu besseren Lösungen.

Wenn Aufwandsschätzungen zu hohe Priorität eingeräumt wird, gelten alle Abweichungen vom festgelegten Weg als Versagen. Dabei liegt das Versagen in der Schätzung selbst. Anstelle von Fristen und Tickets sollten Missionen und Visionen maßgebend sein. Es muss akzeptiert werden, dass Softwareprojekte nicht vollständig im voraus planbar sind. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.