Agile project management 1 giornata - board game - v2

Agile Project Management Un giornata di workshop con il gioco Agile: The Board Game e non solo

Giulio Roggero - Scrum Master,PMI-ACP, PMP, Prince2

E’ un processo Agile?

Requisito 1

Requisito 2

Requisito 3

Requisito 4

Analisi Design Sviluppo Test Rilascio


Requisito 1

Requisito 2

Requisito 3

Requisito 4


Sviluppo Test

Sviluppo Test

Iterazione 2

Iterazione n


Requisito 1

Requisito 2

Requisito 3

Requisito 4


Design Sviluppo Test

Design Sviluppo Test

Iterazione 2

Iterazione n


Refactoring

Refactoring

Refactoring

Analisi Design Sviluppo Rilascio

Analisi Design Sviluppo Refactoring Rilascio



Requisito 1

Requisito 2

Requisito 3

Requisito 4

Test

Test

Test

Test


Refactoring

Refactoring

Refactoring

Test Analisi Sviluppo Rilascio

Test Analisi Sviluppo Refactoring Rilascio



Requisito 1

Requisito 2

Requisito 3

Requisito 4

Design

Design

Design

Design

Benvenuti al CORSO AGILE!

Temi

• I Introduzione generale: framework e processi per il Project Management.

• Lean e Agile: valori e principi. Gemba. Definition of Done. Time Boxing. Kaizen. Kanban.

• Scrum: Lean, Agile applicati. Le tre gambe di Scrum. Overview, Ruoli e Workflow.

• XP: Ruoli, Attività e Pratiche.• Stimare Costi e Tempi: User Stories, Story Point e Poker Game.• Risk Management e Communication Management• eXtreme Programming: Pair Programming, TDD, Refactoring, CI• Da PMP ad Agile: un modo pratico per introdurre Agile nel team.• Tool Software per Agile: Wiki, Issue Tracker e Continuous

Integration.• Agile Scaling. Agile in micro-team. Le certificazioni Agile.

Chi sei?

Cosa fai?

Cosa farai dopo il corso?

Cosa ti piacerebbe fare tra cinque anni?

Cosa ti aspetti dal corso?

Approcci di PM - Predittivo

Alcuni esempi•Waterfall•Spirale•Unified Process (RUP)•PMBoK

Predittivo – Si / No

Pro• Logico e sensato• Pianifica prima di fare• Mantiene una

documentazione scritta• Segue un piano• Mantiene le attività

organizzate

Contro• Sono coinvolte le

persone!– Cambiano idea– Difficile esprimere e

comunicare l’intangibile e i bisogni

– Empatia• Prodotto solo alla fine

Approcci di PM - AdattivoAlcuni esempi

•XP•Scrum•FDD•TDD•Lean

Adattivi

Predittivi

Adattivo – Si / No

Pro• Segue le persone• Apporta valore• Aiuta la

collaborazione• Riduce le barriere

Contro• Difficile da

introdurre• Senza uno sponsor

non decolla• Difficile coinvolgere

il cliente

Quale scegliere?

Negli ultimi 30 anni si sono

alternati approcci differenti

WaterfallRUP

XP

Kanban

Agile

Tutti hanno avuto successi e insuccessi

Problemi nei progetti

• Mancanza della gestione del cambiamento dei requisiti• Cattiva comunicazione• Inadeguatezza del Team• Requisiti non ben definiti• Stime non accurate• Mancanza di un piano di gestione dei Rischi• Cattiva definizione di cosa significa “Finito”• Non dedicare il giusto tempo alla gestione del progetto• Mancanza della conoscenza di come si gestisce un

progetto• Essere sempre troppo ottimisti!

Ottimismo!

COCOMO II

SOFTWARESEPTEMBER/OCTOBER 2000 (Vol. 17, No. 5) pp. 14-

170740-7459/00/$26.00 © 2000 IEEE

Published by the IEEE Computer SocietySafe and Simple Software Cost Analysis

Fattori che influenzano la produttività nel

