Stima dei costi di tempo nella base di codice legacy

Di recente ho iniziato a lavorare su un progetto in cui una vecchia applicazione monolitica viene migrata in un'architettura basata su microservizi.

La base di codice legacy è molto disordinata ("spaghetti code") e spesso una funzione apparentemente semplice (ad esempio denominata "multiplyValueByTen") si rivela successivamente come "migliaia di righe di codice di convalida che coinvolgono 10 tabelle in 3 diversi schemi".

Ora il mio capo mi chiede (giustamente) di stimare quanto tempo ci vorrebbe per scrivere la funzione X nella nuova architettura. Ma ho difficoltà a trovare una stima realistica; spesso sottovaluto enormemente il compito a causa dei motivi che ho indicato sopra e mi imbarazzo perché non riesco a finire in tempo.

La cosa ragionevole potrebbe davvero entrare nel codice, annotare ogni ramo e chiamare ad altre funzioni e quindi stimare il costo del tempo. Ma c'è davvero una minuscola differenza tra documentare il vecchio codice e scrivere effettivamente la nuova versione.

Come dovrei affrontare uno scenario come questo?

Mentre capisco perfettamente come funziona il refactoring del codice legacy, la mia domanda non riguarda "come eseguire refactoring / riscrivere?" ma di dare una risposta realistica a "quanto tempo ci vorrebbe per refactoring / riscrivere la parte X?"

Leggi "Clean Coder" di Bob Martin (e "Clean Code" mentre ci sei). Quanto segue è dalla memoria, ma ti consiglio vivamente di acquistare la tua copia.

Quello che devi fare è una media ponderata di tre punti. Fai tre stime per ogni lavoro:

• uno scenario ottimale - supponendo che tutto vada bene (a)
• uno scenario peggiore - supponendo che tutto vada storto (b)
• l'ipotesi reale - cosa pensi che probabilmente ci vorrà (c)

Il tuo preventivo è quindi (a + b + 2c) / 4

• No, non sarà accurato. Esistono modi migliori per stimare, ma questo metodo è rapido, facile da capire e mitiga l'ottimismo facendoti considerare il caso peggiore.
• Sì, dovrai spiegare al tuo manager che non hai familiarità con il codice e che è troppo imprevedibile per te fare stime precise e accurate senza spendere molto tempo a studiare il codice ogni volta per migliorare la stima (offriti di farlo ma dire che hai bisogno di n giorni solo per dare una stima ferma di quanti altri giorni ci vorranno). Se sei un "JuniorDev", questo dovrebbe essere accettabile per un manager ragionevole.
• Dovresti anche spiegare al tuo manager che le tue stime sono calcolate in media, sulla base del caso migliore, del caso peggiore e del caso probabile e fornire loro le cifre che forniscono anche le barre di errore.
• NON negoziare un preventivo - se il tuo manager cerca di usare il caso migliore per ogni preventivo (sono un pazzo - ma ne ho incontrati alcuni così) e quindi ti prepotente / motivarti nel cercare di rispettare la scadenza, beh, loro sarete delusi a volte. Continua a spiegare le motivazioni alla base delle stime (miglior caso, peggiore caso e probabile) e continua ad avvicinarti alla media ponderata il più delle volte e dovresti essere OK. Inoltre, per i tuoi scopi, mantieni un foglio di calcolo delle tue stime e aggiungi i tuoi dati effettivi al termine. Ciò dovrebbe darti un'idea migliore di come adattare le tue stime.

Modificare:

Le mie ipotesi quando ho risposto a questo:

1. L'OP è uno sviluppatore junior (basato sul nome utente scelto). Qualsiasi consiglio dato non è quindi dal punto di vista di un Project Manager o Team Lead che ci si può aspettare che sia in grado di effettuare stime più sofisticate a seconda della maturità dell'ambiente di sviluppo.
2. Il Project Manager ha creato un piano di progetto costituito da un numero piuttosto elevato di attività pianificate per la consegna in diversi mesi.
3. Al PO viene chiesto di fornire una serie di stime per le attività a cui sono assegnati dal loro Project Manager che desidera un numero ragionevolmente accurato (non una curva di probabilità :)) da inserire nel piano di progetto e utilizzarlo per tenere traccia dei progressi.
4. OP non ha settimane per produrre ogni stima ed è stato bruciato in precedenza fornendo stime troppo ottimistiche e desidera un metodo più accurato rispetto a un dito in aria e dicendo "2 settimane, a meno che il codice non sia particolarmente arcano nel qual caso 2 mesi o più".

