Agile raccontato a mia nonna
Download as PPTX, PDF2 likes1,289 views
Le slide dello speech all'ALM4Dummies 2015 organizzato da domusdotnet.
More Related Content
What's hot (20)
Similar to Agile raccontato a mia nonna (20)
More from Felice Pescatore (20)
Agile raccontato a mia nonna
- 1. getlatestversion Agile raccontato a mia nonna Felice Pescatore www.felicepescatore.it - felice.pescatore@gmail.com - @felicepescatore
- 2. About me Innovation Manager Agile/Lean Coach Agile Enterprise Architect felice.pescatore@gmail.com Microsoft MVP Visual Studio ALM felicepescatore.it @felicepescatore Felice Pescatore Agile@Scale Italy Group
- 3. Agenda Dobbiamo telefonare a qualcuno? No? Allora niente agenda!
- 4. Customer Value Cosa la nostra nonnina vorrebbe
- 5. Customer Value cosa realmente succede.
- 6. Perch辿 ci troviamo in queste condizioni? Il nostro modello di sviluppo prevedeva di consegnare tutto in una volta, certi di aver capito cosa la nostra nonnina voleva; Non abbiamo provato la soluzione; Abbiamo esaurito il budget e non possiamo completare lo sviluppo. Nel frattempo la nostra nonnina 竪 rinvigorita e si 竪 dedicata ad altro, per cui non ha pi湛 bisogno del nostro prodotto!
- 7. Nonna, pensaci tu! andiamo a fare il bucato! !?!?! un po come 束togli la cera e metti la cera損
- 8. Pila di indumenti sporchi Lavaggio di oggi Asciugatura Lavaggio Indumenti indossabili Come fare un buon bucato! 1. Raccolgo tutti gli indumenti da lavare; 2. Scelgo gli indumenti per il prossimo lavaggio, in base alle esigenze e in funzione della capacit di carico della lavatrice; 3. Effettuo il lavaggio; 4. Effettuo lasciugatura; 5. Gli indumenti lavati sono potenzialmente indossabili (non sono stirati).
- 9. Pila di Panni sporchi Lavaggio di oggi Asciugatura Lavaggio Indumenti indossabili Sorpresa! Agile 竪 come fare il bucato!
- 11. Agile Manifesto Principles Con Agile Software Development si sottendono un gruppo di tecniche e metodologie per lo sviluppo del software che condividono un approccio iterativo ed incrementale, in cui i requisiti e la soluzione stessa evolvono costantemente e le attivit sono affidate a self-organizing e cross-functional Teams.
- 12. Agile = Early Value Coinvolgimento e Impegno degli Stakeholder Trasparenza Fast Delivery Abbracciare il cambiamento Gestione del Rischio Focus sul Valore Focus sul Cliente Qualit Analysis Design Coding Testing 20% done (100% usable!) Analysis Design Coding Testing Do we have half a solution yet? Traditional Process Agile Process
- 13. Perch辿 le aziende scelgono Agile Fonte:9THANNUALStateofAgileSurvey-息2015VersionOne,Inc.Allrightsreserved
- 14. Caratteristiche di un progetto Agile Time Boxed Just-in-Time Adaptative Il Team si concentra su un obiettivo alla volta; I requisiti vengono specializzati solo quando si 竪 pronti per realizzarli. Team cross-functional, sia tecnico che funzionale; Planning Adattativo, rivisto in funzione dei risultati, dei feedback e delle esigenze nel micro-periodo di riferimento Obiettivi pi湛 rilevanti da raggiungere legati alliterazione; Soluzione incrementale funzionante a fine di ogni iterazione; Interazione continua con i (key) stakeholders; Rivedere il planning in funzione dei feedback ricevuti;
- 15. Vantaggi per il cliente Il cliente 竪 attivamente coinvolto e ha un maggiore controllo sulle priorit; Opportunit di fornire rapidamente feedback; E costantemente aggiornato sullo stato dello sviluppo; I requisiti sono potenzialmente rivisti dopo ogni iterazione; Viene abbattuto il time-to-market, rendendo potenzialmente disponibile una soluzione incrementale ad ogni iterazione; La data di consegna pu嘆 essere fissata, lasciano per嘆 margine sulle funzionalit e sul budget utilizzabile; La qualit della soluzione 竪 decisamente alta, grazie allenfasi sui test, sia automatici che manuali.
- 16. Vantaggi per lazienda Capire i reali progressi in termini di prodotto e non di planning; I Team di progetto sono coinvolti attivamente in tutte le fasi, lavorando in modo collaborativo; Ritmo di lavoro sostenibile; I Team sono costantemente al lavoro sulle funzionalit a maggior Valore per il cliente, grazie ai feedback frequenti; La documentazione realizzata 竪 la minima indispensabile; Minori costi di sviluppo complessivo, grazia alla riduzione del peso di tutte le attivit non direttamente legate allo sviluppo.
- 17. Sfide coinvolte nello sviluppo Agile del software Difficolt Disciplina Pianificazione Agile 竪 difficile da adottare, richiedendo la partecipazione attiva dei committenti e impattando fortemente sullazienda. Al management viene richiesta una maggiore apertura mentale consentendo ai Team di prendere molte decisioni in modo indipendente. Agile richiede molta pi湛 disciplina delle tecniche tradizionali, richiedendo che la soluzione realizzata sia sempre in uno stato rilasciabile. Ci嘆 implica lutilizzo di pratiche di Continuos Integration e codice funzionante sempre in modo perfetto. Nelle metodologie Agili 竪 necessaria una maggiore e pi湛 raffinata forma di pianificazione, attuata ed aggiornata frequentemente (Planning Onion),
- 18. Miglioramenti ottenuti dalladozione dellAgile Fonte:9THANNUALStateofAgileSurvey-息2015VersionOne,Inc.Allrightsreserved
- 19. 4 Valori, 12 Principi e tante metodologie Scrum XP FDD Lean Crystal SAFe DAD UPEvo DSDM Kanban Fonte:9THANNUALStateofAgileSurvey-息2015VersionOne,Inc.Allrightsreserved
- 20. Scrum in meno di 100 parole Valore Priorit Working Alla fine di ogni iterazione, la soluzione incrementale realizzata deve essere funzionante e chiunque pu嘆 utilizzarla, decidendo se rilasciarla al cliente o continuare a migliorarla. Scrum consente di focalizzarsi sul delivery del massimo Valore di Business nel minor tempo possibile relativo, permettendo di validare rapidamente e costantemente la soluzione ottenuta ad ogni iterazione. Le priorit vengono fissate in funzione di quello che 竪 il Valore da raggiungere e il Team, auto-gestito, individua il modo migliore per sviluppare le feature ad alta priorit.
- 21. Scrum BigPicture
- 22. Processi, Eventi e Artefatti: il Product Backlog Gli elementi del PB sono chiamati Product Backlog Item (PBI) e sono scritti tipicamente in forma di User Story, corredati da Test di Accettazione. I PBI sono tipicamente caratterizzati da: descrizione, priorit, effort, e valore di progetto. Scrum inizia con la creazione del Product Backlog, ovvero lelenco priorizzato delle funzionalit previste per il prodotto. Il PB evolve in funzione del know-how acquisito sul prodotto e alla maturit del Team.
- 23. Processi, Eventi e Artefatti: le User Story
- 24. Daily Scrum Sprint Review Sprint Retrospective Processi, Eventi e Artefatti: lo Sprint Lo Sprint 竪 l'evento principale di Scrum, tipicamente di durata compresa tra 1 e 4 settimane. Lo Sprint 竪 sempre accompagnato da uno Sprint Goal che ne definisce gli obiettivi e produce un incremento funzionale e testato della soluzione. Ogni Sprint inizia con lo Sprint Planning Meeting, prevede una serie di cerimonie specifiche ed 竪 Time-boxed: una volta iniziato non pu嘆 essere modificato se non in casi rari e con conseguenze da valutare.
- 25. Processi, Eventi e Artefatti: Sprint Planning e Sprint Backlog Ogni Sprint inizia con lo Sprint Planning Meeting durante il quale viene definito lo Sprint Goal e creato lo Sprint Backlog, ovvero l'insieme degli elementi (PBI) del Product Backlog selezionati dal Team per lo Sprint. Il Team scegli i work item in funzione dello Sprint Goal e della propria storia (HPT, Know-how, Velocity, ecc), suddividendoli in task di sviluppo stimati in ore (tipicamente da 4h a 16h). I task sono auto-assegnati.
- 26. Gli Information Radiator sono pensati per comunicare rapidamente informazioni a chiunque li osservi, consentendo di avere un quadro immediato dello stato delle attivit e di eventuali problematiche. Scrum/Kanban Board Burndown Chart Regola del 3+3: 3mt in 3minuti Processi, Eventi e Artefatti: Information Radiator
- 27. Kanban Board
- 28. Processi, Eventi e Artefatti: PSI e Definition of Done Un Potentially Shippable Increment, o anche Increment, 竪 il risultato dellattivit di Continuos Integration di ogni Sprint, cosa che rende potenzialmente pronta la soluzione per il delivery, indipendentemente dal fatto che verr presentata o meno agli stakeholder. Un PSI deve soddisfare la Definition of Done (DoD), una serie di criteri che consentono di dichiarare che una 束User Story 竪 completata損. Tali criteri vanno chiaramente ad impattare sulleffort, per cui 竪 fondamentale che la DoD si condivisa da tutto il Team.
- 29. Scrum Team E la responsabile della Vision di prodotto e ha come obiettivo quello di massimizzarne il Valore realizzato. Ha come obiettivo quello di implementare fattivamente Scrum, in modo efficace ed efficiente, allinterno del Team stesso. Core Team Professionisti in grado di realizzare soluzioni Value Driven e Strong Quality compliance.
- 30. Scrum Team: Product Owner Il Product Owner (PO) armonizza la voce degli stakeholder e governa, in modo esclusivo, il Product Backlog: definisce le feature; priorizza le feature e le user stories in funzione del Valore; collabora nella definizione e nella verifica dei test di accettazione; Voce degli Stakeholder Gestisce gli aspetti economici Partecipa al Planning Governance del Product Backlog Definisce e verifica gli Acceptance Test Collabora con il Dev Team
- 31. Scrum Team: Scrum Master Lo Scrum Master (SM) si comporta da Servant Leader / Facilitatore: promuove ladozione di Scrum; protegge il Team dalle interferenze e le distrazioni esterne; promuove lautogestione volta alla crescita delle competenze complessive; elimina gli ostacoli agli avanzamenti. Coach Servant Leader Agile Values Protegge dalle interferenze Rimuove gli impedimenti
- 32. Scrum Team: Development Team Il Development Team (DT) 竪 il braccio operativo auto-organizzato, 竪 in grado di trasformare il Product Backlog in un prodotto rilasciabile; cross-funzionale, ingloba tutte le competenze necessarie (progettazione, sviluppo, testing, ecc..) T-shaped, i membri hanno competenze verticali profonde (Deep) ma sono in grado di supportare il resto del Team su tutte le attivit (Broad); piccole dimensioni, tipicamente da 3 a 7/9 componenti. Produce la soluzione funzionante di qualit
- 33. Recap Efficace Value based Difficile Agile 竪 oggi il modo pi湛 efficace per la realizzazione di progetti complessi. Lobiettivo 竪 quello di creare Valore per tutti gli stakeholder coinvolti. Il punto di partenza sono i 4 valori e i 12 principi del Manifesto Agile. Tra le metodologie che abbracciano il Manifesto, Scrum 竪 la metodologia pi湛 diffusa. Adottare Agile 竪 estremamente difficile, richiedendo disciplina ed impego.
- 34. Risorse e Riferimenti Agile Application Lifecycle Management con VSO/TFS Agile@Scale: visione olistica del valore Lean Philosophy Introduzione a Kanban Application Lifecycle Management (ALM) con Visual Studio Online
- 36. Quote
- 37. http://svy.mk/1BLujLb Per voi sono solo 10 minuti persi, per noi 竪 utilissimo per poter crescere e migliorare!
Editor's Notes
- #5: Il problema 竪 che troppo spesso non siamo in grado di capire cosa vuole il nostro cliente.
- #6: Il problema 竪 che troppo spesso non siamo in grado di capire cosa vuole il nostro cliente.
- #8: Vediamo ora come potremo fare ad affrontare lo sviluppo del software, una delle attivit pi湛 complesse oggi esistenti.
- #13: Se il processo Agile 竪 la nostra attivit di fare il bucato, le Metodologie Agili sono il nostro sapone!
- #14: Se il processo Agile 竪 la nostra attivit di fare il bucato, le Metodologie Agili sono il nostro sapone!
- #19: Se il processo Agile 竪 la nostra attivit di fare il bucato, le Metodologie Agili sono il nostro sapone!
- #20: Se il processo Agile 竪 la nostra attivit di fare il bucato, le Metodologie Agili sono il nostro sapone!