„…unsere Schätztechniken verwechseln fälschlicherweise Aufwand mit Fortschritt und verbergen so die Annahme, dass Männer und Monate austauschbar sind.“ ~ Frederick P. Brooks, Jr.

Schätzungen zur Softwareentwicklung sind schwierig und unzuverlässig. Dies ist kein neues Problem; Wir kämpfen seit Jahrzehnten mit Schätzungen. Dennoch bestehen wir immer noch auf ihnen – sie vermitteln ein (größtenteils falsches) Gefühl der Sicherheit.

Das Problem liegt in der Art der Arbeit, die wir leisten. Es erfordert oft Argumentation und Problemlösung; Wir müssen uns hinsetzen und mit einem Problem ringen, bis wir „es herausfinden“ können. Unsere Schätzungen versuchen, ein gewisses Maß an Vorhersehbarkeit in die Arbeit zu bringen, das von Natur aus unvorhersehbar ist.

Nehmen wir zur Veranschaulichung an, dass Sie mit den Schachregeln vertraut sind. Wenn ich ein Schachbrett vor Sie stelle, während eine Partie läuft, und Ihnen sage, dass Weiß in drei Zügen matt setzen kann – wie lange werden Sie brauchen, um herauszufinden, was diese drei Züge sind? Denken Sie daran, Sie kennen die Regeln, Sie wissen, wie sich die Figuren bewegen und Sie wissen, wie das Spielbrett derzeit aussieht. Mit anderen Worten: Sie verfügen über alle Informationen, von denen man annimmt, dass Sie sie benötigen.

Können Sie es nicht abschätzen? Nun ja... Softwareentwicklung ist so ziemlich dasselbe.

Warum es schwierig ist, Schätzungen richtig zu machen

Bei Softwareprojekten müssen wir eine Reihe von Elementen berücksichtigen – darunter Technologie, Menschen, Anforderungen und externe Abhängigkeiten. In jedem von ihnen besteht Variabilität.

Technologie an sich ist komplex – es gibt eine Vielzahl von Programmiersprachen, Bibliotheken und Tools. Wenn wir all diese Dinge zusammenfassen, treten oft unerwartete Probleme auf. Eine vermeintlich fünfminütige Änderung zum Aktualisieren einer Bibliotheksversion kann zu einem zweitägigen Aufwand werden, da die neue Bibliotheksversion mit einer anderen Bibliothek irgendwo nicht kompatibel ist und daher auch geändert werden muss. Dies erfordert wiederum zusätzliche Tests. Ein Tippfehler in einer Codezeile kann stundenlanges Debuggen nach sich ziehen.

Menschen sind auch nicht immer gleich produktiv – und Schätzungen gehen davon aus, dass wir alle gleich kompetent sind und in einem konstanten Tempo arbeiten, unabhängig davon, ob wir müde, frustriert oder krank sind. In der realen Welt funktioniert das so nicht. Es kommt zu Unterbrechungen und manchmal muss jemand ein oder zwei Stunden damit verbringen, einem Kollegen zu helfen (und das ist keine schlechte Sache).

Anforderungen können unklar sein oder sich ändern, wenn neue Informationen ans Licht kommen (und das sollten sie auch). Wenn ein Entwickler mit der Umsetzung einer neuen Anforderung beginnt und feststellt, dass etwas nicht ganz sinnvoll ist, muss er sich an jemanden wenden, der es für ihn klären kann. Aber was ist, wenn diese Person im Urlaub ist oder den Rest des Tages in Besprechungen steckt? Die „Wartezeit“ führt insgesamt zu einer Verzögerung – was bedeutet, dass eine einzige Frage zu einer Anforderung eine Schätzung ungültig machen kann.

Externe Abhängigkeiten sind schwerer zu kontrollieren als Anforderungsänderungen – wenn wir in eine Welt vordringen, in der wir von externen Anbietern abhängig sind, unterliegen wir deren SLAs zur Behebung von Problemen. Wenn es sich bei der externen Abhängigkeit um eine API handelt, bedeutet dies, dass wir mehrere zusätzliche Fehlerquellen eingeführt haben – Probleme mit unseren Servern, den Servern des Anbieters oder einer der dazwischen liegenden Netzwerkkomponenten führen zu Verzögerungen.

