Risultato dell'applicazione di TFS nell'adozione di Scrum.

1. ALM Saturday
Team Foundation Server
& SCRUM
Pordenone - 5 Ottobre 2013
Manuel Scapolan
Lessons Learned

2. Se capita che…
2

3. • Cambiano le specifiche a pochi giorni dal
rilascio in produzione
3
http://thecodinglove.com

4. 4
• Si inizia subito a sviluppare senza aver fatto
alcuna analisi
http://thecodinglove.com

5. • Ti comunicano che la funzionalità che hai
appena sviluppato non verrà mai usata
5
http://thecodinglove.com

6. E’ ora di cambiare
6

7. Cosa vogliamo
• Produrre software di qualità
• Soddisfare i nostri clienti
• Rispettare i tempi di consegna
• Rispondere velocemente ai cambiamenti
• Migliorare continuamente
7

8. Scrum è la risposta
8

9. Come iniziare?
9

10. Start small
• Siamo partiti con 2 team su 8
• All’inizio è molto frequente fare dei cambiamenti,
meglio se impattano su poche risorse
• Abbiamo scelto uno strumento che ci aiutasse a
tracciare e raccogliere i risultati
10

11. Team Foundation Server
• Completo
• Integrato con gli strumenti di sviluppo
• Aggiornato
• Facile da usare
• Estendibile e personalizzabile
11

12. Collection e Team Project
• Abbiamo creato un Team Project per tutta l’area
di produzione
• All’interno del Team Project abbiamo creato tanti
Team quanti sono i reparti di sviluppo
12

13. Aree e product backlog
• Abbiamo utilizzato le aree per assegnare i
progetti ai singoli team (nel nostro caso un
team gestisce normalmente più progetti)
• Attraverso le aree il product backlog viene
filtrato per team, abbiamo quindi una sorta di
team backlog
13

14. Il calendario degli sprint
• Ogni team ha i suoi sprint
• Uno sprint dura 2 settimane
• Il nome è un progressivo,
ovvero Sprint n
• I team sono tutti sincronizzati,
si parte lo stesso giorno e si
finisce lo stesso giorno
14

15. Sprint planning
• Le stime dei PBI vengono fatte in ore per essere
più precisi nel forecasting
• Il planning dello sprint comincia gli ultimi
giorni di quello precedente con discussione e
stima dei PBI in cima al backlog
• La mattina del primo giorno si chiude il
planning con la definizione dei task
15

16. Bug
• Tracciamo anche chi lo ha scoperto
16

17. Task
• Salviamo sia il tempo stimato iniziale che il
tempo effettivo utilizzato per portare a termine
il lavoro
17
Da completare
Sovrastimato
Sottostimato

18. L’importanza delle stime
• Riuscire a stimare correttamente un’attività è un fattore
determinante per poter rispettare gli impegni presi in fase
di planning
• Per aiutarci nelle stime possiamo:
• Far fare la stima a più componenti del team (stile planning poker)
• Confrontare stime fatte in precedenza
• Non fare task troppo grandi
• Non portare nel backlog PBI non ancora analizzati
• Utilizzare dei task esplorativi che permettano di essere più
confidenti nella stima
18

19. Definition of Done
• Ogni team definisce quali attività devono essere
svolte per considerare chiuso un PBI, come ad
esempio:
• Sviluppo della funzionalità
• Unit testing
• Documentazione
• Superamento delle regole di stile (vedi StyleCop)
• Può cambiare nel tempo
19

20. Impediment
• Attività che impedisce il regolare svolgimento
dei compiti decisi in fase di pianificazione
• Possono essere:
• Richieste di nuove funzionalità o di modifiche a
funzionalità esistenti
• Bug o richieste di supporto
• Attività esterna al team che blocca un task
attualmente in progress
20

21. Gestire gli impediment
• Abbiamo creato una struttura gerarchica per
organizzare e raccogliere gli impediment:
• Impediment della produzione
• Impediment del teamA
• Impediment del team A per lo sprint 1
• Impediment del team A per lo sprint 2
• Impediment del teamB
• Impediment del team B per lo sprint 1
• Impediment del team B per lo sprint 2
21

22. Inserire un nuovo impediment
• Partiamo dal presupposto che sia già stato
discusso e che debba essere fatto nello sprint
corrente:
1. Creiamo un PBI con la motivazione
2. Creiamo i task necessari per portarlo a termine
3. Lo leghiamo come figlio dell’impediment del team
per lo sprint corrente
22

23. Team member «a consuntivo»
• Creiamo un PBI con effort uguale alla capacità
del team member per lo sprint
• Creiamo un task fittizio con le stesse ore del PBI
• Quando comincia lo sprint:
• Il team member crea per ogni attività un nuovo task
con le ore dedicate
• Scala le ore dedicate ai nuovi task da quello fittizio
• A fine sprint il task fittizio viene rimosso
23

24. Il Burndown
• Se non riesco a portare a termine tutte le
attività le lascio nello sprint e le vado a
rimuovere o spostare all’inizio di quello
successivo
24

25. Sprint Retrospective
• Imparare dai propri errori
• Pianificare le azioni correttive già dallo sprint
successivo
• Rendere il miglioramento misurabile
• Coinvolgere e contaminare gli altri team
25

26. Motivazione
26

27. La motivazione cala
• Appena si finisce in rosso
• Quando si sbagliano le stime
• Quando non si raggiunge l’obiettivo dello sprint
• Quando esce un bug in produzione
• Quando si ricevono troppe interruzioni*
27
* Programmers interrupted: http://blog.ninlabs.com/2013/01/programmer-interrupted/

28. La motivazione cresce
• Quando si riesce a portare a termine tutte le
attività di uno sprint
• Quando si centrano le stime
• Quando trovo quello che ho rilasciato viene
utilizzato e migliora il lavoro di qualcun altro
28

29. In conclusione
(allo stato attuale)
29

30. -
• Il costo iniziale è alto e se non si contaminano
le altre aree diventa pesante da sostenere
• Se si smette di migliorare si peggiora
• Si corre il rischio di adottare lo strumento al
posto della metodologia
• Alle prime difficoltà non è facile resistere alla
tentazione di prendere delle scorciatoie
30

31. +
• Col tempo si crea una ritualità che condiziona
la settimana lavorativa
• In ogni momento posso sempre sapere che cosa
devo fare
• L’avere un obiettivo per lo sprint è motivante
• Il raggiungerlo lo è ancora di più
31

32. 29
Thank You! MANUEL SCAPOLAN
website: www.manuelscapolan.it
twitter: manuelscapolan
e-mail: info@manuelscapolan.it