Quantificare il valore del refactoring in termini commerciali [duplicato]

Ho avuto alcuni successo spiegando questi vantaggi:

1. Meno bug in futuro (anche gli addetti alle vendite sanno che i bug sono cattivi)
2. Più facile, più veloce e meno costoso per correggere i bug in futuro.
3. Più facile, più veloce e più economico apportare miglioramenti al prodotto.
4. Più facile, più veloce ed economico aggiungere funzionalità completamente nuove al prodotto.
5. Più facile, più veloce ed economico da integrare con sistemi di terze parti.
6. Quanto prima puoi iniziare il refactoring, meno debito tecnico ti porti e migliore sarà il prodotto (1-5 sarà più facile)

Ho avuto un successo limitato con termini come il debito tecnico, alcuni commerciali lo capiscono, alcuni pensano che siano solo le persone techie che cercano di giustificarsi a fare le proprie cose, tutto dipende dalla persona che stai cercando di spiegare a .

Una strategia che funziona bene (finché non si accumula troppo debito tecnico) la paga un po 'alla volta facendo refatting medio-piccoli all'inizio del prossimo miglioramento / funzionalità / cambiamento che le persone di vendita vogliono.
Rendilo parte della loro richiesta, "certo, possiamo farlo, per prima cosa dovremo migliorare questa parte del sistema per supportare questa nuova funzione."

Se puoi ottenere metriche effettive per quanto tempo verrà risparmiato effettuando refactoring, allora ho trovato che una doppia stima funziona meglio poiché tutti gli addetti ai lavori sanno che le statistiche possono essere manipolate e le statistiche di sviluppo (a seconda del persona) può essere visto come self-serving.
Per doppia stima intendo "certo, la funzione X impiegherà 3 giorni se risolviamo il sottosistema Y, altrimenti guarderai a X + Z giorni per aggirare il problema. Inoltre ridurrà le nostre chiamate di supporto e renderà il piano funzione W più veloce da aggiungere. "

Se le persone come le metriche combinano il tempo speso per le chiamate di supporto su funzionalità / prodotto X con la mia doppia stima, in questo modo è possibile produrre un grafico / foglio di calcolo / costi per mostrare il costo della caratteristica X in base al supporto continuo chiama con una stima di riduzione dai refactoring.
Nel corso del tempo, è possibile produrre cifre reali per la feature X prima e dopo il refactoring.

Ottenere cifre reali per i costi di sviluppo è più complicato dal momento che ogni funzione viene implementata una sola volta (si spera!). Un'idea è quella di tenere traccia di quanto tempo impiegano i refactoring e produrre un grafico a doppia stima aggiungendo i costi di refactoring come " quello che sarebbe costato senza refactoring ", che è, si spera, più alto della vostra stima attuale, questo dovrebbe rendere molto ovvio il risparmio di tempo / costi.

Fondamentalmente con un codebase cleaner praticamente tutto può essere fatto più velocemente e quindi più economico di quanto non potrebbe altrimenti, il che offre un valore aggiunto e un ROI migliore per i tipi commerciali.

Trovo molto buona la risposta di SteB (che ho svalutato). Mi piacerebbe approfondire un punto della sua risposta (come un esempio che potrebbe essere applicato anche ad altri punti).

Easier, faster and cheaper to made enhancements to the product.

Come convincere la gestione di questo?

Supponiamo che tu abbia appena avuto la versione 1 del prodotto X.

Sai già che la funzione Y è prevista per la versione 2 e la funzione Z è quasi sicuramente necessaria per la versione 3.

Quindi puoi fare un preventivo (eseguire una sessione di toelettatura con le carte da poker) e poi andare dai tuoi manager e dire:

• Con il codice corrente, la funzione Y richiederà 8 settimane, la funzione Z richiederà 6 settimane.
• Con il codice refactored, la funzione Y richiederà 4 settimane, la funzionalità Z richiederà 2 settimane. Il refactoring impiegherà 2 settimane.

Quindi hai i seguenti scenari:

1. Release 2 con funzione Y. La funzione Y costa 8 settimane senza refactoring, 6 settimane con refactoring.
2. Release 2 e 3, con entrambe le funzioni Y e Z. Le caratteristiche Y e Z costano 12 settimane senza refactoring e 8 settimane con refactoring.

Questo è ovviamente solo uno schizzo ma IMO se puoi produrre un'analisi simile potresti avere più possibilità di convincere la tua gestione: significa che hai un'idea concreta dei benefici del tuo refactoring, anche se è solo una stima .

NOTA : se hai difficoltà a produrre un'analisi simile, chiediti quali sono le probabilità che non ne avrai bisogno.

