Schätzung der Zeitkosten in der alten Codebasis

Kürzlich habe ich begonnen, an einem Projekt zu arbeiten, bei dem eine sehr alte monolithische Anwendung in eine auf Mikroservices basierende Architektur migriert wird.

Die alte Codebasis ist sehr unübersichtlich ("Spaghetti-Code") und oftmals eine scheinbar einfache Funktion (z. B. "multiplyValueByTen"), die sich später als "Tausende Zeilen Validierungscode mit 10 Tabellen in 3 verschiedenen Schemata" herausstellt.

Jetzt bittet mich mein Chef (zu Recht) zu schätzen, wie lange es dauern würde, Feature X in der neuen Architektur zu schreiben. Aber ich habe Schwierigkeiten, eine realistische Schätzung zu finden. ich oft enorm unterschätzt die Aufgabe , aus Gründen , über ich gesagt habe und mich in Verlegenheit bringen , weil ich nicht in der Zeit nicht beenden können.

Das Vernünftige scheint wirklich in den Code zu kommen, notiert jede Verzweigung und ruft andere Funktionen auf und schätzt dann den Zeitaufwand. Aber es gibt wirklich einen winzigen Unterschied zwischen dem Dokumentieren des alten Codes und dem tatsächlichen Aufschreiben der neuen Version.

Wie soll ich mich einem solchen Szenario nähern?

Obwohl ich genau verstehe, wie das Refactoring von Legacy-Code funktioniert, geht es bei meiner Frage nicht darum, wie Refactor / Rewrite durchgeführt wird. Aber um eine realistische Antwort zu geben: "Wie lange würde es dauern, Teil X umzugestalten / neu zu schreiben?"

Lesen Sie Bob Martins "Clean Coder" (und "Clean Code", während Sie dabei sind). Das Folgende ist aus dem Gedächtnis, aber ich empfehle dringend, dass Sie Ihr eigenes Exemplar kaufen.

Was Sie tun müssen, ist ein gewichteter Durchschnitt von drei Punkten. Sie machen drei Schätzungen für jede Arbeit:

• ein Best-Case-Szenario - vorausgesetzt, alles läuft gut (a)
• ein Worst-Case-Szenario - wenn alles schief geht (b)
• die tatsächliche Vermutung - was Sie denken, wird es wahrscheinlich dauern (c)

Ihre Schätzung ist dann (a + b + 2c) / 4

• Nein, es wird nicht genau sein. Es gibt bessere Möglichkeiten zur Schätzung, aber diese Methode ist schnell, einfach zu verstehen und mindert den Optimismus, indem Sie den schlimmsten Fall in Betracht ziehen.
• Ja, Sie müssen Ihrem Vorgesetzten erklären, dass Sie mit dem Code nicht vertraut sind und dass es zu unvorhersehbar ist, genaue Schätzungen vorzunehmen, ohne den Code jedes Mal gründlich zu untersuchen, um die Schätzung zu verbessern (bieten Sie dies jedoch an) Nehmen wir an, Sie brauchen n Tage, um eine genaue Schätzung zu geben, wie viele Tage es noch dauern wird). Wenn Sie ein "JuniorDev" sind, sollte dies für einen vernünftigen Manager akzeptabel sein.
• Sie sollten Ihrem Vorgesetzten auch erklären, dass Ihre Schätzungen gemittelt werden, basierend auf dem besten Fall, dem schlechtesten Fall und dem wahrscheinlichen Fall, und ihnen Ihre Zahlen geben, die ihnen auch die Fehlerbalken geben.
• Verhandeln Sie NICHT über eine Schätzung - wenn Ihr Manager versucht, für jede Schätzung den besten Fall zu verwenden (sie sind ein Narr - aber ich habe einige davon getroffen) und motivieren Sie dann, die Frist einzuhalten, na ja, sie werde manchmal enttäuscht sein. Erklären Sie weiterhin die Gründe für die Schätzungen (bester Fall, schlechtester Fall und wahrscheinlicher Fall) und halten Sie sich die meiste Zeit an den gewichteten Durchschnitt, und Sie sollten in Ordnung sein. Führen Sie für Ihre eigenen Zwecke auch eine Kalkulationstabelle Ihrer Schätzungen und fügen Sie Ihre tatsächlichen Werte hinzu, wenn Sie fertig sind. Das sollte Ihnen eine bessere Vorstellung davon geben, wie Sie Ihre Schätzungen anpassen können.

