zurück zum Artikel

Jede Entwicklerin und jeder Entwickler kennt die Herausforderung, Aufwand für die Entwicklung Code zu schätzen. Die wenigsten machen das gerne. Warum ist Schätzen so unbeliebt, warum ist es überhaupt erforderlich und worauf sollte man achten?

Jede Entwicklerin und jeder Entwickler kennt die Herausforderung, Aufwand für die Entwicklung Code zu schätzen. Die wenigsten machen das gerne. Warum ist Schätzen so unbeliebt, warum ist es überhaupt erforderlich und worauf sollte man achten?

Die Frage, warum überhaupt geschätzt werden muss, lässt sich leicht beantworten. Zu wissen, wie lange eine Aufgabe voraussichtlich noch dauern wird, ist essenziell für die Planung, wer in einem Team wann was ausführen kann. Auch über Teamgrenzen hinweg ist eine gewisse Zeitplanung essenziell, immerhin müssen Teams koordiniert und Ressourcen beschafft werden. Außerdem haben auch andere Abteilungen wie Marketing ein Interesse daran, frühzeitig in die Planung eingebunden zu sein.

Letztlich steckt hinter der Aufgabe zu schätzen lediglich das Bedürfnis, ungefähr zu wissen, wann man wie weit ist, um sich entsprechend vorbereiten zu können, damit alle im Fluss arbeiten können und keine unnötigen Wartezeiten entstehen. Das ist ein durchaus legitimer Ansatz, der zudem erforderlich ist, um Hand in Hand zu arbeiten. Dieses Vorgehen stößt in aller Regel auch auf Verständnis und niemand hat etwas dagegen. Warum wird Schätzen also dennoch häufig abgelehnt?

Hier kommt in aller Regel ein zweiter Aspekt ins Spiel, nämlich die Kontrolle. Wenn man die Frage, wie lange etwas noch dauern wird, beantwortet, dann wissen Entwicklerinnen und Entwickler, dass das meistens mit einer gewissen Verbindlichkeit einhergeht und dass das über kurz oder lang dazu führt, dass sie sich rechtfertigen müssen, warum der Plan nicht eingehalten wird. Dabei war gar nicht von einem Plan die Rede, sondern lediglich von einer Schätzung!

In der Praxis wird an der Stelle gerne das Buzzword Commitment verwendet, was verschleiern soll, dass es sich um eine von außen erwartete Verbindlichkeit handelt: Commitment klingt dafür viel zu selbstgewählt und selbstbestimmt. Das ist es aber in aller Regel nicht.

Der Punkt dabei ist das fehlende Vertrauen. Außenstehende können die Entwicklung häufig nicht beurteilen, sollen sie aber verwalten. Um dafür eine Grundlage zu haben, werden irgendwelche Zahlen benötigt (mit Betonung auf "irgend"), da diese sich hervorragend zum Planen und Verwalten eignen. Und genau da entsteht das Problem – aus einer ungefähren und ungenauen Schätzung wird ein verbindlicher Plan.

Was dabei gerne vergessen wird, ist, dass eine Schätzung per se unscharf und ungenau sein muss, denn das ist die Definition einer Schätzung. Wenn man es genau wüsste, müsste man ja nicht schätzen. An der Stelle zeigt sich ein gravierendes Unverständnis von Entwicklung, dass diese nämlich kein wiederholbarer Prozess, sondern ein kreativer Akt ist, weshalb es auch "Entwicklung" und nicht "Produktion" heißt.

Bücher wie "The Art of Programming" von Donald E. Knuth zeigen, dass man Softwareentwicklung durchaus als Kunst ansehen kann und weniger als Ingenieurswissenschaft. Natürlich hat Softwareentwicklung etwas davon, nämlich das Erschaffen von Strukturen, aber es gibt eben auch künstlerisch-kreative Anteile. Und die werden häufig vergessen.

Der Punkt ist nun: Schätzen zum Koordinieren von Teams ist legitim, und dafür braucht man auch eine ungefähre Planung. Die Frage ist dann aber, wie macht man das?

Storypunkte versus absolute Zeit

Prinzipiell gibt es zwei grundverschiedene Ansätze, wie geschätzt werden kann: absolut oder relativ. Absolut zu schätzen heißt, die tatsächlich benötigte Zeit vorherzusagen. Relativ zu schätzen bedeutet hingegen, die einzelnen Aufgaben lediglich in Relation zueinander zu setzen. Dabei muss eine relative Schätzung nicht zwingend auf Zeit bezogen sein, sondern kann auch auf anderen Faktoren basieren.

Was spricht dafür, in absoluter Zeit zu schätzen? Zunächst einmal, dass die meisten Entwicklerinnen und Entwickler ein ganz passables Gespür für Zeit haben, sofern die Aufgabe klar ist. Im Umkehrschluss gilt: Ist eine Aufgabe unklar, wird es extrem schwer, den Aufwand zeitlich zu schätzen, sodass Unklarheiten sehr schnell auffallen.

