Perché per stimare le storie degli utenti utilizziamo i punti storia anziché i giorni umani?

Nelle metodologie agili (ad es. SCRUM), la complessità / lo sforzo necessario per le storie degli utenti sono misurati in punti Storia. I punti storia vengono utilizzati per calcolare il numero di storie utente che una squadra può prendere in un'iterazione.

Qual è il vantaggio di introdurre un concetto astratto (punti della trama), in cui possiamo semplicemente usare una misurazione concreta, come i giorni-uomo stimati? Possiamo anche calcolare la velocità, stimare la copertura di un'iterazione, ecc. Usando i giorni-uomo stimati.

Al contrario, i punti della storia sono più difficili da usare (perché il concetto è astratto) e anche più difficile da spiegare agli stakeholder. Che vantaggio offre?

Penso che uno dei principali vantaggi sia che gli umani e gli sviluppatori in realtà sono piuttosto scarsi nel valutare il tempo. Pensa anche alla natura dello sviluppo: non è una progressione lineare dall'inizio alla fine. Spesso è "scrivere il 90% del codice in 10 minuti e poi strappare i capelli per il debug per 17 ore". È piuttosto difficile da stimare in senso orario.

Ma l'uso di un'astrazione distoglie l'attenzione dal tempo effettivo in ore o giorni e si concentra invece sulla descrizione della spesa relativa e della complessità di un'attività rispetto ad altre attività. Gli umani / gli sviluppatori sono più bravi in ​​questo. E poi, una volta che ti canticchi con quelle stime puntuali e alcuni progressi effettivi, puoi iniziare a guardare il tempo più empiricamente.

Ho il sospetto che vi sia anche un effetto osservatore che si verifica con le stime temporali che non accadrebbe con le stime puntuali. Ad esempio, l'incentivo a effettuare il sandbag di una stima e consegnare il modo "prima del previsto" verrà disattivato con l'indirizzamento indiretto in un sistema basato su punti.

Se stai usando numeri di Fibonacci (o qualcosa di simile), limita il numero di opzioni durante la stima di una storia. Ho lavorato con un gruppo che utilizzava solo numeri bassi: 1, 2, 3, 5, 8 e 13. Avevamo una storia di riferimento che era un 5. Questo ci ha permesso di prendere facilmente decisioni rapide sulla complessità di una storia mentre facevamo Planning Poker . L'altro effetto collaterale era che qualsiasi cosa classificata come 13 probabilmente non aveva informazioni sufficienti e doveva essere ulteriormente scomposta. Dubito seriamente che sarebbe stato così facile e semplice se stessimo usando ore grezze.

Il Product Owner parla la lingua delle parti interessate e dovrebbe essere in grado di tradurre tra i punti della storia e le ore di lavoro (o altre unità) secondo necessità. Durante il mio periodo come PO, ho avuto alcuni dati concreti sul fatto che 1 punto della storia = 4 ore-uomo, ma ovviamente ogni squadra è diversa.

Modificare:

Con la consapevolezza che 1 punto = 4 ore, potresti teoricamente cambiare il tuo mazzo di Planning Poker a 4, 8, 12, 20, 32 e 52. Ma quei numeri sembrano più difficili da gestire. Penso che astrarre mentalmente i valori su qualcosa di semplice, ad es. "Meno di un giorno", "più di una settimana", ecc. E se lo farò, potrei anche attenermi all'unità astratta senza punti di storia.

È per consentire alla stima di migliorare nel tempo, senza che tutti gli stimatori debbano adeguare la stima.

Piuttosto che tutti coloro che sono coinvolti nella stima devono pensare come "OK .. sembra 2 giorni uomo .. ma l'ultimo sprint abbiamo sottovalutato tutto, quindi forse sono davvero 2,5 giorni uomo. O 3?", Continuano come sempre. "5 punti storia!"

Quindi, modifichi la stima di quanti punti della storia il team può superare in uno sprint, in base ai risultati misurati effettivi negli sprint precedenti. "In precedenza abbiamo fatto 90-110 punti trama per sprint!"

Direi che la teoria alla base di ciò è che gli sviluppatori sono più bravi a stimare la complessità relativa dei diversi compiti di sviluppo che a stimare gli assoluti . Soprattutto se più persone stanno valutando un compito che potrebbe essere svolto da ognuno di loro (e non tutti lavorano alla stessa velocità di tutti gli altri).

