L'abilità individuale dovrebbe essere considerata nei punti della storia?

La mia comprensione della stima della storia è stata che si dovrebbe stimare la dimensione di una storia come sarebbe per uno sviluppatore medio immaginario, un po 'come il concetto di "ragionevole spettatore" nella legge. Cioè, non dovresti stimare le dimensioni della storia supponendo che tu debba farlo .

Per fare un esempio: nel mio precedente lavoro facevo parte di un team in cui ero di gran lunga lo sviluppatore Ruby più fiducioso. I miei compagni di squadra stimavano abitualmente storie legate a Ruby molto più grandi di me, con argomenti del tipo "Beh, non so come X funzioni in Ruby, quindi mi ci vorranno anni per farlo".

La mia tesi contro questo deriva dal fatto che la pianificazione dello sprint è il punto in cui entra in gioco la capacità della squadra. Questo è il forum corretto per dire: "La nostra capacità di questo sprint sarà leggermente inferiore al solito perché la maggior parte delle attività sono basate su Ruby e abbiamo solo un forte sviluppatore di Ruby". Questo fattore durante la stima raddoppierebbe questo aspetto.

Gradirei qualsiasi riferimento autorevole nelle risposte, ma anche le opinioni semplici sarebbero fantastiche.

I punti della storia sono una stima relativa. Quindi il doppio dei punti significa il doppio del livello di sforzo. Le stime relative sono meno soggette alle variazioni del livello di abilità. La domanda non è tanto quanto tempo impiegheresti per 1 punto, ma che 2 punti richiedono uno sforzo potenziale 2 volte maggiore. Il livello di abilità potrebbe importare di più se prendessi dei giorni ideali anziché i punti della storia, perché presumi un livello di produttività individuale.

Le stime relative sono più solide. Inoltre, la valutazione del punto della storia non dovrebbe essere eseguita da un individuo, ma dovrebbe derivare da uno sforzo collettivo della squadra . Per storie meno complesse, di solito c'è un rapido accordo. Per storie più impegnative, la squadra arriverà con un risultato al quale la maggior parte dei membri sarà d'accordo, e quindi implicitamente terrà conto del livello di abilità collettiva della squadra.

Infine, la valutazione della storia viene eseguita in un momento in cui gli incarichi all'interno della squadra non sono necessariamente già decisi. Questo è un altro argomento per non tener conto del livello di abilità individuale. Per la pianificazione dello sprint, prenderai la capacità del punto di trama del team, che è una figura che si evolverà in base ai dati sulle prestazioni effettive, in modo da adattarsi automaticamente al livello di abilità globale della tua squadra.

In conclusione, la capacità individuale non dovrebbe essere presa in considerazione per la stima. Ma anche se fosse fatto, a causa delle stime collettive e della solidità dell'approccio relativo, non importerebbe molto.

La risposta canonica è che non è necessario modificare le stime per sviluppatore. Ciò significherebbe che ottieni molti più punti per sprint rispetto ai tuoi pari, e va bene perché i punti misurano la velocità della squadra , non gli sviluppatori. Le aziende possono stimare quanto il team produrrà per ottenere aspettative approssimative di consegna e tutto è fantastico.

Tuttavia, ciò provoca in pratica ogni tipo di problema. Cosa succede se sei in vacanza quella settimana? Cosa succede quando arriva il momento delle recensioni e ti rendi conto che stai producendo il 200% dei punti medi della storia per il 110% dello stipendio medio? Cosa succede quando gli affari iniziano a pensare che la velocità della squadra divisa per le persone sia in realtà un'approssimazione accurata? Cosa succede quando le aziende si rendono conto che stai producendo molti più bug rispetto ai tuoi colleghi (ignorando che produci molte più funzionalità)? Cosa costituisce storie "a morso" quando le persone hanno morsi così vari?

Quello che ho scoperto durante la mia carriera è che in gran parte non ha importanza. Il processo è lì per servirti, non viceversa. Se la tua organizzazione deve valutare se gli sviluppatori sono sovraccarichi, i punti trama per gli sviluppatori sono una buona soluzione. Se la tua organizzazione deve misurare la velocità della squadra, i punti della storia dev-agnostici forniranno un quadro più chiaro. Eppure sono sempre un'approssimazione e saranno sempre maltrattati e male interpretati.

Alla fine, sono punti inventati per un processo inventato che è necessario adattare al proprio ambiente.

TL; DR
Dovremmo sempre presumere che solo gli sviluppatori competenti saranno assegnati a una storia particolare.

La competenza (o la sua mancanza) non è un insulto. È semplicemente una misura ragionevole delle capacità di uno sviluppatore che non è né in ritardo né eccezionalmente esperto.

