Agile@scale: be SAFe!

656 views

Published on

Confronto tra i framework Agile@Scale, SAFe & DAD.

Published in: Engineering
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
656
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
22
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Agile@scale: be SAFe!

  1. 1. Agile@Scale: be SAFe! DAD & SAFe 07 Aprile 2014 @felicepescatore Disciplined Agile Delivery Italy Groupwww.felicepescatore.it Felice Pescatore
  2. 2. Agile@Scale: be SAFe! Reality is complex… software is complex! COMPLEX Emergent Practices COMPLICATED Good Practices CHAOTIC Novel Practices SIMPLE Best Practices Cynefin Model 2
  3. 3. Agile@Scale: be SAFe! Too complicated 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. 4. Agile@Scale: be SAFe! Con il 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. 5. Agile@Scale: be SAFe! Agile Manifesto 5
  6. 6. Agile@Scale: be SAFe! What Agile isn’t… 6
  7. 7. Agile@Scale: be SAFe! DSDM Atern 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. 8. Agile@Scale: be SAFe! Domain Complexity 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. 9. Agile@Scale: be SAFe! A project is more than only development… @Scale… why? 9
  10. 10. Agile@Scale: be SAFe! The Idea, 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. 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. 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. 13. Agile@Scale: be SAFe! SAFe «Big Picture» 13
  14. 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. 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. 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. 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. 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. 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. 20. Agile@Scale: be SAFe! THE AGILE 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. 21. Agile@Scale: be SAFe! DAD PHASES: 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. 22. Agile@Scale: be SAFe! DAD PHASES: 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. 23. Agile@Scale: be SAFe! DAD PHASES: 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. 24. Agile@Scale: be SAFe! DAD PHASES: 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. 25. Agile@Scale: be SAFe! DAD PHASES: 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. 26. Agile@Scale: be SAFe! GOAL DRIVEN 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. 27. Agile@Scale: be SAFe! DAD Governance 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. 28. Agile@Scale: be SAFe! SAFe Governance 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. 29. Agile@Scale: be SAFe! DAD «on» SAFe InceptionI ConstructionC TransitionT I C TI C T 29
  30. 30. Agile@Scale: be SAFe! DAD «on» SAFe I 30
  31. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 46. Agile@Scale: be SAFe! SAFe Key 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. 47. Agile@Scale: be SAFe! DAD Key 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. 48. Agile@Scale: be SAFe! @felicepescatore ABOUT ME 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. 49. Agile@Scale: be SAFe! THANKS FOR WATCHING Quest'opera è distribuita con Licenza Creative Commons Attribuzione - Non commerciale 3.0 Italia.

×