Alternativa cinica: ho visto che gli sviluppatori non arrivano mai a stime temporali. Se qualcosa impiega più tempo del previsto, sei andato oltre. Ma se qualcosa impiega meno tempo del previsto, gli sviluppatori potrebbero giocherellare con esso, gold-plate, o semplicemente rallentare e prendersela comoda dal momento che gli è stato assegnato un compito comodo. Prendere le unità di tempo reali da una stima può frenare queste tendenze. Termina l'alternativa cinica.

I giorni o le ore dell'uomo sono come dici tu concreti. Quindi, quando un'attività è stimata in 5 ore e ne richiede 6, ora è un'attività in ritardo.

Quando hai una storia di 3 punti e ci vogliono 6 ore, ci sono volute 6 ore, non è tardi, ci sono volute solo sei ore. La misurazione della velocità è più un fattore di quanti di quei punti vengono fatti in uno sprint e quel numero può variare, perché non è concreto. Inoltre non stai misurando ogni attività, ma il totale di tutte le attività. Quando hai ore su ogni attività, la tentazione è lì per misurare ogni attività. Quando ciò accade, non si ottiene alcun vantaggio allo sprint per aver terminato con il passare del tempo ed è una conseguenza per aver terminato nel tempo di una determinata attività.

Può essere una transizione al pensiero in termini di punti. Un posto in cui ho lavorato prima ancora di introdurre taglie di magliette usate agilmente solo per avere un'idea del livello di sforzo. I punti sono solo un'estensione di questo.

Ciò non significa che non vi siano controversie o assegnazioni arbitrarie ai punti. Abbiamo membri del nostro team che quasi sempre votano il numero più basso e si lamentano quando pensano che un'attività sia un 1 e pensiamo che sia un 3 che stiamo soffrendo di inflazione puntuale.

L'astrazione è una specie di punto. L'uso del "man day" come misura comporta una serie di insidie, tra cui:

1. Se il team non ha familiarità con la tecnologia che utilizzerà, allora può essere davvero difficile fornire stime in tempo reale di quanto tempo potrebbe richiedere un'attività. È molto più probabile che siano in grado di fornire buone stime relative, ad esempio "l'attività A richiederà probabilmente il doppio del compito B".
2. Diverse persone lavorano a tariffe diverse! Se usi i "giorni dell'uomo" devi praticamente cambiare la stima del tempo quando un'attività viene passata da uno sviluppatore all'altro. Chi definisce quanto lavoro costituisce comunque una "giornata dell'uomo"?

Se vuoi stimare le giornate lavorative è un semplice calcolo:

user points in story / average user points per developer per day = estimated man days

Come già accennato, i punti della storia sono una misura relativa della complessità. Si può usare la potenza di 2 serie (1,2,4,8,16 ...) o una scala di Fibonacci (1,2,3,5,8,13,20 ...) per la stima. Come gli sviluppatori sposati sono abbastanza abili nel dire qualcosa del genere:

La funzione A è quasi doppia rispetto alla funzione B.

Ma è davvero difficile dire "quanto tempo" questa funzionalità impiegherà per l'implementazione. Lascia che sia bilanciato dalla velocità. Quindi se qualcosa fosse stimato come 5 ma risultasse essere un 13, una velocità più lenta normalizzerebbe quella per l'iterazione (o potresti rivalutare).

Ora, c'è un'altra alternativa, si chiama "giorni ideali" (alcuni simili a quelli dei giorni umani, ma non sono sicuro che sia quello che intendevi dire) e conosco un bel po 'di squadre che lo preferiscono. I giorni ideali devono essere interpretati come:

Se questo è tutto ciò che faccio dopo essere venuto in ufficio e fare solo le pause necessarie, non avere interruzioni e avrà tutto ciò di cui ho bisogno per "implementare la storia", cioè nessuna attività periferica come riunioni, rispondere a mail ecc.,

Mike Cohn, uno dei tanti noti evangelisti agili, fornisce il seguente confronto tra punti della storia e giorni ideali

Punti della storia