Questo può essere una questione di approccio di una determinata azienda. Ho visto le aziende personalizzare le stime per sviluppatori particolari. Ho anche visto aziende che hanno imposto un sistema in cui tre sviluppatori selezionati casualmente fanno stime della storia prima di assegnare casualmente uno sviluppatore (non uno dei tre iniziali) all'attività.

Ogni sistema può funzionare, ogni sistema può fallire. La domanda non è tanto quale sistema sia migliore, ma piuttosto quali difetti l'azienda è in grado / disposta a gestire .

In linea di principio, il tempo di studio per padroneggiare la lingua / il quadro non dovrebbe essere incluso. Minore tangente: sebbene non debbano esistere in un mondo ideale, dovrebbero essere inclusi i tempi di studio per ostacoli specifici al progetto o alla trama.

Ci sono molte giustificazioni per farlo, ma credo che questo approccio sia generalmente una scelta migliore, perché rimane fedele all'intenzione di stimare un carico di lavoro. Questa potrebbe essere solo una mia opinione, piuttosto che obiettività. Non posso dirlo con certezza.

Il tempo di studio è personale . È nell'ambito di un particolare sviluppatore che deve lavorare su una particolare tecnologia. Non è rilevante quando si valuta il carico di lavoro di una user story, in quanto una user story rientra solo nell'ambito di applicazione (e della tecnologia che utilizza).

Il tempo di studio generalmente non si accumula. Diciamo che il nostro novellino conosce poco di C # e stimiamo che abbia bisogno di tre giorni in più per capire l'ambiente prima di poter fare il lavoro. Come è comune in molte aziende in cui ho lavorato, ora siamo in una riunione in cui ci si aspetta che stimiamo diverse storie utente (individualmente). Per esempio, diciamo che abbiamo tre storie da affrontare.

• Aggiungiamo tre giorni a ogni storia? Se tutte e tre le storie hanno un focus tecnico simile, ciò significa che il debuttante non avrà effettivamente bisogno del tempo extra per la seconda e la terza storia. Abbiamo sopravvalutato il lavoro di sei giorni.
• Aggiungiamo un giorno a ogni storia? Neanche questo è corretto. Se finiamo per assegnare il novellino a una delle tre storie, allora gli abbiamo fatto due brevi giorni di studio; e abbiamo concesso due giorni non necessari di tempo di studio ad altri sviluppatori.
• Aggiungiamo tre giorni a una storia? Come possiamo garantire che questa storia verrà gestita prima delle altre due? Il punto centrale della creazione di storie utente separate è che le storie di solito possono essere affrontate indipendentemente l'una dall'altra. La correttezza della nostra stima ora dipende sia dal presupposto che il nostro rookie farà il lavoro, più l'ordine in cui è assegnato i compiti (se è importante, ad esempio, se il carico di lavoro combinato supera un singolo sprint).

Nota :
ci sono altri casi in cui il tempo di studio si accumula, ad esempio se le tre storie sono su argomenti selvaggiamente diversi e richiedono competenze diverse.
Ma per scoprire se questo è il caso o meno, dovremmo guardare tutte e tre le storie contemporaneamente, il che inizia lentamente a violare il principio di avere storie utente indipendenti . Se avessimo affrontato queste stime in incontri separati, possibilmente con diversi sviluppatori presenti; non saremmo in grado di valutare accuratamente la sovrapposizione tra le storie.

Poiché non possiamo garantire quali storie finiranno effettivamente per essere realizzate (il cliente potrebbe rifiutare una grande stima) e chi sarà assegnato a loro, cercare di rendere conto di un determinato sviluppatore da assegnare a una determinata storia è inutile. Finisce solo per confondere l'acqua.

Invece, dovremmo rendere una stima del carico di lavoro supponendo che il rookie sia già stato velocizzato (ed è quindi uno sviluppatore uguale per i suoi colleghi).
Tale stima è indipendente dallo sviluppatore e pertanto la correttezza della stima non varia in base a quale sviluppatore viene assegnato alla storia.

Nota
È ancora importante riconoscere che un determinato sviluppatore potrebbe aver bisogno di più tempo per studiare prima di poter affrontare una storia particolare. Questa è ancora una considerazione molto rilevante. Ma questa considerazione non dovrebbe essere collegata alla storia , ma piuttosto all'assegnazione di questo particolare sviluppatore a questa particolare storia.

Ma, come ho iniziato, questo può variare da una società all'altra. Alcune aziende potrebbero non preoccuparsi troppo del tempo di studio (ad esempio se lo sviluppatore dovrà inevitabilmente imparare ad usare la tecnologia comunque). Altri potrebbero fare molto affidamento sull'accuratezza di queste stime, poiché influenza la fatturazione a un cliente.

Alla fine, si tratta di raccogliere il tuo veleno. Nessuno di questi approcci è garantito per essere più preciso degli altri.

