Softwareabschätzung: Traum und Realität

Softwareabschätzung: Traum und Realität

Es gibt tatsächlich nach wie vor viele Leute – vor allem im Management – die glauben, die Entwicklungszeit von Software ließe sich abschätzen, vorhersagen, ja, irgendwie planen.

Die Realität spricht jedoch eine andere Sprache.

Viele Verzögerungen lassen sich erklären, und, ja, sogar vorhersagen und vor allem vermeiden. So kommt es z. B. in großen Projekten immer wieder vor, daß die Informationen nicht an die Ohren gelangen, die diese Informationen dringend brauchen würden. Dadurch sieht es dann eine Weile länger so aus, als wäre alles in Ordnung, nur, damit danach alles völlig zusammenbricht.

Doch auch wenn sich solche Einzelfälle vermeiden lassen, so ist das große Gebiet der Softwareabschätzung, der vorherigen Planung, ein Gebiet großer Unwägbarkeiten und ebenso großer Spielräume.

Immer 80% fertig

So wies bereits Neno Loje in seinem Vortrag zu der DevConnections darauf hin, daß Programmierer meistens zu 80% mit ihrem aktuellen Projekt fertig sind. Sagen sie, sie seien weniger weit fertig, käme sonst wohl die Frage, was sie denn die ganze Zeit gemacht hätten. Wären sie weiter im Fortschritt, würde der Vorgesetzte bald eine Abgabe erwarten. So verharren sie lange (ewig) bei den 80%.

20%-80%

80% sind ohnehin eine gute Marke, kennen wir diese doch bereits vom Pareto-Prinzip. Und so ist dem nicht selten so, daß eine Software bereits nach kurzer Zeit (20%) fast fertig (80%) scheint. Benötigen wir jedoch eine vollkommen fertige Software (100%), so brauchen wir für die restlichen 20% oft 80% der Gesamtzeit – dieser kleine Rest dauert also 4x so lange wie die gewaltigen Fortschritte von zuvor. Das sind natürlich nur grobe Abschätzungen, oft treffen sie jedoch qualitativ durchaus zu.

Widerspruch gegen das Schätzen

Ralf Westfal schreibt in seinem Artikel für die Visual Studio One ebenfalls von dem hoffnungslosen Unterfangen der Abschätzung, der das Management jedoch nach wie vor abgöttisch die Treue hält. Und er bringt zahlreiche Beispiele, wie z. B. vom US-Militär, bei dem Aufträge regelmäßig 30% und mehr teurer werden. Dabei wäre ich selber auch gerne so schlau (und würde so viel Geld für meine Arbeit bekommen) wie die Leute, die dort für die vorherigen Abschätzungen zuständig sind.

Er bringt noch zahlreiche weitere Beispiele aus allen Bereichen – nicht nur in der SW-Industrie sind die Abschätzungen schwierig. In seinem Artikel zeigt sich jedoch auch: eine grobe Abschätzung ist doch möglich. Ist der jüngste Flieger auch doppelt so teuer, wie geplant, so ist er doch selten 10x so teuer. Wobei.. ausschließen kann man auch das nicht.

Wie lange dauert Arbeit denn eigentlich?

Hier gibt es eigentlich nur das Parkinsonsche Gesetz zu beachten, und schon hat man eine perfekte Abschätzung. Arbeit dauert immer genauso lange, wie man Zeit dafür hat. Das ist in sehr weiten Zügen richtig. Hat man wenig Zeit, kann man trotzdem oft eine (ausreichende) Lösung hinhuddeln. Hat man hingegen ewig viel Zeit, so wird man auch erst kurz vor dem Abgabetermin fertig. Die Lösung ist dann evtl. viel besser, vielleicht wurde aber auch nur getrödelt.

Abschätzungsmechanismen

COCOMO sowie FPA sind zwei Verfahren, mit denen ich mich ausführlicher auseinander gesetzt habe. Letzten Endes ist beiden Verfahren gemein, daß sie versuchen, mit mathematischen, deterministischen Methoden, beim Anwender den Glauben zu erzeugen, eine genaue Abschätzung sei möglich. Jedoch: das Zählen von Aufwänden im FPA-Modell ist nicht eindeutig, und beim COCOMO gibt es noch eine ganze Reihe von (willkürlichen) Stellschrauben, über das Drehen welcher man das Ergebnis deutlich nach oben oder unten beeinflussen kann.