Bearbeiten:

Meine Vermutungen, als ich das beantwortete:

1. Das OP ist ein Junior Developer (basierend auf dem gewählten Benutzernamen). Aus Sicht eines Projektmanagers oder Teamleiters kann daher nicht davon ausgegangen werden, dass er je nach Reifegrad der Entwicklungsumgebung differenziertere Schätzungen vornehmen kann.
2. Der Projektmanager hat einen Projektplan erstellt, der aus einer relativ großen Anzahl von Aufgaben besteht, deren Ausführung mehrere Monate in Anspruch nehmen soll.
3. Das OP wird gebeten, eine Reihe von Schätzungen für die von seinem Projektmanager zugewiesenen Aufgaben vorzulegen, die eine einigermaßen genaue Zahl (keine Wahrscheinlichkeitskurve :) enthalten sollen, um in den Projektplan eingespeist und zur Verfolgung des Fortschritts verwendet zu werden.
4. OP hat nicht Wochen Zeit, um jede Schätzung zu erstellen, und wurde zuvor durch zu optimistische Schätzungen verbrannt. Es wird eine genauere Methode angestrebt, als einen Finger in die Luft zu stecken und "2 Wochen" zu sagen, es sei denn, der Code ist besonders geheimnisvoll. In diesem Fall sind es 2 Monate oder mehr".

Der gewichtete Drei-Punkte-Durchschnitt funktioniert in diesem Fall gut. Es ist schnell, für Nicht-Techniker verständlich und sollte über mehrere Schätzungen hinweg zu einer annähernden Genauigkeit führen. Insbesondere, wenn OP meinen Rat bezüglich der Aufzeichnung von Schätzungen und Ist-Werten befolgt. Wenn Sie wissen, wie ein realer "Worst Case" und "Best Case" aussieht, können Sie die tatsächlichen Werte in Ihre zukünftigen Schätzungen einfließen lassen und sogar die Schätzungen für Ihren Projektmanager anpassen, wenn der schlimmste Fall schlechter ist als Sie dachten.

Lassen Sie uns ein Beispiel machen:

• Bester Fall, aus Erfahrung war der schnellste, den ich je gemacht habe, ein sehr einfacher, einwöchiger Start bis zum Ende (5 Tage).
• Aus Erfahrung gab es den schlimmsten Fall, dass es überall Links gab und es dauerte 6 Wochen (30 Tage)
• Tatsächliche Schätzung, ich werde wahrscheinlich 2 Wochen (10 Tage) brauchen

5 + 30 + 2x10 = 55

55/4 = 13.75, was Sie Ihrer PM mitteilen. Vielleicht runden Sie bis zu 14 Tage. Im Laufe der Zeit (z. B. zehn Aufgaben) sollte der Durchschnitt ermittelt werden.

Haben Sie keine Angst, die Formel anzupassen. Vielleicht endet die Hälfte der Aufgaben mit Albträumen und nur zehn Prozent sind einfach; also machst du die Schätzung a / 10 + b / 2 + 2c / 5. Lerne aus deinen Erfahrungen.

