Scrum community presentation_it
-
Upload
tony-lucca -
Category
Technology
-
view
192 -
download
0
Transcript of Scrum community presentation_it
2
Contesto
• Il tempo sottratto allo Sprint per attività non pianificate è un impedimento, rispetto al raggiungimento degli obiettivi dello stesso come stabilito dallo Sprint Planning.
• Se non si conoscono gli impedimenti, non si possono rimuovere.
Per conoscere: misurare, visualizzare
3
Perché evidenziare le interruzioni dovute ad attività non pianificate
perché il tempo sottratto allo sprint diminuisce le chance di realizzare il suo obiettivo
per determinare meglio le cause di ciò che fa variare l’andamento del team (es. “andiamo più lenti perché ci sono troppi ‘tapulli’” è diverso da “andiamo più lenti perché ci siamo dovuti occupare anche di altro”).
4
Sprint velocity
• Classicamente: numero di story point per sprint
• Estensione possibile: “velocità netta” = numero di story point che secondo le nostre stime avremmo potuto fare nello sprint se non ci fossero state delle attività non pianificate”
5
Esempio intuitivo di “velocità netta”
• nel primo sprint vengono fatti 20 story point, e nel secondo sprint 10. Ma nel secondo sprint il tempo effettivo a disposizione è stato dimezzato ==> la velocità “netta” non è cambiata
• Se il tempo a disposizione era lo stesso allora siamo realmente andati più lenti e dunque c’è un problema (La qualità del codice? Abbiamo un debito tecnico?)
6
Velocità netta
• Story point x (giorni uomo disponibili/giorni uomo spesi in attività pianificate)
• Le velocità nette di diversi sprint sono confrontabili• Analogia: se faccio 100 km in un’ora e 50 km in
mezz’ora la velocità è sempre di 100 km/h, non posso dedurre che il motore ha problemi
• Se invece faccio 100 km in un ora e 50 km in quella successiva, potrei supporre che devo fermarmi e controllare il motore
7
Ma le stime devono essere “unbiased”. E’ Utile riverificare che non ci siano “deviazioni” nelle stime relative
• Triangulation• Un campione degli item del Product Backlog di
uguale “taglia” vengono messi in una unica colonna (vengono discussi e spostati se necessario):
8
Simulazione
• 10 story point in totale• Sprint di 10 giorni (due settimane lavorative)• “team” di due persone (per semplificare)• Solo user story, nessun task (per semplificare)• Lo sprint avrà delle interruzioni, cinque dei 20
giorni uomo disponibili saranno usati per item non pianificati (e slack time)
• L’obiettivo dello sprint verrà raggiunto comunque
13
Giorno 4: l’Item A è finito, vi viene posta una barra, e viene spostato in “done”, all’item B viene aggiunta una barra, e l’item C viene messo in “doing”.
17
Il giorno 7 cominciamo a tracciare il tempo segnando l’unplanned item con la barra nera, e quello che è stato da esso interrotto con una barra rossa. I giorni uomo sottratti sono tracciati nell’”unplanned burnup”.
19
Giorno 9: vengono aggiunte la barre a D e all’unplanned item, e la barra rossa a C, il burn-up graph viene aggiornato
21
Giorno 10: aggiunte barre agli item C e “unplanned”. Quest’ultimo è terminato e viene messo in “done”
22
Giorno 10: uno dei due membri del team si prende uno “slack” (per studio, per fare pair programming, o altro)
23
Giorno 11: fine sprint, finiti gli item C e lo slack. vi vengono aggiunte le barrette e vengono spostati in “Done”.
24
Osservazioni
• Il numero totale di stanghette nere è il numero di giorni uomo dello sprint
• Il numero totale di stanghette nere che marcano gli item pianificati misurano il tempo speso in item pianificati.
• Il numero totale di stanghette nere degli item non pianificati e degli slack (e la unplanned “burn up”) rappresentano il tempo sottratto allo sprint dagli item non pianificati
• Le barre rosse sono il tempo in cui un item è rimasto “interrotto” e non finito
25
Misure
• Velocità dello sprint: numero di story point per sprint• Velocità netta dello sprint: Velocità netta moltiplicata
per giorni uomo disponibili/giorni uomo spesi per gli item pianificati.
• La velocità netta fornisce una proiezione di quella che potenzialmente sarebbe la velocità dello sprint senza interruzioni
• Velocità netta per giorno uomo = velocità netta/giorni uomo disponibili = story point per “barretta”
27
Disposizione delle User story rispetto agli scostamenti con la velocità (netta) dello sprint
1
-1
0
28
Se visualizziamo la deviazione rispetto alla velocità media dello sprint sui taskColorati per area tecnologica:
Potremmo tener conto anche della Skill Matrix
30
Evidenziando per ogni task il valore preso dalla skill matrix possiamo visualizzare le correlazioni:
Da estendere. Esempio di estensione: più persone diverse hanno lavorato sullo stesso task
31
Per farla più complicata:
• Pooled variance http://en.wikipedia.org/wiki/Pooled_variance
32
Il “quantum time” può essere anche minore di un giorno
• Settare il “quantum time” a meno di un giorno (esempio ½ giorno)
• Durante il “quantum time” viene eseguita, dal “guardiano della taskboard”, l’aggiunta delle stanghette (utilizzando la sua checklist)
33
Checklist per i membri del team (da verificare)
• Quando ho finito un item e inizio a lavorare su uno nuovo, lo metto sotto il mio avatar, a fianco dell’altro (o degli altri)
• Se metto un ‘#’ sugli item fatti significa che dico al guardiano della taskboard di non aggiungervi nessuna stanghetta (ma almeno un item deve essere senza ‘#’)
A B C#
34
In caso vi siano item non pianificati
A B C# unplanned
• Aggiungo l’item non pianificato a fianco di quelli esistenti
35
La checklist del guardiano della taskboard
• Allo scadere di ogni “quantum time”, per ogni avatar, se questi non ha “unplanned item”, metto una stanghetta in uno solo tra quelli in doing e non marcati con ‘#’– Se ha anche degli “unplanned”, metto una stanghetta
sull’”unplanned” più “in vista”, aggiungo una stanghetta rossa su tutti gli altri unplanned e su uno solo dei planned che non ha la ‘#’
• Alla fine del daily standup verifico che per ogni avatar vi sia non più di un item pianificato.
36
Daily Stand Up Checklist
• Il guardiano della taskboard esegue quanto previsto dalla sua checklist
• Ogni membro del team, al suo turno, sposta in “done” quello che ha finito
• A fine giro, il guardiano del kanban verifica che vi sia non più di un item pianificato per avatar
• Per ogni avatar senza item, viene aggiunto un item “slack”
37
Perché?
• Evidenziare le interruzioni• Settare una “baseline” per l’improvement
sulla base di dati misurati con criterio• Per team che hanno più stati (kanban like)
usare diversi tipi di stanghetta per fase aiuta a fare “value stream map”.
• Legittimare lo “slack time” (senza nasconderlo)