Sono nel commento di @ maple_shaft sopra:

Non scrivere codice errato , anche durante la prototipazione. Pensa al tuo codice prototipo come a un approccio bullet tracciante. Qualcosa che diventerà il prodotto finale anche se non è ancora lì.

Non è necessario spiegare o giustificare il refactoring per la gestione: dovrebbe essere una parte continua del processo. Proprio come tu non spieghi perché stai facendo una specifica struttura ereditaria, usando un framework specifico, ecc. Questi sono dettagli tecnici. I tuoi clienti si preoccupano solo dei risultati, siano essi dirigenti o clienti finali.

Ciò che si vuole evitare sono i lunghi tempi di inattività in cui "nulla" accade per quanto riguarda il mondo esterno. Per esempio. non vuoi scrivere una quantità enorme di codice errato, quindi impiegare 3 settimane per refactarlo per renderlo buono. Prima di tutto, non funzionerà molto bene; e in secondo luogo potresti essere tentato di spiegare che ora stai prendendo tempo al refactoring. Che a un estraneo sembrerà come se stessi facendo una specie di vacanza da geek.

Refactor early . Se vedi che qualcosa non va, e sarebbe un po 'difficile rimediare: fallo. Addendum a questo: se non sei sicuro che qualcosa sia sbagliato, o non sai come migliorarlo, lascialo da solo fino a quando non lo fai.

Ci sono stato molte volte.

Ci sono alcuni modi per gestirlo, anche se non facile.

L'hai quasi detto tu stesso: si preoccupano solo di consegnare il più velocemente possibile. Mostra agli stakeholder un caso aziendale in cui un round di refactoring di X mese ridurrà il tempo necessario per sviluppare nuovi round e tenterà di stimare un ritorno sull'investimento, dopo un anno circa, per il refactoring.

Oppure, se questo è molto difficile, ci sono altri arugments economici che potrebbero aiutare: "Dato che stiamo eseguendo un prototipo in produzione, abbiamo bisogno di assumere altri due ingegneri per mantenerlo. Questo costo può essere evitato se prendiamo un progetto di refactoring. ".

Se disponi di centri di costo interni, ecc., assicurati che le persone operative che supportano questa applicazione ne facciano pagare di più rispetto a simili applicazioni "produttive meritevoli".

Se la tua squadra ha qualche controllo, potrebbe essere possibile incorporare il refactoring nelle nuove fasi di sviluppo del feature. Supponiamo che vogliano inserire gerarchie complesse in un modello di dati già merdoso - includere il refactoring come requisito tecnico per apportare eventuali modifiche al modello di dati. Un caso simile: se chiedete al vostro idraulico di cambiare il radiatore, se il tubo è troppo arrugginito per funzionare correttamente, si verificherà. cambia anche questo, poiché è la sua professione a sapere cosa fare. La stessa cosa (dovrebbe) vale per gli sviluppatori di software.

Se colpisci il muro, raccogli le statistiche per i tuoi argomenti. Tagga ogni bug / problema operativo riportato che avrebbe potuto essere evitato dal codice di produzione valido. Quindi potresti mostrare un caso aziendale riducendo i bug con così tanti% e aumentando il tempo di attività / stabilità di un'altra%.

Tuttavia, c'è sempre un fatto che gli sviluppatori di software vogliono fare la migliore soluzione possibile, quando solo "abbastanza buono" lo farà. Se non riesci a inventare argomenti economici per il refactoring, probabilmente non ne vale la pena e non dovrebbe essere fatto.

Mettere un prototipo in produzione è peggio di un progetto di design scadente perché troppi decisori credono che sia meglio di quanto non sia in realtà. Durante il processo di costruzione del prototipo, ricordavi a tutti che "Questo è non pronto per la produzione. " Le probabilità di arrivare a questo punto erano basse perché non erano sicuri che:

• Potrebbe essere costruito.
• Qualcuno ne avrebbe davvero avuto bisogno / l'avrebbe usato.

Non concentrarti su "Te l'avevo detto" ma chiarisci che non sarai in grado di mantenere il programma del prototipo né puoi utilizzare nessuno di questi parametri per determinare come ci vorrà molto tempo per creare funzionalità pronte per la produzione. Vederanno la funzione del prodotto, ma ricorderanno loro problemi come:

• Potrebbe non essere in grado di gestire un numero maggiore di utenti
• La gestione degli errori non è sufficiente per l'utente tipico
• Non può contenere molte delle funzionalità appena richieste.
• C'è poco o nessun test

