TFS and Scrum - Lessons Learned

739 views

Published on

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

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
739
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
10
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

TFS and Scrum - Lessons Learned

  1. 1. ALM Saturday Team Foundation Server & SCRUM Pordenone - 5 Ottobre 2013 Manuel Scapolan Lessons Learned
  2. 2. Se capita che… 2
  3. 3. • Cambiano le specifiche a pochi giorni dal rilascio in produzione 3 http://thecodinglove.com
  4. 4. 4 • Si inizia subito a sviluppare senza aver fatto alcuna analisi http://thecodinglove.com
  5. 5. • Ti comunicano che la funzionalità che hai appena sviluppato non verrà mai usata 5 http://thecodinglove.com
  6. 6. E’ ora di cambiare 6
  7. 7. Cosa vogliamo • Produrre software di qualità • Soddisfare i nostri clienti • Rispettare i tempi di consegna • Rispondere velocemente ai cambiamenti • Migliorare continuamente 7
  8. 8. Scrum è la risposta 8
  9. 9. Come iniziare? 9
  10. 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. 11. Team Foundation Server • Completo • Integrato con gli strumenti di sviluppo • Aggiornato • Facile da usare • Estendibile e personalizzabile 11
  12. 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. 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. 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. 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. 16. Bug • Tracciamo anche chi lo ha scoperto 16
  17. 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. 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. 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. 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. 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. 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. 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. 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. 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. 26. Motivazione 26
  27. 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. 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. 29. In conclusione (allo stato attuale) 29
  30. 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. 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. 32. 29 Thank You! MANUEL SCAPOLAN website: www.manuelscapolan.it twitter: manuelscapolan e-mail: info@manuelscapolan.it

×