Beachten Sie, ich mache keine Annahmen über die Qualität der PM. Ein schlechter PM gibt dem Projektvorstand eine kurze Schätzung, um die Genehmigung zu erhalten, und schikaniert dann das Projektteam, um zu versuchen, die unrealistische Frist zu erreichen, zu der sie sich verpflichtet haben. Die einzige Verteidigung besteht darin, Aufzeichnungen zu führen, damit Sie sehen können, wie Sie Ihre Schätzungen abgeben und diesen nahe kommen.

Dies könnte ein guter Moment sein, um einen quasi agilen Ansatz einzuführen. Wenn Sie anstelle einer Schätzung in Stunden / Tagen eine Fibonacci-Typenskala zugewiesen haben und jeder Aufgabe einen Wert zugewiesen haben, der davon abhängt, wie groß sie ist:

• 0 - sofort
• 0,5 - schneller Gewinn
• 1 - einfache Änderung
• 2 - ein paar einfache Änderungen
• 3 - anspruchsvoller
• 5 - erfordert einige Überlegungen
• 8 - ein erheblicher Arbeitsaufwand
• 13 - ein großes Stück Arbeit, das wahrscheinlich abgebaut werden muss
• 20 - ein gewaltiger arbeitsaufwand, der unbedingt abgebaut werden muss

Sobald Sie eine Reihe solcher Aufgaben geschätzt haben, arbeiten Sie daran. In einer agilen Umgebung entwickeln Sie eine Geschwindigkeit, die ein Maß dafür ist, wie viele Punkte Sie beispielsweise in einer Woche erzielen. Nachdem Sie einige Wochen lang getestet und gelernt haben (Sie können dies als Teil des Prozesses an Ihren Vorgesetzten verkaufen - "Ich benötige einige Wochen Test und lerne, den Schätzungsprozess zu verstehen"), werden Sie es sein Sie können sich sicherer darauf verlassen, wie viele Punkte Sie pro Woche durchsetzen können, und so Ihre geschätzten Punkte schneller in die Zeit umsetzen.

https://pm.stackexchange.com/questions/4251/why-would-teams-the-fibonaccence-for-story-points-verwenden

https://stackoverflow.com/questions/9362286/why-is-the-fibonacci-series-used-in-agile-planning-poker

Dies ist nicht wirklich agil, da es nicht die Zeremonien beinhalten würde, aber ich habe die Idee vom OP, dass er alleine ist. Hoffentlich könnte dieser Ansatz zuversichtlichere Schätzungen liefern.

Das erste, was Sie tun, ist, Daten darüber zu sammeln, wie lange es dauert, bis Sie etwas erledigt haben. Je mehr Daten Sie über die Leistung Ihres Teams haben, desto besser. Es wird auf der ganzen Linie sein, aber mach dir darüber im Moment keine Sorgen. Es ist die Wahrheit und Sie müssen Ihrem Chef die Realität zeigen.

Dann wirst du ein paar Bücher kaufen.

1. Software Estimation: Demystifizierung der schwarzen Kunst von Steve McConnell
2. Effektiv mit Legacy-Code von Michael Feathers arbeiten

In McConnells Buch erfahren Sie, wie Sie mit dem Sammeln von Daten beginnen und wie Sie mit diesen Daten genauere Schätzungen erhalten. Schätzen Sie immer 3 Punkte! Immer. Achten Sie darauf, die Teile des Buches hervorzuheben, in denen davon die Rede ist, wie schlecht die Codequalität Ihre Schätzungen sprengt. Zeigen Sie sie Ihrem Chef.

Erklären Sie, dass Sie, wenn genaue Schätzungen für das Unternehmen wichtig sind, die Dinge anwenden müssen, die Sie aus Feders Buch lernen. Wenn Sie schnell, reibungslos und vorhersehbar vorgehen möchten, müssen Sie damit beginnen, den Code umzugestalten und ihn in ein Testgeschirr umzuwandeln. Ich war genau dort, wo du bist. Die Entwicklungszeit ist völlig unvorhersehbar, weil Sie keine Ahnung haben, was Sie möglicherweise brechen könnten, oder? ... Ja. Nimm es in ein Testgeschirr. Ein CI-Server, der diese Tests ausführt, kann ebenfalls nichts anrichten.

