Downloaded 47 times
Uploaded byFelice Pescatore
Agile@scale: be SAFe!
Il documento discute l'approccio Agile a scala, enfatizzando l'importanza di pratiche adattive per gestire la complessità dei progetti software. Viene presentato un framework per la disciplina Agile Delivery (DAD) e il Scaled Agile Framework (SAFe), illustrando la necessità di un approccio empirico in situazioni complesse. Si evidenziano i ruoli, le cerimonie e gli artefatti coinvolti in vari livelli di gestione dei progetti per garantire una transizione efficace e il raggiungimento degli obiettivi.
More Related Content
Similar to Agile@scale: be SAFe!
Agile@scale: be SAFe!
- 1. Agile@Scale: be SAFe! DAD& SAFe 07 Aprile 2014 @felicepescatore Disciplined Agile Delivery Italy Groupwww.felicepescatore.it Felice Pescatore
- 2. Agile@Scale: be SAFe! Realityis complex… software is complex! COMPLEX Emergent Practices COMPLICATED Good Practices CHAOTIC Novel Practices SIMPLE Best Practices Cynefin Model 2
- 3. Agile@Scale: be SAFe! Toocomplicated and too complex for traditional approach If a process is too unpredictable or too complicated for the planned, (predictive) approach, then the empirical approach (measure and adapt) is the method of choice. - Ken Schwaber 3
- 4. Agile@Scale: be SAFe! Conil cappello “Agile” non si intende un insieme di processi e tool. Agile è un set di Valori e Pratiche su cui basare le proprie attività, e, perché no, I processi e i tool utilizzati. Agile… what? 4
- 5. Agile@Scale: be SAFe! AgileManifesto 5
- 6. Agile@Scale: be SAFe! WhatAgile isn’t… 6
- 7. Agile@Scale: be SAFe! DSDMAtern RUP / Open UP FDD Fuller Approaches (still agile) SCRUM Crystal eXtreme Programming Lightweight Approaches Disciplined Agile Delivery, DAD Scaled Agile Framework, SAFe@Scale Agile Agile Umbrella 7
- 8. Agile@Scale: be SAFe! DomainComplexity Straight -forward Intricate, emerging Compliance requirement Low risk Critical, audited Team size Under 10 developers 1000’s of developers Co-located Geographical distribution Global Enterprise discipline Project focus Enterprise focus Technical complexity Homogenous Heterogeneous, legacy Organization distribution (outsourcing, partnerships) Collaborative Contractual Disciplined Agile Delivery Flexible Rigid Organizational complexity @Scale… what? 8
- 9. Agile@Scale: be SAFe! Aproject is more than only development… @Scale… why? 9
- 10. Agile@Scale: be SAFe! TheIdea, the Build, the Environment Aggredire il mercato con una nuova idea • Generata dall’esigenza, Pensata per creare un’esigenza • Chi finanzia il progetto? Quali sono i rischi? Di quante persone ho bisogno? Quanti Team? Dove avvengono le attività? Quali sono le tecnologie di supporto?, ... Program Level & Inception Program Level & Inception • Creare il Program Backlog (Feature), Creare i Team Backlog (User Story), Identificare i PSI (Potential Shippable Increment), …. Team Level & Construction • Prendere in carico il Team Backlog, Definire le iterazioni in relazione ai PSI, Definire i Task, Scegliere le pratiche da utilizzare, … Program Level & Transition • Completato lo sviluppo, il sistema deve essere manutenuto in erogazione e fruibile correttamente da client di tipologia diversa (anche molto!) 10
- 11. Agile@Scale: be SAFe! Leaders(in ALM) have strong capabilities in agile practices, including driving portfolio management support and support for enterprise agile capabilities, such as SAFe and Disciplined Agile Delivery (DAD)* * Tratto da: Magic Quadrant for Application Development Life Cycle Management (19 November 2013) SAFe and DAD 11
- 12. Agile@Scale: be SAFe! SAFe,Scaled Agile Framework • Framework maturo per l’adozione di pratiche Agili all’interno di contesti Enterprise • In grado di gestire, con successo, un ampio numero di «Agilisti» e di Team • Costruito sui principi delle metodologie Agile@Core e Lean • Sincronizzazione tra sviluppo e delivery Grazie alla «Big Picture» è possibile evidenziare le relazioni ed i ruoli dei vari attori aziendali che concorrono al processo Agile@Scale, unitamente agli artefatti e le cerimonie di riferimento 12
- 13. Agile@Scale: be SAFe! SAFe«Big Picture» 13
- 14. Agile@Scale: be SAFe! SAFe:Portfolio Level Ruoli / Team • Program Portfolio Manager • Enterprise Architect • Epic Owner Cerimonie • Strategic Investment Planning • Kanban Portfolio Planning: Epic Artefatti • Investment Themes • Business and Architecture Epics • Portfolio Backlog • Portfolio Vision • Metrics 14
- 15. Agile@Scale: be SAFe! SAFe:Program Level Ruoli / Team • Product Management • Release Management • System Team • DevOps • Business Owners • System Architect • Release Train Engineer • UX Architect Cerimonie • PSI/Release Planning • System Demo • Inspect & Adapt Workshop Artefatti • Product Roadmap • Vision • Program Backlog • Team Backlog • NFRs • Architecture Runway • Business and Architecture Feautures • PSI Objectives • Metrics 15
- 16. Agile@Scale: be SAFe! SAFe:Team Level Ruoli / Team • Agile Teams • Product Owner • Scrum/Agile Master Cerimonie • Sprint Planning • Backlog Grooming • Daily Stand-up • Sprint Demo • Sprint Retrospective • HIP Sprints Artefatti • Team Backlog (vincolato dai NFRs) • Team PSI Objective • Sprint Goals • Working Software • Spikes • Metrics 16
- 17. Agile@Scale: be SAFe! DAD,Disciplined Agile Delivery • Framework per lo sviluppo di soluzioni End-to-End con ampia libertà di personalizzazione • Costruito sui principi delle metodologie Agile@Core e Lean • Scalabile, people-first oriented, learning oriented, goal-driven, enterprise aware, risk and value driven • Linee guida per la governance di team enterprise secondo le best-guide Agili Grazie alla «Big Picture» è possibile evidenziare le fasi di sviluppo di una soluzione end-to-end in ambito enterprise secondo i principi Agili. DAD è un framework ibrido, Value & Risk driven, fortemente orientano alle persone e al loro apprendimento, il tutto con la finalità di produrre in modo ottimale il delivery della soluzione. I C T Inception Construction Transition 17
- 18. Agile@Scale: be SAFe! DAD,Agile Big Picture Inception Construction 1 Construction 2 Construction 3 Transition 1 Construction 4 Transition 2 Avere una visione PSI PSI PSI Deploy in Produzione New PSI (Next Release) Nuovo Deploy in Produzione PSI: Potential Shippable Increment 18
- 19. Agile@Scale: be SAFe! DAD,Lean Big Picture Inception Lean Construction 1 Transition 1 Lean Construction 2 Transition 2 Avere una visione PSI when Done Deploy in Produzione New PSI (Next Release) Nuovo Deploy in Produzione PSI: Potential Shippable Increment 19
- 20. Agile@Scale: be SAFe! THEAGILE 3C RHYTHM Concept Inception Coordinate Construction Collaborate Transition Conclude Release rhythm Iteration rhythm Development Collaborate Iteration Planning Coordinate Stabilize Conclude Daily rhythm Coordinatio n Meeting Coordinate Daily Work Collaborate Stabilize Conclude La terna (rhythm) Coordinate-Collaborate-Conclude ritorna a vari livelli in un progetto governato tramite DAD: 20
- 21. Agile@Scale: be SAFe! DADPHASES: INCEPTION Stakeholderconsensus Project/ProductApprovedtostart Collaborate ConcludeCoordinate • Individuare i possibili Team Member; • Pianificare una sessione di “vision” del progetto; • Precettare gli stakeholder per la sessione di “vision” . • Rifinire la Vision; • Effettuare una prima valutazione dei requisiti; • Effettuare una prima ipotesi Architetturale; • Valutare la fattibilità del progetto; • Creare un primo Release Plan; • Strutturare il (i) Team; • Settare l’ambiente; • Garantirsi la sostenibilità economica • Identificare i rischi. • Review di quanto definite (mailstone); • Comunicare la Vision agli stakeholder; • Impegnarsi sulle Iterazioni ed i rilasci continui. Fino ad alcune ore (se tutti gli stakeholder sono disponibili) Idealmente: 1-2 settimane Media: 4 settimane Caso Peggiore: Più mesi Qualche ora 21
- 22. Agile@Scale: be SAFe! DADPHASES: CONSTRUCTION PHASE Second Stakeholderconsensus SufficientFunctionality Collaborate ConcludeCoordinate Dimostrare che le assunzioni Architetturali sono corretti tramite pezzi funzionati della stessa • Produrre incrementalmente soluzioni utilizzabili; • Condividere lo stato del progetto con gli stakeholder; • Essere in linea con gli obiettivi organizzativi; • Allinearsi con gli altri Team; • Migliorare se stessi ed il Team nell’insieme. • Determinare quando quello che si è sviluppato è sufficiente per il raggiungimento degli obietti; • Stabilizzare la soluzione. Tipicamente: 1 iterazione Caso peggiore: Molte iterazioni Tipicamente: diverse iterazioni Idealmente: alcune ore 22
- 23. Agile@Scale: be SAFe! DADPHASES: AGILE CONSTRUCTION PHASE Typical Construction Iteration for Agile DAD Approach • Iteration planning • Iteration modeling Pratiche standard: • Focalizzare le attività; • Meeting di Coordinamento giornaliero; • Test di regressione; • Evoluzione dell’Architettura ed eventuali Spike relativi (task di una o più story); • Continuous Integration; • Refactoring; • Ritmo sostenibile; • Priorizzare i work item; • Attività di configurazione; • “Track “done” delle attività (es. Burndown) • JIT model storming • Iteration demo; • Retrospettiva; • Valutare le funzionalità sufficienti al raggiungimento dell’obiettivo; • Aggiornamento del Release plan. 2 ore per ogni settimana dell’iterazione Tipicamente: due settimane nel caso di progetti standard, Quattro settimane nel caso di progetti complessi con integrazione tra Team cross-agile Caso peggiore: Sei Settimane 2 ore per ogni settimana dell’iterazione Pratiche avanzate: • Test-driven development (TDD); • Acceptance TDD; • Continuous deployment (CD); • Parallel independent testing; • Non-solo development; • Look-ahead modeling; • Look-ahead planning; • Continuous documentation. Iterationstart Potentiallyconsumablesolution Coordinate Collaborate Conclude 23
- 24. Agile@Scale: be SAFe! DADPHASES: AGILE CONSTRUCTION PHASE Typical Construction Day Coordinate Collaborate Conclude StartofDay WorkingBuild • Meeting di coordinamento giornaliero; • Aggiornamento della Taskboard • Aggiornamento dell’Iteration Burndown. • Affrontare i problemi bloccanti; • Creare i test; • Sviluppare codice; • Integrare quanto sviluppato; • Risolvere i problemi ed i bug; • Modellazione; • Validazione del Codice. • Stabilizzare quanto realizzato. Fino a 15 minuti Tipicamente: 5 o 6 ore Idealmente: Non necessario 24
- 25. Agile@Scale: be SAFe! DADPHASES: TRANSITION PHASE Third Sufficientfunctionality Productionready Collaborate ConcludeCoordinate Pianificazione • Piano di transizione; • Testing e fixing di fine sviluppo; • Pilot della soluzione; • Finalizzare la documentazione; • Comunicare il deployment; • Preparazione ambiente di erogazione; • Training degli stakeholder. • Review dello stato di ready in produzione; • Deploy della soluzione. Idealmente: nessun effort temporale Tipicamente: 1 ora a settimana per l’intera fase Idealmente: nessun effort temporale Media: 4 settimane Caso Peggiore: Più mesi Idealmente: meno di un ora Caso Peggiore: Più mesi 25
- 26. Agile@Scale: be SAFe! GOALDRIVEN Not all iterations are created equal! Construction Goals Transition GoalsInception Goals • Costituire il Team • Identificare la Vision del progetto • Portare gli stakeholder a concordare sulla Vision • Essere allineati al contest aziendale • Identificare la strategia tecnica iniziale, i requisiti iniziali e definire il piano di release iniziale • Configurare l’ambiente (fisico e digitale) di lavoro • Assicurarsi la sostenibilità economica del progetto • Identificare i rischi • Produrre sempre una soluzione potenzialmente utilizzabile • Catturare le richieste di cambiamento proveniente dagli stakeholder • Avvicinarsi velocemente ad una release per il deploy • Mantenere e migliorare i livelli qualitative esistenti • Verificare il prima possibile l’architettura • Garantire che la soluzione è pronta per la produzione • Essere sicuri che gli stakeholder sono pronti per usare la soluzione • Effettuare il deploy della soluzione in produzione • Compiere la missione del progetto • Incrementare le competenze (skill) dei Team Member • Migliorare le infrastrutture esistenti Ongoing Goals • Migliorare i process e l’ambiente • Sfruttare le infrastrutture esistenti • Governare il rischio 26
- 27. Agile@Scale: be SAFe! DADGovernance Strategy • Esistono modalità diverse di governance per i progetti @Scale, in particolare rispetto al contesto di applicazione • DAD supporta differenti strategie e modalità di governance • Le strategie fanno tesoro di quanto già in essere presso l’azienda • Applicare ogni decisione quanto più localmente possibile Corporate Investimenti ITOperationDelivery/Deployment Security Infrastrutture (Servizi, Cloud…) Dati Information Technology 27
- 28. Agile@Scale: be SAFe! SAFeGovernance Deliverable and Alignments Shared Resources • Operat.l Acceptance Plan • Acceptance Criteria Plan • Reqs Specification Doc • Sys Security Plan • Production Ops Manual • Security Guide • 508 Certification • ATO • Privacy Impact Assess • User Guide • SLA Program Portfolio Man. • Quad Chart • IPT Charter • BRD • Project Charter • Acquisition Strategy Program and Release Management • PMP • Transition Plan • Risk Register/Log • Outcome Stmt • Version Description Doc • Deployment Plan • Lessons Learned • Legislation • Budget • Policy • Directives • Architectural Standard • Data Exchange Standards • Hosting Stregies • Security Standards System Architect • System Design Doc System Team • Test Evaluation • Master Test Plan Ruoli SAFe con responsabilità inerenti la documentazione dell’SDLD (Software Development Lifecycle Documentation) 28
- 29. Agile@Scale: be SAFe! DAD«on» SAFe InceptionI ConstructionC TransitionT I C TI C T 29
- 30. Agile@Scale: be SAFe! DAD«on» SAFe I 30
- 31. Agile@Scale: be SAFe! DAD«on» SAFe Collaborate ConcludeCoordinate • Individuare i possibili Team Member; • Pianificare una sessione di “vision” del progetto; • Precettare gli stakeholder per la sessione di “vision” . • Rifinire la Vision; • Effettuare una prima valutazione dei requisiti; • Effettuare una prima ipotesi Architetturale; • Valutare la fattibilità del progetto; • Creare un primo Release Plan; • Strutturare il (i) Team; • Settare l’ambiente; • Garantirsi la sostenibilità economica • Identificare i rischi. • Review di quanto definite (mailstone); • Comunicare la Vision agli stakeholder; • Impegnarsi sulle Iterazioni ed in rilasci continui. Fino ad alcune ore (se tutti gli stakeholder sono disponibili) Idealmente: 1-2 settimane Media: 4 settimane Caso Peggiore: Più mesi Qualche ora I 31
- 32. Agile@Scale: be SAFe! DAD«on» SAFe Collaborate ConcludeCoordinate • Individuare i possibili Team Member; • Pianificare una sessione di “vision” del progetto; • Precettare gli stakeholder per la sessione di “vision” . • Rifinire la Vision; • Effettuare una prima valutazione dei requisiti; • Effettuare una prima ipotesi Architetturale; • Valutare la fattibilità del progetto; • Creare un primo Release Plan; • Strutturare il (i) Team; • Settare l’ambiente; • Garantirsi la sostenibilità economica • Identificare i rischi. • Review di quanto definite (mailstone); • Comunicare la Vision agli stakeholder; • Impegnarsi sulle Iterazioni ed in rilasci continui. Fino ad alcune ore (se tutti gli stakeholder sono disponibili) Idealmente: 1-2 settimane Media: 4 settimane Caso Peggiore: Più mesi Qualche ora I 32
- 33. Agile@Scale: be SAFe! DAD«on» SAFe Collaborate ConcludeCoordinate • Individuare i possibili Team Member; • Pianificare una sessione di “vision” del progetto; • Precettare gli stakeholder per la sessione di “vision” . • Rifinire la Vision; • Effettuare una prima valutazione dei requisiti; • Effettuare una prima ipotesi Architetturale; • Valutare la fattibilità del progetto; • Creare un primo Release Plan; • Strutturare il (i) Team; • Settare l’ambiente; • Garantirsi la sostenibilità economica • Identificare i rischi. • Review di quanto definite (mailstone); • Comunicare la Vision agli stakeholder; • Impegnarsi sulle Iterazioni ed in rilasci continui. Fino ad alcune ore (se tutti gli stakeholder sono disponibili) Idealmente: 1-2 settimane Media: 4 settimane Caso Peggiore: Più mesi Qualche ora I 33
- 34. Agile@Scale: be SAFe! DAD«on» SAFe Collaborate ConcludeCoordinate • Individuare i possibili Team Member; • Pianificare una sessione di “vision” del progetto; • Precettare gli stakeholder per la sessione di “vision” . • Rifinire la Vision; • Effettuare una prima valutazione dei requisiti; • Effettuare una prima ipotesi Architetturale; • Valutare la fattibilità del progetto; • Creare un primo Release Plan; • Strutturare il (i) Team; • Settare l’ambiente; • Garantirsi la sostenibilità economica • Identificare i rischi. • Review di quanto definite (mailstone); • Comunicare la Vision agli stakeholder; • Impegnarsi sulle Iterazioni ed in rilasci continui. Fino ad alcune ore (se tutti gli stakeholder sono disponibili) Idealmente: 1-2 settimane Media: 4 settimane Caso Peggiore: Più mesi Qualche ora I 34
- 35. Agile@Scale: be SAFe! DAD«on» SAFe • Iteration planning • Iteration modeling Pratiche standard: • Focalizzare le attività; • Meeting di Coordinamento giornaliero; • Test di regressione; • Evoluzione dell’Architettura ed eventuali Spike relativi (task di una o più story); • Continuous Integration; • Refactoring; • Ritmo sostenibile; • Priorizzare i work item; • Attività di configurazione; • “Track “done” delle attività (es. Burndown) • JIT model storming • Iteration demo; • Retrospettiva; • Valutare le funzionalità sufficienti al raggiungiment o dell’obiettivo; • Aggiornamento del Release plan. Pratiche avanzate: • Test-driven development (TDD); • Acceptance TDD; • Continuous deployment (CD); • Parallel independent testing; • Non-solo development; • Look-ahead modeling; • Look-ahead planning; • Continuous documentation. Coordinate Collaborate Conclude C 35
- 36. Agile@Scale: be SAFe! DAD«on» SAFe InceptionI ConstructionC TransitionT I C TI C T • Iteration planning • Iteration modeling Pratiche standard: • Focalizzare le attività; • Meeting di Coordinamento giornaliero; • Test di regressione; • Evoluzione dell’Architettura ed eventuali Spike relativi (task di una o più story); • Continuous Integration; • Refactoring; • Ritmo sostenibile; • Priorizzare i work item; • Attività di configurazione; • “Track “done” delle attività (es. Burndown) • JIT model storming • Iteration demo; • Retrospettiva; • Valutare le funzionalità sufficienti al raggiungiment o dell’obiettivo; • Aggiornamento del Release plan. Pratiche avanzate: • Test-driven development (TDD); • Acceptance TDD; • Continuous deployment (CD); • Parallel independent testing; • Non-solo development; • Look-ahead modeling; • Look-ahead planning; • Continuous documentation. Coordinate Collaborate Conclude C 36
- 37. Agile@Scale: be SAFe! DAD«on» SAFe • Iteration planning • Iteration modeling Pratiche standard: • Focalizzare le attività; • Meeting di Coordinamento giornaliero; • Test di regressione; • Evoluzione dell’Architettura ed eventuali Spike relativi (task di una o più story); • Continuous Integration; • Refactoring; • Ritmo sostenibile; • Priorizzare i work item; • Attività di configurazione; • “Track “done” delle attività (es. Burndown) • JIT model storming • Iteration demo; • Retrospettiva; • Valutare le funzionalità sufficienti al raggiungiment o dell’obiettivo; • Aggiornamento del Release plan. Pratiche avanzate: • Test-driven development (TDD); • Acceptance TDD; • Continuous deployment (CD); • Parallel independent testing; • Non-solo development; • Look-ahead modeling; • Look-ahead planning; • Continuous documentation. Coordinate Collaborate Conclude C 37
- 38. Agile@Scale: be SAFe! DAD«on» SAFe 38 • Iteration planning • Iteration modeling Pratiche standard: • Focalizzare le attività; • Meeting di Coordinamento giornaliero; • Test di regressione; • Evoluzione dell’Architettura ed eventuali Spike relativi (task di una o più story); • Continuous Integration; • Refactoring; • Ritmo sostenibile; • Priorizzare i work item; • Attività di configurazione; • “Track “done” delle attività (es. Burndown) • JIT model storming • Iteration demo; • Retrospettiva; • Valutare le funzionalità sufficienti al raggiungiment o dell’obiettivo; • Aggiornamento del Release plan. Pratiche avanzate: • Test-driven development (TDD); • Acceptance TDD; • Continuous deployment (CD); • Parallel independent testing; • Non-solo development; • Look-ahead modeling; • Look-ahead planning; • Continuous documentation. Coordinate Collaborate Conclude C
- 39. Agile@Scale: be SAFe! DAD«on» SAFe • Iteration planning • Iteration modeling Pratiche standard: • Focalizzare le attività; • Meeting di Coordinamento giornaliero; • Test di regressione; • Evoluzione dell’Architettura ed eventuali Spike relativi (task di una o più story); • Continuous Integration; • Refactoring; • Ritmo sostenibile; • Priorizzare i work item; • Attività di configurazione; • “Track “done” delle attività (es. Burndown) • JIT model storming • Iteration demo; • Retrospettiva; • Valutare le funzionalità sufficienti al raggiungiment o dell’obiettivo; • Aggiornamento del Release plan. Pratiche avanzate: • Test-driven development (TDD); • Acceptance TDD; • Continuous deployment (CD); • Parallel independent testing; • Non-solo development; • Look-ahead modeling; • Look-ahead planning; • Continuous documentation. Coordinate Collaborate Conclude C 39
- 40. Agile@Scale: be SAFe! DAD«on» SAFe I C TI C T Collaborate ConcludeCoordinate Pianificazione • Piano di transizione; • Testing e fixing di fine sviluppo; • Pilot della soluzione; • Finalizzare la documentazione; • Comunicare il deployment; • Preparazione ambiente di erogazione • Training degli stakeholder. • Review dello stato di ready in produzione; • Deploy della soluzione. Idealmente: nessun effort temporale Tipicamente: 1 ora a settimana per l’intera fase Idealmente: nessun effort temporale Media: 4 settimane Caso Peggiore: Più mesi Idealmente: meno di un ora Caso Peggiore: Più mesi T 40
- 41. Agile@Scale: be SAFe! DAD«on» SAFe 41 Collaborate ConcludeCoordinate Pianificazione • Piano di transizione; • Testing e fixing di fine sviluppo; • Pilot della soluzione; • Finalizzare la documentazione; • Comunicare il deployment; • Preparazione ambiente di erogazione; • Training degli stakeholder. • Review dello stato di ready in produzione; • Deploy della soluzione. Idealmente: nessun effort temporale Tipicamente: 1 ora a settimana per l’intera fase Idealmente: nessun effort temporale Media: 4 settimane Caso Peggiore: Più mesi Idealmente: meno di un ora Caso Peggiore: Più mesi T
- 42. Agile@Scale: be SAFe! DAD«on» SAFe TransitionT Collaborate ConcludeCoordinate Pianificazione • Piano di transizione; • Testing e fixing di fine sviluppo; • Pilot della soluzione; • Finalizzare la documentazione; • Comunicare il deployment; • Preparazione ambiente di erogazione • Training degli stakeholder. • Review dello stato di ready in produzione; • Deploy della soluzione. Idealmente: nessun effort temporale Tipicamente: 1 ora a settimana per l’intera fase Idealmente: nessun effort temporale Media: 4 settimane Caso Peggiore: Più mesi Idealmente: meno di un ora Caso Peggiore: Più mesi 42 T
- 43. Agile@Scale: be SAFe! DAD«on» SAFe Collaborate ConcludeCoordinate Pianificazione • Piano di transizione; • Testing e fixing di fine sviluppo; • Pilot della soluzione; • Finalizzare la documentazione • Comunicare il deployment; • Preparazione ambiente di erogazione; • Training degli stakeholder. • Review dello stato di ready in produzione; • Deploy della soluzione. Idealmente: nessun effort temporale Tipicamente: 1 ora a settimana per l’intera fase Idealmente: nessun effort temporale Media: 4 settimane Caso Peggiore: Più mesi Idealmente: meno di un ora Caso Peggiore: Più mesi T 43
- 44. Agile@Scale: be SAFe! DAD«on» SAFe Collaborate ConcludeCoordinate Pianificazione • Piano di transizione; • Testing e fixing di fine sviluppo; • Pilot della soluzione; • Finalizzare la documentazione • Comunicare il deployment; • Preparazione ambiente di erogazione; • Training degli stakeholder. • Review dello stato di ready in produzione; • Deploy della soluzione. Idealmente: nessun effort temporale Tipicamente: 1 ora a settimana per l’intera fase Idealmente: nessun effort temporale Media: 4 settimane Caso Peggiore: Più mesi Idealmente: meno di un ora Caso Peggiore: Più mesi T 44
- 45. Agile@Scale: be SAFe! DAD«on» SAFe Collaborate ConcludeCoordinate Pianificazione • Piano di transizione; • Testing e fixing di fine sviluppo; • Pilot della soluzione; • Finalizzare la documentazione • Comunicare il deployment; • Preparazione ambiente di erogazione; • Training degli stakeholder. • Review dello stato di ready in produzione; • Deploy della soluzione. Idealmente: nessun effort temporale Tipicamente: 1 ora a settimana per l’intera fase Idealmente: nessun effort temporale Media: 4 settimane Caso Peggiore: Più mesi Idealmente: meno di un ora Caso Peggiore: Più mesi T 45
- 46. Agile@Scale: be SAFe! SAFeKey Point • Framework maturo e robusto, ben documentato e utilizzato in diversi contesti reali; • Ruolo centrale delle persone in tutte le fasi di delivery, con ruoli chiari, artefatti precisi e eventi espliciti; • Visione olistica dell’organizzazione aziendale, con una identificazione di 3 livelli di partecipazione e valore; • Focus sulla qualità del software (Agile & DevOps); • Costanti review ed aggiornamenti. • Prescrittivo; • Pesante/Complesso; • Incentrato sui processi di Certificazione; Pro Pro 46
- 47. Agile@Scale: be SAFe! DADKey Point • Framework ibrido che si fonda su approcci Agile e Lean affermati; • La gestione delle milestone permette di adattarlo a contesti enterprise reali; • Ampia flessibilità rispetto alle pratiche Agili da adottare; • Forte attenzione sugli aspetti architetturali ed ingegneristici; • Governance chiara per i program/product manager. • Adozione poco nota; • Limitata azione di formazione per la certificazione; • Mancanza di prescrizioni per un’adozione sistematica delle pratiche Agili. Pro Pro 47
- 48. Agile@Scale: be SAFe! @felicepescatore ABOUTME get in touch Disciplined Agile Delivery Italy Group Felice Pescatore, Agile Software Architect Email: felice.pescatore@gmail.com Cell. 392/7157684 www.felicepescatore.it 48
- 49. Agile@Scale: be SAFe! THANKSFOR WATCHING Quest'opera è distribuita con Licenza Creative Commons Attribuzione - Non commerciale 3.0 Italia.