it-swarm.it

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

Stiamo iniziando a utilizzare i punti storia qui per il nostro sviluppo Agile, ma trovo difficile 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?

36
six8

Questo può aiutare come antipasto: Mike Cohn sui punti della storia . Ma questo è molto meglio: Agile Development Teams: Scope and Scale with 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 uno user story di riferimento , quindi assegnargli un numero arbitrario di (story) punti , 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 velocità .

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

Funziona .

36
user2567

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

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 valore 13/21/Huge è troppo grande per il backlog dello sprint. Queste sono stime per cose su cui non sei ancora pronto a lavorare (e quindi non hai suddiviso in attività più piccole (non suddividerle fino a quando non sono necessarie). Tuttavia, forniscono una stima della dimensione di un'attività nel backlog del prodotto (che consente una pianificazione futura). Quando si arriva 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 delle parti sia uguale 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
    Devi aggiungere un'attività in modo specifico per andare a definire l'attività
    (ovvero scrivere documentazione o presentazione).
5
Martin York

Sono una perdita di tempo.

enter image description here

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

Interessante che questa opinione ora provenga dal ragazzo che ha scritto Scrum e XP dalle trincee e il cui nome dell'azienda ( Crisp ) può essere trovato su così tanti mazzi di pianificazione delle carte da poker 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.

2
azheglov

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 trama è di prendere circa due compiti nel progetto e assegnare loro due diversi valori dei punti trama. Quindi si stimano le altre attività usando quelle due approssimazioni del punto storia come base per la stima. Cioè 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 usare pianificazione del poker per determinare quanto lavoro i tuoi sviluppatori riterranno necessario un requisito rispetto ai tuoi 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
indyK1ng

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 parametri 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).

0
Michael Brown

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

Prendi una casa mobile. Se fossi nel settore delle case mobili, 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 un doppio largo 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 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 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 pianificazione del poker quando la squadra è pronta per partire.

0
Aaron McIver