La media ponderata su tre punti funziona bene in questo caso. È rapido, comprensibile ai non tecnici e su diverse stime dovrebbe arrivare alla media qualcosa che si avvicina alla precisione. Soprattutto se l'OP prende il mio consiglio riguardo alla tenuta di registri di stime ed effettivi. Quando sai che aspetto hanno il "Caso peggiore" e il "Caso migliore" del mondo reale, puoi inserire i dati effettivi nelle tue stime future e persino aggiustare le stime per il tuo project manager se il caso peggiore è peggiore di quanto pensassi.

Facciamo un esempio funzionante:

• Nel migliore dei casi, per esperienza, il più veloce che ho fatto è stato molto semplice, una settimana dall'inizio alla fine (5 giorni)
• Il caso peggiore, per esperienza, c'è stato quel tempo in cui c'erano collegamenti dappertutto e alla fine mi sono voluti 6 settimane (30 giorni)
• Stima effettiva, probabilmente mi ci vorranno 2 settimane (10 giorni)

5 + 30 + 2x10 = 55

55/4 = 13.75 che è quello che dici al tuo PM. Forse arrotonderai per 14 giorni. Nel tempo, (ad esempio dieci attività), dovrebbe raggiungere una media.

Non aver paura di modificare la formula. Forse metà delle attività finisce con incubi e solo il dieci percento è facile; quindi fai la estmate a / 10 + b / 2 + 2c / 5. Impara dalla tua esperienza.

Nota, non sto facendo ipotesi sulla qualità del PM. Un cattivo PM fornirà una breve stima alla commissione del progetto per ottenere l'approvazione e quindi fare il prepotente con il team del progetto per cercare di raggiungere la scadenza non realistica a cui si sono impegnati. L'unica difesa è quella di tenere un registro in modo che tu possa essere visto fornire le tue stime e avvicinarti a loro.

Questo potrebbe essere un buon momento per introdurre un approccio quasi agile. Se invece di stimare in termini di ore / giorni hai allocato una scala di tipo fibonacci e hai dato ad ogni attività un valore basato su quanto è grande:

• 0 - istantaneo
• 0,5 - vittoria rapida
• 1 - semplice modifica
• 2 - un paio di semplici modifiche
• 3 - più impegnativo
• 5 - richiederà qualche riflessione
• 8 - una notevole quantità di lavoro
• 13 - un grosso pezzo di lavoro che probabilmente deve essere scomposto
• 20 - un grosso pezzo di lavoro che deve assolutamente essere scomposto

Quindi, una volta stimata una serie di attività come questa, ci lavori. In un ambiente agile sviluppi una "velocità" che è una misura di quanti punti raggiungi, diciamo, in una settimana. Dopo aver fatto alcune settimane di test-and-learning (puoi venderlo al tuo manager come parte del processo - "Avrò bisogno di alcune settimane di test e imparare a capire il processo di stima") sarai più fiducioso in quanti punti puoi spingere ogni settimana e quindi puoi tradurre i tuoi punti più rapidamente nel tempo.

https://pm.stackexchange.com/questions/4251/why-would-teams-use-the-fibonacci-sequence-for-story-points

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

Questo non è veramente agile in quanto non implicherebbe le cerimonie, ma dall'OP ho l'idea che sia da solo. Speriamo che questo approccio possa dare delle stime più sicure.

La prima cosa che fai è iniziare a raccogliere dati su quanto tempo impieghi per fare qualsiasi cosa in questo momento. Più dati hai sulle prestazioni del tuo team, meglio è. Andrà su tutta la linea, ma non preoccuparti di questo in questo momento. È la verità e devi mostrare la realtà al tuo capo.

Allora vai a comprare qualche libro.

1. Software Stimation: Demystifying the Black Art di Steve McConnell
2. Lavorare efficacemente con Legacy Code di Michael Feathers

Il libro di McConnell ti dirà come iniziare a raccogliere dati e poi spiegarti come usarlo per ottenere stime più accurate. Dai sempre una stima di 3 punti! Sempre. Assicurati di evidenziare le parti del libro che parlano di come la scarsa qualità del codice farà esplodere le tue stime. Mostrali al tuo capo.

