Agile Project Management

Agile Project Management

Metodologie nuove per gestire progetti complessi

Sunday, February 5, 12

Wallenstein VS Giants


Wallenstein

Ci troviamo nel 1618, alla vigilia della Guerra dei Trent’Anni, i cinque più potenti mercenari dell’epoca si sfidano nella conquista dell’europa centrale.

Vince chi totalizza piu’ punti•1 punto viene assegnato per ogni territorio in proprio possesso.•1 punto viene assegnato per ogni edificio costruito sui territori posseduti.•1 punto viene assegnato al giocatore con più Mercati in ognuna delle cinque regioni.•2 punti vengono assegnati al giocatore con più Cattedrali in ognuna delle cinque regioni.•3 punti vengono assegnati al giocatore con più Castelli in ognuna delle cinque regioni


Wallenstein – durante il gioco


Wallenstein - meccanica

Tutti i giocatori hanno, nel turno (tranne in inverno), queste dieci azioni da compiere, una sola per ogni territorio posseduto:1. Costruire un Mercato2. Costruire una Cattedrale3. Costruire un Castello4. Primo Movimento (spostamento o attacco)5. Secondo Movimento (spostamento o attacco)6. Raccogliere le tasse*7. Raccogliere il grano *8. Assoldare cinque armate9. Assoldare tre armate10. Assoldare un armata e fare uno spostamento*Il raccogliere tasse e grano causa lo scontento della popolazione che potrebbe rivoltarsi

Tutti i giocatori sceglieranno, contemporaneamente dove e quali azioni esercitare.Successivamente verrà stabilito l’ordine di gioco, verrà deciso mischiando e posando sul tavolo di gioco le carte giocato.


Giants

Ci troviamo sull’Isola di Pasqua tra ul V e il XVII secolo. La civita’ RapaNui costruisce degli incredibili monumenti funerari, gli Ahus (ahoo). Questi monoliti sono scolpiti da una sola pietra vulcanica ed eretti sulle sponde dell’isola.

Il gioco consiste nel costruire i monumenti funerari in modo collaborativo. Chi mette a disposizione piu’ risorse e/o manodopera e/o erige piu’ Ahus vince.


Giants - meccanica

Ogni giocatore puo’ compiere piu’ azioni per turno:• Piazzare un lavoratore, uno stregone o un capo• Fare una stregoneria• Erigere un Ahus

I giocatori possono usare i lavoratori e i pali di legno piazzati dali altri giocatori per trasportare gli Ahus vicino alla sponda dell’Isola. Ogni volta che viene usato il lavoratore di un altro giocatore questo guadagna dei punti


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


Benvenuti al CORSO SU AGILE!


Chi sei?Cosa fai?Cosa farai dopo il corso?Cosa ti piacerebbe fare tra cinque anni?Cosa ti aspetti dal corso?


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, Attivita’ e Pratiche.Stimare Costi e Tempi: User Stories, Story Point e

Poker Game.Risk Management e Communication ManagementDa PMP ad Agile: un modo pratico per introdurre

Agile nel team.Sunday, February 5, 12

ApprofondimentiAgile and Scrum Anti-Patterns: cosa si pensa

comunemente di Agile e Scrum che in realta’ non e’ vero

Self organizing teams: esempi reali di aziende auto organizzate

Pomodoro: tecnica di gestione del tempo e dei task day by day

Gemba, Kaizen e Kanban: alcuni metodi introdotto in Toyota e riadattato a diverse realta’ industriali e di servizi

Forme contrattuali agili: se vogliamo essere agili dobbiamo esserlo anche nei contratti

Mindmaps


Una sorpresa...


Obiettivi1. Diventare Agile Project Manager2. Conoscere i 4 Valori e i 12 Principi di Agile3. Definire e riconoscere le 10 ragioni di spreco

secondo Lean4. Conoscere e fare coaching di

Uno Scrum WorkflowDegli Scrum RolesDelle fasi di stima e pianificazione Agile

