Come misurare il valore potenziale del refactoring

Su un vecchio progetto di grandi dimensioni con un debito tecnico, come è possibile stimare o misurare in modo affidabile il vantaggio del codice di refactoring?

Ad esempio, supponiamo di avere alcuni componenti all'interno di una soluzione di stack software scritti in una lingua precedente e alcuni componenti successivi scritti in una lingua più recente. Nuove funzioni e correzioni di bug vengono costantemente aggiunti a questa soluzione da un team di sviluppo.

Gli sviluppatori suggeriscono che sostituire i componenti del vecchio linguaggio esistenti con la nuova versione sarebbe "una buona cosa". Tuttavia, questo lavoro non aggiungerebbe funzionalità extra e costerà x dev-days.

Un addetto alle vendite suggerisce di aggiungere "una nuova fantastica funzionalità". l'azienda misura il valore del suo suggerimento utilizzando una formula. vale a dire. Guadagnerà la società F milioni di sterline, in t anni con un costo di x giorni lavorativi

Come può l'azienda costare la proposta di refactoring in modo significativo? e in quali circostanze è probabilmente l'opzione più redditizia per l'azienda?

Guadagnerà la società F milioni di sterline, in t anni con un costo di x giorni lavorativi

Il che ignora i costi di manutenzione, i costi di supporto, i costi di vendita / marketing e fa molte ipotesi su come la funzionalità verrà adottata sul mercato.

Ma comunque; la tua domanda è abbastanza chiara su cosa stai cercando:

Come posso presentare un caso aziendale per il refactoring?

La cosa principale da capire è che il tempo è uguale al denaro. Puoi andare direttamente a "5 sviluppatori 2 settimane = 80 ore * 5 sviluppatori * $ 50 / ora -> $ 20.000" e questo ha senso per gli uomini d'affari. Gli imprenditori intelligenti noteranno che quei 5 sviluppatori vengono pagati in entrambi i modi, con i quali contrasti che non sta spendendo / risparmiando $ 20.000 - sta usando i $ 20.000 nel modo più redditizio. Comunque, avanti con l'elenco.

• Efficienza - Presumibilmente, puoi fare più cose con C # che VB6. Strumenti migliori, librerie migliori, qualunque cosa. Le nuove tecnologie tendono ad essere migliori nelle cose rispetto a quelle più vecchie. Se riesci a fare cose in meno tempo, significa che stai risparmiando i soldi dell'azienda.
• Spese generali : la codifica non è l'unico costo del software. Considera cosa succede quando esce Windows 2020. Quanto tempo e fatica impiegherai a far funzionare quell'app VB6? Quanto tempo e impegno sono maggiori di un'app C #? Ciò sta facendo risparmiare denaro alla tua azienda.
• Qualità - Presumibilmente, puoi fare cose con una qualità superiore in C # rispetto a VB6 (o con un'architettura più pulita, o qualunque altra sia il tuo obiettivo di refactoring). Una qualità superiore significa meno bug. Meno bug significa meno costi per correggerli, meno costi di assistenza ai clienti per risolvere tali problemi, meno perdite dei clienti a causa di problemi di qualità, aumento delle vendite a causa di una reputazione di qualità ... tutti i dollari per la tua azienda.
• Risparmio di risorse umane - Ammettiamolo: nessuno vuole lavorare con quella merda app VB6. Ciò significa che più persone lasceranno l'azienda portando a tempo e denaro spesi per sostituirle. Ciò significa che ci vuole più tempo e denaro per assumere nuovi dipendenti. Peggio ancora, significa che avrai sviluppatori che stanno commettendo un suicidio in carriera lavorando con quell'app VB6. Questi sviluppatori a loro volta accelerano la spirale della morte per problemi di qualità. Ridurre il fatturato e i tempi di assunzione fa risparmiare denaro alla tua azienda. Tenere lontani gli sviluppatori schifosi e schifosi salva la tua azienda.
• Morale - Allo stesso modo, i programmatori che sono già lì odiano lavorare in VB6. Lo faranno e potrebbero anche farlo bene. Ma fa schifo. Forse non per tutti, ma sicuramente per alcuni. Ciò significa più tempo trascorso a navigare sul Web per recuperare la motivazione. Significa pranzi più lunghi. Significa meno cose da fare mentre i programmatori impiegano più tempo a riprendersi dal lavoro schifoso.
• Funzionalità - Questo è meno applicabile con i refactor tecnologici, ma si applica all'architettura come refactor. Alcuni problemi di codice ti impediscono attivamente di fornire la fantastica funzione X per guadagnare tonnellate di denaro. Forse non puoi ridimensionare. Forse non puoi ottenere i dati per fare una buona informazione. Forse il codice è un tale nido di ratto che è proibitivamente difficile svolgere effettivamente il lavoro. Qualunque cosa. A volte sei a quel punto, a volte stai guidando dritto verso quel punto. È difficile tradurre in business-speak, ma se puoi "questo problema ci impedisce di sfruttare le opportunità X, Y e Z" può essere potente.