Spiega che se per l'azienda sono importanti stime accurate, dovrai iniziare ad applicare le cose che stai imparando dal libro di Feather. Se si desidera procedere in modo rapido, fluido e prevedibile, è necessario iniziare a refactoring del codice e inserirlo in un cablaggio di prova. Sono stato proprio dove sei. I tempi di sviluppo sono completamente imprevedibili perché non hai idea di cosa potresti rompere, giusto? ... Sì. Mettilo in un cablaggio di prova. Neanche un server CI per l'esecuzione di questi test potrebbe danneggiare.

Infine, spiega al tuo capo che le cose saranno ancora un po 'imprevedibili per un po'. Probabilmente tra qualche anno, ma quello sviluppo diventerà più facile ogni giorno e le stime diventeranno più accurate man mano che avrai più dati e il codice migliorerà. Questo è un investimento a lungo termine per l'azienda. Ci sono passato di recente, ci sono voluti quasi 2 anni per diventare per lo più prevedibili.

So di aver parlato più del miglioramento del codice che della stima, ma la dura verità è che le tue stime saranno pessime fino a quando non potrai domare la base di codice legacy. Nel frattempo, usa la performance storica per valutare quanto tempo ci vorrà. Col passare del tempo, ti consigliamo di prendere in considerazione se hai già ottenuto il codice o meno nelle specifiche nelle tue stime.

Ora il mio capo mi sta giustamente chiedendo una stima su quanto tempo ci vorrebbe per scrivere la funzione X nella nuova architettura. Ma ho difficoltà a trovare una stima realistica; spesso a volte sottovaluto il compito per motivi che ho indicato sopra e mi imbarazzo perché non riesco a finire in tempo.

Forse stai pensando nella casella di presentazione di una stima. Devo lavorare nel codice legacy e quando faccio una stima più formale, di solito ne faccio due o tre :

1. Stima primaria - supponendo che devo dedicare un po 'di tempo a scavare ma l'architettura consente le modifiche che vogliamo
2. Stima angelica - presume che tutto sia trasparente / facile da trovare e devo fare solo piccole modifiche (questo è quello che tralascio a volte ... specialmente se so che ci sono solo diavoli in una particolare base di codice)
3. Stima abissale - presume che la struttura fondamentale del codice legacy sia incompatibile con la funzione richiesta e dovrò fare un grande refactoring per far funzionare le cose

Tutte e tre le stime tengono conto della robustezza della funzionalità in sé e per sé, di qualsiasi esperienza che ho avuto con quella base di codice generale e della mia impressione sul cambiamento (che ho scoperto può essere abbastanza accurato)

Dopo che queste stime sono state pubblicate, tengo aggiornato il mio manager su quale sembra avere a che fare. Se si scopre che stiamo osservando una caratteristica abissale, allora dovremmo sacrificarla - è successo. Se il tuo capo non può accettare che ci siano caratteristiche abissali per un determinato pezzo di codice legacy, allora auguro loro buona fortuna, perché avranno una vita molto difficile e frustrante.

Quando ho affrontato questo tipo di problema, mi sono affidato a fornire intervalli sulle mie stime. Ho smesso di dire ai miei capi "è difficile fare buone stime improvvisate su questo codice. Se ne chiedi uno, sarà una stima molto ampia". Una volta ho dato "3 giorni a 3 anni" come stima. Inutile dire che non era una stima popolare, ma è quello che ho dato.

La chiave di questo è un accordo che aggiornerò le mie stime man mano che il lavoro avanza. Quindi, se mi viene detto "Implementa XYZ, quanto tempo ci vorrà?" la mia risposta potrebbe essere "da qualche parte tra un giorno e 4 mesi. Tuttavia, se mi fai guardare il codice per alcune ore, posso ridurre l'incertezza in quella finestra". Poi vado a vedere il codice e torno con "2-4 settimane". Questa non è ancora una finestra ideale, ma almeno è qualcosa che può essere gestita.

Ci sono alcune chiavi per questo:

• Convincere il capo che queste stime sono meglio trattati come una conversazione perché si saperne di più su ciò che il compito si presenta come mentre si lavora. Questa è un'opportunità per il tuo capo di avere informazioni che non avrebbe se chiedessero solo un preventivo.
• Offri opzioni su come andare avanti quale velocità di sviluppo del codice commerciale rispetto al miglioramento delle stime. Dai loro una manopola extra che possono girare. A volte i capi sanno che un'attività deve solo essere eseguita e hanno solo bisogno di una stima del campo da baseball. Altre volte eseguono i pro e i contro di un'attività e la capacità di affinare le stime è preziosa.
• Se possibile, offro anche bonus di sinergia. Spesso ci sono miglioramenti architettonici che avrebbero benefici per molte attività. Se ho 10 attività che richiedono "1-2 mesi adesso, ma impiegherei 2 settimane con l'upgrade X", è più facile vendere le 20 settimane che potrebbero essere necessarie per l'aggiornamento X.