5. Creare e mantenere un Product Backlog6. Spiegare le ragioni di perche’ adottare Agile7. Analizzare e spiegare perche’ un’azienda non

riesce ad applicare Agile


Altri temi? Vostre proposte

....

....

....

....

....


Introduzione


Approcci di PM - Predittivo

Alcuni esempiWaterfallSpiraleUnified Process (RUP)PMBoK


Predittivo – Si’/No

Pro• Logico e sensato

• Pianifica prima di fare

• Mantiene una documentazione scritta

• Segue un piano

• Mantiene le attivita’ 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

XPScrumFDDTDDLean

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


Wallenstein VS Giants

Predittivo Adattivo


Quale scegliere?

Negli ultimi 30 anni si sono alternati approcci differenti

Waterfall

RUP

XP

Kanban

Agile

Tutti hanno avuto successi e insuccessi


OsservareAssimilare

RiealaborareMigliorare Continuamente


3 lavori predittivi3 lavori adattivi


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 produttivita’ nel software su prj da 100 KSLOC.

Migliorare i sw tools tipicamente migliora del 50% la produttivita’.

Migliorare il team il 353%!


Principali fattori di Successo

Team + Sponsorship + Cliente


Definizione di Successo


Successo

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

Il successo in Agile e’ misurato sul valore generato dal progetto


Cercate produttuvita’?

Agile non fa per voi!

Agile e’ per:•Apportare facilmente cambiamenti

•Creare velocemente valore•Aumentare la transparenza


Agile non e’

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


Agile e’

• Uno specchio della realta’• Un processo guidato dal valore• Un continuo adattamento agli

input esterni (requisiti, aspettative, ambito) con lo scopo di massimizzare il valore globale dell’output (prodotto/servizio/qualita’/soddisfazione)


Lean e Agile


Agile Manifesto

www.agilemanifesto.orgIndividuals and interactions

over processes and toolsWorking software

over comprehensive documentationCustomer collaboration

over contract negotiationResponding 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?


Teoria della comunicazione

CC Einar Faanes

funzione referenziale (contesto)funzione emotiva (mittente)funzione conativa (destinatario)funzione fàtica (contatto)funzione poetica (messaggio)funzione metalinguistica (codice)

Feedback


Teoria dell’ottimizzazione

Ottimizzazione molti-obiettivi conflittuali

Diverse alternative, diversi decisori, diversi criteri

Non esiste l’ottimo assoluto ma un compromesso

L’ottimizzazione locale dei singoli criteri non porta


Esempio di analisi multi-criteri

criteriaalternatives


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 buildingPensare “al proprio orticello” non aiuta il progettoMolto spesso lavori complessi hanno bisogno di piu’ occhiLavorare in un ambiente armonioso aiuta il progetto

Ottimizzare il globale e non il singoloMisurare il singolo spinge a non collaborareNon e’ detto che se tutti sono ottimali il progetto e’ ottimale


Interazioni VS Tools?

VS

CONSIGLIO: prima capire le persone e come lavorano poi scegliere i tools di supporto.

NO!I tool sono importanti se rispecchiano il modo di

lavorare del teamDevono ridurre quasi a zero il tempo e il costo

delle operazioni ripetitiveAgevolare la comunicazione remotaRendere trasparente il progetto


esercizio

camminiamo


Agile Manifesto

www.agilemanifesto.orgIndividuals and interactions

over processes and toolsWorking software

over comprehensive documentationCustomer collaboration

over contract negotiationResponding to change

over following a plan




Documentazione?

In un progetto software qual’e’ il documento che rispecchia meglio la realta’?

La documentazione e’ importante, molto importante

E’ importante se e’ veraIl 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!


Metodi di Testing

TDD Test driver development

Unit TestingIntegration TestingUser TestingInteraction Testing


Contratto

Firma e approvazione

16/06/2011