software su prj da 100 KSLOC.

Migliorare i sw tools tipicamente migliora del

50% la produttività.

Migliorare il team il 353%!

Principali fattori di Successo

Team + Sponsorship + Cliente

Definizione di Successo

Successo

Il valore dipende dal contesto del progetto ed è definito con il Cliente

Il successo in Agile e’

misurato sul valore

generato dal progetto

I requisiti non si toccano! Il valore non si tocca!

Da PM ad Agile

Cercate produttività?Agile non fa per voi!

Agile è per:•Apportare facilmente cambiamenti•Creare velocemente valore•Aumentare la trasparenza

Agile non e’

•Poca o nessuna documentazione•Requisiti di massima•Nessuna pianificazione•Nessun controllo di progetto•Fare e poi pensare•Un waterfall interattivo

Agile Manifesto

www.agilemanifesto.org• Individuals and interactions

over processes and tools• Working software

over comprehensive documentation• Customer collaboration

over contract negotiation• Responding to change

over following a plan

http://www.agilemanifesto.org/

Tools e Processi

• Quale tool usiamo per tracciare lo stato del progetto?

• Che processo adottiamo per rilasciare una versione?

• Come tracciamo i bugs?• Come tracciamo le ore su un progetto?• Come misuriamo le performance delle persone sul

progetto?• Come formalizziamo con il cliente la chiusura del

progetto?

• Tutte domande che vi siete fatti almeno una volta …

• … che soluzioni avete trovato e adottato?

Individui e Interazioni

Comunicare, comunicare, comunicare!• Tanti documenti, anche ben scritti e

formalizzati non servono se non sonoletti e compresi

• Presentazioni senza coinvolgere i partecipanti non sono efficaci se non si ha la sicurezza che il messaggio sia compreso

Team building• Pensare “al proprio orticello” non aiuta il progetto• Molto spesso lavori complessi hanno bisogno di più occhi• Lavorare in un ambiente armonioso aiuta il progetto

Ottimizzare il globale e non il singolo• Misurare il singolo spinge a non collaborare• Non è detto che se tutti sono ottimali il progetto è

ottimale

Esercizio

camminiamo

Agile Manifesto







Documentazione?

In un progetto software qual’è il documento che rispecchia meglio la realtà?

• La documentazione è importante, molto importante

• E ’ importante se è vera• Il progetto evolve la documentazione

non sempre!• E’ un costo molto alto tenere

aggiornata la documentazione

Software!

Software funzionante? Si/No/Forse/A volte si/Solo in questo caso no!

Agile Manifesto







Contratto

Firma e approvazione 16/06/2011

• Oggetto del contratto• Elenco Specifiche: A, B, C• Dettaglio Specifiche• Assunzioni e Limiti• Tempi: 3 mo• Costi: 100.000$• Modalita’ di approvazione del prodotto/servizio• Pagamento• Diritti di recesso• Penali

… e dopo un mese?

Firma e approvazione 16/06/2011

e ora chi paga?

• Oggetto del contratto: OK• Elenco Specifiche: A, B, C, D, E• Dettaglio Specifiche: in realtà C è D+E• Assunzioni e Limiti• Tempi: 4 mo• Costi: 120.000$• Modalita’ di approvazione del

prodotto/servizio• Pagamento• Diritti di recesso• Penali

Esercizio

Come procedete?• 10’ per discussione• 5’ per gruppo di incontro con il signor White

• L’azienda My Oil S.p.A. deve aggiornare il sistema di monitoraggio delle trivellazioni petrolifere secondo la norma che entrera’ in vigore fra un mese da oggi

• Il signor White è l’incaricato di My Oil per fornirvi tutte le informazioni necessarie, l’importante è che il nuovo sistema sia operativo in tutte le 100 sedi entroun mese

• Non ci sono limiti di budget

Esempi di contratti “Agili”

•A forchetta minima e massima (PERT aiuta)

•A condivisione del rischio: 50%-50% sul budget risparmiato

