it-swarm.com.de

So messen Sie den potenziellen Wert von Refactoring

Wie können Sie bei einem alten, großen Projekt mit technischen Schulden den Nutzen von Refactoring-Code zuverlässig abschätzen oder messen?

Angenommen, Sie haben einige Komponenten in einer Software-Stack-Lösung in einer älteren Sprache und einige spätere Komponenten in einer neueren Sprache. Diese Entwicklung wird ständig von einem Entwicklungsteam um neue Funktionen und Fehlerbehebungen erweitert.

Die Entwickler schlagen vor, dass das Ersetzen der vorhandenen alten Sprachkomponenten durch die neue Version "eine gute Sache" wäre. Durch diese Arbeit würden jedoch keine zusätzlichen Funktionen hinzugefügt, und es würde x Entwicklertage kosten.

Ein Verkäufer schlägt vor, "eine großartige neue Funktion" hinzuzufügen. Das Unternehmen misst den Wert seines Vorschlags anhand einer Formel. dh. Es wird dem Unternehmen über t Jahre F Millionen Pfund einbringen, was x Arbeitstage kostet

Wie kann das Unternehmen den Refactoring-Vorschlag sinnvoll kosten? und unter welchen Umständen ist es wahrscheinlich die rentabelste Option für das Unternehmen?

46
Ewan

Es wird dem Unternehmen über t Jahre F Millionen Pfund einbringen, was x Arbeitstage kostet

Dabei werden Wartungskosten, Supportkosten und Vertriebs-/Marketingkosten ignoriert und viele Annahmen darüber getroffen, wie die Funktion auf dem Markt eingesetzt wird.

Aber was auch immer; Ihre Frage ist klar genug, wonach Sie suchen:

Wie kann ich ein Business Case für das Refactoring erstellen?

Die Hauptsache ist, dass Zeit gleich Geld ist. Sie können direkt zu "5 Entwickler 2 Wochen = 80 Stunden * 5 Entwickler * 50 USD/Std. -> 20.000 USD" wechseln, und das ist für Geschäftsleute sinnvoll. Kluge Geschäftsleute werden feststellen, dass diese 5 Entwickler in beide Richtungen bezahlt werden, womit Sie kontern, dass sie die 20.000 US-Dollar nicht ausgeben/sparen - sondern die 20.000 US-Dollar auf die profitabelste Weise verwenden. Sowieso weiter mit der Liste.

  • Effizienz - Vermutlich können Sie mit C # mehr Dinge erledigen als mit VB6. Bessere Werkzeuge, bessere Bibliotheken, was auch immer. Neuere Technologien sind in der Regel besser als ältere. Wenn Sie Dinge in kürzerer Zeit erledigen können, bedeutet dies, dass Sie dem Unternehmen Geld sparen.
  • Overhead - Codierung ist nicht die einzige Kosten für Software. Überlegen Sie, was passiert, wenn Windows 2020 herauskommt. Wie viel Zeit und Mühe werden Sie aufwenden, um diese VB6-App daran arbeiten zu lassen? Wie viel mehr Zeit und Mühe kostet das als eine C # -App? Das spart Ihrem Unternehmen Geld.
  • Qualität - Vermutlich können Sie in C # Dinge mit höherer Qualität als in VB6 erledigen (oder mit einer saubereren Architektur oder was auch immer Ihr Refactoring-Ziel ist). Höhere Qualität bedeutet weniger Fehler. Weniger Fehler bedeuten weniger Kosten für die Behebung dieser Fehler, weniger Kosten für den Kundensupport, um diese Probleme zu beheben, weniger Kundenverluste aufgrund von Qualitätsproblemen, höhere Umsätze aufgrund des Rufs für Qualität ... alle Dollar für Ihr Unternehmen.
  • HR Savings - Seien wir ehrlich: Niemand möchte mit dieser beschissenen VB6-App arbeiten. Das bedeutet, dass mehr Menschen das Unternehmen verlassen, was Zeit und Geld kostet, um sie zu ersetzen. Das bedeutet, dass die Einstellung neuer Mitarbeiter mehr Zeit und Geld kostet. Das Schlimmste ist, dass Sie Entwickler haben, die mit dieser VB6-App Selbstmord begehen können. Diese Entwickler beschleunigen wiederum die Todesspirale der Qualitätsprobleme. Durch die Reduzierung von Umsatz und Einstellungszeiten sparen Sie Ihrem Unternehmen Geld. Selbstgefällige, beschissene Entwickler fernzuhalten, rettet Ihr Unternehmen.
  • Moral - Ebenso hassen es die Programmierer, die bereits dort sind, in VB6 zu arbeiten. Sie werden es tun, und sie könnten es sogar gut machen. Aber es ist scheiße. Vielleicht nicht für jedermann, aber sicherlich für einige. Das bedeutet mehr Zeit für das Surfen im Internet, um die Motivation wiederzugewinnen. Es bedeutet längere Mittagessen. Es bedeutet weniger, Dinge zu erledigen, während Ihre Programmierer länger brauchen, um sich von der blöden Arbeit zu erholen.
  • Fähigkeit - Dies gilt weniger für technologiegetriebene Refaktoren, gilt jedoch für Architektur-Refaktoren. Bestimmte Codeprobleme hindern Sie aktiv daran, coole Funktionen X bereitzustellen, um eine Menge Geld zu verdienen. Vielleicht können Sie nicht skalieren. Vielleicht können Sie nicht an die Daten kommen, um coole Informatik zu machen. Vielleicht ist der Code so ein Rattennest, dass es unerschwinglich schwierig ist, die Arbeit tatsächlich zu erledigen. Wie auch immer. Manchmal bist du an diesem Punkt, manchmal fährst du direkt auf diesen Punkt zu. Es ist schwer, geschäftlich zu übersetzen, aber wenn Sie können, kann das "Dieses Problem hindert uns daran, die Chancen X, Y und Z zu nutzen" mächtig sein.

