Bereiche der Schätzbarkeit

In den letzten beiden Tagen habe ich mal wieder zusammen mit Andrea Kaden einen Zeitmanagement-Workshop für Softwareentwickler gegeben. Natürlich kamen wir dabei auch auf das Thema Schätzung. Das treibt Entwickler immer wieder und immer noch sehr um. Sie empfinden schlicht großen Stress, wenn es vorhersagbar nicht klappt, Schätzungen einzuhalten. Sie fühlen sich unwohl, zur Unehrlichkeit gezwungen zu werden.

Das verstehe ich sehr gut. Deshalb bemühe ich mich, Hilfestellung bei diesem Thema zu geben. Ich versuche zu erklären, warum es mit dem Schätzen schwer bis unmöglich ist. Ich versuche, einen alternativen Weg aufzuzeigen, auch ohne Schätzungen verlässlich wertvolle Software herzustellen. Ich verweise auf andere, die auch versuchen, Entspannung zu vermitteln.

Deshalb heute auch dieser Blogartikel. Ein weiterer Versuch, Softwareschätzungen besser verständlich zu machen. Und zwar ausgehend von einer Analogie:

Skalen der Physik

Aus der Physik kennen wir, wie unterschiedlich “dasselbe” sich verhalten kann. Da gibt es z.B. die klassischen Aggregatzustände. “Dasselbe” - hier z.B. Wasser - ist im einen Aggregatzustand fest, im nächsten flüssig und schließlich gasförmig.

“Dasselbe” verhält sich damit nach Aggregatzustand sehr unterschiedlich. Eis kann man schneiden und daraus etwas bauen, z.B. einen Iglu. Flüssiges Wasser lässt sich nicht formen, dafür kann man damit schneiden und andere Stoffe auflösen und verarbeitbar machen. Dampf wiederum zerstört andere Stoffe eher (z.B. Desinfektion), ist dafür aber ein Mittel, um Maschinen anzutreiben.

So ist die Natur eben. Damit haben wir kein Problem. Wir nutzen diesen “Wesenswandel”, statt zu fordern, Wasser müssen sich unter allen Bedingungen gleich verhalten.

Ebenso bei den unterschiedlichen “Erscheinungsformen” der Physik. Die Suche nach einer vereinheitlichenden Theorie ist zwar schon lange im Gange. Einstweilen leben wir jedoch damit, dass uns die Physik sehr unterschiedlich entgegentreten kann.

Da ist die Quantenphysik. Sie beschäftigt sich mit der Physik der kleinsten Teile. Man könnte sie auch Mikro- oder gar Nano-Physik nennen. Wie es da zugeht, ist schon abenteuerlich: da wird geschwungen, da wird teleportiert, da ist Kopplung ohne Verbindung. Alles ist so ganz anders als wir es gewohnt sind.

Denn wir leben in der Welt der Newtonschen Physik. Da verhalten sich die Dinge wie ordentliche Billiardkugeln. Das Verhalten von einzelnen Teilen ist recht gut berechenbar. Wir haben auch ein gutes Gefühl dafür entwickelt, wie wir uns hier verhalten müssen, um bestimmte Ziele zu erreichen. Fahrradfahren, Baseball spielen, Autofahren… das alles findet im Rahmen dieser Meso-Physik statt.

Doch das ist nicht alles. Es gibt noch eine Physik des Größeren. Relativistische Physik beschäftigt sich mit Phänomenen, die bei großen Massen oder nahe der Lichtgeschwindigkeit zu beobachten sind. Die Struktur des Universums ist eine Sache der Makro-Physik, nicht der Newtonschen.

“Die Dinge” verhalten sich in der Physik also durchaus unterschiedlich, je nachdem in welchem Aggregatzustand sie sich befinden oder welcher Größenordnung sie angehören. Und so scheint es mir auch bei der Softwareentwicklung.

Skalen der Softwareentwicklung