• Aiuta a guidare il comportamento interfunzionale, ad esempio i team stimano storie sulla complessità totale dell'implementazione dall'interfaccia utente al database e viceversa.
• Le stime di SP non decadono, cioè tra qualche mese una storia a 5 punti è ancora probabile che sia di 5 punti, ma una stima del giorno ideale può cambiare a seconda dell'abilità / velocità di sviluppo acquisita di quel particolare programmatore
• Gli SP sono una misura pura della dimensione, cioè riflettono solo e solo la complessità della dimensione. Periodo. Nessuna durata ecc., La gettò. Questo è il lavoro della velocità. Ma non così nei giorni ideali. In effetti con i giorni ideali si tende a confonderlo con i giorni di calendario. Mantenerlo astratto mentre gli SP combattono la tentazione di confrontarsi con la realtà. Solo una misura delle dimensioni. Nessuna assurdità.
• In genere è più veloce dei giorni ideali. Può essere complicato per le prime due storie, ma una volta capito, è più veloce.
• Diversi sviluppatori possono avere una visione diversa della loro stima del giorno ideale per completare una storia. Potrei fare lo stesso in 3 e tu in 5. Gli SP sono più o meno uniformi su tutta la linea. Livellano il campo di gioco per così dire.

Giorni ideali

• Più facile da spiegare al di fuori della squadra; per ovvie ragioni :)
• Più facile da stimare inizialmente come menzionato sopra. Ma una volta capito l'SP, arriva naturalmente

Ora, quale scegliere dipende dalla squadra. Tuttavia, poiché la maggior parte delle risposte qui e la mia esperienza personale, preferisco i punti della storia. I giorni ideali non hanno davvero un grande vantaggio rispetto agli SP (e Mike Cohn sostiene anche SP insieme a molti altri evangelisti agili).

I punti storia ti aiutano anche a misurare il miglioramento delle prestazioni della squadra nel tempo. Inoltre, non è necessario rivalutare tutto poiché le prestazioni migliorano.

Prendi questo esempio che utilizza i giorni uomo:

Il team stima diversi compiti con giornate lavorative. Funziona per un po ', ma dopo un po' vedi che il team è fatto più velocemente con molte attività di quanto si pensasse inizialmente. Quindi il team rivaluta le attività. Funziona per un po ', e dopo qualche tempo vedi di nuovo la stessa cosa: il team è finito più velocemente con molte attività di nuovo. Quindi rivaluti di nuovo, e questa storia si ripete ancora, e ancora e ancora ...

Perché? Perché le prestazioni della tua squadra sono aumentate. Ma tu non lo sai.

Lo stesso esempio con i punti della storia:

Il team stima la dimensione delle storie degli utenti. Dopo alcuni sprint, vedi che la squadra può fare circa 60 punti trama per sprint. Più tardi, vedi che il team ha raggiunto più di 60 punti trama, forse 70. E il team continua così, raccoglie più storie utente per i prossimi sprint e le consegna.

Perché? Perché le prestazioni sono aumentate. E puoi misurarlo. E non è necessario rivalutare tutto dopo che le prestazioni della tua squadra sono aumentate.

Innanzitutto, le persone sono migliori a stime relative rispetto a stime assolute. I babilonesi che mappano e valutano la luminosità relativa delle stelle ne sono un ottimo esempio. Non hanno ottenuto le cifre assolute giuste, ma l'ordine è stato per lo più perfetto anche per intensità molto simili.

Il secondo vantaggio è che una delle ragioni principali per fare questo esercizio è guidare la conversazione. Se inizi a discutere in giorni esatti, la conversazione potrebbe rapidamente deragliare.

Come diceva Napoleone: il piano è inutile, la pianificazione è preziosa.

In terzo luogo, il project manager non deve modificare tutte le stime, solo perché risulta che le stime sono state annullate di un fattore, ad esempio, del 130%.

I punti storia riflettono la complessità del problema e, quindi, riflettono la fiducia (o il rischio) della precisione della stima.

Una storia con un alto livello di storia mi dice che c'è molto da fare con la storia dell'utente che non è concreta.

L'idea è di vedere qual è un buon equilibrio tra vari punti della storia. Se mi viene mostrato un piano di iterazione con storie con tutti i punti salienti, questo mi dà poca fiducia sul fatto che l'iterazione verrà eseguita come previsto e che dobbiamo guardare altre storie per l'iterazione o iniziare a scomporle.

Quando comunichi con un manager o il Product Owner, i punti salienti della storia significano che sarà estremamente confuso su quando otterranno una caratteristica particolare. Una delle soluzioni a ciò è quella di scomporre la storia e, si spera, avrai una combinazione di punti di storia bassa e alta con cui lavorare in modo da poter dimostrare iterativamente progressi al Product Owner.

I giorni dell'uomo stimano il tempo necessario per fare qualcosa. Sono utilizzati al meglio quando gli articoli che si stanno valutando sono molto precisi e misurabili. Compiti specifici, ben noti e ripetibili sono stimabili in giorni lavorativi.