Alles in allem kommt es darauf an, "dieses Zeug wird uns helfen, unsere Arbeit besser zu machen; wenn wir unsere Arbeit besser machen, können wir Ihnen mehr Geld verdienen/sparen".

48
Telastyn

Die Frage, die Sie sich stellen sollten, ist, wie ist der Verkäufer wissen, dass die Funktion x Entwicklertage Arbeit kostet. Angesichts der Tatsache, dass selbst gute Projektmanager mit langjähriger Berufserfahrung dies nicht oft sagen können, scheinen solche Daten, die von einem Verkäufer stammen, äußerst ... spekulativ.

Nach meiner Erfahrung machen Verkäufer normalerweise keine Schätzungen, aber Vermutungen darüber, wie viel für das Management zu viel ist oder Kunde: Wenn das Management bereit ist, 50 Mannwochen Arbeit zu zahlen, dies aber absolut ablehnt 75 Mannwochen, lassen Sie uns sagen, dass die Funktion 70 Mannwochen dauern wird, während Sie bereit sind, neu zu verhandeln (was für eine echte Schätzung nicht in Frage kommt) bis zu 55 Mannwochen.

  • Einerseits haben Sie Schätzungen von IT-Experten erstellt, die Folgendes sagen:

    Laut dieser speziellen Prüfung verschwenden wir 8 000 USD pro Tag mit einer veralteten Technologie im Vergleich zu ähnlichen Projekten ähnlicher Größe, die neuere Technologien verwenden. Es scheint auch, dass die Migration der gesamten Codebasis 50 bis 80 Mannwochen dauern wird. Während dieser Zeit würden keine neuen Funktionen veröffentlicht. Es besteht auch ein 10% iges Risiko, dass die Migration einer bestimmten Komponente zu 20 bis 30 zusätzlichen Arbeitswochen führt.

  • Auf der anderen Seite haben Sie Vermutungen von Verkäufern durchgeführt, basierend auf ihrer Hebelwirkung bei Verhandlungen mit der Person, die sie überzeugen müssen.

