In der Praxis herrschen neunzig und neunzig

Die ersten 90 Prozent des Codes machen die ersten 90 Prozent der Entwicklungszeit aus. Die restlichen 10 Prozent des Codes machen die restlichen 90 Prozent der Entwicklungszeit aus.

- Tom Cargill, Bell Labs

Was bedeutet das konkret in der Praxis? Dass Programmierer viel arbeiten und 180% aus sich heraus geben, oder?

Stellen Sie sich das so vor: Wenn Sie mit der Arbeit an Software beginnen, können Sie in relativ kurzer Zeit große Mengen an Code schreiben. Dieser neue Code kann eine Menge neuer Funktionen hinzufügen. Das Problem ist, dass die Funktionalität oft nicht "erledigt" ist, dass es Bugs, kleine Änderungen (kleine Unternehmen) und so weiter geben kann. Die Software scheint also fast fertig zu sein (zu 90%), da sie die meisten Anwendungsfälle unterstützt. Die Software braucht aber noch Arbeit. Der Sinn dieser Regel ist, dass trotz des Gefühls, dass die Software fast fertig ist, der Arbeitsaufwand, um diese Software in den ordnungsgemäßen Betriebszustand zu versetzen, so groß ist, wie der, fast fertig zu werden. Das liegt daran, dass die Fehlerbehebung oft zeitaufwändig ist, aber nicht viel Code produziert.

Das Problem ist, dass die meisten Entwickler davon ausgehen, dass die Software "fast fertig" ist, da dies relativ einfach ist, verglichen mit der tatsächlichen Schätzung des Gesamtaufwands, den die Software in Anspruch nehmen wird.

Es ist ein Hinweis auf ein weit verbreitetes Szenario, das leider noch heute auftritt:

1. Das Team wird gebeten, den Arbeitsaufwand für das Schreiben des gesamten Codes abzuschätzen (dh zu schätzen).
2. Das Projekt wird mit zahlreichen internen und externen Anstrengungen fortgesetzt, um "Zeit und Budget einzuhalten".
3. Für einen signifikanten Prozentsatz des Projekts wird "on target" angegeben. Dies wird oft noch dadurch verschärft, dass zuerst die einfachen Aufgaben ausgewählt werden, um sicherzustellen, dass gute Fortschritte erzielt werden.
4. Irgendwann ist dann ein kritischer Punkt erreicht, an dem die Realität akzeptiert werden muss: Das Projekt wird nicht rechtzeitig abgeschlossen und der Veröffentlichungstermin wird zurückgeschoben (oftmals mehrmals).

"90%" ist eine willkürliche Zahl, aber es macht den Punkt gut: Schätzungen sind Vermutungen und werden wahrscheinlich falsch (oft sehr falsch) sein, und die menschliche Natur stellt sicher, dass wir fast immer unter der Schätzung liegen, so dass die Dinge überlaufen.

Ich habe eine andere Version davon gehört (auch "90-90-Regel" genannt), die so aussieht:

Nachdem ich 90% der Funktionalität implementiert habe, muss ich noch die anderen 90% implementieren .

Beide Versionen beziehen sich auf die Schwierigkeit, den Aufwand für die Entwicklung von Softwareprodukten richtig einzuschätzen, und auf die häufigen Fallstricke, in die Menschen fallen:

• Statistiken veröffentlichen, wenn Schätzungen erforderlich sind und im Grunde genommen geraten wird ("Ich bin zu 80% fertig")
• Konzentration auf die algorithmische Komplexität des zu schreibenden Codes zum Nachteil des Arbeitsvolumens (Unterschätzung des erforderlichen Aufwands für allgemeine Aufgaben)
• fehlende Schritte ("aus den Augen, aus dem Kopf")
• Unterschätzen Sie den Aufwand für die Pflege und Änderung des vorhandenen Codes
• Unterschätzung des Aufwands für den Kesselschild- / "Kleber" -Code

