Stima dei costi temporali in base al codice legacy

Leggi "Clean Coder" di Bob Martin (e "Clean Code" mentre ci sei). Quanto segue viene dalla memoria, ma io strongmente ti suggerisco di acquistare la tua copia.

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

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

La tua stima è quindi (a + b + 2c) / 4

• No, non sarà accurato. Esistono modi migliori per stimare, ma questo metodo è veloce, facile da capire e mitiga l'ottimismo, considerando il caso peggiore.
• Sì, dovrai spiegare al tuo manager che non hai familiarità con il codice e che è troppo imprevedibile per te fare stime accurate e precise senza spendere molto tempo a esaminare il codice ogni volta per migliorare la stima (offerta a fai questo, ma dì che hai bisogno di n giorni solo per dare una stima precisa di quanti più 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 mediate, in base al caso migliore, al caso peggiore e al caso probabile e dare loro le cifre che danno anche loro le barre di errore.
• NON negoziare su una stima - se il tuo manager cerca di utilizzare il caso migliore per ogni stima (sono pazzi - ma ne ho incontrati alcuni simili) e poi ti spaventa / ti motiva nel tentativo di raggiungere la scadenza, beh, a volte saranno delusi. Continua a spiegare la logica alla base delle stime (caso migliore, caso peggiore e caso probabile) e ti avvicini sempre di più alla media ponderata e dovresti essere OK. Inoltre, per i tuoi scopi, tieni un foglio di calcolo delle tue stime e aggiungi i tuoi effettivi quando hai finito. Questo dovrebbe darti un'idea migliore di come aggiustare le tue stime.

Modifica

Le mie ipotesi quando ho risposto a questo:

1. L'OP è uno sviluppatore minore (basato sul nome utente scelto). Qualsiasi consiglio dato non è quindi dalla prospettiva di un Project Manager o Team Lead che potrebbe essere 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 composto da un numero piuttosto elevato di attività pianificate per richiedere diversi mesi di consegna.
3. All'OP 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 del progetto e utilizzare per tenere traccia dei progressi .
4. OP non ha settimane per produrre ogni stima ed è stato bruciato prima dando stime troppo ottimistiche e vuole un metodo più accurato di un dito in aria e dicendo "2 settimane, a meno che il codice sia particolarmente arcano in cui caso 2 mesi o più ".

La media ponderata a tre punti funziona bene in questo caso. È veloce, comprensibile al non tecnico e su diverse stime dovrebbe fare la media su qualcosa che si avvicina alla precisione. Soprattutto se OP prende il mio consiglio su come tenere un registro delle stime e dei reali. Quando sai che aspetto hanno un "caso peggiore" e un "caso migliore" nel mondo reale, puoi inserire i dati effettivi nelle stime future e persino aggiustare le stime per il tuo project manager se il caso peggiore è peggiore di quanto pensavi.

Facciamo un esempio funzionante:

• Best case, from experience the fastest I've done a really straightforward one was a week start to finish (5 days)
• Worst case, from experience, there was that time that there were links everywhere and it ended up taking me 6 weeks (30 days)
• Actual Estimate, it'll probably take me 2 weeks (10 days)

5+30+2x10 = 55

55/4 = 13.75 which is what you tell your PM. Maybe you round up to 14 days. Over time, (e.g. ten tasks), it should average out.

Non aver paura di adattare la formula. Forse metà dei compiti finisce con gli incubi e solo il dieci percento è facile; quindi rendi il compagno a / 10 + b / 2 + 2c / 5. Impara dalla tua esperienza.

Nota, non sto facendo alcuna ipotesi sulla qualità del PM. Un PM scadente darà una breve stima al consiglio di progetto per ottenere l'approvazione e quindi farà il prepotente con il team del progetto per cercare di raggiungere la scadenza irrealistica a cui si è impegnata. L'unica difesa è quella di tenere un registro in modo da poter essere visto dare le tue stime e avvicinarsi a loro.

Questo potrebbe essere un buon momento per introdurre un approccio quasi agile. Se invece di stimare in termini di ore / giorni hai assegnato una scala di tipo fibonacci & ha dato a ciascun compito un valore basato su quanto è grande:

• 0 - istantaneo
• 0.5 - vincita rapida
• 1 - modifica semplice
• 2 - un paio di semplici modifiche
• 3 - più impegnativo
• 5 - richiederà qualche riflessione su
• 8 - una quantità significativa di lavoro
• 13 - una grande parte di lavoro che probabilmente deve essere scomposta
• 20 - una grossa porzione di lavoro che deve essere necessariamente suddivisa

Quindi, una volta valutato un gruppo di attività come questa, si lavora su di esse. In un ambiente agile sviluppate la 'velocità' che è la misura di quanti punti ottenete, diciamo, una settimana. Una volta che hai fatto alcune settimane di test-and-learn (puoi venderlo al tuo manager come parte del processo - "Avrò bisogno di un paio di settimane di test e imparerò a capire il processo di stima") sii più sicuro di quanti punti puoi spingere ogni settimana e amp; quindi puoi tradurre i tuoi punti stimati più facilmente nel tempo.

link

link

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

La prima cosa che fai è iniziare a raccogliere dati su quanto tempo ci vuole per fare qualcosa in questo momento. Più dati hai sulla performance della tua squadra, meglio è. Sarà tutto sulla lavagna, ma non preoccuparti di questo adesso. È la verità e devi mostrare la realtà del tuo capo.

Allora andrai a comprare qualche libro.

1. Stima del software: Demistificare l'arte nera di Steve McConnell
2. Lavorare efficacemente con il codice legacy di Michael Feathers

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

Spiega che se le stime accurate sono importanti per l'azienda, dovrai iniziare ad applicare le cose che stai imparando dal libro di Feather. Se vuoi andare rapidamente, senza problemi e in modo prevedibile, dovrai iniziare a rifattorizzare il codice e metterlo in un'imbracatura di prova. Ho avuto ragione dove sei. Il tempo di sviluppo è completamente imprevedibile perché non hai idea di cosa potresti rompere, giusto? ... Sì. Prendilo in un'imbracatura di prova. Un server CI per eseguire questi test non può ferire nessuno dei due.

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

So di aver parlato più di come migliorare il codice che di stimare, ma la dura verità è che le tue stime saranno pessime finché non sarai in grado di domare il codice base legacy. Nel frattempo, utilizza la performance storica per valutare quanto tempo ci vorrà. Con il passare del tempo, ti consigliamo di prendere in considerazione se hai già ottenuto il codice fino alle specifiche nelle tue stime.

Now my boss is rightly asking me an estimation on how long would it take to write feature X in the new architecture. But I'm having difficulties coming up with a realistic estimation; often times I way underestimate the task due to reasons I've stated above and embarrass myself because I can't finish in time.

Probabilmente stai pensando di inviare una stima una . Devo lavorare su un codice legacy, e quando faccio una stima più formale, di solito faccio due o tre :

1. Preventivo primario - presupponendo che debba dedicare un po 'di tempo a scavare, ma l'architettura consente le modifiche che vogliamo
2. Stima angelica - presuppone che tutto sia trasparente / facile da trovare e devo solo apportare piccole modifiche (questo è quello che tralascio qualche volta ... specialmente se so che ci sono solo diavoli in un particolare codice di base )
3. Abyssal Estimate - presuppone che la struttura fondamentale del codice legacy sia incompatibile con la funzione richiesta e avrò un importante refactoring per far funzionare le cose

Tutte e tre le stime prendono in considerazione quanto sia dura la funzionalità e di per sé, qualsiasi esperienza abbia avuto con quella base di codice generale e il mio istinto riguardo al cambiamento (che ho trovato possibile essere abbastanza preciso)

Dopo che queste stime sono uscite, tengo aggiornato il mio gestore su cui sembra che ci stiamo occupando. Se si scopre che stiamo osservando una caratteristica abissale, allora potremmo dover sacrificarla - è successo. Se il tuo capo non può accettare che ci siano caratteristiche abissali per un dato 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 basato sull'offerta di intervalli sulle mie stime. Sono uscito con il dire ai miei capi: "è difficile fare delle buone stime su questa base di codice. Se ne chiedi una, sarà una stima molto ampia". Ho dato "3 giorni a 3 anni" come stima una volta. 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 "Implementare XYZ, quanto tempo ci vorrà?" la mia risposta potrebbe essere "tra un giorno e 4 mesi, tuttavia, se mi lasci effettivamente guardare il codice per qualche ora, posso ridurre l'incertezza in quella finestra". Vado quindi a guardare il codice e torna con "2 o 4 settimane". Non è ancora una finestra ideale, ma almeno è qualcosa che può essere gestito.

Ci sono alcuni tasti per questo:

• Convinci il capo che queste stime sono trattate meglio come una conversazione perché vorrà saperne di più su come appare l'attività mentre la lavori. Questa è un'opportunità per il tuo capo di avere informazioni che non avrebbero se chiedessero solo una stima singola.
• Offri opzioni su come andare avanti quale velocità di sviluppo del codice commerciale e come migliorare le stime. Dare loro una manopola in più che possono trasformare. A volte i padroni sanno che un compito deve essere fatto e hanno solo bisogno di una stima del ballpark. Altre volte stanno eseguendo pro e contro di un'attività, e la possibilità di perfezionare le stime è preziosa.
• Se possibile, offrirò anche bonus di sinergia. Spesso ci sono miglioramenti architettonici che potrebbero portare benefici a molte attività. Se ho 10 compiti che richiedono tutti "1-2 mesi ora, ma ci vorrebbero 2 settimane con l'aggiornamento X", è più facile vendere le 20 settimane necessarie per l'aggiornamento X.

Se ho un capo che non si sente a proprio agio nel ricevere un intervallo che viene aggiornato mentre procedo, darò loro un unico numero e la mia metodologia. La mia metodologia è una combinazione di una regola empirica che mi è stata detta come giovane sviluppatrice e legge di Hofstader .

Estimate how long you think the task should take, then quadruple that number and give that as your estimate.

and

Hofstadter's Law: "It always takes longer than you expect, even when you take into account Hofstadter's Law."

The sensible thing might seem to really get into the code, note every branch and calls to other functions and then estimate the time cost. But there is really a minuscule difference between documenting the old code and actually writing down the new version.

Questa è la soluzione al tuo problema. Non puoi stimare se non hai requisiti. Dì al tuo capo che dovrai farlo prima di poter iniziare a programmare. Dopo alcune funzioni e moduli, potresti scoprire che sono stati tutti codificati in modo coerente (in questo caso scarsamente), quindi hai una previsione per determinare le stime future. Assicurati di adattare il tuo preventivo se scopri che la codifica peggiora.

Capisco che il tuo capo vuole una stima, ma senza sapere come vengono utilizzate queste informazioni, non sappiamo quanto siano esatte le tue stime. Parla con lui e scoprilo. Se ha solo bisogno di un numero per dare il suo capo, è possibile gonfiare leggermente le stime e fornire un numero. Per i clienti che attendono di pagare il codice fino a quando ciò non viene fatto, assicurati di scoprire se le date di scadenza rigide genereranno entrate significative.

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

Gestisco casi come questo dando una stima basata su ciò che sembra comportare ma con il caveto che è probabile che siano sorprese. Anche se non ho avuto a che fare con il codice legacy, ho avuto alcune brutte sorprese riguardo all'input: ho visto alcune ore trasformarsi in un paio di settimane e una volta in questo-is-impossible (After Scavo considerevole Ho capito che non avevo abbastanza dati in un certo caso, 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 anche se non riesci a trovare buone stime. Forse i compagni di squadra o il management riempiranno le lacune. Sono terribile, la maggior parte delle squadre amava lavorare con me. Mantieni la calma, fai squadra e continua il refactoring.

Il debito tecnico ti dà belle sfide, ma ricorda che una società / squadra che ha finito per produrre debito continuerà a produrre debiti 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 usato un'euristica per stimare le caratteristiche in un progetto brownfield: abbiamo stimato quanto tempo sarebbe stato necessario implementare quella funzionalità in un progetto greenfield senza qualsiasi già implementato. Quindi abbiamo moltiplicato quella stima per 2 per gestire la pulizia dei detriti già esistenti.

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

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

'Listen boss! We are just refactoring here. There is no new functionality to deliver, and no customers waiting for that functionality; so there shouldnt be any deadlines. This is going to take as long as it takes, you need to decide whether we have to do it or not.'

Usa una ferma gesticolazione assertiva come puntare e sederti sulla sedia.

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