Es geht darum, wie einflussreich Sie in Ihrem Unternehmen sind. Kommunikation ist hier der Schlüssel, und hier überzeugen Vertriebsmitarbeiter normalerweise IT-Experten, wenn es darum geht, dem Management (oder einem Kunden) die Vorteile einer Funktion zu erläutern.

Beachten Sie, dass Sie, wenn Ihre Schätzungen in der Vergangenheit recht genau waren, an Ansehen und Einfluss gewinnen. Wenn Ihre Schätzungen immer falsch wären, würde das Management Ihre Vorschläge wahrscheinlich ignorieren.

Bei den Schätzungen ist es äußerst schwierig, hier eine wertvolle zu erstellen, da eine Vielzahl von Parametern zu berücksichtigen ist. Unter anderen:

  • Wissen Sie tatsächlich, wie geschickt Ihr Team in C # im Vergleich zu VB6 ist? Basiert es auf tatsächlichen Messungen oder nur auf Vermutungen?

  • Hat dieses Team große Projekte in C # entwickelt? Kennen sie die Tools, die sie verwenden sollten (IDE, Debugger, Profiler usw.)? Benötigen Sie zusätzliche Lizenzen (was in der Welt von Microsoft Tausende von Dollar pro Computer bedeutet)?

  • Ist das aktuelle Projekt völlig klar und Sie können garantieren, dass es bei der Migration keine Überraschungen gibt? Ist es einfach, alles, jedes Feature neu zu schreiben, oder gibt es Überraschungen?

  • Haben Sie die Infrastruktur, die C # unterstützt? Was ist mit kontinuierlicher Integration? Was ist mit Ihrem Build-Server? Styleguides? Statische Prüfer?

  • Können Server (wenn es sich um eine Web-App handelt) oder Kunden-PCs (wenn es sich um eine Desktop-App handelt) in der Produktion die Version von .NET Framework ausführen, die Sie voraussichtlich verwenden werden?

Aber das Wichtigste ist zu wissen, warum möchten Sie alles neu schreiben. Was ist das Problem, das Sie durch ein Umschreiben lösen möchten? Produktivitätsverlust? Wie messen Sie es? Wie zeigen Sie dem Management diesen Produktivitätsverlust?

