Umfang der Routinearbeit in der Softwareentwicklung und deren Auswirkungen auf die Schätzung

Ich bin überzeugt, dass der Umfang der Routinearbeit in der Softwareentwicklung relativ gering, wenn nicht vernachlässigbar ist und sein sollte und dass dies das grundlegende Problem der Softwareschätzung ist.

Lassen Sie mich beschreiben, wie ich zu diesem Schluss komme, und mir sagen, ob die Argumentation schwerwiegende Mängel aufweist:

1. Alles, was mit hoher Genauigkeit geschätzt werden kann, ist Routinearbeit, dh Dinge, die zuvor getan wurden. Alle anderen Arten von Arbeit, die Forschung und Kreativität betreffen, können nicht wirklich geschätzt werden, zumindest nicht mit einer Genauigkeit von beispielsweise +/- 20 Prozent.

2. Bei der Softwareentwicklung geht es darum, sich wiederholende Aufgaben zu vermeiden. Eines der Grundprinzipien ist TROCKEN (wiederholen Sie sich nicht). Immer wenn ein Programmierer sich wiederholende Dinge tut, ist es Zeit, eine Abstraktion zu finden, die diese Wiederholung vermeidet. Diese Abstraktionen können einfache Dinge sein, wie das Extrahieren des wiederholten Codes in eine Funktion oder das Einfügen in eine Schleife. Sie können auch komplexer sein als das Erstellen einer domänenspezifischen Sprache. In jedem Fall erfordert ihre Umsetzung Forschung (hat das schon jemand gemacht?) Oder Kreativität.

Aus diesen beiden Punkten ziehe ich die obige Schlussfolgerung.

Eigentlich habe ich mich schon eine ganze Weile gefragt, warum diese Beziehung nicht in jeder anderen Diskussion, jedem Blog-Beitrag oder Artikel über Software-Schätzung erwähnt wird. Ist es zu theoretisch? Sind meine Annahmen falsch? Oder ist es zu trivial - aber warum glauben dann die meisten mir bekannten Entwickler, dass sie Schätzungen mit einer Genauigkeit von +/- 20 Prozent oder besser durchführen können?

Bei jedem einzelnen Projekt kann dies zutreffen. Wenn Sie jedoch im Laufe der Jahre an mehreren ähnlichen Projekten für verschiedene Unternehmen arbeiten, können Sie feststellen, dass Sie im Grunde das gleiche Problem viele Male mit nur geringfügigen Abweichungen „lösen“.

Zum Beispiel habe ich Datenzugriffsschichten so oft geschrieben, dass ich es jetzt lieber als "lange Hand" mache, als das beliebte ORM des Monats zu verwenden. Es ist für mich schneller und einfacher, die "Routineprobleme" mit bekannten Lösungen zu lösen, als neue Macken in Komponenten von Drittanbietern zu finden und zu lösen.

Natürlich könnte ich mein eigenes ORM schreiben, um den sich wiederholenden Code zu vereinfachen, ohne die unbekannten Macken im System eines anderen hinzuzufügen, aber dieser Code würde zu der Firma gehören, für die ich gerade arbeitete, und andere Entwickler würden ihn genauso skurril finden wie jede andere ORM von Drittanbietern.

In ähnlicher Weise ist meiner Erfahrung nach die meiste Programmierung die Automatisierung von Geschäftsprozessen, und obwohl jedes Unternehmen gerne denkt, dass ihre Prozesse für sie einzigartig sind; In Wirklichkeit sind sie nicht.

Um nicht zu sagen, dass die Schätzung einfach ist! Es ist einfacher, aber ich finde, dass das Schätzproblem heutzutage eher auf die Unzulänglichkeit der Anforderungen als auf die Zeit zurückzuführen ist, die für die Codierung aufgewendet wurde.

Die Anforderungen lassen sich in drei Kategorien einteilen:

1. Vage, Details dem Entwickler überlassen.

"Mach mir eine Website, es muss cool sein und meine Widgets verkaufen"

Diese sind in der Regel am einfachsten abzuschätzen. Wenn ein schweres unerwartetes Problem auftritt, können Sie die Anforderungen einfach in etwas funktional Äquivalentes ändern und das Problem vermeiden.

2. Sehr spezifisch

"Machen Sie die Header Hintergrundfarbe # ff1100"

Super schnell und einfach zu schätzen. Aber! Die Anforderung muss sich ändern. "Hmm nein bei zweiten Gedanken, probieren Sie dieses andere Rot" oder "Warten Sie! Ich meinte nur auf dieser einen Seite!" Die Echtzeitspanne "Wie lange dauert es, bis ich mit der Header-Farbe zufrieden bin" hat also nichts mit den Codierungsschätzungen zu tun

3. Vage, Details angenommen

"Mach mir eine Website (genau wie Facebook)"

Hier muss die Vielzahl der nicht angegebenen Annahmen, "natürlich möchten Sie ein anderes Logo", "es sollte unendlich viel scrollen", "auf 1 Milliarde Benutzer skalierbar sein!" Steuern Sie die Schätzung effektiv. Entweder denkt der Entwickler an alles und treibt die Schätzung über die Erwartungen hinaus "1 Meeelion Mannstunden", oder er denkt an / nimmt an, dass nur die Basismerkmale erforderlich sind und gibt eine zu niedrige Schätzung ab. "Oh, ein oder zwei Wochen, ich nehme an, du willst Facebook nur in einen Iframe setzen, oder?"

Erfahrungsgemäß ist das Codieren sehr schnell, aber das Entwerfen von Anforderungen ist (normalerweise) das Schwierigste, und dies wird immer mehr auf Nicht-Codierer übertragen. Mit agilen Methoden wird die Codierungsgeschwindigkeit erhöht, indem diese Verantwortung eher auf das Unternehmen als auf Entwickler übertragen wird.

Warum glauben die meisten mir bekannten Entwickler, dass sie Schätzungen mit einer Genauigkeit von +/- 20 Prozent oder besser durchführen können?

Weil wir unsere Geduld mit dem Problem weit mehr schätzen als das eigentliche Problem.

Wenn ich einen springenden Ball animieren will, könnte ich einen Tag, eine Woche, einen Monat oder ein Jahr damit verbringen und trotzdem nur eine Animation eines springenden Balls haben. Hoffentlich sieht es besser aus, je mehr Zeit ich damit verbringe, aber ab einem bestimmten Punkt bin ich lächerlich.

Wie viel Mühe ich in das Abprallen des Balls gesteckt habe, hängt von der Zeit ab, die angemessen ist, um ihn zu verwenden. Wenn meine Fähigkeiten nicht ausreichen, kann es sein, dass ich einen Ball bekomme, der nur dort sitzt. Aber wenn die Frist kommt, sollte ich die Frist verschieben oder zumindest einen Ball auf den Bildschirm bekommen? Der Wasserfall bestand darauf, dass der Ball abprallte, und so rutschte der Zeitplan ab. Agile sagt, hol den Ball einfach raus. Zumindest werden wir herausfinden, wie sehr sich die Leute für das Hüpfen interessieren. So rutschte die Qualität ab.

Ich versuche sicher zu sein, dass meine Bälle abprallen, aber wenn die Frist abläuft, ist es besser, einen statischen Ball zu produzieren als gar nichts. Daher schätze ich die Zeit basierend auf der angemessenen Zeit, die für ein Problem aufgewendet werden muss, bevor über Alternativen gesprochen wird. Manchmal springt der Ball einfach nicht. Manchmal ist das in Ordnung. Einen Monat lang zu verschwinden ist nicht in Ordnung.