Es wäre schön, wenn die Softwareentwicklung immer gleich wäre. One-size-fits-all Methoden und Werkzeuge sind der Traum jedes Managers. Aber so ist die Softwarewelt leider nicht.

Für mich gibt es auch Mikro-, Meso-, Makro-Softwareentwicklung. Unterscheidungskriterium ist wie in der Physik die Granularität, die sich hier auf den Scope bezieht. Scope, d.h. der Horizont von Anforderungen an Softwareverhalten (Funktionalität + Effizienz), kann eng oder weit sein.

Mikro-Softwareentwicklung liegt für mich vor, wenn der Scope so eng ist, dass seine Umsetzung weitestgehend in handwerklicher Arbeitsweise stattfinden kann. Es ist klar, was erreicht werden soll (Anforderungen). Es ist klar, wie das erreicht werden soll (Entwurf). Nun muss es vor allem noch getan werden (Implementation).

Makro-Softwareentwicklung findet am anderen Ende des Spektrums statt. Hier ist die Arbeitsweise vor allem eine forschende. Es muss noch erforscht werden, was eigentlich getan werden soll. Es muss womöglich auch noch erforscht werden, welche Mittel wie eingesetzt werden könnten. Es fällt noch schwer, einen Entwurf zu machen, weil so viele Unbekannte im Spiel sind. An handwerkliche Implementation ist gar nicht zu denken.

Zwischen Makro- und Mikro-Softwareentwicklung liegt die Meso-Softwareentwicklung. Auch bei ihr ist der handwerkliche Anteil gering. Für die Codierung liegt noch nicht genügend Klarheit vor. Allerdings wurde schon einiges erforscht, so dass nun mehr an einem Plan gearbeitet werden kann.

Entwicklungsaufwand schätzen in unterschiedlicher Granularität

Die unterschiedliche Granularität der Softwareentwicklung führt nun dazu, dass die Schätzbarkeit varriert. Ich bin sogar versucht zu sagen, die Schätzbarkeit definiere die Granularität.

Mikro-Softwareentwicklung ist aus meiner Sicht gut vorhersagend schätzbar. Hier können Ergebnisversprechen abgegeben werden. Der handwerkliche Anteil ist absehbar und er beträgt nicht mehr als maximal 16 Arbeitsstunden. Wenn der Scope eng genug ist, lässt sich die Umsetzung in 4, 8 oder 16 Arbeitsstunden zusagen. Was ich heute um 9h beginne, kann ich spätestens morgen um 17h abliefern - so lautet die im Mikro-Bereich mögliche Zusage.

Das funktioniert, wenn die Vorbereitung gut ist. Das bedeutet, der Scope ist eng und Analyse wie Entwurf sind weitgehend abgeschlossen.

Und es ist auch notwendig, dass das funktioniert. Sonst ist kein verlässlicher Fortschritt bei der Softwareentwicklung zu erzielen.

Ich bin auf der Mikro-Ebene also ganz für vorhersagende Schätzung und Ergebnisversprechen.

Ebenso auf der Makro-Ebene. Dort ist aus meiner Sicht auch Schätzung möglich. Allerdings ist das eine Abschätzung in Größenordnungen. Als Softwareentwickler ist es unser Job, für Anforderungen sehr schnell den ganz groben Aufwand einzuschätzen. Handelt es sich um einen Scope, der in Wochen, Monaten, Jahren umgesetzt werden kann? Wenn wir einen Auftrag annehmen, sollten wir so viel Erfahrung haben, dass wir eine solche Aussage machen können.

Aber Achtung: Nur weil ein Projekt auf der Makro-Ebene bei Wochen statt Monaten eingeordnet wird, heißt das nicht, man könne einen Fertigstellungstermin angeben! Dafür ist der Anteil an Analyse und Entwurf, der zunächst noch zu leisten ist, viel zu groß.

Nichtsdestotrotz sind Schätzungen auf Mikro- und Makro-Ebene möglich und notwendig. Auf der Mikro-Ebene kann ein Ergebnisversprechen abgegeben werden; auf der Makro-Ebene ist es allerdings nur ein Verhaltensversprechen.