Tutto sommato, si riduce a "questa roba ci aiuterà a fare meglio il nostro lavoro; se lo facciamo meglio, possiamo fare / risparmiare più denaro".

La domanda che dovresti porti è come fa il venditore a sapere che la funzione costerà x giorni di lavoro per gli sviluppatori. Dato che anche buoni project manager con anni di esperienza professionale spesso non possono dirlo, tali dati provenienti da un venditore sembrano estremamente ... speculativi .

Secondo la mia esperienza, i venditori di solito non fanno stime, ma indovinano quanto sia troppo per la gestione o il cliente: se la gestione è pronta a pagare 50 settimane uomo di lavoro, ma rifiuterà assolutamente 75 settimane uomo, diciamo che la funzione richiederà 70 settimane-uomo mentre si è pronti a rinegoziare (qualcosa che è fuori discussione per una stima reale) fino a 55 settimane-uomo.

• Da un lato, hai stime fatte da esperti IT che dicono qualcosa come:

  Secondo questo specifico audit, stiamo sprecando $ 8 000 al giorno utilizzando una tecnologia obsoleta rispetto a progetti simili di dimensioni simili che utilizzano tecnologie più recenti. Sembra anche che ci vorranno dalle 50 alle 80 settimane-uomo per migrare l'intera base di codice; durante questo periodo, non ci sarebbero nuove funzionalità rilasciate. Esiste anche un rischio del 10% che la migrazione di un componente specifico possa comportare 20-30 settimane lavorative aggiuntive.

• D'altra parte, hai ipotesi fatte dai venditori, in base alla loro influenza quando negozia con la persona di cui hanno bisogno per convincere.

Dipende da quanto sei influente nella tua azienda. La comunicazione è la chiave qui, ed è qui che i venditori di solito conquistano i professionisti IT quando si tratta di spiegare i vantaggi di una funzionalità alla direzione (o a un cliente).

Nota che se in passato le tue stime erano abbastanza precise, guadagni reputazione e influenza. Se le tue stime fossero sempre sbagliate, la direzione probabilmente ignorerebbe le tue proposte.

Per quanto riguarda le stime, è estremamente difficile realizzarne uno prezioso qui, poiché ci sono un numero enorme di parametri da tenere in considerazione. Tra gli altri:

• Sai davvero quanto è abile il tuo team in C # rispetto a VB6? Si basa su misurazioni effettive o solo ipotesi?

• Questo team ha sviluppato grandi progetti in C #? Conoscono gli strumenti che dovrebbero usare (IDE, debugger, profiler, ecc.)? Hai bisogno di licenze aggiuntive (che, nel mondo di Microsoft, significano migliaia di dollari per macchina)?

• Il progetto attuale è totalmente chiaro e puoi garantire che non ci saranno sorprese durante la migrazione? È semplice riscrivere tutto , ogni caratteristica o ci sarebbero sorprese?

• Hai l'infrastruttura che supporta C #? Che dire dell'integrazione continua? E il tuo server di build? Guide di stile? Pedine statiche?