Schätzungen können auch zu der Annahme führen, dass die Arbeit teilbar ist. Wenn die Entwicklung einer Funktion schätzungsweise 10 Tage in Anspruch nimmt, heißt das dann, dass zwei Entwickler sie in fünf Tagen schaffen können? Oder 10 Entwickler an einem Tag? Leider können neun Frauen in einem Monat kein Kind bekommen . Tatsächlich führt das Hinzufügen weiterer Entwickler, um den Prozess zu beschleunigen, nur zu einem höheren Kommunikationsaufwand, was die Situation wahrscheinlich noch verschlimmern wird.

Warum Stakeholder Schätzungen wünschen

Es ist nicht schwer zu verstehen, warum unsere Stakeholder Schätzungen wünschen. Letztendlich bezahlt jemand für die Arbeit, die wir leisten. Sie haben Budgets, sie haben Fristen, sie müssen Kunden zufriedenstellen und sie müssen den ROI berechnen. Wenn wir ihnen sagen können, was sie wann erwartet, wird dieser Prozess einfacher.

In einigen anderen Branchen können Aufgaben so genau definiert sein, dass wir sie zuverlässig abschätzen können. Wenn wir an einer Produktionslinie Widgets zusammenbauen und wissen, dass die Montage eines Widgets genau 10 Minuten dauert, wissen wir, dass wir sechs Widgets in einer Stunde zusammenbauen können. Allerdings sind unsere Widgets (im Gegensatz zu unserer Software) standardisiert – es ist also unwahrscheinlich, dass wir von der Norm abweichen, es sei denn, die Produktionslinie wird stillgelegt. Dasselbe Denken, das in anderen Branchen funktioniert, kann nicht auf Software übertragen werden. Jede innovative Lösung, die wir entwickeln, beinhaltet die Lösung eines neuen, neuartigen Problems. Wir können auf Erfahrungen aus der Vergangenheit zurückgreifen, aber wir betreiben keine Produktionslinie.

Traditionelle Schätzungsansätze

Std

Das ist selbsterklärend – wir schätzen, dass die Erledigung einer bestimmten Aufgabe eine bestimmte Anzahl von Stunden in Anspruch nehmen wird. In der Praxis sind die Menschen darin schrecklich und wir verstehen es meist sehr falsch. Dies ist auch gefährlich, da die Stundenschätzungen je nach Teammitglied variieren – eine zweistündige Aufgabe für einen Entwickler mit 10 Jahren Java-Erfahrung wird wahrscheinlich keine zweistündige Aufgabe für einen Absolventen sein, der vor einem Monat mit dem Erlernen von Java begonnen hat .

Story-Punkte

Dies ist der von Scrum vorgeschlagene Ansatz.

Story Points sind eine relative Maßeinheit, die Aufgaben miteinander vergleicht. Mit anderen Worten, wir beginnen mit einer Proxy-Aufgabe wie „Füge einen Bildschirm mit fünf Feldern, einem API-Endpunkt und einer Datenbanktabelle dahinter hinzu“ und weisen ihr einen beliebigen Wert (normalerweise basierend auf der Fibonacci-Folge) zu. Wenn unserer Proxy-Aufgabe fünf Story-Punkte zugewiesen werden und wir unsere nächste Aufgabe schätzen – „Fügen Sie einen Bildschirm mit zehn Feldern, zwei API-Endpunkten und einer Datenbanktabelle dahinter hinzu“ – entscheiden wir möglicherweise, dass die Aufgabe etwas komplexer ist, und weisen sie zu Acht Geschichten weisen darauf hin. Story Points stellen keine Tage, Stunden oder andere zeitspezifische Metriken dar – sie dienen lediglich dem Vergleich verschiedener Aufgaben.

Anschließend berechnen wir die Anzahl der Story Points, die ein Team im Verlauf eines Sprints abschließt, und ermitteln daraus die „Geschwindigkeit“ des Teams. Dabei handelt es sich um eine Kennzahl, die uns einen Hinweis darauf gibt, wie viele Story Points wir während eines Sprints absolvieren können. Diese Kennzahl basiert auf dem Team als Ganzes und nicht auf Einzelpersonen.