•A bande: si concorda il budget, si fissa di volta in volta lo step a prezzo fisso

•Time and material classico

Agile Manifesto







Quindi? Piano o Valore?

Una pianificazione è fondamentale

Ma la pianificazione deve poter variare senza impattare sul progetto

Rispondere ai cambiamenti permette di tenere sotto controllo il vero progetto:

•Quello che apporta valore •Soddisfa le aspettative

Agile è pianificazione con un controllore retroattivo

VS

StoriaJeff Sutherland introdusse nel 1995 l’idea che

i team si muovessero sull’orlo del caos e si auto-controllassero come succede in natura.

Ken presento’ con Jeff al OOPSLA95 il primo paper su SCRUM.

L’ultima edizione e’ del gennaio 2011 http://jeffsutherland.com/ScrumPapers.pdf

Gli autori affermano che:“Scrum non e’ una metodologia o un processo formale ma un algoritmo di compressione delle migliori abitudini in ambito dello sviluppo del software osservate in tutto il mondo negli ultimi 50 anni”

jeffsutherland.com

kenschwaber.wordpress.com

http://jeffsutherland.com/ScrumPapers.pdf

Scrum Roles

Product Owner

Cosa fa Massimizza il valore di

ogni Sprint Decide quali sono gli item

piu’ importanti di ogni Sprint

Puo’ cambiare le priorita’ di volta in volta

Raffina i backlog Prende le decisioni che

impattano sul prodotto

Cosa non dovrebbe fare Il project manager Sviluppare Decidere tecnologie e

processi

Team (pigs)

FOCUS!

7 persone ± 2Cross-funzionale: non solo sviluppatori ma anche tester,

interaction design, content managers e tutte le figure professionali necessarie per sviluppare un prodotto di valore

Preferibilmente co-located: riduce i tempi di comunicazione e migliora i rapporti del team

Full-time sul progetto: le “abitudini” di Scrum prevedono una dedizione al progetto giorno per giorno e un ritmo sostenibile difficilmente da parte di membri del team “multi-tasking”

Team (pigs)

Cosa fa Sviluppa il prodotto

indicato dal product owner Da idee al Product Owner

su come migliorare il prodotto

Si auto-organizza all’interno dello sprint

Tiene traccia degli item di backlog completati

Stima gg per gg il backlog rimanente

Cosa non dovrebbe fare Implementare item che non

sono nell sprint backlog Aggiungere item allo sprint

backlog Cambia spesso i suoi

membri

Stakeholders (chickens)• Sono tutti gli appartenenti all’organizzazione che possono essere impattati dal progetto.• Possono partecipare ai meetings ma senza diritto di parola

Le persone del team

belbin.com

• “Plant”: creativa e brava a risolvere i problemi in modi non convenzionali. Uno per team.

• Monitor Evaluator: il logico, prende decisioni imparziali e pesa in modo razionale le opzioni del team.

• Co-ordinators: aiuta a mantenere il focus del team, fa emerge i membri del team e delega in modo appropriato.

• Resource Investigators: migliora i processi e porta la voce del team fuori.• Implementers: il motore che pianifica strategie efficaci e le porta a

compimento.• Completer Finishers: intervengo alla fine per completare il task

rimuovendo errori e ottimizzando la qualita’.• Teamworkers: sono il collante del team, si identificano con il team e

aiutano nel lavoro di squadra.• Shapers: il leader, fa in modo che il team non perda focus e spinta. • “Specialist”: ha una conoscenza molto specifica nella key area del progetto.

emerged.

Scrum Master

Favorire l’auto-organizzazione!

•Una persona con backgroud differenti, es: Engineering, Testing, Quality Control, Product Management, Project Management

•Energica e umile•Dedicata full-time su grossi progetti•In Team piccoli può essere un membro

del Team•ATTENZIONE PM o Team Leaders che

diventate Scrum Master: dovete cambiare molto il vostro approccio,è un lavoro completamente diverso!

Scrum Master