Ad esempio, se un addetto alle vendite può effettuare in media 20 chiamate al giorno al giorno, possiamo calcolare quanto tempo impiega ciascuna chiamata e da ciò possiamo stimare il numero di giorni lavorativi necessari per effettuare 1000 chiamate.

In questo esempio si può concretamente pensare in termini statistici alla lunghezza mediana di una chiamata perché si può presumere che tutte le chiamate siano effettivamente la stessa cosa.

I punti storia determinano quale combinazione di storie può essere fatta in una iterazione. Sono usati per combinare obiettivi eterogenei con confini sfocati e per misurare quanti possono essere fatti in un intervallo di tempo fisso. Stimano la complessità dei blocchi di lavoro confrontati tra loro in modo da poterli sommare.

Ad esempio, la tua squadra ha sviluppato 5 storie per un totale di 23 punti nell'iterazione 1 e 8 storie per 20 punti nell'iterazione 2. Da questo puoi stimare che nell'iterazione due la tua squadra farà alcune storie il cui totale è di circa 20 punti nell'iterazione 3.

Si noti che non è necessario determinare la dimensione di un punto e, in particolare, non si presume affatto che ogni storia della stessa dimensione impiegherà lo stesso tempo per essere sviluppata! Lavoriamo solo su somme e punti per iterazione. Non ho nemmeno menzionato quanto dura l'iterazione.

Se cammini verso un umano per strada e chiedi "Quanto era grande un T-rex?" le risposte fluttuerebbero anche se la maggior parte degli umani sa cos'è un T-rex, quanto è grande il suo tipo, ma nessuno lo sa davvero per certo - perché non abbiamo una scala relativa da cui basare.

Questo è il comportamento cognitivo che stai cercando di capire con la previsione e molte metodologie con cicli di spin con " Ce l'ho! .. ho il segreto per una previsione accurata! " Olio di serpente per le masse. Quando in realtà prevedi che stai effettivamente dicendo a voce alta " PERMETTERO x giorni / ore / punti per il completamento " - è in un certo senso la creazione di un "timebox" affinché l'evento venga eseguito all'interno.

Per me, Points sta solo spostando i confini, alla fine della giornata a meno che tu non sia in una squadra che è felice di dire " * Beh, abbiamo 3 settimane per sprint e il pollice succhia ... immagino che dovremmo sparare per 30 punti da completare in quel ciclo! Chi è con me! * "Ed è così profondo come vai nella modellazione delle previsioni - bene! ..come realisticamente stai solo fissando un budget arbitrario e basta. Inoltre, in retrospettiva, guardi il lavoro completato con un senso di "merda santa, abbiamo fatto trenta volte quello scatto, che era piuttosto bello" e non si può fare molto al riguardo. Puoi usare la velocità per determinare a metà sprint che stai ottenendo il botto per il tuo budget budget chiedendo a voce alta " Abbiamo già colpito 15 punti?"ma il pericolo qui è che stai usando Velocity per misurare la produttività e non la capacità che da quello che capisco dà il via alla gestione dei rilasci reattivi (punti della storia) nella testa.

Il sistema di punti è quasi troppo intelligente per non notare che si attacca ancora tempo relativo all'equazione, tutto dai "cicli di sprint" concordati ai tuoi standup giornalieri in cui si applica qualche regola nascosta sulla durata + complessità = " Max sta prendendo troppo tempo con quel compito "istinto innato sentendo codice squadra momento rosso?

Il cervello umano non può prevedere perché comporta molta memoria di lavoro mista a richiamo a lungo / breve termine, quindi è come chiedere a uno studente di matematica alle prime armi di fare delle frazioni nella testa non sulla carta .. Ecco perché altri settori non concordano mai su una previsione e convalidare costantemente le previsioni nel tempo relativo (ad es. il geologo non smette mai di modellare le previsioni fino a quando quel metro cubo non è stato scavato dal terreno e quindi "fatto").