Oggetto del contrattoElenco Specifiche: A, B, CDettaglio SpecificheAssunzioni e LimitiTempi: 3 moCosti: 100.000$Modalita’ di approvazione del prodotto/servizioPagamentoDiritti di recessoPenali


… e dopo un mese?

Firma e approvazione

16/06/2011

e ora chi paga?

Oggetto del contratto: OKElenco Specifiche: A, B, C, D, EDettaglio Specifiche: in realta’ C e’ D+EAssunzioni e LimitiTempi: 4 moCosti: 120.000$Modalita’ di approvazione del prodotto/servizioPagamentoDiritti di recessoPenali


esercizio

Come procedete?

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

L’azienda Trivellazioni Felici 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 e’ l’incaricato di Trivellazioni Felici per fornirvi tutte le informazioni necessarie, l’importante e’ che il nuovo sistema sia operativo in tutte le 100 sedi entro un mese

Non ci sono limiti di budget


Collaborazione con il cliente

Domande di difficile risposta

1. Lavorare a stretto contatto con il cliente2. Respirare la stessa “aria”3. Avere le stesse aspettative

Fa superare piu’ facilmente la conflittualita’ intrinseca dei contratti

Che bisogni ha il cliente?Come lavora il cliente?Cosa vede il cliente?Come comunicare con lui?Quali aspettative ha?


Esempi di contratti “Agili”

•A forchetta minima e massima (PERT aiuta)

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

•Time and material classico


Piano

Quante volte questi piani sono stravolti il giorno dopo che sono stati scritti?

Gantt?PERT?Milestones?Project Management Plan?Analisi dei Requisiti?


Valore?

Questi valori sono scolpiti nella pietra o variano nel tempo?

Cos’e’ per il Cliente il valore?Un servizio/un prodotto che apporta valore al

proprio businessAumenta la competitivita’Riduce i costiAumenta i ricaviAumenta la penetrazione di mercatoAlza le barriere di ingresso ai competitorCrea nuovi mercatiEcc…


Progetti falliti* ma di valore

* nella accezzione di Scope-Cost-Schedule

Progetto falliti (fuori budget, scope o time) hanno portato valore in azienda. Ecco alcuni esempi:Post-itFacebookGMail


Teoria del controllo

Misurare l’output per calibrare gli input

Verificare il software funzionante per validare i requisiti implementati e pianificati


Quindi? Piano o Valore?

Agile e’ pianificazione con un controllore retroattivo

VS•Una pianificazione e’ 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


Eserciziowww.agilemanifesto.org

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


Scrum


Cosa non e’ scrum

Scrum != Ad Hoc

Scrum non e’ una scusa per far meno e costare meno:- “Non abbiamo bisogno di analisi dei requisiti”- “Non abbiamo bisogno di stime”- “Siamo agili!”

FALSO!


Una formula per Scrum?

Scrum = timeboxed iteration + backlogs + meeting giornalieri

NON BASTA SOLO QUESTO!

Implemetare Agile? NO

Implementare Scrum ed essere Agili SI’


Ambito

Lean

Agile

• 5 Principici• 10 Cause di Spreco

• 4 Valori• 12 Principi

Team

Necessita e Bisogni

Cliente

Aspettative

Valore


Storia

jeffsutherland.com

kenschwaber.wordpress.com

Jeff 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”


http://jeffsutherland.com/ScrumPapers.pdf

http://jeffsutherland.com/ScrumPapers.pdf

Most common methodologies

Dic 2008


2008


Obiettivi di Scrum

Auto organizzarsi! INSIEME!

1. Energia2. Concentrazione sugli obiettivi3. Chiarezza4. Transparenza


Aiuta a

•Aumentare la velocita’ di sviluppo•Allineare il progetto con le esigenze

del business•Creare valore in azienda•Comunicare in modo costante e trasparente

a tutti i livelli aziendali•Migliorare l’ambiente di lavoro delle persone


Le tre gambe di Scrum

TrasparenzaIspezioneAdattamento