Auf der Meso-Ebene würde ich mich jedoch anders verhalten. Sie ähnelt zwar im Hinblick auf den geringen Anteil an handwerklicher Arbeit der Makro-Ebene, eine Größenordnungsabschätzung wäre also möglich. Doch der Drang ist hier sehr groß, viel genauere Abschätzungen mit Ergebnisversprechen zu bekommen. Die Diskrepanz zwischen Gewünschtem und Möglichem ist so groß, dass ich eine Abschätzung verweigern würde.

Um es konkreter zu machen:

• Ein Feature mit einer programmiersprachlichen Funktion als Entsprechung liegt für mich auf der Mikro-Ebene. Geeignet geschnitten, kann hier verlässlich angegeben werden, ob die Implementation max. 16 Arbeitsstunden dauert.
• Ein ganzes Projekt ist Makro-Softwareentwicklung. Es sollte nicht begonnen werden, bevor nicht die Größenordnung klar ist. Es sollte aber eben nicht versucht werden, daraus einen Abgabetermin abzuleiten. Aufgrund der Größenordnung kann der Kunde jedoch entscheiden, ob er genügend Budget hat, um das Projekt mit guten Erfolgsaussichten zu beauftragen. Wenn ja, kann ein fixes Zeit- und Geldbudget vereinbart werden - allerdings eben kein fixer Scope. Außerdem ist der Ressourceneinsatz zu definieren, mit dem die Budgets verbrannt werden, um sich kontinuierlich in Richtung Ziel zu bewegen.
• Auf der Meso-Ebene bewegt sich dann alles zwischen Feature und Projekt. Selbst Gruppen von Features, bei denen jedes einzelne auf der Mikro-Ebene schätzbar ist, sollten nicht zusammen betrachtet werden. Der Grund: Ein Zeitmanagement zur Erfüllung von Ergebnisversprechen der Mikro-Ebene ist jenseits von 2 Tagen kaum mehr möglich. Selbst wenn die Umsetzung handwerklich klar ist, ist nicht klar, was in der Organisation in 3, 5, 8 Tagen los ist.

Vorgehen

Das Ergebnis ist eine Vorgehensweise, bei der der nächste Schritt (Feature) glasklar ist, das Ziel in relativ weiter ferne liegt und langsam wandert (Projekt) und die nächsten Wegabschnitte so vernebelt sind, dass ständige Adaption mit Blick auf den Leitstern notwendig ist.

Das mag sich für Sie wenig befriedigend anhören. Es ist einfach ganz anders, als Ihre Kunden/Manager es gern hätten. Die möchten ihr Leben auf Newtonsche Physik ausrichten und Softwareentwicklung nach den “Gesetzen” der Mikro-Ebene betreiben. Aber das ist leider nicht möglich.

Wir können uns ein Leben ohne Nutzung von Quantenphysik und relativisticher Physik nicht mehr vorstellen. Oder wollten Sie ernsthaft ohne die Segnungen von Nanotechnologie, Strahlenmedizin oder moderner Chipherstellung leben? Doch die Physik dahinter blenden wir aus.

Bei der Softwareentwicklung ist das allerdings nicht möglich. Auch hier geht es nicht ohne Mikro, Meso, Makro - nur müssen wir uns dessen bewusst sein. Wir müssen lernen, dass Softwareentwicklung nicht nur nach “Mikro-Gesetzen” abläuft. Mikro, Meso, Makro brauchen eine differenzierte Betrachtung und angepasste Verhaltensweisen. Was bei Mikro funktioniert, funktioniert deshalb noch lange nicht bei Meso und Makro - und umgekehrt. Das müssen wir uns immer wieder klar machen.

Bildnachweis

Feynmann Diagram Gluon Radiation by Joel Holdsworth (Joelholdsworth) [GFDL, CC-BY-SA–3.0 or CC BY 2.5], via Wikimedia Commons