Questo è un argomento complesso e ci sono frequenti dibattiti sull'argomento. Non mi piace il concetto di opinione "canonica" su questo: ci sono varie opinioni con valore. Ma ci sono valori, principi e pratiche di supporto che dovrebbero guidare l'approccio.

Quanto segue si basa sulle mie opinioni personali che lavorano con i team di scrum da oltre 10 anni. Ma è solo la MIA opinione.

1. Punti della storia come metodo di previsione L'intento originale dei punti della storia era di trovare un metodo rapido per stimare lo sforzo con lo scopo di prevedere ciò che una squadra può completare durante un periodo di tempo. Alcuni dei "luminari" affermano che i punti vengono utilizzati solo per prevedere l'ambito a lungo termine (ad esempio in un rilascio) e non per determinare la capacità a livello di sprint. Inoltre, il concetto è che i team stanno applicando il "dimensionamento relativo" basato su valori storici (lo sforzo X è simile allo sforzo B, che era di 3 punti). Questo accelera il processo di stima in modo che i team non debbano suddividere il lavoro futuro in pacchetti di lavoro dettagliati e applicare ore a tutte le attività. I team ad alte prestazioni si sforzano di far crescere tutti i tecnici in membri molto competenti con livelli di abilità simili. (Questo concetto verrà esplorato più nel punto 4). Quando questo viene raggiunto, il livello di abilità individuale non è realmente una variabile nel dimensionamento. MA: di solito ci vuole molto tempo e sforzi concertati per raggiungere questo obiettivo. Quindi ... cosa facciamo prima di arrivarci?

2. Le ore delle attività determinano la capacità dello sprint: secondo gli stessi "luminari" che affermano che i punti vengono utilizzati per le previsioni a lungo termine, propongono anche di utilizzare le ore delle attività per determinare la capacità dello sprint, anziché i punti. A mio avviso, va bene, ma dirò che quando ho aiutato i team a "Prestazioni elevate", le loro abilità livellate sono state mediate su dove potevano determinare con precisione cosa potevano completare in uno sprint usando solo i punti Storia . Ancora una volta, questo può essere un obiettivo verso il quale ci impegniamo, ma i team più recenti non sono pronti per questo. Pertanto, potresti trovare in un singolo sprint una storia con 2 punti che ha 12 ore di lavoro e un'altra con 25 ore di sforzo. Allora cosa fai? Alcune persone che chiamo "puristi agili" affermeranno che la dimensione della Storia (in punti) dovrebbe essere agnostica per la durata. Altri non sono d'accordo. Leggi la logica dell'articolo 3 e vedi cosa ne pensi.

3. Puntamento della storia per consenso: applicazione di volume, incognite, complessità, conoscenza

