Qual è la migliore spiegazione di cosa sono i Story Points?

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

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

• Il cervello umano è solo unable per stimare correttamente nel tempo. Soprattutto se più di poche ore.
• Ciò è notevolmente amplificato dalla quantità di incertezze nello sviluppatore del software, dalle pressioni psicologiche da parte del management (quando si stima, si commette ...) e dalla differenza di competenze nel team.
• Tuttavia, siamo abbastanza good nel confrontare le cose. Siamo abbastanza accurate lì.

L'idea è di prendere una user story di riferimento , quindi dargli 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 saranno 300 punti.

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

Per ottenere una velocità precisa, devi fare poche iterazioni e calcolare quanti punti la tua squadra ha completato in un dato intervallo di tempo.

Funziona .

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

L'unica cosa che vorrei aggiungere (enfasi) è che non siamo bravi a stimare i compiti. Possiamo stimare compiti relativi ad altri compiti purché siano approssimativamente della stessa dimensione. Più grande è la differenza tra i compiti, peggio ancora.

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

Non è come se stimassi il prossimo compito come il 42% dell'attività di riferimento. È la stessa metà del lavoro raddoppiare il lavoro triplicare il lavoro ecc.

Il nostro team utilizza Planing Poker : in questo abbiamo un compito di riferimento di 2 punti storia. Quindi usiamo la serie di Fibonacci per valutare i compiti: 1,2,3,5,8,13,21, Enorme ,? relativo al compito di riferimento (Piuttosto che il Fibonacci ho visto le altre squadre usare le potenze di 2. 1,2,4,8,16,32, Enorme ,?) Ho visto altre squadre usare (piccolo (1), medio ( 2), grande (3), XLarge (4) quando calcolavano la velocità funzionava ancora.)

Il punto è che quando la dimensione dell'attività aumenta 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ù ampio alla fine del percorso di stima.

Quindi, se la tua attività di riferimento è 2SP. Quindi fare una stima di 1/2/3/5 è relativamente facile in quanto il compito è di dimensioni simili. Una volta superato il triplo di volte rispetto all'attività di riferimento (5SP), la stima diventa più difficile (l'8/9 / 10SP ha importanza). Tutto ciò che si può dire è più grande di 5SP e più piccolo di 13SP, quindi 8SP è adatto.

Qualunque cosa con un valore SP di 13/21 / Huge è troppo grande per lo sprint backlog. Si tratta di stime per cose per le quali non sei ancora pronto a lavorare (e quindi non sono suddivise in attività più piccole (non interromperle finché 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 loro, dovresti avere abbastanza conoscenze per suddividerle in compiti più piccoli per lo sprint backlog e rivalutarli singolarmente (Nota: è un malinteso comune che la somma di le parti sono uguali all'originale).

• Qualsiasi cosa tu stimi, poiché Huge deve essere scomposto in compiti più piccoli.
• Qualcosa che è stimato come? significa che non è definito abbastanza bene per stimare
  È necessario aggiungere un'attività in modo specifico per andare e definire l'attività (scrivere qualche documentazione o presentazione).

I punti storia sono una misura relativa di quanto sia difficile un compito. Questo perché gli umani sono in realtà migliori alle stime relative rispetto alle misurazioni precise.

Nel modo in cui usi i punti della storia, prendi due compiti sul progetto e assegni loro due valori di story point diversi. Quindi stimerai le altre attività usando quelle approssimazioni a due piani come base per la tua stima. Cioè L'attività C non è molto più difficile del compito A, ma incredibilmente più semplice del compito B, quindi è solo di circa 2 piani in più di lavoro rispetto all'attività A.

Quando hai finito di stimare tutti i requisiti che hai finora, puoi stimare quanti puoi ottenere in uno sprint. Nei prossimi sprint, stimerai quanti ne hai completati. I punti storia di un requisito vengono conteggiati come completati solo se il requisito è soddisfatto. Non c'è "80% completo" in Scrum. Questo perché gli umani sono davvero cattivi nella stima della completezza. Dopo alcuni sprint, dovresti avere un'idea di quanti story point puoi fare per sprint.

Come valuti? Puoi utilizzare pianificare il poker per determinare il lavoro che i tuoi sviluppatori ritengono necessario per soddisfare i tuoi requisiti di base.

Raccomando anche di leggere The Agile Samurai . A mio parere, fa un buon lavoro spiegando questi e altri concetti Agile.

Ecco un link con ulteriori informazioni sui punti storia.

Ecco un altro link.

Sono una perdita di tempo.

link

Interessante che questa opinione provenga ora dal ragazzo che ha scritto Scrum e XP dalle trincee e il cui nome aziendale ( Crisp ) può essere trovato su così tanti mazzi di carte da poker di pianificazione utilizzate da così tanti team in tutto il mondo.

L'ultima frase dell'OP: "Ci sono delle buone risorse per spiegare i punti della storia?" Sì, questo libro è una buona risorsa. Spunti di riflessione.

La spiegazione più semplice che riesco a capire è usare un oggetto che è tangibile e può fornire un esempio concreto.

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

A questo punto, la mentalità dei programmatori inizierà a parlare di un approccio semplificato; non impiega 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 si tratta di una stima in (punti, rane, widget) poiché non possiamo MAI stimare accuratamente nel tempo e quindi stimare in (punti, rane, widget) rimuove la convinzione che possiamo.

Per sapere quanto tempo ci vorrà per costruire useremo le nostre tendenze nel tempo; quindi nel tempo sempre più accurato nelle nostre stime.

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

Come altri hanno menzionato, i punti della storia sono una misura relativa della complessità per una storia di un utente. Il vero vantaggio dei punti storia si realizza quando

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

Dopo alcune iterazioni di misurazione nei punti della storia e nella velocità di tracciamento, dovresti essere in grado di stimare con precisione quanti punti della storia possono essere contenuti in un determinato periodo (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 correttamente. Cioè se la squadra a può completare 120 story points in uno sprint di due settimane, aspettarsi che la squadra b abbia gli stessi risultati è irrealistica.

Come menzionato da qualcun altro, la pianificazione del poker è un grande aiuto quando si utilizza questo metodo perché aiuterà a identificare storie che necessitano di ulteriori perfezionamenti (se c'è una discrepanza tra i voti, significa che c'è un'incertezza nei requisiti).