Dove si inserisce Scrum


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

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


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. Sunday, February 5, 12

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 puo’ essere un membro del Team•ATTENZIONE PM o Team Leaders che diventate

Scrum Master: dovete cambiare molto il vostroapproccio, e’ 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

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

fare


Scrum roles – note importantiScrum Master e Productr Owner NON possono essere lo stesso

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

Scrum MasterProduct OwnerTeam

Un cambio di approccio e’ fondamentale!

Da assegnare attivita’, verificare lo stato a Aiutare, supportare, fare coaching e mentoring, rimuovere

gli impedimenti Essere al servizio del team!


Scrum Artifacts


Product BacklogLista di features con priorita’Roadmap del prodottoResponsabilita’ del Product OwnerTutto quello che e’ nel Product backlog e’ il prodottoQuello 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

Funzionalita’/requisiti clienteMiglioramenti tecnici/tecnologiciEsplorazioni su nuovi aspetti del

prodotto/del softwareBugs conosciuti


Come viene descrittoScrum non definisce un metodoLe user stories sono uno dei metodi piu’

usatiSi 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>"


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 sprintUno o piu’ task sono relativi a un item del Product

BacklogOgni task ha una stima in oreOgni task e’ assegnato a una persona che lo

richiede in modo volontario


Product Backlog a muro


Definition of Done

Definizione di completatoTipicamente e’ una regola di backgroud di tutto il progettoEs: una feature si considera completata se:

CodificataGli unit test sono tutti passedIl codice e’ commentatoLa funzionalita’ e’ utilizzabile dall’utente e soddisfa i

requisiti di usabilita’ definiti nella sua user storyE’ integrata nel setup/ambiente di deployE’ taggata sotto repositoryHa la documentazione utente


PSPI

Chiudere sempre secondo la Definition of Done concordata!

Potentially Shippable Product IncrementOgni Sprint idealmente finisce con un prodotto

potenzialmente rilasciabileMAI 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


Un momento di analisi del Product


Architettura emergente


Esercizio

Creare il product backlog per la presentazione di un’idea di applicazione iPad che favorisca la diffusione di Agile e di Scrum


Scrum Workflow


Overview


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 2Durata: 2-4 orePartecipanti: Scrum Master, TeamStrumenti: Sprint Backlog a muroObiettivo: definizione e stima dei task per lo Sprint

Backlog


Running the Sprint

Durata: 1-6 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


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


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


Poker game con Fibonacci


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 – Poker Game• 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 selezionateSunday, February 5, 12

Stime - PERT

ID Days --> optimum

likely worst pert var1 Global

AnalysisGlobal Analysis

1.1 Analysi

s1,00 1,00 1,00 1,00 0,00

1.2 Design 2,00 2,00 2,00 2,00 0,002 Codin

g

2.1 Desktop containerDesktop container

2.1.1 Window Manager 1,00 2,00 2,00 1,83 0,172.1.2 Background 0,20 0,50 1,00 0,53 0,132.1.3 Screen resize 0,20 0,20 0,50 0,25 0,052.1.4 HTML Integration 0,10 0,20 0,50 0,23 0,072.1.5 Unit Testing 0,50 1,00 1,00 0,92 0,08


Re-stimare


Risk analysis

Tenere un registro dei rischi del progettoStimare un peso dell’impattoStimare una probabilita’ che il rischio possa