• In produzione, i server (se si tratta di un'app Web) o i PC dei clienti (se si tratta di un'app desktop) sono in grado di eseguire la versione di .NET Framework che si prevede di utilizzare?

Ma la cosa più importante è sapere perché vuoi riscrivere tutto. Qual è il problema che stai cercando di risolvere attraverso una riscrittura? Una perdita di produttività? Come lo misurate? Come mostri questa perdita di produttività al management?

Una volta che hai dimostrato che stai sprecando, diciamo, $ 8 000 al giorno a causa del VB6 (il che significa che risparmierai $ 8 000 al giorno dopo la migrazione a C #), come spieghi il vantaggio di mantenere ogni sviluppo di nuove funzionalità e concentrarsi su una riscrittura completa? Qual è il vantaggio rispetto alla riscrittura progressiva in cui si esegue la migrazione dei componenti in piccoli blocchi uno per uno, offrendo al contempo nuove funzionalità?

Innanzitutto, è necessario stimare il costo di sviluppo per il re-factoring come si farebbe con la richiesta di funzionalità guidata dalle vendite.

Questo potrebbe essere difficile per essere precisi se si tratta di un lavoro di grandi dimensioni ma, supponendo che tu abbia persone sufficientemente esperte nelle 2 tecnologie, dovrebbe essere fattibile.

In secondo luogo, è necessaria una stima del costo del non factoring. Se stavi facendo le stime per me, mi aspetterei un certo livello di metriche. Ad esempio, la differenza tra il costo medio di sviluppo per il codice VB e per il codice C # per un quarto. O alcuni di questi. Dipenderà ovviamente dalla precisione con cui lo segui.

Con questi 2 numeri, è possibile stimare il periodo di rimborso che il re-factoring ti darà, cioè a che punto il re-factoring passerà da un costo netto a un guadagno netto.

Posso solo immaginare quanto sia convincente qualsiasi risultato dato. Tuttavia, se è meno di un anno, sarà probabilmente abbastanza forte, molto più di 2 anni, quindi potresti benissimo lottare.

Inoltre, probabilmente vale la pena aggiungere altre dimensioni per aiutare a costruire il tuo caso. Uno che ho usato in passato è vedere se qualche intervista di uscita ha citato la tecnologia come pilota. In tal caso, puoi sostenere che il re-factoring manterrà il personale (assunzioni e formazione sono v costose).

Ovviamente, puoi argomentare queste cose senza prove a sostegno, ma trovo che possa fare un'enorme differenza nell'impatto del caso.

Il valore del refactoring emerge in molti modi diversi.

Ti aiuta ad apportare altre modifiche in un secondo momento, quindi i giorni X necessari per quella funzione ora richiederebbero 2 / 3X giorni per essere completati. Per usare la terminologia agile aumenta la velocità.

La modifica esplicita elencata nel tempo sarebbe di aiuto poiché non sarà più necessario mantenere gli sviluppatori con esperienza VB6, ma solo quelli con esperienza C #.

Aiuta anche in altri modi meno tangibili come la fidelizzazione e il reclutamento del personale. Un lavoro che fa C # e VB6 sarebbe più o meno attraente di un lavoro che fa solo C #? Sarebbe più o meno probabile che prenda un lavoro o rimanga a lavorare lavorando su una buona base di codice o su una pessima?

Penso che il punto in cui mancano le altre risposte sia la necessità di misurare il costo del refactoring rispetto al mancato guadagno derivante dal non refactoring.

Il refactoring per motivi di modifica del codice è una perdita di tempo. Deve apportare valore alla tabella. In questo contesto non intendo passare un'ora a eseguire il refactoring di una classe problematica, ma il refactoring principale come passare a una lingua CLR diversa da quella utilizzata nell'esempio.

• Se continuiamo a fare quello che stiamo facendo, ci stiamo perdendo qualcosa? Esiste un vecchio design croccante in atto che ci sta trattenendo dal realizzare valore? Ad esempio, se vogliamo aggiungere una funzionalità, è così difficile che potrebbero essere necessarie ad esempio 100 ore per l'implementazione, rispetto a 50 ore per il refactoring e 25 ore per l'implementazione rispetto al nuovo design?

• Il codice esistente comporta un debito tecnico che ci sta costando soldi? Questo vecchio merdoso codice è la fonte di bug? Finiamo per lavorare gratuitamente per risolvere i problemi a causa sua? A nessuno piace regalare ore redditizie redditizie gratuitamente.

• Il costo del refactoring è uguale o inferiore al costo del non refactoring?

• È possibile ammortizzare il costo facendo sì che una piccola squadra di rockstar ripari il codice che causa il maggior numero di problemi? Possiamo distribuire il refactor tra le versioni? Ci sono piccole inefficienze ovunque: possiamo "colmare le lacune" per così dire con questo lavoro extra?

Vantaggi dell'avere un sistema refactored

Si crea un caso aziendale per il refactoring confrontando i vantaggi di business tra fare e non farlo. Significa o riduzione dei costi reali attuali o un aumento del futuro afflusso di denaro reale.

Le voci di bilancio chiave interessate dal refactoring sono le seguenti:

• Costi di manutenzione - se l'attuale sistema è un fragile mucchio di spaghetti, ed è osservabile in pratica che la correzione di piccoli bug (sia nello sviluppo che nelle operazioni) richiede una grande quantità di ore-uomo, quindi ci si potrebbe aspettare che i costi di tale la manutenzione sarà inferiore per un sistema "riprogettato correttamente". Dai un'occhiata a quali sono i tuoi costi annuali di pura manutenzione e come potrebbero realisticamente cambiare dopo la riscrittura.

• Costo dell'aggiunta di nuove funzionalità: anche in questo caso, se la struttura e la struttura del sistema attuali rendono irragionevolmente dispendioso il tempo di scrivere nuove funzionalità, una riscrittura potrebbe consentire risparmi. Dai un'occhiata al tuo budget pianificato per le nuove funzionalità, ma sii realistico: se affermi che noterai un miglioramento del 50%, ti aspetti di sviluppare effettivamente funzionalità in x mesi-uomo che in precedenza richiedevano 2 * x mesi-uomo per la realizzazione; tali promesse possono essere difficili da mantenere.

• Impatto sulla qualità del software sulle vendite: se il sistema attuale causa frequentemente problemi visibili al cliente, ad esempio arresti anomali o tempi di inattività, nonostante un adeguato impegno di manutenzione, una riscrittura può essere una soluzione. Se questo è un grosso problema, gli stessi addetti alle vendite possono quantificare il valore di una "caratteristica" chiamata "prodotto più stabile".

Se i tre punti sopra non raggiungono il costo atteso di riscrittura (e altro; il costo opportunità di spendere x giorni di deviazione su non caratteristiche è uguale al valore di quelle caratteristiche, che è maggiore del costo puro di x dev -days) quindi temo che sia così: i risparmi previsti non giustificano la riscrittura.

Inoltre, se la tua tabella di marcia non mostra la necessità di "quanto più è possibile fornire" nuove funzionalità, i risparmi dovrebbero essere in una forma "che impiegava 10 persone a fare tutto il necessario, ma dopo la riscrittura abbiamo "Sarò in grado di fare lo stesso con solo 6 persone" . Se riesci a "vendere" più progetti di sviluppo di quelli che hai sviluppatori, allora migliorare l'efficienza ti consente di sviluppare più cose, ma se il business con le risorse attuali è già in grado di sviluppare tutte le cose che portano valore aggiunto, quindi l'unico vantaggio finanziario può venire dal pagare meno persone o avere persone più economiche.

Il valore del refactoring può essere misurato in questo modo: attualmente la nuova funzione x avrà un costo di 5 sviluppatori 2 settimane. Se eseguiamo il refactoring del vecchio componente, il costo delle nuove funzionalità verrà ridotto di circa il 20%. Quindi la nuova funzione x costerà solo 4 sviluppatori in 2 settimane.

Il refactoring è un investimento nel ridurre il costo degli sviluppi futuri. Se non riesci a formulare tale argomento per il tuo refactoring, probabilmente non esiste un caso commerciale per questo.