ALM Saturday

Team Foundation Server & SCRUM

Pordenone - 5 Ottobre 2013

Manuel Scapolan

Lessons Learned

Se capita che…

2

• Cambiano le specifiche a pochi giorni dal

rilascio in produzione

3

http://thecodinglove.com

4

• Si inizia subito a sviluppare senza aver fatto

alcuna analisi

http://thecodinglove.com

• Ti comunicano che la funzionalità che hai

appena sviluppato non verrà mai usata

5

http://thecodinglove.com

E’ ora di cambiare

6

Cosa vogliamo

• Produrre software di qualità

• Soddisfare i nostri clienti

• Rispettare i tempi di consegna

• Rispondere velocemente ai cambiamenti

• Migliorare continuamente

7

Scrum è la risposta

8

Come iniziare?

9

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

Team Foundation Server

• Completo

• Integrato con gli strumenti di sviluppo

• Aggiornato

• Facile da usare

• Estendibile e personalizzabile

11

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

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

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

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

Bug

• Tracciamo anche chi lo ha scoperto

16

Task

• Salviamo sia il tempo stimato iniziale che il

tempo effettivo utilizzato per portare a termine

il lavoro

17

Da completare

Sovrastimato

Sottostimato

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

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

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

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

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

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

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

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

Motivazione

26

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/

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

In conclusione

(allo stato attuale)

29

-

• 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

+

• 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

29

Thank You! MANUEL SCAPOLANwebsite: www.manuelscapolan.ittwitter: manuelscapolane-mail: info@manuelscapolan.it