A presentation (in italia

1. Le attività “unplanned” negli Sprint (draft) Antonio Lucca (tonyx1@gmail.com) 1

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 2

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”). 3

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” 4

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?) 5

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 6

7. Ma le stime devono essere “unbiased”. E’ Utile riverificare che non ci siano “deviazioni” nelle stime relative Triangulation Un campione degli item del ProductBacklog di uguale “taglia” vengono messi in una unica colonna (vengono discussi e spostati se necessario): 7

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 slacktime) L’obiettivo dello sprint verrà raggiunto comunque 8

9. Situazione iniziale 9

10. Giorno 1: gli item A and B vengono messi in “doing” 10

11. Giorno 2: gli item vengono marcati con una barretta per indicare che è trascorso un giorno 11

12. Giorno 3: gli item sono ancora in “doing”, viene aggiunta una barra ad entrambi 12

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”. 13

14. Giorno 5: una marca aggiuntiva agli item B e C 14

15. Giorno 6: una marca aggiuntiva agli item C e B, che viene messo in Done 15

16. … ma durante la giornata un “unplanned” item interrompe il lavoro su ‘C’ 16

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’”unplannedburnup”. 17

18. Giorno 8: vale la stessa regola 18

19. Giorno 9: vengono aggiunte la barre a D e all’unplanned item, e la barra rossa a C, il burn-upgraph viene aggiornato 19

20. Sempre giorno 9: le attività vengono divise 20

21. Giorno 10: aggiunte barre agli item C e “unplanned”. Quest’ultimo è terminato e viene messo in “done” 21

22. Giorno 10: uno dei due membri del team si prende uno “slack” (per studio, per fare pairprogramming, o altro) 22

23. Giorno 11: fine sprint, finiti gli item C e lo slack. vi vengono aggiunte le barrette e vengono spostati in “Done”. 23

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 24

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” 25

26. Un po’ di conti: 26

27. Disposizione delle User story rispetto agli scostamenti con la velocità (netta) dello sprint 1 0 -1 27

28. Se visualizziamo la deviazione rispetto alla velocità media dello sprint sui task Colorati per area tecnologica: Potremmo tener conto anche della Skill Matrix 28

29. Skillmatrix (From Henrik Kinberg’s Blog) 29

30. Evidenziando per ogni task il valore preso dalla skillmatrix possiamo visualizzare le correlazioni: 30 Da estendere. Esempio di estensione: più persone diverse hanno lavorato sullo stesso task

31. Per farla più complicata: Pooledvariancehttp://en.wikipedia.org/wiki/Pooled_variance 31

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) 32

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 # 33

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 dailystandup verifico che per ogni avatar vi sia non più di un item pianificato. 35

36. DailyStand 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” 36

37. Perché? Evidenziare le interruzioni Settare una “baseline” per l’improvement sulla base di dati misurati con criterio Per team che hanno più stati (kanbanlike) usare diversi tipi di stanghetta per fase aiuta a fare “valuestreammap”. Legittimare lo “slacktime” (senza nasconderlo) 37

38. Quotes Tutti i modelli sono falsi, ma qualcuno è utile Ogni buon regolatore di un sistema deve essere un modello di quel sistema 38