Wenn Sie gezeigt haben, dass Sie aufgrund von VB6 beispielsweise 8.000 US-Dollar pro Tag verschwenden (was bedeutet, dass Sie nach der Migration auf C # 8.000 US-Dollar pro Tag sparen), wie erklären Sie den Vorteil, jede neue Funktionsentwicklung und zu halten Konzentrieren Sie sich auf eine vollständige Neufassung? Was ist der Vorteil im Vergleich zu progressives Umschreiben, bei dem Sie Ihre Komponenten nacheinander in kleinen Blöcken migrieren und gleichzeitig neue Funktionen ausliefern?

12

Zunächst müssen Sie die Entwicklungskosten für das Re-Factoring wie bei der verkaufsgesteuerten Funktionsanforderung schätzen.

Es mag schwierig sein, genau zu werden, wenn es sich um eine große Aufgabe handelt. Vorausgesetzt, Sie haben ausreichend Erfahrung mit den beiden Technologien, sollte dies machbar sein.

Zweitens benötigen Sie eine Schätzung der Kosten für das Nicht-Re-Factoring. Wenn Sie die Schätzungen für mich vornehmen würden, würde ich ein gewisses Maß an Metriken erwarten. Zum Beispiel die Differenz zwischen den durchschnittlichen Entwicklungskosten für VB Code und für C # -Code über ein Viertel. Oder einige davon. Dies hängt natürlich davon ab, wie genau Sie dies verfolgen.

Mit diesen beiden Zahlen können Sie die Amortisationszeit schätzen, die Ihnen das Re-Factoring bietet, d. H. An welchem ​​Punkt wird das Re-Factoring von den Nettokosten zu einem Nettogewinn.

Ich kann nur raten, wie überzeugend ein bestimmtes Ergebnis sein würde. Wenn es jedoch weniger als ein Jahr ist, wird es wahrscheinlich ziemlich stark sein, viel mehr als 2 Jahre, dann können Sie gut kämpfen.

Darüber hinaus lohnt es sich wahrscheinlich, weitere Dimensionen hinzuzufügen, um Ihren Fall zu erstellen. Eine, die ich in der Vergangenheit verwendet habe, ist zu sehen, ob Exit-Interviews die Technologie als Treiber zitierten. In diesem Fall können Sie argumentieren, dass durch das Re-Factoring Mitarbeiter gehalten werden (Einstellung und Schulung sind sehr teuer).

Natürlich können Sie diese Dinge argumentieren, ohne Beweise zu liefern, aber ich finde, dass dies einen großen Unterschied für die Auswirkungen des Falls bedeuten kann.

3
Alex

Ich denke, der Punkt, den die anderen Antworten verpassen, ist, dass Sie die Kosten für das Refactoring an den entgangenen Einnahmen aus dem Nicht-Refactoring messen müssen.

Refactoring zum Ändern des Codes ist Zeitverschwendung. Es muss Wert auf den Tisch bringen. In diesem Zusammenhang meine ich nicht, dass Sie eine Stunde damit verbringen, eine Problemklasse umzugestalten, sondern das Haupt-Refactoring, z. B. den Wechsel zu einer anderen CLR-Sprache, wie Sie sie in Ihrem Beispiel verwendet haben.

  • Wenn wir weitermachen, was wir tun, verpassen wir dann etwas? Gibt es ein altmodisches Design, das uns davon abhält, Werte zu realisieren? Wenn wir beispielsweise ein Feature hinzufügen möchten, ist es so schwierig, dass es z. 100 Stunden für die Implementierung, 50 Stunden für die Umgestaltung und 25 Stunden für die Implementierung gegen das neue Design?

  • Trägt der vorhandene Code technische Schulden das kostet uns Geld? Ist dieser beschissene alte Code die Quelle von Fehlern? Arbeiten wir am Ende kostenlos, um Probleme zu beheben? Niemand mag es, lukrative abrechnungsfähige Stunden kostenlos zu verschenken.

  • Sind die Kosten für das Refactoring gleich oder geringer als die Kosten für das Nicht-Refactoring?

  • Ist es möglich, die Kosten zu amortisieren, indem ein kleines Team von Rockstars den Code überarbeitet, der die meisten Probleme verursacht? Können wir den Refactor auf Releases verteilen? Überall gibt es kleine Ineffizienzen: Können wir mit dieser zusätzlichen Arbeit sozusagen "die Lücken füllen"?

2
user22815

Der Wert des Refactorings kommt auf verschiedene Arten zum Tragen.

Es hilft Ihnen, später weitere Änderungen vorzunehmen, sodass die X Tage, die diese Funktion benötigt hätte, jetzt 2/3X Tage dauern würden. Um die agile Terminologie zu verwenden, wird die Geschwindigkeit erhöht.

Die explizite Änderung würde im Laufe der Zeit helfen, da Sie keine Entwickler mit VB6-Erfahrung mehr warten müssen, sondern nur noch diejenigen mit C # -Erfahrung.

Es hilft auch auf andere, weniger greifbare Arten wie Mitarbeiterbindung und Rekrutierung. Wäre ein Job mit C # und VB6 mehr oder weniger attraktiv als ein Job mit C #? Würden Sie mehr oder weniger wahrscheinlich einen Job annehmen oder bei einem Job bleiben, der an einer netten oder einer miesen Codebasis arbeitet?

2
Sign

Vorteile eines überarbeiteten Systems

Sie erstellen ein Geschäftsmodell für das Refactoring, indem Sie die geschäftlichen Vorteile zwischen dem Tun und dem Nicht-Tun vergleichen. Dies bedeutet entweder eine Reduzierung der aktuellen realen Kosten oder eine Erhöhung des zukünftigen realen Mittelzuflusses.

Die wichtigsten Budgetposten, die vom Refactoring betroffen sind, sind folgende:

  • Wartungskosten - Wenn das derzeitige System ein zerbrechlicher Haufen Spaghetti ist und in der Praxis zu beobachten ist, dass das Beheben kleiner Fehler (sowohl in der Entwicklung als auch im Betrieb) eine große Menge an Arbeitsstunden in Anspruch nimmt, ist zu erwarten, dass die Kosten für solche Probleme hoch sind Die Wartung eines "ordnungsgemäß neu gestalteten" Systems ist geringer. Sehen Sie sich an, wie hoch Ihre jährlichen reinen Wartungskosten sind und wie sie sich nach dem Umschreiben realistisch ändern können.
  • Kosten für das Hinzufügen neuer Funktionen - Auch wenn das aktuelle Systemdesign und die aktuelle Systemstruktur das Schreiben neuer Funktionen unangemessen zeitaufwändig machen, kann ein Umschreiben zu Einsparungen führen. Sehen Sie sich Ihr geplantes Budget für neue Funktionen an, aber seien Sie realistisch. Wenn Sie behaupten, dass Sie eine 50% ige Verbesserung sehen, erwarten Sie, dass Sie Funktionen tatsächlich in x Mannmonaten entwickeln, deren Realisierung zuvor 2 * x Mannmonate gedauert hat. Solche Versprechen können schwer zu halten sein.

  • Auswirkungen der Softwarequalität auf den Umsatz - wenn das aktuelle System häufig vom Kunden sichtbare Probleme verursacht, z. Abstürze oder Ausfallzeiten trotz angemessenem Wartungsaufwand, dann kann ein Umschreiben eine Lösung sein. WENN Dies ist ein großes Problem, dann können dieselben Vertriebsmitarbeiter den Wert eines "Features" quantifizieren, das als "stabileres Produkt" bezeichnet wird.

Wenn die drei oben genannten Punkte nicht die erwarteten Kosten für das Umschreiben erreichen (und mehr), entsprechen die Opportunitätskosten für das Ausgeben von x Dev-Tagen für Nicht-Features dem Wert dieser Features, der größer ist als die reinen Kosten von x Dev -days) dann fürchte ich, dass es das ist - die erwarteten Einsparungen rechtfertigen das Umschreiben nicht.