Cosa fa Tutor del team Aiuta Team e PO ad avere

successo nel progetto Protegge il Team dai fattori

esteri Facilita le relazioni Toglie gli impedimenti E’ al servizio del Team Aiuta a capire il flow-value

dello Scrum

Cosa non dovrebbe fare Il project manager Il team leader Il product owner Assegna Task Dice alle persone cosa fare

Scrum roles – note importanti

• Scrum Master e Productr Owner NON possono essere lo stesso individuo

• E il Project Manager? NON ESISTE!• I ruoli di PM sono divisi tra i tre ruoli di Scrum:

• Scrum Master• Product Owner• Team

• Un cambio di approccio è fondamentale!

Passare da assegnare attività everificare lo stato (SAL) a Aiutare, supportare, fare coaching e mentoring,

rimuovere gli impedimenti Essere al servizio del team!

Scrum Artifacts

Product Backlog

• Lista di features con priorita’• Roadmap del prodotto• Responsabilita’ del Product Owner• Tutto quello che e’ nel Product backlog e’ il

prodotto• Quello fuori NON ESISTE!• Il product backlog evolve nel tempo:

• Priorita’• Descrizione e dettagli (raffinamento del Product

Backlog)• Stime

• NE ESISTE UNO SOLO

Esempio – Product backlog

Cosa include

•Funzionalità/requisiti cliente•Miglioramenti

tecnici/tecnologici•Esplorazioni su nuovi aspetti

del prodotto/del software•Bugs conosciuti

Come viene descritto• Scrum non definisce un metodo• Le user stories sono uno dei metodi piu’

usati• Si possono usare anche Work Breakdown

Structure (WBS)• A volte viene creato un Release Backlog

come sottoinsieme del BP per definire l’ambito della release del prodotto

User Story

"As a <role>, I want <goal/desire> so that <benefit>"

Una user story su excel

alarm.search

"As a User I want to search alarms by name, type, application, date, range of dates and free text search so that I can analyze problems on the system"

filters are automatically added looking at column names and can be combined in OR and AND (like workflow in console)

TBD VH 5

User Story ID Front Back Business Value

Priority

Estimated Story Point

Sprint Backlog• L’insieme di task da completare in uno sprint• Uno o piu’ task sono relativi a un item del

Product Backlog• Ogni task ha una stima in ore• Ogni task e’ assegnato a una persona che lo

richiede in modo volontario

Definition of Done

• Definizione di completato• Tipicamente e’ una regola di backgroud di tutto il progetto• Es: una feature si considera completata se:

• Codificata• Gli unit test sono tutti passed• Il codice e’ commentato• La funzionalita’ e’ utilizzabile dall’utente e soddisfa i requisiti di

usabilita’ definiti nella sua user story• E’ integrata nel setup/ambiente di deploy• E’ taggata sotto repository• Ha la documentazione utente

La definition of done NON deve variare di volta in volta, e’ fissa! Una volta che e’ decisa si segue sempre quella.

PSPI

Chiudere sempre secondo la Definition of Done concordata!

Potentially Shippable Product Increment• Ogni Sprint idealmente finisce con un

prodotto potenzialmente rilasciabile• MAI lasciare le cose a meta’: meglio

chiudere una cosa in meno e spostarla nel prossimo sprint che lasciare le cose aperte a fine sprint

Motivazioni del PSPI

•Permette di raccogliere i feedback velocemente

•Riduce i rischi (bugs non alla fine)

•Aiuta il cliente finale a prendere confidenza del prodotto

•Migliora l’apprendimento

Previsioni e Stime

1.Una previsione metereologica e’ valida 1-2 giorni

2.Al terzo giorno e’ gia’ molto incerta

3.Oltre il terzo e’ una speculazione

Scrum Planning

Pianificare in Agile???•Si pianifica di piu’ e piu’ spesso!•Me tenere sotto controllo il flusso del valore (Value Flow) la pianificazione e la stima sono fondamentali

•Riflettere sulle sitme a posteriori aiuta a stimare meglio la volta dopo

