Scrum community presentation_it

38
Le attività “unplanned” negli Sprint (draft) Antonio Lucca ([email protected]) 1

Transcript of Scrum community presentation_it

1

Le attività “unplanned” negli Sprint (draft)

Antonio Lucca ([email protected])

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

9

Situazione iniziale

10

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

11

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

12

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

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

14

Giorno 5: una marca aggiuntiva agli item B e C

15

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

16

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

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

18

Giorno 8: vale la stessa regola

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

20

Sempre giorno 9: le attività vengono divise

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”

26

Un po’ di conti:

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

29

Skill matrix

(From Henrik Kinberg’s Blog)

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)

38

Quotes

• Tutti i modelli sono falsi, ma qualcuno è utile• Ogni buon regolatore di un sistema deve

essere un modello di quel sistema