Agile@scale - Agile Day 2013

  • 2,697 views
Uploaded on

Talk introduttivo tenuto all'IAD 2013 su Agile@Scale e DAD/TFS.

Talk introduttivo tenuto all'IAD 2013 su Agile@Scale e DAD/TFS.

More in: Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,697
On Slideshare
0
From Embeds
0
Number of Embeds
6

Actions

Shares
Downloads
25
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. PROGRAM AGILE_AT_SCALE DO 10, I=1,10 PRINT *,'Agile @Scale: Hello World!' 10 CONTINUE STOP END Agile Day 2013 – Agile@Scale: Hello World Felice Pescatore L’adozione di Agile in contesti enterprise strutturalmente legati al pattern command-and-control 1
  • 2. Abstract @scale…. What? Agile@Scale :Hello World Agile Day 2013 – Agile@Scale: Hello World In questo talk andremo a vedere come sia possibile adottare in un contesto particolarmente burocratizzato e fortemente legato al pattern command-and-control, un approccio Agile per l’Application Life Management (ALM), ovvero per la gestione dell’intero ciclo di vita di un progetto software di tipo enterprise. 2
  • 3. We talk about …. and more > > > Agile Day 2013 – Agile@Scale: Hello World Il Sistema Software: dalla sua idea alla sua dismissione Agile Framewok: Disciplined Agile Delivery Applicazione pratica: il contesto della PA 3
  • 4. A new project… Salve capo, ho parlato con il cliente… ho capito tutto!!!! Allora domattina partiamo, tanto siamo Agili e possiamo correggere il tiro durante le iterazioni Hmmm… fammi capire una cosa: hai fatto una previsione di costo (e di tempi) sul progetto? Siamo in grado di realizzare quanto richiesto con il knowhow interno? A che rischi ci esponiamo? Dovrei fare un’analisi funzionale e concordare con il cliente quanto necessario. Scusa, ma non siamo Agili? Mi stai dicendo di dover fare un’analisi up-front per rispondere alle mie domande in stile waterfall? @!#!!@@... beh forse basterebbero 6 mesi per lo sviluppo e 5/6 sviluppatori. E il resto del Team di Delivery, oltre alle tecnologie, all’architettura ai tempi di messa in produzione e ai costi di manutenzione? ????? ma io…. io in realtà sono un Product Owner… queste cose sono più aspetti tecnologici e tecnici. Dovremmo discuterne con il Team…. Ma non abbiamo il Team e non possiamo costituirne uno senza avere un’idea di massima dei vari elementi del progetto che ci consentano di decidere se impegnarci o meno in esso. @!#!!@@.. . Forse questo Agile non è proprio un granché. Agile Day 2013 – Agile@Scale: Hello World 4
  • 5. Software Project Visto dallo SVILUPPATORE Quando dobbiamo ultimarlo ? Che linguaggio usiamo? Ancora un’altra attività? Ho troppe cose da fare! Chi fa cosa? Agile Day 2013 – Agile@Scale: Hello World Il PM (Team Lead) non mi convince. Quali funzionalità inseriremo nella prima versione? Perché non utilizziamo l’ultimo framework per questo? Qual è l’architettura del sistema? Devo aggiornare le mie competenze Qual è il Data Model del sistema? 5
  • 6. Software Project Visto dal BUSINESS Quando tempo impiegheremo? Quante risorse per il Team di Dev? Chi allochiamo come capo progetto? Agile Day 2013 – Agile@Scale: Hello World Quanto ci costa? Quali funzionalità inseriremo nella prima versione? Chi è il principale sponsor finanziario? (chi ci paga?) Possiamo riutilizzare qualcosa già fatto? Come facciamo a monitorare e controllare le attività? Siamo sicuri di farcela con i tempi e con i costi stimati? Riusciremo a sviluppare un sistema di qualità? 6
  • 7. Creare VALORE Common objective Customer BUSINESS ( & stakeholders) Business Value • • • • • • • Deployment Team Internal Stakeholder Team Lead Project Manager Business Smell Reduce Time-to-Market • Quality Delivered to Customer Is Unacceptable Augment Value-To• Delivering New Features to Market Customer Takes Too Long Increase Quality-To• Features Are Not Used by Market Customer Increase Flexibility • Software Is Not Useful to Increase Visibility Customer Reduce Cost • Software Is Too Expensive to Increase Product Build Lifetime • Us Versus Them • Customer Asks for Everything Including the Kitchen Sink Agile Day 2013 – Agile@Scale: Hello World Company Sponsor Software Architect DevOps > > > > Soluzioni rispondenti alle attese Minore Time-to-market ROI più corto Riduzione waste-time …. 7
  • 8. IT Project Management World most used Methodology 14.00% Agile Adoption (38,6 %) Agile 12.00% Agile Methodologies Nessuna Iterative RUP Spirale Waterfall CMMI ISO 9000 10.00% 8.00% 6.00% 4.00% 2.00% 0.00% 0.00% 10.00% 20.00% 30.00% 40.00% 50.00% 2009 2010 Source: Forrester/Dr. Dobb’s Global Developer Technographics® Survey, Q3 2010 Source: Forrester/Dr. Dobb’s Global Developer Technographics Survey, Q3 2009 2010 (2010) (2009) 2009 Base: 1,023 application development professionals Base: 1,298 application development professionals † Agile Day 2013 – Agile@Scale: Hello World 8
  • 9. Pure Agile? sorry, Water-SCRUM-Fall Agile PURE Adoption (26 %) termine derivato da una ricerca di Forrester intitolata “Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today”. Our methodology is a helpful guide, but we diverge from it in order to deliver on time 9% 3% We follow our methodology closely and seldom diverge from it 47% 26% Our methodology is key to the success of our project We pay lip service to our methodology, but it’s really shelfware 15% Our methodology neither helps, nor impedes our progress Si rischia di complicare la governance del progetto prendendo a caso pezzi del mondo Agile e pezzi del mondo Waterfall: • profonda modellazione e pianificazione; • approccio simil-Scrum per il development della soluzione; • processo di delivery complesso e lungo. Source: Forrester/Dr. Dobb’s Global Developer Technographics® Survey, Q3 2009 Agile Day 2013 – Agile@Scale: Hello World 9
  • 10. Disciplined Agile Delivery Our choice Construction & Transition Inception Business + Deploy Team + Customer & External Stakeholders Disciplined Agile Delivery (DAD) è un process framework Agile utile a gestire in modo integrato l’ALM in contesti enterprise, prediligendo un approccio: • People-first • Learning-oriented • Risk and Value driven • Goal-driven • Hybrid • Enterprise aware Unified Process (UP) «Hybrid process framework» che adotta il meglio delle pratiche e delle filosofie delle varie metodologie “CORE” Agile Extreme Programming (XP) Disciplined Agile Delivery (DAD) Scrum Agile Modeling Harmony Process Lean • Scalable Agile Day 2013 – Agile@Scale: Hello World 10
  • 11. The Road Ahead for agility@scale Team size Compliance requirement 1000’s of developers Under 10 developers Critical, audited Low risk Domain Complexity Geographical distribution Co-located Straight -forward Global Disciplined Agile Delivery Enterprise discipline Project focus Enterprise focus Agile Day 2013 – Agile@Scale: Hello World Organization distribution (outsourcing, partnerships) Collaborative Organizational complexity Flexible Intricate, emerging Rigid Contractual Technical complexity Homogenous Heterogeneous, legacy 11
  • 12. Value & Risk Driven • Lavorare prima sugli elementi a maggior Valore per gli stakeholder; • Continua verifica del Valore prodotto; • Determinare quando è stato state implementate funzionalità sufficienti a soddisfare il Valore richiesto; • Produrre sempre soluzioni potenzialmente utilizzabili durante il ciclo di vita; • Valutare continuamente nuovi elementi di lavoro aggregate alla crescente comprensione di ciò che realmente si vuole ottenere. Risk Driven Goal based Value Driven Agile Day 2013 – Agile@Scale: Hello World • Validare l’Architettura il prima possibile; • Ottenere il consenso degli Stakeholder con dimostrazioni pratiche; • Essere compliance con la direzione aziendale (enterprise aware); • Lavorare prima su ciò che porta un reale incremento di know-how al Team; • Abbattere il debito tecnico; • Utilizzare degli Spike per verificare specifiche assunzioni. 12
  • 13. GOAL … must be S.M.A.R.T GOAL: a measurable value…. not only… GOAL must be SMART! • • • • • Specific, ovvero chiaro e identificabile (es: abbattere il Time-to-Market); Measurable, implica la possibilità di tracciare i progressi e capire quando si è raggiunto l'obiettivo (es: il nuovo Time-to-Market deve essere di 3mesi); Achievable, ovvero alla portata del Team che lo prende in carico (es: il nuovo Time-toMarket deve essere di 1gg non è ragionevole); Relevant, deve essere sentito come qualcosa di importante (es: in generale, interessa a ben pochi che avete impiegato 2gg per migliorare - un algoritmo di ricerca di 1ms); Timely, sviluppato quando richiesto. Agile Day 2013 – Agile@Scale: Hello World 13
  • 14. 3C Rythm …not only music! Ciclo di Deming (Deming Cycle) che prevede un miglioramento costante grazie ad una interazione tra ricerca, progettazione, test, produ zione e vendita DAD contempla al suo interno un modello di qualità che prende il nome di 3C Rhythm, ovvero un Ritmo (o se vogliamo Cadenza) scandito su tre Accenti. Coordinate Collaborate Conclude D - Do. Esecuzione del programma, dapprima in contesti circoscritti; Release rhythm Inception Construction Transition Coordinate Collaborate Conclude Iteration Planning Development Stabilize Coordinate P - Plan. Pianificazione; Collaborate Conclude Coordinatio n Meeting Daily Work Stabilize Coordinate Collaborate Conclude C - Check. Test e controllo, studio e raccolta dei risultati e dei riscontri; A - Act. Azione per rendere definitivo e/o migliorare il processo Iteration rhythm Coordinate::Plan Collaborate::Do e parte di Check Conclude::parte di Check ed Act Agile Day 2013 – Agile@Scale: Hello World Daily rhythm 14
  • 15. People First Principles and Values Le Persone ed il modo in cui collaborano sono l’elemento primario per il successo DAD TEAM Members are encouraged to Self Disciplined: impegnati solo sul lavoro che si è in grado di fare bene Agile Day 2013 – Agile@Scale: Hello World Self Organizing: stima e pianificazione del proprio lavoro Self Aware: capire come migliorarsi Cross functional teams Specialisti trasversali Nessuna gerarchia nel Team 15
  • 16. People First Learning Oriented Domain learning Primo approccio ai requisiti Rilascio incrementali di soluzioni potenzialmente utilizzabili Partecipazione attiva degli stakeholder durante tutto il ciclo di vita del sistema Process improvement Retrospettiva alla fine delle Iterazioni Monitoraggio dei miglioramenti Condivisione degli skill tramite la pratica del “non-solo development” Agile Day 2013 – Agile@Scale: Hello World Technical learning Spike Architetturali Confutare le scelte Architetturali tramite soluzioni funzionanti (working code) General strategies Training Education Mentoring/coaching I Membri del Team sono “general specialist” e non solo “specialist” 16
  • 17. People First Potential roles on disciplined agile teams Business Analyst Secondary roles • • • • • Domain Expert Technical Expert Independent Tester Integrator Specialist Primary roles Stakeholder Team Lead Product Owner Agile Team Member Architecture Owner Agile Day 2013 – Agile@Scale: Hello World Project Manager • • • • • 17
  • 18. Enterprise Aware Governing Agile Team Un Team Agile, per propria natura, fornisce: • Un aggiornamento continuo dello stato di Pratiche: avanzamento del progetto (fotografia) agli • Partecipazione attiva degli stakeholder; stakeholder; • Soluzioni potenzialmente utilizzabili ad ogni iterazione; • Importanti momenti di condivisione per consentire agli stakeholder di indirizzare lo scope del progetto; • Richiede un impegno superiore per gli stakeholder che devono essere fattivamente presenti. • Risk-value lifecycle; • Review esplicite di milestone light-weight • Meeting giornaliero di coordinamento; • Demo al completamento di ogni iterazione; • Demo «all-hands», ovvero con il supporto di tutto il Team e tenuta a rotazione; • Seguire le convenzioni aziendali; • Lavorare a stretto contatto con gli Architect aziendali; • Metriche automatizzate per la valutazione dei risultati in ottica auto- migliorativa. Agile Day 2013 – Agile@Scale: Hello World 18
  • 19. Enterprise Aware Know your company Seguire le convenzioni aziendali • Standard e best practice Architetturali; • Best practice di Codifica; • Best practice di gestione dei Dati; • Linee guida nella definizione della User • Team; • infrastrutture aziendali; • Migliorare e sviluppare le infrastrutture aziendali; • Lavorare a stretto contatto con l’Enterprise Architecture (EA) Team. Agile Day 2013 – Agile@Scale: Hello World Contribuire alla crescita dell’azienda nel complesso; • Interface (UI); • Riutilizzare e sfruttare al massimo le Contribuire alla crescita personale e del Arricchire e rafforzare il know-how relativo all’Agile. • Enterprise Architecture Team; • Data Management Team; • Governance Aziendale; • Quality Assurance; • Project management Office (PMO). Interazione Migliorare l’ecosistema aziendale Seguire le convenzioni aziendali: Condivisione della conoscenza • 19
  • 20. Process Model Base, Agile Based «DAD promotes following a full delivery lifecycle – be it a Scrum-based one, an agile one, a continuous delivery one, or something else – that is as light as your situation allows.» BASIC Agile Based Discipline Personal Agility Agile Day 2013 – Agile@Scale: Hello World 20
  • 21. Process Model Advanced, Lean Based ADVANCED Lean Based MORE Discipline Personal Agility Agile Day 2013 – Agile@Scale: Hello World 21
  • 22. Inception Phase First Phase • Individuare i possibili Team Member; • Pianificare una sessione di “vision” del progetto; • Precettare gli stakeholder per la sessione di “vision” . Collaborate • Rifinire la Vision; • Effettuare una prima valutazione dei requisiti; • Effettuare una prima ipotesi Architetturale; • Valutare la fattibilità del progetto; Conclude • Review di quanto definite (mailstone); • Comunicare la Vision agli stakeholder; • Impegnarsi sulle Iterazioni ed i rilasci continui. • Creare un primo Release Plan; • Strutturare il (i) Team; • Settare l’ambiente; Stakeholder consensus Project / Product Approved to start Coordinate • Garantirsi la sostenibilità economica • Identificare i rischi. Fino ad alcune ore (se tutti gli stakeholder sono disponibili) Agile Day 2013 – Agile@Scale: Hello World Idealmente: 1-2 settimane Media: 4 settimane Caso Peggiore: Più mesi Qualche ora 22
  • 23. Construction Phase Second Phase Dimostrare che le assunzioni Architetturali sono corretti tramite pezzi funzionati della stessa Collaborate • Produrre incrementalmente soluzioni utilizzabili; • Condividere lo stato del progetto con gli stakeholder; Conclude • Determinare quando quello che si è sviluppato è sufficiente per il raggiungimento degli obietti; • Stabilizzare la soluzione. • Essere in linea con gli obiettivi organizzativi; • Allinearsi con gli altri Team; • Migliorare se stessi ed il Team nell’insieme. Tipicamente: 1 iterazione Caso peggiore: Molte iterazioni Agile Day 2013 – Agile@Scale: Hello World Tipicamente: diverse iterazioni Sufficient Functionality Stakeholder consensus Coordinate Idealmente: alcune ore 23
  • 24. Construction Phase Typical Construction Iteration • Iteration planning • Iteration modeling Collaborate Pratiche standard: Pratiche avanzate: • Focalizzare le attività; • Test-driven development (TDD); • Iteration demo; • Meeting di Coordinamento giornaliero; • Acceptance TDD; • Retrospettiva; • Test di regressione; Iteration start Conclude • Evoluzione dell’Architettura ed eventuali Spike relativi (task di una o più story); • Continuous deployment (CD); • Parallel independent testing; • Non-solo development; • Look-ahead modeling; • Continuous Integration; • Look-ahead planning; • Refactoring; • Continuous documentation. • Ritmo sostenibile; • Valutare le funzionalità sufficienti al raggiungimento dell’obiettivo; • Aggiornamento del Release plan. • Priorizzare i work item; • Attività di configurazione; • “Track “done” delle attività (es. Burndown) Potentially consumable solution Coordinate • JIT model storming 2 ore per ogni settimana dell’iterazione 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 Agile Day 2013 – Agile@Scale: Hello World 24
  • 25. Construction Phase Typical Construction Day Coordinate Collaborate • Affrontare i problemi bloccanti; Aggiornamento della Taskboard • Stabilizzare quanto realizzato. • Sviluppare codice; Aggiornamento dell’Iteration Burndown. • Creare i test; Working Build Start of Day Meeting di coordinamento giornaliero; Conclude • Integrare quanto sviluppato; • Risolvere i problemi ed i bug; • Modellazione; • Validazione del Codice. Fino a 15 minuti Agile Day 2013 – Agile@Scale: Hello World Tipicamente: 5 o 6 ore Idealmente: Non necessario 25
  • 26. Transition Phase Third Phase Pianificazione Collaborate • Piano di transizione; Sufficient functionality • Testing e fixing di fine sviluppo; • Pilot della soluzione; Conclude • Review dello stato di ready in produzione; • Deploy della soluzione. Production ready Coordinate • Finalizzare la documentazione; • Comunicare il deployment; • Training degli stakeholder. Idealmente: nessun effort temporale Tipicamente: 1 ora a settimana per l’intera fase Agile Day 2013 – Agile@Scale: Hello World Idealmente: nessun effort temporale Media: 4 settimane Caso Peggiore: Più mesi Idealmente: meno di un ora Caso Peggiore: Più mesi 26
  • 27. Phases Goals Not all iterations are created equal! Inception Goal • 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 Transition Goal Construction Goal • Produrre sempre una soluzione potenzialmente utilizzabile Garantire che la soluzione è pronta per la produzione • Catturare le richieste di cambiamento proveniente dagli stakeholder Essere sicuri che gli stakeholder sono pronti per usare la soluzione • Avvicinarsi velocemente ad una release per il deploy Effettuare il deploy della soluzione in produzione • Configurare l’ambiente (fisico e digitale) di lavoro • Mantenere e migliorare i livelli qualitative esistenti • Assicurarsi la sostenibilità economica del progetto • Verificare il prima possibile l’architettura • Identificare i rischi Ongoing Goal • Compiere la missione del progetto • Migliorare i process e l’ambiente • Incrementare le competenze (skill) dei Team Member • Sfruttare le infrastrutture esistenti • Migliorare le infrastrutture esistenti • Governare il rischio Agile Day 2013 – Agile@Scale: Hello World 27
  • 28. Case Study Ancitel SpA Ancitel: azienda operante nel campo dei servizi per la PA Tutto bello, ma funziona? Si, con disciplina e impegno! Agile Day 2013 – Agile@Scale: Hello World 28
  • 29. Case Study Ancitel SpA – Laboratorio Smart Services and Meta Services for SMART e-Government • SMART è un progetto sperimentale di ricerca industriale che vuole rispondere in modo innovativo ai bisogni nel mercato dei servizi di e-Government. • In collaborazione con l’Università di Milano Bicocca e altri partner industriali, SMART affronta il tema dei servizi di e-Government a disposizione del cittadino applicando in modo industriale l’approccio innovativo della service science, in cui produttore e consumatore collaborano insieme per realizzare un sistema a valore aggiunto. • Nella progettazione dei servizi si considerano i punti di vista di tutti gli attori interessati (cittadini, imprese, Pubbliche Amministrazioni) combinando, integrando e realizzando servizi a valore aggiunto • Per realizzare il progetto SMART, è stato aperto un laboratorio di ricerca ed innovazione nella sede di Napoli. Agile Day 2013 – Agile@Scale: Hello World 29
  • 30. Case Study Ancitel SpA Ancitel: azienda operante nel campo dei servizi per la PA • • • • • • Laboratorio «SMART» di innovazione per la PA Nuovo progetto Membri del Team assolutamente entusiasti Apertura e disponibilità dei dirigenti aziendali Possibilità di adozione di tool maturi ed innovativi Completa fiducia dai diretti responsabili Agile Day 2013 – Agile@Scale: Hello World • • • • • Team junior e neo-formato Nessuna adozione Agile pre-esistente Complessità dello scenario di riferimento Contesto di fruizione non preparato ad una costante collaborazione ed interazione Iniziale diffidenza del resto della struttura IT 30
  • 31. Case Study Ancitel SpA Inception Agile Day 2013 – Agile@Scale: Hello World 31
  • 32. Case Study Ancitel SpA Construction Agile Day 2013 – Agile@Scale: Hello World 32
  • 33. Case Study Ancitel SpA Transition Agile Day 2013 – Agile@Scale: Hello World 33
  • 34. Agile@Scale and… … at Work! DEMO Agile Day 2013 – Agile@Scale: Hello World 34
  • 35. Agile Day 2013 – Agile@Scale: Hello World 35
  • 36. www.felicepescatore.it THANK YOU Agile Software Architect & Metodology Head Ancitel Spa Agile Day 2013 – Agile@Scale: Hello World @felicepescatore Disciplined Agile Delivery Italy Group 36