Quindi i team guardano un pezzo di lavoro e devono concordare i punti che saranno una delega per il livello di sforzo. Giusto? Supponendo che tutte le abilità siano uguali, allora è facile raggiungere il consenso. Ma spesso le squadre hanno un ragazzo che è un guru di Java, un altro che non è così grande in Java (forse era una persona C # o .Net o Cobol e sta imparando Java). Quindi l'attività X per Bob è molto semplice. Per Jane, è più difficile.

I team agili cercano di promuovere la proprietà del codice collettivo e la crescente / crescente competenza. Quindi di solito non assegniamo storie alle persone in base alla loro esperienza: preferiamo che i team lavorino collettivamente su storie e imparino insieme. Ciò è in linea con il concetto di "rallentare per accelerare": se ci prendiamo il tempo di offrire a Jane esperienza con Java, mentre questo potrebbe rallentarci all'inizio, in seguito avremo sviluppatori Java più competenti. In effetti, se abbiamo un solo esperto Java e ognuno lavora sulle proprie aree di competenza, stiamo creando una situazione con potenziali "punti di errore". Cosa succede nello sprint quando il 90% del lavoro è Java, ma Bob (il nostro esperto Java) è malato o in vacanza? Espandendo le competenze, eliminiamo i potenziali colli di bottiglia e riduciamo il rischio. Con quello in mente: Quando il team guarda una storia, dovrebbero avere in mente diversi concetti durante il dimensionamento. Puoi pensare all'acronimo VUCK per ricordare questo.

Volume: alcuni sforzi sono abbastanza semplici, ma richiedono un grande volume di compiti ripetuti. (Avevo un ragazzo che doveva copiare e riformattare oltre 50 tavoli che dicevano che era 1 punto perché era semplice. Ma riflettendo, il team si è reso conto che mentre era facile, richiedeva tempo e c'era un grande volume di tavoli da essere spostati e ottimizzati. Quindi abbiamo dovuto regolare nuovamente i punti a causa del volume di lavoro)

Incognite: a volte PENSIAMO di sapere cosa fare, ma identifichiamo anche alcune incognite: queste rappresentano RISCHI . Ciò implica che potremmo imbatterci in problemi imprevisti che dobbiamo risolvere, riprogettare o provare una soluzione diversa.

Complessità: questo è abbastanza ovvio. Alcune soluzioni sono tecnicamente complesse. Sappiamo esattamente cosa fare, ma richiede competenza tecnica. La complessità implica anche qualche rischio, no? Quindi, anche se tutti abbiamo pari competenze, la complessità tecnica implica che potremmo imbatterci in sfide impreviste. Quindi potremmo allargare questa storia.

Conoscenza: conosciamo davvero ciò che stiamo risolvendo? A volte i clienti non sono del tutto chiari sulla soluzione che desiderano e stiamo sperimentando un po '. O forse nessuno ha mai implementato questa soluzione (nuova tecnologia mai usata prima) e quindi non sappiamo cosa non sappiamo.

A mio avviso, ognuna di queste considerazioni è in realtà un proxy per una durata prolungata. Storia facile, molto volume? Ci vorrà più tempo, o dobbiamo dividere la storia. Incognite? Aggiunto rischio, ricerca, sperimentazione, potrebbe richiedere più tempo o dobbiamo dividere la storia. Complesso? Rischio aggiunto, necessità di correggere bug, riprogettazione ecc., Quindi potrebbe richiedere più tempo. Non sai se abbiamo le conoscenze richieste? Abbiamo ulteriori rischi, potrebbe essere necessario sperimentare, ecc., Quindi potrebbe richiedere più tempo ...

Vedi dove sta andando? Quindi, mentre il concetto di punti della storia ci scoraggia dal pensare alla durata durante la stima, d'altra parte sarebbe illogico avere una storia in 1 punto che possiamo completare in 4 ore e un'altra storia in 1 punto che è semplice ma che richiederà 2 settimane.

4. I team ad alte prestazioni eliminano i silos e i colli di bottiglia: poiché i team cercano di far salire di livello tutti i membri, a volte hanno membri meno esperti che affrontano nuove sfide o accoppiano il codice per condividere le conoscenze al fine di migliorare come team. Come accennato in precedenza, questo è un requisito se la squadra raggiungerà mai livelli di prestazione elevati reali.

Quindi, se Jane si offre volontaria per intraprendere quello sforzo Java e questo farebbe lo sforzo 2x o 3x la durata dello stesso sforzo se Bob lo facesse, che cosa fai? Nel tempo, i miei team hanno deciso di ridimensionare le storie in base al livello di sforzo (LOE) / VUCK per le persone che lavorano allo sforzo. Non ha senso per Bob, il team Guru, dire "è un 1" quando per Jane non sarà facile e ci vorrà una settimana per completarlo, oltre a richiedere un po 'del tempo di Bob per la codifica delle coppie e la revisione del codice. Pertanto, abbiamo aumentato questi punti per riflettere il vero LOE. La prossima volta che è arrivata una storia simile, quello che era un 8 per Jane in precedenza è diventato un 5. Alla fine, tutti hanno convenuto che fosse un facile 3. A quel punto, sapevamo che stavamo crescendo come una squadra.

TLDR

No, ma forse non per il motivo che pensi.

Versione lunga

Molte delle altre risposte hanno spiegato che i punti storia dovrebbero essere calcolati esclusivamente in relazione ad altri lavori. Questo è assolutamente vero. Dato che i punti storia stimano la quantità di lavoro anziché il tempo necessario per completarlo, non ha molto senso assegnare i punti storia in base a un individuo.

Ad esempio (uno dei miei preferiti), considera il tuo compito "Scava una buca". Puoi stimarlo in base alla quantità di terra da rimuovere o al tempo impiegato per rimuovere la terra. Il mio amico scava tutto ad un ritmo di 3 metri all'ora, ho un grande escavatore meccanico in modo da poterne gestire 100! L'unica costante è la quantità di terra - quindi è quello che usiamo come nostra unità di stima.

Tuttavia, un secondo (e a mio avviso più importante) motivo per scartare la capacità degli sviluppatori di stimare le storie degli utenti è il fatto che quasi tutte le storie degli utenti saranno probabilmente elaborate da più persone.

Potresti avere un architetto, uno sviluppatore, un tester, forse un secondo sviluppatore per eseguire l'interfaccia utente. Prima che la tua user story sia contrassegnata come Fine (idealmente distribuita e realizzata) molte persone diverse ci hanno lavorato. Improvvisamente l'idea di stimare in base allo sviluppatore in questione ha ben poco senso, l'unico modo per stimare con precisione quanti sforzi saranno coinvolti dal team è misurare la velocità dei team e stimare il lavoro da completare per il team.

Non c'è un "io" in squadra e assolutamente nessun io nella pianificazione agile!