Project Management Agile

1. Project Management Agile

2. Perché? Guardiamo qualche dato: • Quasi i due terzi dei progetti eccedono la stima dei costi in maniera significativa; • Praticamente il 63% dei progetti eccedono la stima dei tempi; • Il 64% delle funzionalità incluse nei prodotti sono raramente/mai utilizzate; • Solo il 32% dei progetti hanno pieno successo;

3. Sistemi complessi: serve un approccio differente

4. PM Tradizionale vs PM Agile Piani certi, change ridotte, stakeholders limitati, tecnologia certa: Puntare, Mirare e fare Fuoco! …in caso contrario: Puntare, fare Fuoco e Mirare! Sfruttare il feedback e correggere la rotta in corso d’opera

5. Il manifesto Agile: Gli individui e le interazioni più che i processi e gli strumenti; Deliverable funzionanti consegnati più che la documentazione esaustiva; La collaborazione col cliente  più che la negoziazione dei contratti; Rispondere al cambiamento più che seguire un piano; Ovvero, fermo restando il valore delle voci a destra, consideriamo più importanti le voci a sinistra.

6. I valori Agili Comunicazione (facilitata, diretta, personale, massimizzata); Feedback continuo; Semplicità : KISS Rule ( Keep It Simple, Stupid!); Focalizzazioneagliobiettivi (Amplificare il ritorno di valore al committente, diminuire lo spreco, massimizzare la focalizzazione sul lavoro da fare); CustomerOrientation (Short Feedback Cycle); Fiducia; Collaborazione; Auto-sviluppo e curiosità; Auto-organizzazione (Il team decide in autonomia come realizzare il lavoro, attraverso quali modalità, decidendone regole e processi); Coraggio.

7. Il team Agile • Orientamento verso il valore di business del cliente; • Spiccata competenza tecnica individuale; • Dimensione ridotta; • Auto disciplina e organizzazione; • Propensione alla collaborazione; • Capacità di adattamento; • Disponibilità e apertura all’apprendimento.

8. Come arrivarci? Evoluzione personale Evoluzione del team Adjourning Ha: Testane i limiti Ri: Crea novità Shu: Impara i fondamenti

9. Tendiamo a ri (離)

10. Comunicazione Agile La comunicazione agile si basa sui seguenti punti: • Riduzione linee di comunicazione; • Comunicazioni face-to-face; • Co-locazione del team; • Rilasci frequenti (timeboxing); • Information radiators; • Planning Meeting; • Daily Meeting; • Retrospective Meeting; • Demo Meeting; • Pair Programming;

11. Timeboxing : diamoci scadenze strette e regolari Scrum ( agile , timeboxed ) A cascata ( tradizionale ) Plan Plan Plan Plan Plan Plan Plan Plan Deliver Deliver Review Review Plan Build Build Build Build Build Build Build Build Build Test Test Test Test Test Test Test Test Test Review Review Review Review Review Review Review Review Review Deliver Iterativo Plan Build Review Deliver Test Of both the problem And the solution Plan Build Review Deliver Test Short termiseasier in predict and estimate ratherthan long term

12. Userstories : facciamoci raccontare i deliverable dai destinatari Come studente Voglio un accesso alla rete wireless del mio istituto Al fine di consultare siti Internet (per motivi didattici) Come <utente tipo> voglio <eseguire alcune azioni> al fine di <ottenere questi risultati> Come insegnante Voglio limitare l’accesso alla rete in specifici orari Al fine di evitare distrazioni dalle lezioni

13. Prioritizzazione delle USs Una volta collezionate le userstories è necessario assegnare loro una priorità. Il valore di business che si ottiene sviluppando la funzionalità: Il costo di sviluppo e mantenimento della funzionalità; Il peso del knowledge che verrebbe acquisito se sviluppata la funzionalità. La capacità di abbattimento dei rischi grazie allo sviluppo della funzionalità.

14. Stima delle USs Terminata la raccolta e la prioritizazione delle user stories, il team seleziona e stima le stesse: 1. Determinazione della velocità del team per singolo sprint/iterazione; 2. Selezione delle storie da implementare nello sprint corrente in funzione della velocità; 3. Stima delle storie usando unità di misura tipo: • Ideal days: tempo in giorni al netto di interruzioni; • Story points: punti di misurazione relativa in una iterazione; 4. Scomposizione delle storie in task. • Le storie devono essere di piccola dimensione e per stimarle usare pochi valori (es. 1, 2, 4, 8, 16, 32, 64 ); • Le stime le produce chi lavorerà sulle storie; • Il team intero trova accordo sui valori delle stime; • L’esperienza pregressa del team (di quel team) genera stime affidabili.

15. SCRUM : l’ordine dal caos

16. SCRUM player roles

17. Il processo

18. Strumenti SCRUM : il backlog • Funzionalità  User Stories; • Product backlog  Minimum MarketableFeatures; • Release backlog  pacchetto rilsciabile • Sprint  time box breve lasso di tempo in cui si realizzano compeltamente • Tasks scomposizioni delle funzionalità in compiti eseguibili da un membro del team

19. Strumenti SCRUM : Sprint burndown chart

20. Strumenti SCRUM : Taskboard

21. “Cerimonie” SCRUM ( meetings )

22. REGOLE Definizione di lavoro terminato (definition of done DOD); Taskboard, Burndown chart, backlog aggiornati e visibili a tutto il team; Nessuna interruzione dello sprint; Change e riprioritizzazioni rimandate al prossimo sprint; Nessun “break” tra gli sprint; Ritmi sostenibili; Alla fine di ogni sprint, il lavoro viene presentato; Team: cross-funzionale e tra 5 e 9 membri; Tutto il team deve presenziare al DailyScrum Meeting; Il team propone aggiunta/rimozione delle stories dal backlog.

23. Grazie a tutti! Vi è piaciuto ? Fatelo sapere !