Diese Regel ergänzt die 80-20-Regel. Nun gibt es viele verschiedene Interpretationen der 80-20-Regel, aber die beiden, die mir am besten gefallen, sind:

1. Die ersten 80% der Produktentwicklung machen 20% des Aufwands aus.
2. 80% der Fehler sind in 20% des Codes enthalten.

In der Praxis bedeutet dies Folgendes: Die Entwicklung beginnt und schreitet bis zu einem bestimmten Zeitpunkt fort, an dem die ersten Verzögerungen bemerkt werden. Die Verzögerungen können unterschiedlicher Natur sein:

• Schlechte Qualitätskontrolle, was zu Fehlern führt
• Zusätzliche Anforderungen, die der Kunde auf dem Weg gefunden hat (und die Gründe dafür können auch vielfältig sein)
• Unklare Anforderungen von Anfang an, die dazu führen, dass Teile der vorherigen Entwicklung verworfen werden (was auch zu Regressionsfehlern führen kann)
• Anfängliche Unterschätzung aufgrund unklaren Umfangs, menschlichen Versagens oder unvorhergesehener Umstände. Diese unvorhergesehenen Umstände können Krankheitstage, Rücktritt, Hardwareausfälle oder im Extremfall Vulkanausbrüche sein (einmal mussten wir ein Projekt verschieben, weil wir aufgrund eines Vulkanausbruchs auf Island nicht vor Ort fliegen konnten).

Fazit ist, dass es viel einfacher ist, sich dem Ziel zu nähern, als es tatsächlich zu erreichen.

Ich finde die Wikipedia- Erklärung ziemlich aufschlussreich:

Dies summiert sich zu 180% in einer Anspielung auf die Bekanntheit von Softwareentwicklungsprojekten, die ihre Zeitpläne erheblich überschreiten (siehe Schätzung des Softwareentwicklungsaufwands). Es drückt sowohl die grobe Zuordnung von Zeit zu einfachen und schwierigen Teilen eines Programmierprojekts als auch die Ursache für die Verspätung vieler Projekte aus, da die schwierigen Teile nicht vorhergesehen werden können. Mit anderen Worten, es braucht mehr Zeit und mehr Programmieraufwand als erwartet, um ein Projekt zum Laufen zu bringen.

Was bedeutet das konkret in der Praxis? Dass Programmierer eine Menge Arbeit leisten und 180% aus sich heraus geben, oder?

Nein, Programmierer erledigen immer die gleiche Menge an Arbeit pro Zeiteinheit. Das Zitat handelt von einer Unterschätzung von Kosten und Überschreitungen. Die 180% sind der Zeit- und Geldaufwand, den das Projekt am Ende kostet.

Es bedeutet ungefähr "Es wird doppelt so lange dauern, wie Sie denken" und "Sie werden denken, dass es Ihnen gut geht, bis es bereits zu spät ist (die Frist ist nahe)".

In der Praxis bedeutet dies, dass die Menschen sich selbst belügen.

Wenn ein Programmierer sagt, "wir sind zu 90% fertig", bedeutet dies, dass 90% des Aufwands für die Erstellung der Funktionen aufgewendet wurden.

Wenn ein Projektmanager sagt, "wir sind zu 90% fertig, ich brauche nur jemanden, der das erledigt", bedeutet dies, dass er zu 90% über das Budget verfügt (und wahrscheinlich zu 50% fertig ist). Dies ist ein Kunde ohne Geld, mit hohen Erwartungen und einer schlechten Einstellung.

Der Unterschied besteht darin, dass das Fertigstellen eines Projekts mehr Aufwand erfordert als das Codieren von Funktionen: qa, Fehlerkorrekturen, Kopierbearbeitungen, Bereitstellung.

Diese Dinge müssen im Projekt verwaltet werden und liegen in der Verantwortung des Projektmanagers. Dies überrascht häufig neue PMs, die auf "90% Feature Complete" auslaufen, nur um zu erkennen, dass sie nur auf halbem Weg zu "Projekt erledigt" sind.