Stime• Il Product Owner e’ responsabile per assegnare

il business value di ogni item del BP• Il Team e’ responsabile per stimare l’effort di

sviluppo di ogni item del PB• Il Team e il Product Owner fanno un’analisi di

rischio• Lo Scrum Master aiuta in questa fase

• Scrum non definisce tecniche di stima• Story Points e Ideal Time• Range Estimation• PERT

Stime – Planning Poker• Ogni membro del team si crea delle carte con la

sequenza di Fibonacci: 1, 2, 3, 5, 8, 13, 21, BIG• Le user stories sono visibili a muro o sul pavimento o su

un tavolo• Lo scrum master sceglie una User Story rappresentativa

della quale si conoscono abbastanza dettagli e che sia piccola

• Il team concorda che quella vale 1• Lo Scrum Master scegli un’altra User Story• Ogni membro del team di nascosto sceglie una carta• Quanto tutti hanno scelto scoprono la carta• La maggioranza vince, si discute sulle differenze se ci

sono disaccordi e si rivota• Si itera il processo fino a quando non sono finite le User

Stories selezionate

Eserciziowww.agilemanifesto.org

I…and i… over p…and t..W… s… over d…C… c… over c…R.. To c… over p…

Esercizio

Creare il product backlog con

Agile: The Board Game

Lo SPRINTTimeboxing e non solo

Il tempo non basta mai

sett 1 sett 2 sett 3 sett 4 sett 5

Done

Done

Done

Funziona?

Pro Si pensa di essere piu’

produttivi Diversificare aiuta a non

annoiarsi Si puo’ star dietro a piu’

clienti Si possono sfruttare i

“tempi morti”

Contro Sotto stress Ore piccole Tempo perso nel cambio di

contesto

… e se fossimo monotasking?

sett 1 sett 2 sett 3 sett 4 sett 5

Done

Done

Done

Pomodoro Technique

www.pomodorotechnique.com

• Scegli il task da completare• Imposta il Pomodoro a 25 minuti

(Il Pomodoro è il timer)• Lavora sul task senza distrazioni o

interruzioni fino a che il Pomodoro non suona, dopo metti una spunta nel tuo foglio della To Do List

• Prenditi un piccolo break (5 minuti vanno bene)• Ogni 4 pomodori prenditi una pausa un po' più

lunga

L’importanza del time-boxing•Aiuta a concentrarsi su una singola attivita’•Da quell’adrenalina positiva per portare a termine un

compito•Permette di semplificare i task•Riduce il lavoro inutile•Incrementa la concretezza (stare con i piedi per terra)•Permette di avere un ritmo nel lavoro (non ci sono piu’

riunioni senza fine che finiscono con un ‘?’)•Aiuta a trovare accordi con se stessi e con il team•Permette di pianificare meglio le attivita’ e stimarne il

costo

Sprint Planning – Part 1

• Durata: 2-4 ore• Partecipanti: Product Owner, Scrum Master, Team• Strumenti: Product Backlog a muro, Definition of

Done• Obiettivo: estrazione degli item per lo sprint

Sprint Planning – Part 2

• Durata: 2-4 ore• Partecipanti: Scrum Master, Team• Strumenti: Sprint Backlog a muro• Obiettivo: definizione e stima dei task per lo Sprint

Backlog

Running the Sprint

• Durata: 1-4 settimane (2 consigliate)• Partecipanti: Product Owner,

Scrum Master, Team• Strumenti: Product & Sprint Backlog a muro, Definition of Done• Attivita’:

• Sviluppo• Rifinitura del Product Backlog (5-10%)• Ri-Stima degli item del backlog• Ri-Prioritizzazione del product backlog• Analisi di dettaglio

Daily Meeting

• Durata: 15’, ogni gg, alla stessa ora, nello stesso posto (possibilmente in piedi davanti allo Sprint Backlog)

• Partecipanti: Scrum Master, Team• Strumenti: Sprint Backlog a muro• Attivita’:

• Ogni team member dice: cosa ha fatto, cosa fara’, che impedimenti ha

• Si fissano le riunioni

Sprint Review

• Durata: 2-4 ore• Partecipanti: Product Owner, Scrum Master, Team• Strumenti: PSPI• Obiettivo: validare con il Product Owner la chiusura

dello Sprint

Agile metricsMisurare in agile

Quanto?

Misurare solo il necessarioe non di più!

Vale lo stesso concetto di semplicità che si usa per scrivere

il codice

Tenere lo storico delle misurazioni

Effetti collaterali di metriche errate

Misura del progresso

“Our highest priority is to satisfy the customer through early and

continuous delivery of valuable software”

Il working software è la principale misura del progresso

Running Tested Features

Misura diretta del risultato

Se non cresce c’è un problema

Se cresce è motivante per il team

1 2 3 4 5 6 7 8 9 10 11 12 13 140

2

4

6

8

10

12Running Tested Features

RTF

Iteration

Feat

ures

Misurare il business value

RevenueCost savingsMarket share

Customer relationsReputation

…

Financial value

Baseline Release 1 Release 2 Release 3 Release 40

20000

40000

60000

80000

100000

120000

140000

160000

180000

Hard Value Delivered per Release

Total RevenueTotal CostsProfitabilityProfitability Change

Un’idea da Lean Startup

Vado a fare un test sperimentale

Al 50% degli utenti fornisco il prodotto vecchio

All’altro 50% fornisco il prodotto con una nuova feature

Misuro entrambi

Se ci sono variazioni allora l’introduzione della feature

ha influito sul business, altriumenti è indifferente

split-test

Report in Scrum• Product Burndown Chart• Sprint Burndown Chart• Test reports• Architecture diagram status

Burn down chart

Velocity = 43 points in 10 days

Velocity

Velocity (misura del team per il team)

Osservazione empirica della corrente capacità del team di svolgere il lavoro

Quantità di lavoro prodotta in un dato periodo

Molto utile per prevedere quando verrà completato un lavoro per una derminata

quantità di funzionalità

Utile per stimare quanti requisiti saranno rilasciati entro

una data prefissata

Velocity attenzione a…

Basata sulle metriche relative ad un particolare team

La dimensione è definita dal team stessoStories, points, ideal time

Non utile al di fuori dell’ambitoSolo per un dato team in un dato progetto!

Prende in cosiderazione solo il lavoro completato

Il team è contento se ha una velocità alta e mantenuta Non solo questo fattore è importante!

Esercizio

Rilasciare con Scrum il primo PSPI


KAIZENMiglioramento continuo

Lean

•Ha origini dal TPS (Toyota Production System) sviluppato tra il 1948-1975•TPS si basa su

• Continuo miglioramento - Kaizen• Rispetto per le persone• Una vision a lungo termine• Il giusto processo crea i giusti risultati• Creare valore attraverso lo sviluppo delle persone• Risolvere subito i problemi

•Ha due pilastri• Just-in-time• Automation

•Due scopi• Ridurre gli sprechi• Dare valore subito al cliente

Value Stream Mapping

Fresare Saldare Verniciare Assemblare

10 maggiori cause di spreco

Qualsiasi cosa che non aggiunge valore al clientefinale e’ considerata uno spreco:

1. Produzione di cose non necessarie2. Attesa3. Delegare il lavoro4. Processi non necessari5. Lavoro non completato6. Cambio continuo di attivita’7. Evidenziare i difetti alla fine del progetto8. Team che non lavora al suo potenziale9. Perdita di conoscenza10.Assecondare i desideri piu’ che le necessita’

razionali

Inbox

Google ha proposto la priority inbox e funziona!Oppure cancellate la posta che non vi serve

La posta non letta e’ un esempio di spreco:• Aumento consistente di giorno in giorno

della posta non letta (“teoria del vetro rotto”)

• Mancanza di evidenza dell’importanza dei vari messaggi

• Maggior tempo per discriminare la posta importante da quella meno importante