Zuletzt erklären Sie Ihrem Chef, dass die Dinge noch eine Weile unvorhersehbar sein werden. Wahrscheinlich ein paar Jahre, aber diese Entwicklung wird täglich einfacher und die Schätzungen werden genauer, je mehr Daten Sie haben und je besser der Code wird. Dies ist eine langfristige Investition für das Unternehmen. Ich habe dies kürzlich durchlaufen, es hat fast 2 Jahre gedauert, bis es größtenteils vorhersehbar war.

Ich weiß, dass ich mehr über die Verbesserung des Codes als über das Schätzen gesprochen habe, aber die harte Wahrheit ist, dass Ihre Schätzungen mies sind, bis Sie die alte Codebasis zähmen können. In der Zwischenzeit können Sie anhand der historischen Leistung abschätzen, wie lange dies dauern wird. Im Laufe der Zeit sollten Sie berücksichtigen, ob Sie den Code bereits in Ihren Schätzungen angegeben haben oder nicht.

Jetzt fragt mich mein Chef zu Recht, wie lange es dauern würde, Feature X in der neuen Architektur zu schreiben. Aber ich habe Schwierigkeiten, eine realistische Schätzung zu finden. Oft unterschätze ich die Aufgabe aus den oben genannten Gründen und schäme mich, weil ich nicht rechtzeitig fertig bin.

Sie überlegen vielleicht, ob Sie eine Schätzung abgeben sollen. Ich muss mit altem Code arbeiten und wenn ich eine formellere Schätzung vornehme, mache ich normalerweise zwei oder drei :

1. Primäre Schätzung - vorausgesetzt, ich muss ein bisschen graben, aber die Architektur lässt die gewünschten Änderungen zu
2. Angelic Estimate - setzt voraus, dass alles transparent / leicht zu finden ist und ich nur geringfügige Änderungen vornehmen muss (dies ist die, die ich manchmal auslasse ... insbesondere, wenn ich weiß, dass es nur Teufel in einer bestimmten Codebasis gibt)
3. Abyssal Estimation - geht davon aus, dass die grundlegende Struktur des Legacy-Codes mit der angeforderten Funktion nicht kompatibel ist und ich umfangreiche Umgestaltungen vornehmen muss, damit die Dinge funktionieren

Alle drei Schätzungen berücksichtigen , wie hart die Funktion an und für sich ist, jede Erfahrung , die ich mit diesem allgemeinen Code - Basis gehabt haben, und mein Bauchgefühl über die Änderung (die ich gefunden habe , kann ziemlich genau sein)

Nachdem diese Schätzungen vorliegen, halte ich meinen Vorgesetzten auf dem Laufenden, um welche es sich handelt. Wenn sich herausstellt, dass wir uns mit einem abgrundtiefen Feature befassen, müssen wir es möglicherweise opfern - es ist passiert. Wenn Ihr Chef nicht akzeptieren kann, dass es für einen bestimmten Teil des Legacy-Codes abgrundtiefe Merkmale gibt, dann wünsche ich ihnen viel Glück, denn sie werden ein sehr schwieriges und frustrierendes Leben führen.

Wenn ich mit dieser Art von Problem konfrontiert war, habe ich mich darauf verlassen, meine Schätzungen zu ändern. Ich habe es nicht geschafft, meinen Vorgesetzten mitzuteilen, "es ist schwierig, gute Schätzungen für diese Codebasis zu erstellen. Wenn Sie nach einer fragen, wird dies eine sehr breite Schätzung sein." Ich habe "3 Tage bis 3 Jahre" als Schätzung einmal angegeben. Unnötig zu sagen, dass es keine populäre Schätzung war, aber es ist, was ich gab.