manifestarsiDefinire dei piani di contigencyAttribuire dei responsabili ad ogni rischioSi possono usare analisi di Montecarlo (vedi Riskology

- http://www.systemsguild.com/riskology)

Tutte le attivita’ di risk vanno nello Sprint Backlog


Esempio di Risk register

Risk Category Risk Name Risk

NumberProbability

(1-3)Impact (1-3) Risk Score Mitigation Contingency Action By Action When

GuestsThe guests find the party boring

1.1. 2 2 4

Invite crazy friends, provide sufficient liquor

Bring out the karaoke Mack within 2hrs

Guests Drunken brawl 1.2. 1 3 3

Don’t invite crazy friends, don't provide too much liquor

Bring in the guards Jerry Now

*da wikipedia


http://en.wikipedia.org/wiki/Karaoke

http://en.wikipedia.org/wiki/Karaoke

Priorita’!

Costo Valore Rischio

Priorita’

Priorita’ massima: minor costo, maggior valore (rischio minimo)

3 variabili

Product Owner


Esercizio

Fare la stima del vostro product backlog


Scrum Reporting


Report in Scrum

Product Burndown ChartSprint Burndown ChartTest reportsArchitecture diagram status


Trasparenza a diversi livelliI Chicken NON devono vedere lo Sprint

BurndowchartLa trasparenza e’ sulle features completateNON su come il team si auto organizza

Lo sprint backlog e’ per il team, meglio su carta!


Velocity = 43 points in 10 days


Velocity


Alcuni scrum anti-patterns•Ottimizzazione prematura del processo

Scrum•Accumulare lavoro non fatto e continuare a

farne di nuovo•Lavorare come singoli paladini e non in

Team•Piu’ di un Product Owner•Nessun Stakeholder•“Copiate e migliorate quello che c’era prima”•Nuove storie sono aggiunte allo Sprint

backlog durante lo sprint (con la scusa


12 Principi di Agile

http://agilemanifesto.org/iso/it/principles.html


“La nostra massima priorità è soddisfare il clienterilasciando software di valore, fin da subitoe in maniera continua.”

Unit Tesing + Continuos Integration

Jenkins-CI


Esercizio


“Accogliamo i cambiamenti nei requisiti,anche a stadi avanzati dello sviluppo.I processi agili sfruttano il cambiamentoa favore del vantaggio competitivo del cliente.”

Prendere le decisioni architetturali il piu’ tardi possibile per poterle cambiare quando serve. Prendere le decisioni di valore.

Semplicita’!!!!


“Consegnamo frequentemente software funzionante, con cadenza variabile da un paio di settimane a un paio di mesi,preferendo i periodi brevi.”

Ritmo e buone abitudini


“Committenti e sviluppatori devono lavorare insiemequotidianamente per tutta la durata del progetto.”

Stesso ufficio openspace

oppure

Video conferenze


“Fondiamo i progetti su individui motivati.Diamo loro l'ambiente e il supporto di cui hanno bisognoe confidiamo nella loro capacità di portare il lavoro a termine.”

No incentivi singoliIncentivi sul teamTrasparenzaComunicazioneAutonomiaFiducia


“Una conversazione faccia a facciaè il modo più efficiente e più efficace per comunicarecon il team ed all'interno del team.”

Non dire le cose per email quando si possono dire di persona


“Il software funzionante è il principale metro di misura di progresso.”

I feedback del cliente sono la piu’ grande misura del successo del progetto


“I processi agili promuovono uno sviluppo sostenibile.Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in gradodi mantenere indefinitamente un ritmo costante.” Ritmo sostenibile


“La continua attenzione all'eccellenza tecnicae alla buona progettazione esaltano l'agilità.” Eccellenza e

progettazione portano alla semplicita’


“La semplicità - l'arte di massimizzare la quantitàdi lavoro non svolto - è essenziale.”

"

Imports System.ConsoleClass HelloWorld Public Shared Sub Main() WriteLine("Hello, world!") End Sub End Class


ANTI-IF CAMPAGN

esercizio


“Le architetture, i requisiti e la progettazionemigliori emergono da team che si auto-organizzano.”

No micro gestioneSi’ ritmo e abitudini

No best practicesSi’ preferred practices


“A intervalli regolari il team riflette su comediventare più efficace, dopodiché regola e adattail proprio comportamento di conseguenza.”

Essere leali e obiettiviSaper gioire per i successiSaper riconoscere gli sbagli

Non vivere con l’incubo dell’errore ma con la consapevolezza di saper riconoscere e correggere gli errori


5 WHYs

esercizio


Esercizio

A coppie scrivere su un foglio a muro• 4 valori di Agile• 12 principi sottostanti ad Agile


Simuliamo un progetto Agile

Agile: The Board Game


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


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

•Uno scopo•Ridurre gli sprechi•Dare valore subito al cliente


Lean Flow

http://www.lean.org/WhatsLean/Principles.cfm

Spostare l’attenzione dalla creazione del prodotto al processo produttivo: “the production flow”


5 principi di Lean1.Definire il valore, per ogni famiglia di prodotto, dal punto di

vista del cliente finale.2.Identificare i passi del value stream, per ogni famiglia di

prodotto, eliminando possibilmente tutti gli step che non creano valore.

3.Assicurarsi che i vari passi del value siano vicini e possano creare un flusso veloce verso il cliente finale.

4.Una volta che il value stream e’ attivato favorire l’intervento del cliente per atto ad aumentare il valore degli step.

5.Una volta che il valore e’ definito, il value stream identificato, gli sprechi rimossi e il flusso introdotto ricominciare di nuovo il processo fino a quando il valore e’ prodotto senza sprechi.


Value Stream Mapping

Fresare Saldare Verniciare Assemblare


Esercizio


10 maggiori cause di sprecoQualsiasi cosa che non aggiunge valore al cliente

finale 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

messaggiMaggior tempo per discriminare la posta importante da

quella meno importanteLentezza del client di posta!


Bugs

Meglio mettere nel cassetto i bugs e riaprire il cassetto quandosi avra’ il tempo

Meglio non avere bugs!

Una lista molto lunga di bugs “vecchi” non aiuta a mantenere il flusso di valore:Se un bug e’ piu’ vecchio di X mesi significa che non

e’ importante (altrimenti sarebbe venuto giu’ il mondo!)

Avere tanti bugs e non risolverli non aiuta a dare le giuste priorita’


Gemba

Nei progetti software cos’e’ il Gemba?

In Toyota e’ la pratica di andare a vedere la linea di produzione

I manager non guardano email, grafici, report, ma direttamente la linea di produzione

I problemi sono vissuti sul campo, ci si rende conto della complessita’ e delle persone.


A3


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


Title:

Background

Current Situation

Goal

Analysis

Recommendations

Plan

Follow - up

A3 -Verble/Shook


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

1. Scegli il task da completare2. Imposta il Pomodoro a 25 minuti

(Il Pomodoro è il timer)3. 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

4. Prenditi un piccolo break (5 minuti vanno bene)5. 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


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


Agile anti-patterns

http://www.agileforall.com/2009/06/03/agile-antipattern-insanity-5-insanity-antipatterns/

http://agileantipatterns.com/

Never meeting iteration commitmentsTesting late Poor estimatingNot trying to improveNot assigning action items


Scrum#E’ una evoluzione di Scrum ponendo Scrum all’interno del Lean

ThinkingRilassa certi aspetti a seconda dei progetti. Es:

Iterazioni: time boxed oppure flow-based.Prodotto: il team e’ responsabile del prodotto.Management: i manager guida e fa coach al team. Si lavora

insieme.Imparare: dal modello del flow con la big picture sempre

presente.Priorita’: non solo valore per il cliente ma anche sulla

riduzione degli sprechi.Continuos Integration: build che funzionano in automaticoAcceptance Test: definiti prima di codificare.Limitare il WIP: non iniziare nuove storie se non sono

concluse quelle precendenti.


Scrum Scaling


Scrum di ScrumOgni team lavora con un suo ScrumOgni settimana un membro del team si incontra con

gli altri membri degli altri team per fare un Daily meeting

Puo’ essere scalato in modo indefinitoI rappresentanti possono cambiare di volta in volta


Team VirtualiE’ possibile applicare Scrum da remoto su team dislocati

geograficamentiE’ difficile farlo funzionareI tools di comunicazione sono fondamentali, devono

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

Chat, Call e Video Call devono essere sempre accessibiliIl repository del codice sempre condivisoI 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 componentiIl codice e’ di tutti, non del Team singolo, NO CODICE

PRIVATONon 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


Come aiutareFare un A3 della situazione con Value Stream MappingAffrontare un problema alla voltaNon cercare di ottimizzare tutto subitoAvere una spinta molto forte dai top-managerCercare consenso dal bassoIntrodurre un Changing AgentChiedere la consulenza di un Coach. Il Coach e’ una

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


Una ricetta per Kanban1. Concentrarsi a rilasciare sempre software di

Qualita': TDD, Code Inspection, Arcihtecture and Design Patterns e Software Factories

2.Ridurre il Work-in-Progress (WIP)3.Rilasciare spesso4.Bilanciare la domanda di nuove funzionalita'

con il lavoro che si riesce a smaltire (Throughput)

5.Dare priorita' alle cose6.Ridurre le cause di variabilita' migliorando la

predicibilita'

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


Conclusioni


La chiusura di un progetto

Raccogliere 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.orgMasterPractitionerCoachTrainer

PMI-ACP - www.pmi.orgAtern DSDM - www.dsdm.org


http://www.pmi.org

http://www.pmi.org

http://www.dsdm.org/

http://www.dsdm.org/

Studiare come Scrum MasterSeguire il corso di Scrum Master di due giorni

insegnato da un Scrum Trainer CertificatoApplicare Scrum su un progetto e/o partecipare ad un

progetto ScrumStudiare il libro di Ken Schware “Agile Project

Management with Scrum”Sostenere un esame online con 40 domande in 60

minuti.


Studiare per PMI-ACP

Pre-requisiti: 2000h di PM + 1500h di Agile PM + 21h di Training su Agile (16 ore questo corso)

Studiare i libri:Agile Project Management with Scrum The Art of Agile developmentUser Stories AppliedAgile Estimation and PlannigScaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale ScrumThe Software Project Manager's Bridge to AgilityLean-Agile Software Development: Achieving Enterprise AgilityCoaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Manager...Agile Project Management: Creating Innovative Products (2nd Edition)Agile Retrospectives: Making Good Teams GreatKanban: Successful Evolutionary Change for Your Technology Business

Inoltre questo link ti da una panoramica di tutte le aree da studiare - http://agiletraining.com/2011/09/24/pmi-acp-agile-certification-exam-study-tips

Qui l’handbook PMI - http://www.pmi.org/Certification/~/media/PDF/Certifications/PMI-ACP_Handbook.ashx


http://agiletraining.com/2011/09/24/pmi-acp-agile-certification-exam-study-tips




http://www.pmi.org/Certification/~/media/PDF/Certifications/PMI-ACP_Handbook.ashx




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


Ringraziamenti

Si ringraziano tutti i partecipanti ai corsi 2011 per i preziosi feedback e la grande partecipazione al corso.

Si ringrazia Michael Vizdos che con i suoi fumetti mi ha ispirato e divertito - www.implementingscrum.com.

Ringrazio tutti i colleghi di Intré che fanno da cavia per tutte le mie sperimentazioni.

Ringrazio Elena, Arturo e Edoardo per la pazienza che hanno avuto durante le mie sere di studio e ricerca.


http://www.michaelvizdos.com/

http://www.michaelvizdos.com/

http://www.implementingscrum.com/

http://www.implementingscrum.com/

Diritti

Queste slide sono il frutto di un anno di lavoro e dieci anni di esperienza.

Non posso dire che siano complete e perfette ma possono essere una buona base di partenza.

Ho deciso di pubblicarle Open Source per favorire la diffusione di Agile e del Project Management in generale. In questo periodo di difficile cambiamento sono convinto che applicare questi concetti permetterà a molte aziende di diventare più competitive nel mercato e più vivibili al loro interno.

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


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

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

Agile Project Management

Business

Transcript of Agile Project Management