Der Prozess des Schätzens von Story Points wird als „ Planning Poker “ bezeichnet und findet im Rahmen von Backlog-Grooming-Sitzungen statt, an denen das gesamte Entwicklungsteam beteiligt ist. Es gibt viel Widerstand gegen Story Points , aber der Prozess der Zuweisung von Story Points ist immens wertvoll, da er es einem ganzen Team ermöglicht, eine Aufgabe zu diskutieren und zu verstehen. Ich persönlich glaube, dass dies immer noch ein viel besserer Ansatz ist, als zu versuchen, die Stunden zu schätzen.

Alternative Ansätze

Wir nutzen Schätzungen, um ein Gefühl der Vorhersehbarkeit zu schaffen. Während Schätzungen schwierig und unzuverlässig sind, gibt es andere Möglichkeiten, Vorhersagbarkeit zu schaffen.

Vorhersehbarkeit kann durch einen regelmäßigen Lieferrhythmus erreicht werden – mit anderen Worten, wir liefern regelmäßig etwas an die Produktion (z. B. eine Bereitstellung nach jedem zweiwöchigen Sprint). Wir können zwar nicht zuverlässig vorhersagen, was in Produktion gehen wird, aber wir können fast garantieren, dass alle zwei Wochen etwas bereitgestellt wird. Da wir Geschichten als Arbeitseinheiten definieren, die einen tatsächlichen Geschäftswert schaffen, bedeutet dies, dass wir uns kontinuierlich auf einen besseren Zustand zubewegen.

Obwohl die Entwicklungsarbeit oft nicht teilbar ist, können wir sie rationalisieren, indem wir einem Problem mehr Intelligenz zuweisen – z. B. Paarprogrammierung oder Mobprogrammierung. Dabei geht es nicht um Arbeitsteilung, sondern darum, gemeinsam an der Lösung desselben Problems zu arbeiten. Dies kann die Entwicklung beschleunigen, da die eigentliche Arbeit in der Problemlösung und nicht im Tippen besteht – zwei Köpfe lösen ein Problem besser.

Transparenz ist der Schlüssel – unerwartete Überraschungen sind an der Tagesordnung, aber stellen Sie als Entwicklungsteam sicher, dass Ihre Stakeholder über Ihre Fortschritte und die Probleme, auf die Sie stoßen, Bescheid wissen.

Teilen Sie Aufgaben in kleine, granulare Einheiten auf. Kleine Codeteile sind aufgrund ihres begrenzten Umfangs einfacher zu entwickeln, einfacher zu testen und vorhersehbarer.

Wenn Sie einen Kostenvoranschlag abgeben müssen, machen Sie sich klar, welche Voraussetzungen für Ihren Kostenvoranschlag gelten. Beispielsweise könnte bei Ihrer Schätzung von drei Tagen für die Implementierung einer Funktion davon ausgegangen werden, dass sich die Anforderungen nicht ändern, dass es keine Bibliothekskonflikte gibt und dass alle externen APIs jederzeit verfügbar sind. Dies ist vielleicht nicht realistisch, aber indem Sie es explizit sagen, helfen Sie Ihren Stakeholdern auch, die zugrunde liegende Komplexität zu verstehen.

Zusammenfassend lässt sich sagen, dass eine Schätzung schwierig ist. Verwenden Sie es als Richtlinie und Ziel, aber denken Sie daran, dass Ihre Schätzungen wahrscheinlich falsch sein werden. Anstatt zu versuchen, dass Ihre Schätzungen zu 100 % korrekt sind, konzentrieren Sie sich darauf, Aufgaben zu verstehen, schrittweise kleine Arbeitsschritte zu liefern, häufig einen Mehrwert zu liefern und gegenüber Ihren Stakeholdern transparent zu sein.

PS Schauen Sie sich auch die #noestimates-Bewegung an .

Haftungsausschluss: Wie immer sind die in diesem Beitrag geäußerten Ansichten meine eigenen.