Der Schlüssel dazu ist eine Vereinbarung, dass ich meine Schätzungen im Laufe der Arbeit aktualisieren werde. Wie lange dauert es, wenn ich die Meldung "Implementiere XYZ" erhalte? Meine Antwort könnte lauten: "Irgendwo zwischen einem Tag und vier Monaten. Wenn Sie mich jedoch einige Stunden lang den Code anzeigen lassen, kann ich die Unsicherheit in diesem Fenster verringern." Ich schaue mir dann den Code an und komme mit "2 bis 4 Wochen" zurück. Das ist immer noch kein ideales Fenster, aber es kann zumindest verwaltet werden.

Hierfür gibt es einige Schlüssel:

• Überzeugen , den Chef , dass diese Schätzungen besser als ein Gespräch behandelt werden , weil Sie werden mehr darüber erfahren , was die Aufgabe aussieht , während Sie daran arbeiten. Dies ist eine Gelegenheit für Ihren Chef, Informationen zu erhalten, die er nicht hätte, wenn er nur um eine einzige Schätzung gebeten hätte.
• Bieten Sie Optionen an, wie Sie vorgehen können, um die Geschwindigkeit der Entwicklung von Handelscodes im Vergleich zur Verbesserung der Schätzungen zu bestimmen. Gib ihnen einen zusätzlichen Knopf, den sie drehen können. Manchmal wissen die Bosse, dass eine Aufgabe nur erledigt werden muss, und sie benötigen nur eine Schätzung des Baseballstadions. In anderen Fällen haben sie die Vor- und Nachteile einer Aufgabe, und die Fähigkeit, die Schätzungen zu verfeinern, ist wertvoll.
• Nach Möglichkeit biete ich auch Synergieboni an. Oft gibt es architektonische Verbesserungen, die für viele Aufgaben von Vorteil sind. Wenn ich 10 Aufgaben habe, die alle "1-2 Monate jetzt, aber 2 Wochen mit Upgrade X" dauern, ist es einfacher, die 20 Wochen zu verkaufen, die für Upgrade X erforderlich sind.

Wenn ich einen Chef habe, der es nicht mag, einen Bereich zu erhalten, der im Laufe der Zeit aktualisiert wird, gebe ich ihm eine einzelne Nummer und meine Methodik. Meine Methodik ist eine Kombination aus einer Faustregel, die mir als junger Entwickler mitgeteilt wurde, und Hofstaders Gesetz .

Schätzen Sie, wie lange die Aufgabe Ihrer Meinung nach dauern sollte, vervierfachen Sie diese Zahl und geben Sie sie als Schätzung an.

und

Hofstädter-Gesetz: "Es dauert immer länger als erwartet, auch wenn Sie das Hofstädter-Gesetz berücksichtigen."

Das Vernünftige scheint wirklich in den Code zu kommen, notiert jede Verzweigung und ruft andere Funktionen auf und schätzt dann den Zeitaufwand. Aber es gibt wirklich einen winzigen Unterschied zwischen dem Dokumentieren des alten Codes und dem tatsächlichen Aufschreiben der neuen Version.

Dies ist die Lösung für Ihr Problem. Sie können nicht abschätzen, ob Sie keine Anforderungen haben. Sagen Sie Ihrem Chef, dass Sie dies tun müssen, bevor Sie mit dem Codieren beginnen können. Nach einigen Funktionen und Modulen stellen Sie möglicherweise fest, dass sie alle konsistent codiert wurden (in diesem Fall schlecht), sodass Sie eine Basis haben, um zukünftige Schätzungen zu bestimmen. Stellen Sie einfach sicher, dass Sie Ihre Schätzung anpassen, wenn Sie feststellen, dass sich die Codierung verschlechtert.