Wenn in Ihrer Roadmap nicht so viele neue Funktionen benötigt werden, wie Sie bereitstellen können, sollten die Einsparungen in einer Form erfolgen früher waren 10 Personen erforderlich, um alle erforderlichen Aufgaben zu erledigen, aber Nach dem Umschreiben können wir dasselbe mit nur 6 Personen tun. '. Wenn Sie mehr Entwicklungsprojekte "verkaufen" können als Entwickler, können Sie durch die Verbesserung der Effizienz mehr Dinge entwickeln. Wenn das Unternehmen mit den aktuellen Ressourcen jedoch bereits alle Dinge entwickeln kann, die zusätzlichen Wert bringen, ist dies der einzige finanzielle Vorteil kann dadurch entstehen, dass man weniger Leute bezahlt oder billigere Leute hat.

1
Peteris

Der Wert des Refactorings kann folgendermaßen gemessen werden: Derzeit kostet das neue Feature x 5 Entwickler 2 Wochen. Wenn wir eine alte Komponente überarbeiten, werden die Kosten für neue Funktionen um geschätzte 20% reduziert. Das neue Feature x kostet also nur 4 Entwickler über 2 Wochen.

Refactoring ist eine Investition in die Reduzierung der Kosten zukünftiger Entwicklungen. Wenn Sie dieses Argument für Ihr Refactoring nicht vorbringen können, gibt es wahrscheinlich keinen Business Case dafür.

0
Spasiu