Download to read offline
![… a lot use Water-scrum-Fall
“We believe over 90% of all companies claiming to have adopted agile methodologies, have
only transformed their development teams, minimizing their overall return…thus, our term
“Water-Scrum-Fall”. [Dave West, Forrester Research 2011]
Water scrum Fall](https://image.slidesharecdn.com/2015agilescale-dadevisualstudioonlinedotnetcampus15-150531191020-lva1-app6891/85/DAD-e-Visual-Studio-Online-8-320.jpg)
Uploaded byFelice Pescatore
DAD e Visual Studio Online
Il documento spiega il framework 'Disciplined Agile Delivery' (DAD) come un approccio integrante per la gestione del ciclo di vita delle soluzioni software, enfatizzando la centralità delle persone e un focus sui valori aziendali. Sottolinea come DAD permetta di affrontare sistemi complessi e di promuovere un delivery end-to-end, e illustra le pratiche agili più efficaci a seconda del contesto. Viene anche evidenziato il concetto di 'water-scrum-fall' e il valore di un approccio ibrido per massimizzare il valore per gli stakeholder.
More Related Content
Similar to DAD e Visual Studio Online
DAD e Visual Studio Online
- 1. Template designed by DisciplinedAgile Delivery e Visual Studio Online Agile@Scale series Felice Pescatore felicepescatore.it @felicepescatore
- 2. Chi sono felicepescatore.it @felicepescatore Felice Pescatore Agile@ScaleItaly Group getlatestversion
- 3. Agenda Holistic Vision Agile &Water-scrum-Fall Disciplined Agile Delivery DAD & Visual Studio Online Demo Recap Riferimenti e Risorse
- 4.
- 5. Be Agile isa Must! L’ Agile migliora la collaborazione all’interno del Team e quella con l’esterno, puntando a creare il massimo Valore possibile per gli stakeholder. I Valori e i Principi, dovrebbero essere sempre utilizzati, in qualsiasi contesto produttivo, a differenza di una Metodologia specifica che può essere più o meno adatta.
- 6. Reality is complex…software is complex! • Se siamo in presenza di sistemi Complessi, le metodologie Agili sono la soluzione ideale; • Se siamo in presenza di sistemi Semplici o Complicati, possiamo ricorrere a metodologie tradizionali, perché il dominio di riferimento è noto e la variabilità è estremamente bassa. Ad esempio, per i sistemi Complicati, si può pensare di utilizzare il modello a Spirale, ma non è da escludere lo stesso Waterfall; • Se siamo in presenza del Caos la scelta migliore è, probabilmente, quella di abortire il progetto!
- 7. Agile is areality, but…
- 8. … a lotuse Water-scrum-Fall “We believe over 90% of all companies claiming to have adopted agile methodologies, have only transformed their development teams, minimizing their overall return…thus, our term “Water-Scrum-Fall”. [Dave West, Forrester Research 2011] Water scrum Fall
- 9.
- 10. Agile Umbrella RUP (120+) XP (13) Scrum(9) Kanban (3) Do Whatever!! (0) More Prescriptive More Adaptive RUP has over 30 roles, over 20 activities, and over 70 artifacts more rules to follow fewer rules to follow DSDM Atern Agile Unified Process (AUP) Feature Driven Development Process Approaches (still agile) SCRUM Crystal eXtreme Programming (XP) Lightweight Approaches Agile Disciplined Agile Delivery Scaled Agile Framework@Scale@Scale
- 11. Agile@Scale «Scaling», significa aiutarel’intera azienda nell‘adozione dei Valori e dei Principi Agili, con un occhio attento anche al mondo Lean. E’ molto difficile «scalare» se non si ha già maturato una forte competenza dell’Agile a livello di Team (Team Level)
- 12. Agile@Scale Agile DAD @Scale • Focalizzarsi sugliobiettivi; • Value driven lifecycle; • Team Self-organized; • Prescrittivo; • Project Aware. • Focus sul Delivery; • Risk & Value driven lifecycle; • Team Self-organized con opportuna governance; • Goal driven; • Enterprise Aware. • Grandi Team; • Team distribuiti geograficamente; • Complessità del Dominio; • Complessità Tecnica; • Distribuzione organizzativa.
- 13. Disciplined Agile DeliveryDisciplinedAgile Delivery, DAD DISCIPLINED AGILE DELIVERY
- 14. Disciplined Agile Delivery DisciplinedAgile Delivery (DAD) è un framework per il delivery di soluzioni con una gestione del processo End-to-End. In particolare DAD si focalizza su: • People-‐first, i processi sono guidati dalle persone e non viceversa; • Goal-‐driven, azioni focalizzate su obiettivi mirati; • Hybrid agile, sfruttare le pratiche derivati da metodologie diverse; • Learning-‐oriented, apprendimento continuo; • Full delivery lifecycle, dall’idea alla dismissione; • Solution focused, delivery di soluzione ready-to-use; • Risk-‐value lifecycle, gestione del rischio; • Enterprise aware, aderente al cotesto aziendale.
- 15. DAD, an HybridFramework DAD prende «in prestito» strategie e pratiche comprovante, fornendo un framework consistente e robusto per affrontare il delivery di soluzioni complesse. Geographic Distribution Team Size Organizational Distribution Compliance Domain Complexity Technical Complexity SAFe DevOps …. and more!Outside In Dev. Traditional Agile Data XP Unified Process Agile Modeling Scrum Kanban Lean
- 16. Scale with DAD Ipunti cardine attraverso cui si snoda l’adozione di Disciplined Agile Delivery sono: 1. Focalizzarsi sulla Soluzione e non sul software; 2. Adottare un ciclo completo di delivery; 3. Padroneggiare i goal che sottendono il processo; 4. Adattare il processo allo specifico contesto aziendale; 5. Promuovere la consapevolezza aziendale; 6. Adottare una governance in chiave Lean.
- 17. Scale with DAD DADfa emergere come il delivery di una soluzione vada ben al di là dell’esclusivo sviluppo del software: • Aspetti relativi all’hardware; • Documentazione di supporto; • Cambio dei processi di business, a supporto e inerenti l’adozione della soluzione; • Evoluzione della struttura organizzativa; • Customer Care e Customer Satisfaction. Focalizzarsi sulla Soluzione e non sul software Il supporto di tali attività passa attraverso una serie di Ruoli specifici coinvolti nell’intero ciclo di delivery della soluzione.
- 18. Scale with DAD:Primary & Secondary Roles Team Lead, esperto di processi Agili, mantiene il Team concentrato sul raggiungimento degli obiettivi, rimuovendo gli impedimenti; Product Owner, governance della Vision e delle funzionalità della soluzione; Architecture Owner, indirizza le scelte architetturali e tecnologiche, con l’obiettivo di mitigare i rischi primari annessi; Team Member, formato da professionisti con skill cross-functional a cui viene demandata la realizzazione della soluzione; Stakeholder, clienti e stakeholder interni/esterni, come: Project Sponsor, DevOps, architecture specialists, database groups, amministrativi, ecc.. Secondary Roles, Specialist, Indipendent Tester, Domain Expert, Technical Expert, Integrator. Focalizzarsi sulla Soluzione e non sul software
- 19. Scale with DAD Inception(Portfolio), 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?, ... • Riorganizzare (creare se non presente) il Product Backlog. Construction (Program Level/Inception/Team Level) • Creare il Program Backlog (Feature), Creare i Team Backlog (User Story), Identificare i PSI (Potential Shippable Increment), …. • Prendere in carico il Team Backlog, Definire le iterazioni in relazione ai PSI, Definire i Task, Scegliere le pratiche da utilizzare, … Transition (Program Level) • Completato lo sviluppo, il sistema deve essere manutenuto in erogazione e fruibile correttamente da client di tipologia diversa (anche molto!) Adottare un ciclo completo di delivery
- 20. Scale with DAD Padroneggiarei Goal che sottendono il processo
- 21. Scale with DAD Adattareil processo allo specifico contesto aziendale
- 22. Scale with DAD Migliorarel’ecosistema aziendale • Riutilizzare e sfruttare al massimo le risorse aziendali; • Migliorare e sviluppare le infrastrutture aziendali lavorando a stretto contatto con l’Enterprise Architecture (EA) Team. Seguire le Convenzioni Aziendali • Standard e best practice Architetturali, di Codifica e di gestione Dati; • Linee guida nella definizione della User Interface (UI). Condivisione della conoscenza • Contribuire alla crescita Personale, del Team e dell’Azienda; • Arricchire e rafforzare il know-how relativo all’Agile. Promuovere la consapevolezza aziendale
- 23. Scale with DAD Self-Organization; Utilizzodell’Agile per aumentare la visibilità delle azioni; Risk & Value driven lifecycle; Quality Aware; Review basate su milestone ragionevoli (lightweight); Chiara definizione degli stakeholder; Promuovere la consapevolezza aziendale. Adottare una governance in chiave Lean
- 24. Quality Aware La filosofiaKaizen di Lean è parte integrante di DAD e si sviluppa sul modello 3C Rhythm, ovvero un Ritmo (o se vogliamo Cadenza) scandito su tre Accenti, andando ad integrare: ricerca, progettazione, test, produzione e vendita. Inception Coordinate Construction Collaborate Transition Conclude Release rhythm Iteration rhythm Development Collaborate Iteration Planning Coordinate Stabilize Conclude Daily rhythm Coordination Meeting Coordinate Daily Work Collaborate Stabilize Conclude Coordinate Collaborate Conclude
- 25. Risk & Valuedriven lifecycle Value Driven • Prediligere le Features a maggior Valore per gli stakeholder; • Continua verifica del Valore prodotto; • Determinare quando sono 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 • 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.
- 26. Review basate sumilestone ragionevoli • Stakeholder Vision convalidata; • Architettura convalidata; • Fattibilità del progetto (project viabilità); • Funzionalità in linea con le attese (sufficient functionality); • Pronto per la messa in produzione; • Stakeholder soddisfatti.
- 27. DAD Basic BigPicture
- 28. DAD Advanced BigPicture
- 29. DAD & TFS “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 (11 Febbraio 2015)
- 30.
- 31. Recap • Un soluzionesoftware è un “prodotto” complesso e come tale ha bisogno di opportune soluzioni di gestione per massimizzarne il Valore ed abbattere i Rischi realizzativi; • Le metodologie Agile@Core (es: Scrum ed XP) sono incentrate sulla fase di sviluppo del software e non sull’intera soluzione; • Una soluzione va valutata nella sua interezza, (end-to-end) dall’idea alla sua dismissione, ponendo sempre al centro il Valore (soddisfazione) per il cliente; • Disciplined Agile Delivery è il framework leader nella creazione di soluzioni end-to-end; • Visual Studio Online / TFS è la piattaforma ALM leader di mercato.
- 32. Risorse e Riferimenti AgileApplication Lifecycle Management con VSO/TFS getlatestversion disciplinedagiledelivery.com • Agile@Scale: visione olistica del valore • Lean Philosophy • Introduzione a Kanban • Application Lifecycle Management (ALM) con Visual Studio Online
- 33. Quest'opera è distribuitacon Licenza Creative Commons Attribuzione - Non commerciale 3.0 Italia.
Editor's Notes
- #7 Il framework posiziona i sistemi in 4 quadranti idealmente ben distinti (anche se nella pratica i contorni sono decisamente più sfumati) e suggerisce i relativi pattern comportamentali: Simple, i sistemi che ricadono in questo quadrante sono sostanzialmente contraddistinti da una chiara relazione causa-effetto, in cui l’aleatorietà è praticamente azzerata, e la soluzione è assolutamente evidente e non in discussione: “se butto un sasso da una finestra questo cadrà a terra”. In questo quadrante è possibile decidere anticipatamente cosa fare, applicando, come suggerito, il pattern comportamentale sense-categorize-respond (valutare-classificare-agire). Lo sviluppo del progetto è affidato ad una catena di controllo (command-and-control) e a una serie di knowledge workers (KW) che applicano le proprie competenze in relazione a quanto deciso. Chiaramente la rete tra i KW è decisamente poco influente perché ad ognuno è demandato un compito ben specifico; Complicated, i sistemi che ricadono in questo quadrante rispondono ancora ad una relazione del tipo causa-effetto, ma essa non è così evidente e non è univoca: “se premo il pulsante di accensione del televisore, questo potrebbe accendersi a seconda del fatto che lo stesso sia o meno collegato alla rete elettrica” In questo scenario, K&S suggeriscono di adottare il pattern sense-analyze-respond (valutare-analizzare-agire) che, parte sempre da una valutazione, ma poi si concentra sull’analisi del contesto che viene effettuata tramite l’approccio analitico di scomposizione del sistema in sotto-sistemi più semplici, basandosi sul fatto che il funzionamento d’insieme dei singoli componenti è equivalente a quello del sistema nel suo complesso (somma delle parti). I worker di tale sistema sono gli “Experts”, in grado di contestualizzare le proprie attività e relazionarsi con i propri colleghi per creare un Network che rende meno rigido (anche se non lo elimina) l’approccio command-and-control. Un esempio concreto della sua applicazione: la catena di montaggio; Complex, i sistemi in questo quadrante non possono più essere modellati secondo un approccio lineare (matematicamente secondo equazioni lineari) perché il funzionamento olistico è più della somma del funzionamento delle singole parti, dipendendo anche dalla sua evoluzione/storia. Un ottimo esempio di sistemi complessi sono i sistemi con rientranti (o feedback): “lo stesso motore ha un rendimento diverso in base a come è stato utilizzato” In questo caso l’approccio da seguire è quello di “metterci le mani dentro”, ovvero probe-sense-respond (sondo-valuto-agisco), anche sapendo che potrei perturbare il sistema stessa (principio di indeterminazione di Heisenberg). In questo caso il Network tra i worker diventa fondamentale e il pattern comportamentale diventa inspect-and-adapt, diminuendo anche l’importanza degli Expert a favore di worker più orizzontali in grado di spingersi oltre e rispondere nel modo migliore relativo al contesto; Chaotic, i sistemi di questo quadrante non rispondo più a nessuna legge deterministica o, se lo fanno, ciò avviene per una frazione limitata di tempo che non ha valenza sul piano complessivo. Siamo in presenza di una elevata incertezza in cui ogni tipo di valutazione (sense) o di indagine (probe) non è di alcun aiuto. Ogni approccio di gestione di questi sistemi è destinati, nella stragrande maggioranza dei casi, ad essere fallimentari, e se proprio bisogna intervenire, l’unico pattern perseguibile è act-sense-response, in pratica si opera sul sistema a “naso”, si valuta il risultato e si agisce di conseguenza (agisco-valuto-rispondo). Ogni piccola perturbazione porta ad un effetto potenzialmente devastante e, la stessa azione ripetuta più volte, porta ad effetti diversi. Si è in presenza del cosiddetto effetto farfalla: “il battito delle ali di una farfalla in Brasile può scatenare un tornado in Texas” Sia il Network che la Gerarchia hanno ben poco significato.
- #29 Advanced product teams follow a continuous delivery approach