• Lentezza del client di posta!

Title: What you are talking about.Background

Current Situation

Goal

Analysis

Recommendations

Plan

Follow - up

Why are you talking about it?

Where do we stand?

Where we need to be?What is the specific change you want to accomplish now?

-What is the root cause(s) of the problem?-

What is your proposed countermeasure(s)?

What activities will be required for implementation and who will be responsible for what and when?

How we will know if the actions have the impact needed? What remaining issues can be anticipated?

A3 -Verble/Shook

What’s the problem?

Esercizio

Sprint Retrospective

• Durata: 1.5-3 ore• Partecipanti: Scrum Master, Team• Strumenti: Sprint Backlog, PSPI• Obiettivo: evidenziare le cose positive dello sprint e

ricercare i motivi degli errori, metabolizzare il processo

Com’è organizzato

• Impostare il meeting – 5% del tempo• Raccogliere i dati – 30-50% del tempo• Approfondire i motivi – 20-30% del tempo• Decidere cosa fare – 15-20% del tempo• Chiudere la retrospettiva – 10% del tempo

Esempio di meeting retrospective

• Impostare il meeting – ESVP (Esploratore, Shopper, Vacanziere, Prigioniero)

• Raccogliere i dati – Timeline• Approfondire i motivi – 5Whys• Decidere cosa fare – SMART Goals

(deve essere: Specific, Measurable, Attainable (raggiungibile), Relevant, Timely)

• Chiudere la retrospettiva – ROTI (Return of Time Invested) (0-5)

Maggiori dettagli su Agile Retrospectives (Derby, Larsen)

Esercizio

Fare il meeting retrospective


XP, LEAN E KANBANnon solo SCRUM

Limiti di Scrum

• Si tende a pianificare solo lo sprint successivo.• Si tende ad isolare il team dal management.• Si tende ad applicare prima di avere software di

qualita’ e testato in modo automatico.• Scrum non dice come fare le cose• Si pensa che i team auto-organizzati, da soli,

possano migliorare il processo. Non basta! Il middle-management ha un ruolo findamentale.

• La colocation e il single project sono molto utopici.

XP - eXtreme programming

• Pair Programming: sviluppare le parti piu’ critiche insieme sullo stesso pc condividendo le scelte e il codice

• Test Driven Development: scrivere il test e poi sviluppare la funzionalita’

• Continuos Integration: integrare in modo continuo tutti i componenti software riducendo il rischio di integrazione posticipata

• Refactoring: rivedere periodicamente il codice migliorandolo e rendendolo piu’ mantenibile

• Collective Code Ownership: il codice sorgente e’ di tutti e tutti sanno metterci le mani

• Simple design: tenere sempre il sistema semplice

Pratiche XP

WIP

Ridurre il Work In Progress aiuta a:•Aumetare la qualita’ del lavoro finito•Semplificare processi e procedure•Aumentare la reattivita’ a richieste spot•Migliorare la vita in azienda

Kanban Board

- WIP limitato- Persone assegnate solo quando server- Continua revisione priorita’- Piu’ progetti insieme, anche di diversa natura

Questa e’ molto molto semplice. Tipicamente si mettono le fasi di progetto e le code di attesa.

Altro esempio di Kanban board

Una ricetta per Kanban

da “Kanban: Successful Evolutionary Change for Your Technology Business”

• Concentrarsi a rilasciare sempre software di Qualità: TDD, Code Inspection, Architecture and Design Patterns e Software Factories

• Ridurre il Work-in-Progress (WIP)• Rilasciare spesso

• Bilanciare la domanda di nuove funzionalità con il lavoro che si riesce a smaltire

(Throughput)• Dare priorità alle cose

• Ridurre le cause di variabilità migliorando la predicibilità

http://www.slideshare.net/marcusoftnet/kanbanboards

Scrum Scaling

Scrum di Scrum• Ogni team lavora con un suo Scrum• Ogni settimana un membro del team si

