Qual è la migliore spiegazione di quali sono i Story Point?


36

Stiamo iniziando a utilizzare i punti storia qui per il nostro sviluppo Agile, ma trovo difficile da spiegare e inoltre non riesco a trovare una risposta definitiva a ciò che sono. La cosa migliore che posso fare è indicare altri siti (come http://blog.mountaingoatsoftware.com/tag/story-points ) e dare una vaga generalizzazione di ciò che sono. Sto cercando una buona spiegazione con alcuni esempi di utilizzo che potrebbero essere utili ad altri. Ci sono buone risorse per spiegare i punti della storia?


1
Spiegazione a chi o vuoi una spiegazione generale? Il problema con quest'ultimo è che può essere accolto con un po 'di strabiliante dal momento che non tutti vogliono avere una risposta approfondita.
JB King,

Un collegamento a una risposta approfondita sarebbe sufficiente. Mi è stato chiesto da manager, membri del prodotto, team leader e programmatori. È un nuovo concetto per la maggior parte di loro (anche io).
sei8,

Risposte:


36

Questo può aiutare come antipasto: Mike Cohn sui punti della storia . Ma questo è di gran lunga migliore: squadre di sviluppo agili: portata e scala con Mike Cohn

La soluzione di Mike alle metriche di stima del software è semplice ed efficace. Fatti biologici:

  • Il cervello umano non è in grado di stimare correttamente in tempo. Soprattutto se più di poche ore.
  • Ciò è notevolmente amplificato dalla quantità di incertezze nello sviluppatore di software, dalle pressioni psicologiche da parte della direzione (quando si stima, si impegna ...) e dalla differenza nelle competenze nel team.
  • Tuttavia, siamo abbastanza bravi a confrontare le cose. Siamo abbastanza precisi lì.

L'idea è quella di prendere una storia utente di riferimento , quindi assegnargli un numero arbitrario di punti (storia) , quindi altre storie otterranno punti relativi a quel riferimento.

Se la tua storia di riferimento è di 100 punti e un'altra storia è tre volte più grande, allora sarà di 300 punti.

Per convertire i punti della storia in tempo per la tua pianificazione, devi conoscere la tua velocità .

Per ottenere una velocità precisa, è necessario eseguire poche iterazioni e calcolare quanti punti ha completato la tua squadra in un determinato periodo di tempo.

Funziona .


5
+1 migliore spiegazione. Ma fare la storia di riferimento 100 non è una buona idea. in quanto implica che è possibile stimare con precisione in relazione al riferimento. cioè il mio prossimo compito è il 42% del lavoro di riferimento. Come hai detto, il cervello umano è orribile nel valutare. Quindi abbiamo una storia di riferimento di 2 punti. Quindi usa la sequenza di Fibonacci (come più lontano dalla storia di riferimento che più inesattezze non hai motivo di essere esatto). Planning Poker è tuo amico.
Martin York,

1
Se non vuoi guardare, Mike Cohn su Youtube, ha anche un ottimo articolo di blog su questa roba: blog.mountaingoatsoftware.com/tag/story-points . La parte interessante è che anche con il sistema a punti ha detto che gli umani sono buoni solo fino a circa 8, quindi iniziano a sottovalutare.
DXM,

Ho votato a fondo questa risposta e conteneva informazioni molto preziose. Tuttavia, la domanda era tecnicamente chiedere di più su ciò che definisce specificamente un punto della storia, al contrario di come usarli in modo efficace.
Panzercrisis,

5

Sono d'accordo con tutto @Pierre 303: detto sopra: (a parte il punto di riferimento 100).

L'unica cosa che vorrei aggiungere (enfasi) è che non siamo bravi a stimare i compiti. Possiamo stimare le attività rispetto ad altre attività purché abbiano approssimativamente le stesse dimensioni. Maggiore è la differenza tra i compiti, peggiore diventiamo.

Quindi non sono d'accordo con l'uso di un punto iniziale di 100.

Non è come se si stimasse l'attività successiva come 42% dell'attività di riferimento. È la stessa metà del lavoro, il doppio del lavoro, il triplo del lavoro, ecc.

Il nostro team utilizza Planing Poker : in questo abbiamo un compito di riferimento di 2 punti storia. Usiamo quindi la serie Fibonacci per stimare i compiti: 1,2,3,5,8,13,21, Enorme ,? relativamente al compito di riferimento (Invece di Fibonacci ho visto altre squadre usare poteri di 2. 1,2,4,8,16,32, Enorme ,?) Ho visto altre squadre usare (piccolo (1), medio ( 2), large (3), XLarge (4) quando calcolavano la velocità funzionava ancora.).

Il punto è che all'aumentare della dimensione dell'attività rispetto all'attività di riferimento diventiamo meno in grado di stimare con precisione il suo costo. Quindi non ha senso provare. Ciò si riflette nel gradiente più grande alla fine del percorso di stima.

Quindi, se l'attività di riferimento è 2SP. Quindi fare una stima di 1/2/3/5 è relativamente semplice in quanto le attività hanno dimensioni simili. Una volta superate 3 volte le dimensioni dell'attività di riferimento (5SP), la stima diventa più difficile (è 8/9 / 10SP che conta) Tutto ciò che puoi dire è più grande di 5SP e inferiore a 13SP, quindi 8SP si adatta al conto.

Qualsiasi cosa con un valore SP di 13/21 / Enorme è troppo grande per il backlog dello sprint. Queste sono stime di cose su cui non sei ancora pronto a lavorare (e quindi non sono state suddivise in attività più piccole (non scomporle fino a quando non ne hai bisogno)). Tuttavia, forniscono una stima della dimensione di un'attività nel backlog del prodotto (che consente una pianificazione futura). Quando arrivi al punto in cui lavorerai su di essi, dovresti avere abbastanza conoscenze per suddividerli in compiti più piccoli per il backlog dello sprint e rivalutarli singolarmente (Nota: è un'idea sbagliata comune che la somma di le parti equivalgono all'originale).

  • Tutto ciò che si stima come enorme deve essere suddiviso in compiti più piccoli.
  • Qualcosa che è stimato come? significa che non è abbastanza ben definito per stimare
    È necessario aggiungere un'attività in modo specifico per andare a definire l'attività
    (cioè scrivere un po 'di documentazione o presentazione).

2

I punti storia sono una misura relativa di quanto sia difficile un compito. Questo perché gli esseri umani sono effettivamente migliori a stime relative rispetto a misurazioni precise.

Il modo in cui usi i punti della storia è che prendi circa due compiti nel progetto e assegni loro due diversi valori dei punti della storia. Quindi si stimano le altre attività utilizzando quelle due approssimazioni del punto storia come base per la stima. Vale a dire l'attività C non è molto più difficile dell'attività A ma è incredibilmente più facile dell'attività B, quindi è solo circa 2 punti storia più lavoro dell'attività A.

Quando hai finito di stimare tutti i requisiti che hai finora, stimali quanti ne puoi fare in uno sprint. Nei prossimi sprint, stimerai quanti ne hai completati. I punti trama di un requisito vengono conteggiati come completati solo se il requisito è soddisfatto. Non esiste un "80% completo" in Scrum. Questo perché gli umani sono in realtà pessimi nel valutare la completezza. Dopo alcuni sprint, dovresti avere un'idea di quanti punti della storia puoi fare per ogni sprint.

Come valuti? Puoi utilizzare la pianificazione del poker per determinare la quantità di lavoro che i tuoi sviluppatori ritengono necessaria in relazione ai requisiti di base.

Consiglierei anche di leggere The Agile Samurai . Secondo me fa un buon lavoro spiegando questi e altri concetti Agili.

Ecco un link con ulteriori informazioni sui punti della storia.

Ecco un altro link.


2

Sono una perdita di tempo.

inserisci qui la descrizione dell'immagine

http://www.amazon.com/Lean-Trenches-Managing-Large-Scale-Projects/dp/1934356859/

È interessante notare che questa opinione ora viene dal ragazzo che ha scritto Scrum e XP dalle trincee e il cui nome di società ( Crisp ) può essere trovato su così tanti mazzi di carte da poker di pianificazione utilizzate da così tante squadre in tutto il mondo.

L'ultima frase del PO: "Ci sono buone risorse per spiegare i punti della storia?" Sì, questo libro è una buona risorsa. Cibo per la mente.


Dare un'opinione sul fatto che siano utili o meno non risponde alla domanda su cosa siano.
Bryan Oakley,

0

La spiegazione più semplice che posso trovare è l'uso di un oggetto tangibile e in grado di fornire un esempio concreto.

Porta una casa mobile. Se fossi nel settore delle case mobili, saprei che la costruzione di un singolo wide richiede in genere 5 (punti, rane, widget ... la forma di misurazione è arbitraria) e quindi la costruzione di un doppio wide dovrebbe richiedere circa il doppio dello sforzo o 10 (punti , rane, widget).

La mentalità dei programmatori a questo punto inizierà e parlerà di un approccio semplificato; non richiede il doppio del tempo a causa dell'infrastruttura che consuma la maggior parte del tempo e altri esempi simili. Questo è inevitabile Arpa sul fatto che questa è una stima in (punti, rane, widget) poiché non possiamo MAI effettuare una stima accurata nel tempo e quindi stimare in (punti, rane, widget) rimuove la convinzione che possiamo.

Per sapere quanto tempo ci vorrà per costruire faremo uso delle nostre tendenze nel tempo; quindi nel tempo sempre più accurati nelle nostre stime.

Non dimenticare di pianificare il poker quando la squadra è pronta per partire.


0

Come altri hanno già detto, i punti della storia sono una misura relativa della complessità per una storia dell'utente. Il vero vantaggio dei punti trama si realizzano quando

  1. I punti sono misurati dall'unità responsabile dell'implementazione (individuo o squadra).
  2. Le metriche vengono mantenute per quanti punti aggregati vengono completati dalla stessa unità in una durata costante (velocità).

Dopo alcune iterazioni di misurazione nei punti della storia e velocità di tracciamento, dovresti essere in grado di stimare con precisione quanti punti della storia possono adattarsi in un determinato intervallo di tempo (iterazione o sprint se si utilizza la mischia). Tieni presente che l'applicazione di questa tecnica a un gruppo e il tentativo di utilizzare tali metriche per un team diverso non funzioneranno bene. Cioè se la squadra a riesce a completare 120 punti trama in uno sprint di due settimane, aspettarsi che la squadra b abbia gli stessi risultati non è realistico.

Come altri hanno già detto, pianificare il poker è di grande aiuto quando si utilizza questo metodo perché aiuterà a identificare le storie che necessitano di un ulteriore raffinamento (se c'è una discrepanza tra i voti, significa che c'è incertezza nei requisiti).


1
"Come altri hanno menzionato i punti della storia sono una misura relativa della complessità per una storia dell'utente." Nota che Mike Cohn sostiene che "It's Effort, Not Complexity", vedi mountaingoatsoftware.com/blog/its-effort-not-complexity per una discussione dettagliata su questo argomento.
datentyp
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.