Direi che il sistema Point funziona se non stai facendo previsioni . Stai accettando un pezzo di lavoro basato su un algoritmo di sub-chunking, ma questo è davvero il tuo approccio più vicino alla previsione possibile. In effetti, la tua gestione dei rilasci cercherebbe interruzioni naturali nella coda dei "backlog" che si adattano ai temi (es. In Silverlight che i responsabili dei prodotti aspetterebbero fino a quando non completano il loro backlog e mettono insieme i temi inizialmente impostati. non abbiamo mai saputo cosa stesse facendo il team di ingegneri, in particolare avevamo solo uno schema di base. Avremmo quindi preso quel corpo di lavoro e costruito attorno al nostro evento di marketing (Microsoft Mix)

Quando inizi a bloccare le aspettative di velocità all'interno dei cicli di sprint che si basano su velocità + tempo, torni di nuovo alle stime delle previsioni solo questa volta che stai peggio perché stai giocando al "gioco dipende" ... Ancora più importante stai anche uccidendo il potenziale per la crescita della squadra / crescita della carriera.

L'imposta che paghi per Punti vs Tempo è con i punti che devi cercare per formule di misurazione alternative per tenere traccia dello sviluppo / mentoring delle abilità del lavoro o del comportamento degli sviluppatori.

Dato che avrai ancora bisogno di considerare uno "sviluppatore mediano" come la persona ideale con cui associare abilità / sforzo, puoi quindi basare altri sviluppatori con quella persona per determinare come si stanno comportando nella loro crescita continua all'interno della tua squadra. Evidenzia anche le situazioni in cui gli sviluppatori "veloci" stanno trasportando la maggior parte dell'acqua ma si stanno annoiando o peggio stanno lavorando più ore e nessun riconoscimento / ricompensa a causa di scadenze concorrenti ecc. Gli stand-up non riescono a scoprirlo in realtà, sono davvero lì per rilevare i cattivi odori all'interno della squadra per dire, come in "quella persona sta lottando, lascia aiutare"

Poi arrivano anche le storie di "riporto", storie che non vengono bloccate in quel ciclo di sprint ma poi passano al successivo ciclo di sprint. Che quindi può facilmente creare un effetto a catena se stai prendendo in considerazione il tempo, ma nel momento in cui tieni conto del tempo relativo ... di nuovo, sei appena regredito a "previsione / stima basata sul tempo" e di nuovo il sistema a punti è solo confondere le acque.

Se vai a punti hai ignorato completamente il tempo e intendo completamente come il momento in cui lasci che il tempo si insinui mentre stai giocando l'idea / la metodologia.

Avendo viaggiato in tutto il mondo come evangelista, ho visto un sacco di squadre giurare su tutto ciò che hanno a cuore per aver infranto il codice di previsione agile ... ma ho sempre fatto clic sulla lingua, ho sorriso e me ne sono andato con il pensiero " sì ... l'hai quasi fatto, ma quella padrona che chiamiamo "tempo" ... è solo crudele ... "

Il libro di Mike Cohn "Agile Estimating and Planning" descrive i vantaggi e gli svantaggi della stima con "giorni ideali" o punti della storia, quindi la risposta rapida alla tua domanda è che non è necessario stimare con i punti della storia. Se è più naturale stimare nei giorni ideali, vai avanti.

Penso che il metodo Story Point abbia almeno due importanti vantaggi rispetto al metodo Man-day: in primo luogo, è più facile stimare in SP. SP è relativo e gli umani come noi sono migliori in termini di stima assoluta rispetto al metodo della giornata lavorativa.

In secondo luogo, quando si stima in SP, si ottiene "Team SP" e non "Manday individuale". Quando chiedi "Quanto tempo richiederà questo compito?", Gli sviluppatori senior possono darti 1 giorno ma 5 giorni per un Junior. Questo è il Man-day dipende da chi si assumerà tale compito. Se il proprietario è costretto a cambiare (e lo farà!) Devi riprogrammare tutto. Con SP, è sempre lo stesso chiunque si impegni.

Sono sorpreso che nessuno abbia ancora menzionato la legge sul Parkinson .

Il lavoro si espande in modo da riempire il tempo disponibile per il suo completamento.

Fondamentalmente se stai valutando in qualsiasi tipo di unità di tempo per attività di grandi dimensioni, gli sviluppatori tenderanno a impiegare il tempo che hanno stimato per completarlo o ripassare. Quando effettui una stima in un tempo nebuloso come Story Points o Shirt Sizes, eviti questa trappola.

La stima del punto della storia segue la serie di fibonacci 1,2,3,5,8,13,21 ...

Un cervello umano può facilmente mappare le cose in base alle dimensioni. Ad esempio: abbiamo una carta post it e le assegniamo un punto storia 2 e tre dimensioni della carta post significherebbero 2 * 3 = 6 punti storia.

Lo Story Point 6 si colloca tra le serie di fibonacci numero 5 e 8 con 5 come numero più vicino e quindi il punto di memoria sarebbe 5.