incontra con gli altri membri degli altri team per fare un Daily meeting

• Puo’ essere scalato in modo indefinito• I rappresentanti possono cambiare di volta in

volta

Team Virtuali

• E’ possibile applicare Scrum da remoto su team dislocati geograficamenti

• E’ difficile farlo funzionare• I tools di comunicazione sono fondamentali, devono

permettere un editing live degli oggetti (es: Google Docs)

• Chat, Call e Video Call devono essere sempre accessibili

• Il repository del codice sempre condiviso• I server di test e di continuos integration hanno un

ruolo molto importante perche’ evidenziano i problemi che di solito non emergono naturalmente nei team co-located

Cosa evitare

Feature Teams! SI’!

• Fare Scrum Team per componenti• Il codice e’ di tutti, non del Team singolo,

NO CODICE PRIVATO• Non esistono gruppi speciali: il gruppo

degli architect, il gruppo dei designer ecc I gruppi sono Cross Funzionali

Introdurre Agile in Azienda

Introdurre una metodologia Agile in Azienda

Fasi dell’introduzione

Come aiutare• Fare un A3 della situazione con Value Stream

Mapping• Affrontare un problema alla volta• Non cercare di ottimizzare tutto subito• Avere una spinta molto forte dai top-manager• Cercare consenso dal basso• Introdurre un Changing Agent• Chiedere la consulenza di un Coach. Il Coach e’

una persona che riduce di molto la fase di caos e poi se ne va.

Conclusioni

La chiusura di un progettoRaccogliere le lesson learnedCelebrare il successo e imparare degli erroriNon disperdere il know-how

http://www.svgopen.org/2008/papers/47-Real_time_monitor_in_SVG_a_use_case_in_Machining_Technology_HMI/

Le certificazioni Agile•SCRUM -

www.scrumalliance.org• Master• Practitioner• Coach• Trainer

•PMI-ACP - www.pmi.org•Atern DSDM - www.dsdm.org

http://www.pmi.org/

http://www.dsdm.org/

Links e tools utili

casi d'uso: www.scrumalliance.org/resources?tag=experience+reportlibri consigliati: www.scrumalliance.org/pages/scrum_student_resourcespresentazioni: www.scrumalliance.org/resources?tag=Presentationsdocs: www.scrumalliance.org/resources?tag=2010+Shanghai+Gatheringfumetti: www.implementingscrum.com/section/blog/cartoons/contratti: agile rfp - www.methodsandtools.com/archive/archive.php?

id=84agile manifesto: agilemanifesto.org/iso/it/principles.htmlpmi: pmi.orglean: www.lean.orgscrum alliance: www.scrumalliance.orgpecha-kucha: www.pecha-kucha.org/

Letture consigliate

Progetti Complessi Persone

Mercato e Requisiti dinamici

Controllare il Progetto

Motivare il Team

Prodotti/Servizi di Qualita’ e Valore

AGILE!

Agile quando?

Riferimenti

Giulio Roggero

[email protected]

http://it.linkedin.com/in/giulioroggero

Diritti

Tutti i cartoon sono di Michael Vizdos - www.implementingscrum.com.

Potete usare questo materiale come meglio ritenete opportuno secondo la licenza Creative Common Attribution-ShareAlike 3.0http://creativecommons.org/licenses/by-sa/3.0/

Trovate altro materiale su http://www.slideshare.net/GiulioRoggero/

I giochi qui utilizzati sono di mia concezione, li trovate Open Source:•http://code.google.com/p/agile-the-board-game/•http://code.google.com/p/a3-airplane-game/feeds

http://www.michaelvizdos.com/

http://www.michaelvizdos.com/

http://www.implementingscrum.com/

http://creativecommons.org/licenses/by-sa/3.0/

http://www.slideshare.net/GiulioRoggero/

http://code.google.com/p/agile-the-board-game/

http://code.google.com/p/a3-airplane-game/feeds

Agile project management 1 giornata - board game - v2

Business

Transcript of Agile project management 1 giornata - board game - v2