Query in processo Agile

Non esiste una "formula" per i punti storia (né una risposta "giusta"). Pensa ai punti della storia come a misurare l'altezza di un edificio stando lontano. Potresti non essere in grado di determinare con precisione l'altezza, ma puoi stimare quanto è alto rispetto ad altri edifici o strutture . Lo stesso vale per i punti storia. Vieni con qualche riferimento per "un punto" e misura tutto il resto relativo.

Ci sono vari metodi per determinare i punti della storia, ma quello che preferisco è "pianificare il poker". Compra (o crea) cartoline che contengono i numeri 1, 2, 3, 5, 8, 13, 20 e 40 (leggi qui per vedere perché). Ogni membro del team vota sulla "dimensione" di una caratteristica mostrando la carta più vicina alla dimensione che ritiene sia la caratteristica. Le stime alte e basse spiegano le loro posizioni alla squadra (per convenienza si può avere un voto automatico senza discussione) e la squadra vota di nuovo, ripetendo fino a quando non vi è consenso. Altre carte che possono facoltativamente essere incluse sono 0, 1/2, 100, "infinito" e "?" (significato insicuro). Ci sono pro e contro nell'usare quelle dimensioni che sono discusse in maggior dettaglio altrove.

La velocità, d'altra parte, è più scientifica. È semplicemente il numero medio di punti che una squadra compie ** in una determinata iterazione. C'è una certa varietà nel modo in cui lo misurate (media tutte le iterazioni? Solo l'albero N? Dare più peso alle recenti iterazioni?) Ma se si mantiene coerente la scala del punto storia e i membri del team dovrebbe darvi un'indicazione approssimativa di quanto il team può impegnarsi a completare in una iterazione.

Alla fine, tuttavia, invito i team a fare un "controllo dell'intestino" dopo aver definito un'iterazione. Il team ha bisogno di commit su un corpo di lavoro in una iterazione, che può richiedere funzionalità di taglio se ritiene piace troppo, o aggiungendone alcune se c'è una grande fiducia che c'è spazio per assumere di più.

** Definisco Fatto perché una funzionalità è completamente codificata, testata e convalidata. Non attribuisco un credito parziale per la codifica della "maggior parte" di una funzione (più specificamente per completare la maggior parte delle attività necessarie per completare una funzione). I conterrà una funzione se è stata codificata ma alcuni bug sono stati trovati nei test, ma, naturalmente, inseriranno questi bug nella seguente iterazione e contano i punti della storia lì

I punti della storia rappresentano una dimensione relativa. La cifra attuale non ha importanza. Confrontando due storie è possibile stimare se i due sono la stessa 'dimensione' o se sono diversi nella 'dimensione'. Dimensione qui significa un mix di sforzo, durata, complessità, rischio, novità e molti altri. Non ha molta importanza.

Per determinare le dimensioni relative si paga per fare questo come una squadra usando "pianificazione del poker". Alcune squadre usano le carte, ma in pratica significa che tutti mettono la loro stima sul tavolo allo stesso tempo. Se tutti sono d'accordo, questa è la "dimensione" stimata. Se c'è una grande variazione, la squadra discute perché pensa che sia più grande o più piccola. Quindi stimare di nuovo. Ripeti fino a quando non hai un accordo per ogni storia. Ci sono storie che necessitano di ulteriori esplorazioni. Trasformali in picchi con un massimo di 3 giorni ciascuno. Quindi riunisciti e guarda cosa hai imparato dallo spike.

Per la tua prima iterazione guarda la pila di storie prioritarie e inizia dall'alto. Scegli tutti quelli che credi possano completare come squadra in quell'iterazione. Se finisci le storie prima della fine dell'iterazione, tira fuori altre storie. Se alla fine dell'iterazione le storie sono incomplete, non preoccuparti. Prima di iniziare la prossima iterazione, guarda il totale dei punti storia che hai completato. Non scegliere più punti storia per la tua prossima iterazione. La velocità è la quantità media di punti storia che puoi completare. Alcuni team usano solo la media delle ultime quattro iterazioni. Tieni presente che questa media può cambiare. Questa non è una brutta cosa.

Ci sono alcuni pericoli che vorresti evitare. Stare lontano dalle storie di dimensioni troppo piccole, ad es. dando loro numeri più piccoli di quelli che sono. Stai lontano dall'iscriverti per avere più punti storia di quelli che puoi gestire. È meglio inserire storie aggiuntive piuttosto che avere storie incomplete alla fine dell'iterazione. Stare lontano dall'imporre un numero di punto storia su una squadra particolare. Tutto quello che faranno è mettere valori punto più alti nelle storie. Questa non è un'indicazione dell'aumento della produttività. I punti storia non aiutano a misurare la produttività. Stanno progettando uno strumento per le iterazioni future. Niente di più. Cerca anche di stare lontano dalle storie che dividono lungo la funzione tradizionale, ad es. implementare funzionalità, funzionalità di test, integrare funzionalità, ciascuna con la propria storia separata. Una storia include tutto il lavoro necessario per completare la storia, la codifica, i test, l'integrazione, ecc.

Questo dovrebbe riguardare le basi. Scoprirai che ci sono molti altri aspetti e scenari che vale la pena considerare. L'esperienza arriva con la pratica. Provalo e impara da cosa funziona e cosa no. Buona fortuna!

Entrambe le risposte di @John e @D Stanley sono eccellenti, sebbene dovresti notare che "Planning Poker" non è essenziale per stimare l'utilizzo di storie utente. È solo un buon modo per portare la squadra ad un consenso sulle valutazioni.

Per lo scoop completo su User Story, l'eccellente libro di Mike Cohn Storie utente applicate: per lo sviluppo di software agile è il posto dove andare.