Allerdings spricht gegen das Schätzen in Zeit, dass die Schätzungen häufig drastisch von der anschließend tatsächlich benötigten Zeit abweichen. Das wirkt zunächst wie ein Widerspruch, lässt sich aber leicht erklären: Allzu oft werden hier nämlich "Code Complete" und "Feature Complete" verwechselt, also das Fertigstellen der reinen Codierung und das Fertigstellen des gesamten Features, einschließlich Dokumentation, Tests, Integration und so weiter.

Außerdem zeigt die Erfahrung, dass es ratsam ist, generell einen zeitlichen Puffer für Unerwartetes aufzuschlagen, beispielsweise für Fehlersuche.

All das hat dazu geführt, dass oftmals relativ geschätzt wird. Die Idee dabei ist, einen Bezugspunkt zu wählen und Aufgaben nur noch in Relation zu diesem zu schätzen. Ob es sich dabei um Zeit, Komplexität oder etwas anderes handelt ist offen. Storypunkte, die beispielsweise gerne in Verbindung mit Scrum genutzt werden, schlagen genau das vor: Hier soll die Komplexität von Aufgaben geschätzt werden. Problematisch daran ist, dass eine hohe Komplexität allerdings mit hohem Zeitaufwand assoziiert wird, obwohl das nicht zwingend so sein muss.

In der Praxis erlebt man dann, wie Entwicklerinnen und Entwickler heimlich Punkte in Zeit umrechnen, da nicht in Zeit geschätzt werden darf, sie aber eigentlich mit Zeit wesentlich besser hantieren können als mit einer abstrakten Größe wie "8 Punkten". Das Schätzen passiert also letztlich doch in absoluter Zeit, es wird nur mehr oder weniger geschickt verschleiert.

Mit absoluter Zeit schätzen

Um effektiv mit absoluter Zeit schätzen zu können, müssen drei wichtige Punkte beachtet werden. Zum einen müssen Aufgaben klein genug sein, um sie überblicken zu können. Als gute Faustregel hat sich hierbei die Größenordnung von 16 Stunden bewährt. Was in dieser Zeit voraussichtlich nicht umgesetzt werden kann, ist zu groß und muss weiter heruntergebrochen werden.

Zum zweiten macht es einen riesigen Unterschied, wer schätzt. Gründe hierfür sind individuelle Fähigkeiten, Kenntnisse, Erfahrung und die persönliche Vorgehensweise. Hinzu kommen die jeweilige Tagesform und zu einem gewissen Grad auch Zufall. Deshalb sollten stets jene Entwicklerinnen und Entwickler eine Aufgabe schätzen, die sie auch umsetzen werden. Wird gemeinsam im Team geschätzt, sollte man sich zuvor einigen, wie man mit Diskrepanzen umgeht, ob dann mit dem Mittelwert oder dem Worst Case gerechnet wird, und so weiter.

Zum dritten sollte man ein Bewusstsein dafür schaffen, dass Schätzung falsch sein werden. Genau deshalb benötigt man den bereits angesprochenen Puffer, der beispielsweise für Fehlersuche und Debugging genutzt wird. Dieser Puffer sollte allerdings multiplikativ und nicht additiv berechnet werden, da er bei größeren Aufgaben auch entsprechend größer ausfallen muss. Auch hier muss, wird im Team geschätzt, zuvor eine gemeinsame Strategie überlegt werden.

Wer das alles berücksichtigt, hat eine gute Ausgangsbasis, zumindest halbwegs verlässliche Schätzung abzugeben. Doch was passiert, wenn man die Schätzung doch als festen Plan mit starrem zeitlichen Rahmen nimmt?

Magisches Dreieck und Teufelsquadrat

Hier kommt nun das magische Dreieck ins Spiel, das besagt, dass Zeit, Kosten und Umfang einander bedingen. Ändert man eine der Größen, hat das Auswirkungen auf die anderen beiden Größen. Beispielsweise gilt, dass weniger Zeit dazu führen muss, dass entweder die Kosten steigen oder der Umfang sinkt. Da mehr Kosten in der Regel "ein größeres Team" bedeutet, mehr Personen aber nicht per se schneller sind (sondern nach Frederick Brooks unter Umständen sogar eher den gegenteiligen Effekt haben), bleibt letztlich nur, den Umfang zu reduzieren.

Obwohl das logisch ist, wird es in der Praxis allzu häufig missachtet. Obwohl weniger Zeit als ursprünglich geplant zur Verfügung steht, bleiben Kosten und Umfang fix – und zunächst scheint auch alles zu funktionieren, denn das Ende des Projekts liegt noch in weiter Ferne. Doch Verzögerungen summieren sich auf und am Ende wird die Zeit dann doch knapp: Eine leider häufig anzutreffende "Lösung" ist, den Druck auf die Entwicklung zu erhöhen.