Die Mannwoche

Einer der größten Fehler überhaupt ist wohl, daß es nur den einen Programmierer gibt. Andererseits legen einige Studien jedoch nahe, daß der Unterschied zwischen einem extrem guten und einem extrem schlechten Programmierer durchaus den Faktor 100 betragen kann. Das hieße, die Mannwoche des guten wäre so viel wert wie 100 Mannwochen des schlechten. Und.. um genau zu sein.. viele Aufgaben würde der schlechte Programmierer auch in der 100-fachen Zeit nicht hinbekommen, wenn dort z. B. Anforderungen an den Intellekt gestellt werden oder es um algorithmische Optimierungen geht, die sich einfach nicht mit Fleiß lösen lassen, sondern nur durch ein Ausnahmegehirn.

So habe ich schon so manche Gruppe von Programmierern ehrfürchtig von ihrem eigenen Guru wispern gehört, der sich manchmal für ein paar Tage einschließt, und dann mit einer Lösung hervorkommt, daß alles nur noch Heureka! rufen. Man fühlt sich wohl so, als habe man das Licht gesehen.

Können ist die eine Seite, Wollen die zweite. Derjenige, der schaffen will, der schafft auch, und ist produktiv. Wer das nicht möchte, der dümpelt einfach nur vor sich hin. Nicht wenige Geschichten kursieren im weiteren Bekanntenkreis von Programmierern, für die man extra unwichtige Aufgaben gesucht hat, oder schließlich sogar direkt Aufgaben gesucht hat, von denen man wußte und wollte, daß sie weggeworfen werden, damit diese Personen keinen allzu großen Schaden anrichten könnten.

1000 Zeilen Code pro Tag

Heute habe ich 1250 Zeile Code geschrieben. Da war so gut wie kein autogenerierter Code dabei, kommentiert wird bei mir ohnehin sparsam, ich bin seit einigen Jahren ein Fan von selbstdokumentierendem Code. Ordentliche Gliederungen, Einteilungen, Benamungen, usw. sollten Code auch fast ohne Kommentare lesbar machen. Und.. ich habe nur den Nachmittag daran gesessen.

Die meisten Abschätzungen gehen von ca. 20 Zeilen Code pro Person pro Tag aus (wobei sich das dann auch oft auf größere Teams bezieht).

Und warum? Ich habe mich über ein Problem geärgert und wollte – schnell – eine Lösung. Also habe ich mich hingesetzt, die Wände hochgeklappt, und vor mich hingeschrieben. Solche „Bursts” oder „Sprints” sind durchaus möglich. Lange durchhalten kann ich sie aber auch nicht. Zum einen ist die Aufgabe bei dem Tempo irgendwann gelöst. Zum anderen.. wird dabei doch recht viel Energie verbraucht.

Die Flamme, die doppelt so hell brennt, brennt auch nur halb so lang… und Du hast eine Weile unglaublich hell gebrannt.
~~aus Bladerunner

Dennoch.. was würde das für eine Abschätzung bedeuten, wenn man jemanden kontinuierlich dazu bewegen könnte, 1000 Zeilen Code am Tag, mit einer ordentlichen Klasseneinteilung, gut wartbar, schön anzusehen, zu schreiben?

Die neue Produktivität

Kam früher Wissen meistens von Kollegen oder aus Büchern, so nimmt diese Stelle heute uneingeschränkt – so denn genug Entwickler in dem Bereich tätig sind – das Internet ein. War es noch vor 10 Jahren schwierig, sich eine komplette Lösung für ein Teilproblem zu ergooglen, so ist es heute eher umgekehrt. Stellt man die richtige Frage (Keywords), so landet man fast unweigerlich bei einem guten Artikel, aus dem man eine Lösung entweder fast komplett übernehmen kann, oder der einem zumindets die entscheidende Idee gibt. Und auch da, wo es noch keinen solchen Artikel gibt, ist Hilfe meisten nur einen Post bei Stackoverflow entfernt.