Ich weiß, dass Ihr Chef eine Schätzung wünscht, aber ohne zu wissen, wie diese Informationen verwendet werden, wissen wir nicht, wie genau Ihre Schätzungen sein müssen. Unterhalte dich mit ihm und finde es heraus. Wenn er nur eine Nummer benötigt, um seinem Chef eine Nummer zu geben, können Sie die Schätzungen leicht erhöhen und eine Nummer angeben. Wenn Kunden warten, bis dies erledigt ist, um für Ihren Code zu zahlen, stellen Sie sicher, dass Sie herausfinden, ob Fälligkeitstermine für die harte Linie zu erheblichen Einnahmen führen werden.

In einer Situation wie dieser glaube ich nicht, dass es möglich ist, gute Schätzungen abzugeben. Das Grundproblem ist, dass ein großer Teil der Arbeit darin besteht, genau herauszufinden, was getan werden muss.

Ich behandle solche Fälle, indem ich eine Schätzung gebe, die auf dem basiert, was es zu bedeuten scheint, aber mit der Gewissheit, dass Überraschungen wahrscheinlich sind. Obwohl ich mich nicht mit viel in Bezug auf alten Code auseinandersetzen musste, hatte ich einige sehr böse Überraschungen im Umgang mit Eingaben - ich habe gesehen, dass einige Stunden zu ein paar Wochen wurden und einmal ist dies unmöglich (After Ich fand heraus, dass ich in einem bestimmten Fall nicht genügend Daten hatte, und zwar zurück zum Reißbrett.) Zum Glück versteht mein Chef, wann ich solche Schätzungen mache.

Nun, Schätzung ist eine Fähigkeit, die manche Leute nie gut lernen. Es macht Sie als Entwickler jedoch nicht unbrauchbar, auch wenn Sie keine guten Einschätzungen treffen können. Vielleicht füllen Teamkollegen oder das Management die Lücken. Ich bin schrecklich darin, trotzdem haben die meisten Teams gerne mit mir zusammengearbeitet. Bleiben Sie ruhig, schließen Sie sich zusammen und setzen Sie das Refactoring fort.

Technische Schulden stellen Sie vor nette kleine Herausforderungen, aber denken Sie daran, dass ein Unternehmen / Team, das am Ende Schulden produziert hat, weiterhin Schulden produziert, es sei denn, es gibt Änderungen im Teamgeist oder im Management. Der Code spiegelt nur die sozialen Probleme wider, konzentrieren Sie sich also auf die tatsächlichen Probleme.

Wir haben eine Heuristik zum Schätzen von Features in einem Brownfield-Projekt verwendet: Wir haben geschätzt, wie lange es gedauert hätte, dieses Feature in einem Greenfield-Projekt zu implementieren, ohne dass bereits etwas implementiert worden wäre. Dann multiplizierten wir diese Schätzung mit 2, um bereits vorhandene Ablagerungen zu beseitigen.

Dieser Faktor hängt vom Umfang der Kopplung und der Gesamtcodegröße ab. Wenn Sie jedoch einige Funktionen auf diese Weise ausführen, können Sie diesen Faktor basierend auf den tatsächlichen Nachweisen interpolieren.

Ich denke, Sie sollten sich zu Ihrem Chef setzen, ihm direkt in die Augen schauen und sagen:

'Hören Sie Chef! Wir überarbeiten gerade hier. Es gibt keine neuen Funktionen und keine Kunden, die auf diese Funktionen warten. Es sollte also keine Fristen geben. Dies wird so lange dauern, wie es dauert. Sie müssen sich entscheiden, ob wir es tun müssen oder nicht. '

Verwenden Sie eine feste, durchsetzungsfähige Gestik, wie z. B. Zeigen, und setzen Sie sich in Ihrem Stuhl nach vorne.

Alternativ können Sie sich auch Zahlen machen, um ihn glücklich zu machen. Aber seien wir ehrlich, bis Sie die Hälfte der Arbeit hinter sich haben, werden Ihre Schätzungen ziemlich ungenau sein.