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: [email protected]
Top Related