Come prevedere in modo significativo le stime delle ore quando gli sviluppatori vogliono utilizzare i punti?

L'idea dei punti della storia è di comunicare meglio che le stime hanno sempre qualche incertezza. I punti storia non si riferiscono direttamente a un intervallo di tempo.

Se utilizzi internamente metodi agili, ma esternamente i contratti a tempo fisso / a prezzo fisso, qualcuno deve tradurre tra i due. Che qualcuno sia probabilmente il product manager.

Come suggerito da CandiedOrange in un commento, possono utilizzare i dati storici per tradurre i punti della storia di un backlog stimato in stime temporali per il cliente.

Inoltre, dovrebbero adottare strategie di gestione del rischio per evitare di sottovalutare il tempo richiesto. Una stima semplicistica che considera solo la media dei dati storici ti darà solo una probabilità del 50% di arrivare in tempo! Se una stima di questo tipo viene usata impropriamente come termine, ciò ti farebbe fallire. Invece, dovrebbero considerare la variabilità dei dati storici e comunicare esternamente i tempi che hanno maggiori possibilità di completamento, ad es. una data di consegna quando sono sicuri all'80% che il team può consegnare prima di allora.

Ulteriori letture:

• Steve McConnell: stima del software. Demistificare l'arte nera.

  • Capitolo 4: Da dove viene l'errore di stima?
  • Capitolo 20: Problemi speciali nella stima del programma.

  
  Questo è un libro molto completo che tratta dettagliatamente i dati storici. Riguarda principalmente le tecniche non Agile, ma ciò non significa che non sia applicabile alla tua situazione.
  

• Tom DeMarco: Slack.

  • Parte 4: gestione dei rischi e dei rischi.

  
  Il capitolo citato spiega molto chiaramente perché le stime sono spesso troppo ottimistiche e ha una guida di alto livello per la contabilità del rischio.

In mischia hai una velocità della squadra : punti implementati / fatti per sprint.

Se lo sai

• la velocità media degli ultimi 3 sprint e
• quanti giorni lavorativi ha uno sprint e
• quanto costa un giorno lavorativo

quindi puoi calcolare dollari per punto o ore per punto.

Developers are reluctant to put timings on things,

Questo perché sono intelligenti e hanno imparato dall'esperienza che questa è un'idea stupida che non ha per loro alcun vantaggio.

project managers think story points are a waste of time and

I tuoi project manager hanno bisogno di formazione.

clients just want things done!

È vero! Ma le stime non hanno nulla a che fare con il fare le cose. Trascorrere molto tempo e creare ansia attorno alle stime dell'ora avrà in realtà un impatto negativo sulla produttività (ottenere risultati). Questo è particolarmente vero se si tengono gli sviluppatori a loro. Devono quindi essere strategici nelle loro stime e questo richiede tempo. Tempo trascorso non programmando; non fare le cose.

L'uso delle ore è quasi il peggior modo possibile per valutare:

• Cos'è un'ora esattamente? Se lo sviluppatore fa una pausa biologica, è un'ora? Cosa succede se un PM interrompe la richiesta di stime o completamento percentuale sul proprio compito, costringendo lo sviluppatore a spendere 30 minuti per tornare a quello che stavano facendo? È un'ora?
• Quante ore ci sono in un giorno? 6, 8, 10? Quante ore ci sono nei fine settimana? Pensare in ore porta all'idea fasulla di recuperare i giorni persi con più ore lavorative.
• Sono tutte le ore nello stesso giorno? Studi scientifici mostrano non sono .

I punti storia sono molto più efficaci ma i PM hanno bisogno di sapere come usarli. Le persone non sono brave a giudicare quanto durano le cose quando sono in flusso che è caratterizzato da una mancanza di senso di tempo. Tuttavia, le persone sono brave a confrontare le cose. Se so che costruire la pagina di autenticazione richiede 3 punti, e penso che la home page abbia più o meno la stessa quantità di lavoro, ti dico 3 punti storia.

Quello che i PM dovrebbero fare è prendere quelle stime e determinare, usando l'analisi empirica, quanti giorni ci vogliono per completare 3 punti storia. Ci sarà una variazione in questi numeri. C'è tutto questo campo di conoscenza umana chiamato statistiche che ci aiuta a fare uso di questo tipo di informazioni. Usando questi calcoli i PM prevedono quindi quando il lavoro sarà completato quale livello di precisione è appropriato. Per i clienti e una stima dell'85% (cioè sarà puntuale o all'inizio dell'85% delle volte) è abbastanza buono ma per gli altri clienti è necessaria una stima del 95%. Puoi anche utilizzare i dati per aiutarti a mostrare il costo delle funzionalità e in che modo le modifiche modificano le prestazioni.