Auch dies hat einen unglaublichen Einfluß auf die Produktivität. Wenn ich am Tag 3 verschiedene Aufgaben habe, kann ich nicht in jedem Gebiet direkt ein Experte sein. Sich hier fertigen Code zu besorgen, der zumal oft über schlechte Dokumentation hinweghilft, ist unschätzbar wertvoll. Gleichzeitig ist derjenige, der erfolgreich sucht, weil er zum einen weiß, wie und wo, und zum anderen in einem Bereich unterwegs ist, in dem es einge große Community gibt, ungleich schneller am Ziel als die Person, die entweder nicht weiß, wo sie suchen muß, in ihrer Firma gar nicht suchen darf, oder einfach in relativem technischen Neuland (oder unbekanntem Land) unterwegs ist.


Probleme mit dem Google-Programmieren
Wenn man sich ständig auf Google verläßt, mit angenehm einfachen Programmiersprachen wie C# arbeitet, passiert irgendwann das, was passieren muß: man trifft auf ein Problem, das sich im C# nicht schön abbilden läßt, und für das man auch keine fertig Lösung finden kann. In dem Fall ist es dann oft so, als würde man von einem Bus überfahren werden. Man ist auf den erhöhten Aufwand nicht mehr vorbereitet und hat sich in der Vergangenheit erfolgreich um tiefere Einsichten in Betriebssystem oder Materie der Aufgabe herumgedrückt.
Bei solchen Problemen ist man dann plötzlich deutlich länger bei der Arbeit als gedacht, oft mag man gar völlig überfordert sein.
Das wird wohl lange der Vorteil der Programmierer bleiben, die zumindest eine zeitlang „von Hand” bzw. „the hard way” programmiert haben – sie haben oft tiefere Einsichten in Probleme, in Funktionsweisen und Notwendigkeiten, wenn es z. B. um Betriebssystem-nahe Programmierung, Parallelprogrammierung, oder aufwendige Algorithmik geht.

Der menschliche Faktor

Am wichtigsten ist also der Mensch. Der, der programmiert, aber auch der, der motiviert.

Was taugt der Projektmanager? Motiviert er, hilft er? Oder hindert er, macht er nur Arbeit und Vorschriften? Die Person an der Spitze ist für die gesamte Gruppe noch einmal ein Produktivitätsfaktor. Sitzt hier jemand sehr gutes, können 100 Leute 20% mehr leisten. Oder 50% weniger.

Warum nicht alles ganz so schlimm ist

Viele Dinge mitteln sich hinaus. Der eine ist besser, der andere ist schlechter. Heute bin ich produktiv, morgen surfe ich den ganzen Tag im Netz. (Also, jemand fiktives.) Die Masse bringt den Durchschnitt, das Gesetz der großen Zahlen.

Dazu kommt, daß jeder Projektmanager nochmal 50% auf alle Abschätzungen draufschlägt. Und das sind Abschätzungen, wo schon jede Person 100% gegenüber der eigentlichen Erwartung draufgeschlagen hat. Ist der Projektmanager jedoch nicht listig, so kommt es trotzdem zu einer Verzögerung, wir erinnern uns an Parkinsons Gesetz. Der Trick ist hier nun, die verlängerte Zeit nicht mehr zu kommunizieren. Intern wird immer noch von 1 Woche ausgegangen, extern sind jedoch 2 Wochen kommuniziert. Das Ergebnis wird dann verspätet nach 1.5 Wochen abgegeben, ist aber extern immer noch sehr gut in der Zeit. Evtl. sogar Zeit für QA und Dokumentation.

Mit diesem Ansatz habe ich persönlich gute Erfahrungen gemacht. Natürlich sollte man hier aufpassen, daß man sein Team nicht an der Nase herumführt. Es kann jedoch ein guter Ausgangspunkt sein, um sich weiterzuentwickeln.

Abgesehen davon bleibt natürlich die Notwendigkeit zur Planung bestehen. Allein, wenn man auf dem Schlachtfeld war und sich ein paar Situationen angeschaut und Strategien zurechtgelegt hat, wird man deutlich besser dastehen und die aktuelle Situation besser einschätzen können.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.