Allerdings denken Menschen unter Druck nicht schneller, weshalb das nicht funktioniert. Wie eingangs bereits erwähnt, handelt es sich bei Softwareentwicklung um Entwicklung, nicht um Produktion, und gerade der künstlerisch-kreative Anteil funktioniert unter Druck weitaus schlechter.

Dennoch ist der Druck vorhanden, allerdings sucht er sich dann ein anderes Ventil, nämlich die Qualität. Das ist der einzige Faktor, an dem sich sparen lässt, wenn alle anderen Aspekte festgezurrt sind. Allerdings erzeugt man damit eine Lose-Lose-Situation, denn die Kundin oder der Kunde ist nachher ob der mangelhaften Qualität unzufrieden, und für sich selbst hat man ein instabiles Fundament geschaffen, auf dem man nur schwerlich stabil und tragfähig aufbauen kann.

Genau das wird im sogenannten "Teufelsquadrat" nochmals verdeutlicht: Der Aspekt des Umfangs wird hier zweigeteilt, in "Inhalt" und "Qualität".

Natürlich bedeutet das nicht, dass man Zeit niemals fixieren darf – gerade wenn zum Beispiel auf Messe- oder Konferenztermine hingearbeitet wird, steht der Zeitpunkt nun einmal fest und ist nicht diskutabel. Hier muss dann aber bewusst sein, dass entweder Abstriche am Umfang oder an der Qualität hinzunehmen sind.

Insbesondere, wenn an der Qualität gespart wird, sollte im Anschluss aber mehr als ausreichend Zeit vorhanden sein, um die bestehenden Mängel zunächst zu beheben, bevor man den entstandenen Code als Ausgangsbasis für die weitere Entwicklung nutzt.

WTF-Code

Ansonsten läuft man nämlich Gefahr, in der Entwicklung hässliche Abkürzungen im Code zu verwenden, da man sich nicht die Zeit nimmt, den Code ordentlich zu schreiben. Man baut bewusst "Workarounds" statt Lösungen, fügt "To-do"- und "Fixme"-Kommentare hinzu. Aus den Initialen der drei Begriffe ergibt sich dann der schöne Begriff "WTF"-Code …

Soll entsprechender Code erweitert werden, traut sich niemand an den Code heran. Stattdessen wird eine Schicht um den Kern gezogen, für die allerdings wieder zu wenig Zeit zur Verfügung steht, was zur nächsten Schicht führt, und immer so weiter. Jede weitere Schicht macht den Code in exponentiellem Maß komplexer und umfangreicher. Der Aufwand für Weiterentwicklung und Pflege steigt enorm, ebenso der Frust und die Enttäuschung. Den Code zu pflegen wird zunehmend mühsamer.

Das macht die Entwicklung immer langsamer und teurer, bis irgendwann der Punkt erreicht ist, wo sich die Weiterentwicklung nicht mehr rentiert. Dann bleibt nur noch Stillstand – oder, alles von Grund auf neu zu schreiben, was dann aber auch heißt, das Feld für mehrere Jahre der Konkurrenz zu überlassen. Ob man das als Unternehmen überlebt, sei dahingestellt.

Der einzige Weg, das zu vermeiden, besteht darin, Qualität von Vornherein als oberste Priorität auszurufen und zu leben. Natürlich darf man auch Prototypen und Proof of Concepts bauen, aber diese sollten stets als Wegwerfprodukte im wörtlichen Sinne genommen werden.

Fazit

Softwareentwicklung ist zumindest zu einem gewissen Teil eine Kunst, zu deren Ausübung es Freiraum bedarf. Entwicklerinnen und Entwickler wissen das und sträuben sich daher in aller Regel gegen Schätzungen, die ihnen eine verbindliche und exakte Planung abverlangen. Eine solche ist nur zu leisten, wenn man einige wichtige Aspekte beim Schätzen beachtet – was das Schätzen dann aber enorm aufwendig macht.

Letztlich sollten Unternehmen sich bewusst machen, dass Schätzungen ungenau und unscharf sind und sein müssen, dass sie nur zur Koordination von Teams dienen können, aber dass Schätzungen niemals zum Plan werden dürfen, an dem Erfolg gemessen wird. Bei all dem darf vor allem auch die Qualität nicht ins Hintertreffen geraten, denn sie ist das, was langfristig den meisten Schaden anrichtet – dann nämlich, wenn sie vernachlässigt wird. ( [6])

URL dieses Artikels:
https://www.heise.de/-5043561

Links in diesem Artikel:
[1] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[2] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[3] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[4] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[5] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[6] mailto:webmaster@goloroden.de

Copyright © 2021 Heise Medien