I membri non tecnici del management superiore non intendono cogliere il concetto di refactoring. Hanno in testa questo "funziona" e non rilasceranno quel pensiero per l'intera durata del progetto, non importa quante volte tu abbia detto qualcosa al personaggio. Dovrai renderlo parte delle tue specifiche. I responsabili tecnici potrebbero essere sottoposti a forti pressioni temporali e potrebbero tentare di eliminare molte di queste attività dalle specifiche del progetto. "Perché stiamo lavorando su funzionalità che sono già state completate?" Alcune delle altre anser forniscono alcuni modi per spiegare perché non è così.

Buona fortuna

Mi piace rispondere con analogie non tecniche.

Alcuni esempi:

Puoi facilmente costruire case con mattoni alti fino a 5 piani. Puoi facilmente aggiungere su un solo piano. Ma prova e vai a 20 o 30 piani e improvvisamente bam! le tessere stanno esplodendo perché hai bisogno di un'infrastruttura migliore come le travi di acciaio. Si scopre che l'infrastruttura è importante e la corretta prima possibile attraverso il "refactoring" iniziale ...

Guidi il tuo gar Tutto ciò che serve per correre è il gas! Bene, quello e ... l'olio cambia frequentemente. Oh, raramente, nuove gomme e occasionalmente altri fluidi e parti. Si scopre che la manutenzione fa parte dell'essere un proprietario di un'auto responsabile ...

Puoi definire in modo univoco il refactoring? L'unione di due procedure è probabilmente il refactoring. Ma come cambiare il nome di un oggetto? Un metodo? Una variabile pubblica? Una variabile privata? Cosa succede se si modifica l'implementazione di un metodo senza cambiarne la firma? Cosa succede se questo cambiamento lo rende lento per un certo tipo di input che a sua volta causa un cambiamento in una parte lontana del codice? Immagino che quello che sto dicendo sia che hai bisogno di una definizione molto chiara di ciò che stai cercando di misurare prima di poter scegliere un modo o alcuni modi per misurarlo.

Questo è anche difficile perché non si vede immediatamente il vantaggio del refactoring. Diciamo che hai trasformato 5 oggetti con 12 metodi in 3 oggetti con 5 metodi. In futuro ti risparmierà un sacco di tempo, ma raddoppierà il tempo impiegato per fornire la funzionalità corrente. Quindi è una perdita a breve termine per l'azienda per un ipotetico guadagno a lungo termine. Il refactoring a volte peggiora le cose anche se spesso le rende migliori.

Supponiamo che il refactoring significhi che un cambiamento in una parte del codice richiede che tu modifichi un'altra parte del codice in modo tale che la funzionalità dell'intero programma sia (più o meno) preservata, ma il modo in cui funziona internamente è diverso. Per definizione, quindi, l'utente finale generalmente non vedrà l'effetto del refactoring (a meno che non migliori le prestazioni o consenta una semplificazione dell'interfaccia utente che comunque fornisce all'utente la stessa funzionalità di base).

Quindi devi misurare le cose a lungo termine per mostrare un impatto positivo, e per definizione è un impatto indiretto. Ci ho pensato tutto il giorno oggi e mi ha ricordato uno studio pubblicato sulla rivista Time alcuni anni fa su ciò che rende le persone più longeve. Invece di chiedere alla gente quanto hanno fumato o bevuto bevande gassate o altro, hanno guardato le popolazioni più longeve del pianeta e analizzato centinaia (o migliaia) di dieta, stile di vita e fattori ambientali per determinare quali erano comuni tra quelli in cui erano longevo e raro per le persone in generale.

Mi dispiace che non riesca a pensare a una metrica che potresti misurare ogni mese e mostrare con un piccolo grafico come stai rifattorizzando meglio che mai, o correlare direttamente il refactoring ai profitti della tua azienda. Ma penso che tu (o un dipartimento CS presso un'università affiliata) potresti esaminare le caratteristiche dei team di successo del software per vedere se il refactoring è qualcosa che li distingue o meno. Sospetto che lo farebbe, ma sarei estremamente interessato a vedere uno studio. Forse qualcun altro in questo forum può indicare un tale studio?

Sono stato in tali posizioni (suppongo che tutti noi abbiamo.)

Molto spesso, questa è una risposta molto efficace:

You have paying me for a year to develop this project. If I get hit by a bus tomorrow, do you want to pay someone for two more years, to figure out how to unravel the mess I left behind? Are you not better off paying me for three months, so that the next guy will be up to speed in one month?

Importante: assicurati di non ottenere l'avvio quando ti sentono speso un anno a scrivere codice disordinato, in modo da poter ottenere un prototipo in tempo ...