Se ho un capo che non ha dimestichezza con la ricezione di un intervallo aggiornato mentre procedo, darò loro un singolo numero e la mia metodologia. La mia metodologia è una combinazione di una regola empirica che mi è stato detto da giovane sviluppatore e la legge di Hofstader .

Stima il tempo che pensi che l'attività dovrebbe richiedere, quindi quadruplica quel numero e forniscilo come stima.

e

Legge di Hofstadter: "Ci vuole sempre più tempo del previsto, anche quando si tiene conto della Legge di Hofstadter".

La cosa ragionevole potrebbe davvero entrare nel codice, annotare ogni ramo e chiamare ad altre funzioni e quindi stimare il costo del tempo. Ma c'è davvero una minuscola differenza tra documentare il vecchio codice e scrivere effettivamente la nuova versione.

Questa è la soluzione al tuo problema. Non è possibile stimare se non si hanno requisiti. Di 'al tuo capo che dovrai farlo prima di poter iniziare a scrivere codice. Dopo alcune funzioni e moduli, potresti scoprire che sono stati tutti codificati in modo coerente (in questo caso male), quindi hai una base per determinare le stime future. Assicurati di modificare il preventivo se scopri che la codifica peggiora.

Mi rendo conto che il tuo capo vuole un preventivo, ma senza sapere come vengono utilizzate queste informazioni, non sappiamo quanto esatti debbano essere i tuoi preventivi. Discuti con lui e scoprilo. Se ha solo bisogno di un numero per dare al suo capo, puoi gonfiare leggermente le stime e fornire un numero. Per i clienti in attesa di pagare per il tuo codice fino a quando ciò non avviene, assicurati di scoprire se le date di scadenza fisse genereranno entrate significative.

In una situazione come questa non credo sia possibile fornire buone stime. Il problema di base è che spesso una grande parte del farlo è capire esattamente cosa deve fare.

Gestisco casi come questo dando una stima basata su ciò che sembra comportare, ma con il cavet che sono probabili sorprese. Anche se non ho dovuto affrontare molte cose in termini di codice legacy, ho avuto alcune brutte sorprese nel gestire l'input: ho visto alcune ore trasformarsi in un paio di settimane e una volta in questo è impossibile (Dopo scavando in modo considerevole ho capito che in un determinato caso non avevo abbastanza dati, tornando al tavolo da disegno.) Fortunatamente, il mio capo capisce quando do tali stime.

Bene, la stima è un'abilità che alcune persone non imparano mai bene. Non ti rende inutile come sviluppatore sebbene anche se non riesci a trovare buone stime. Forse i compagni di squadra o la direzione colmeranno le lacune. Sono terribile, ma alla maggior parte delle squadre piaceva lavorare con me. Mantieni la calma, fai squadra e continua il refactoring.

Il debito tecnico offre belle piccole sfide, ma ricorda che una società / squadra che ha finito per produrre debito continuerà a produrre debito a meno che non ci siano cambiamenti nello spirito di squadra o nella gestione. Il codice rispecchia solo i problemi sociali, quindi concentrati sui problemi reali.

Abbiamo utilizzato un'euristica per stimare le funzionalità in un progetto brownfield: abbiamo stimato quanto tempo sarebbe stato implementare quella funzionalità in un progetto greenfield senza nulla di già implementato. Quindi abbiamo moltiplicato quella stima per 2 per occuparci di eliminare i detriti già esistenti.

Questo fattore dipende dalla quantità di accoppiamento e dalla dimensione complessiva del codice, ma se si eseguono alcune funzionalità in questo modo, è possibile interpolare quel fattore in base alle prove effettive.

Penso che dovresti sederti con il tuo capo, guardarlo direttamente negli occhi e dire:

'Ascolta capo! Stiamo solo eseguendo il refactoring qui. Non ci sono nuove funzionalità da offrire e nessun cliente attende tale funzionalità; quindi non ci dovrebbero essere scadenze. Ci vorrà tutto il tempo necessario, devi decidere se dobbiamo farlo o no. "

Usa una gesticolare energica e decisa come indicare e sedersi in avanti sulla sedia.

In alternativa, potresti inventare dei numeri per renderlo felice. Ma ammettiamolo, fino a quando non sei a metà del lavoro le tue stime saranno abbastanza imprecise.