AGILE PROJECT MANAGEMENT: OVERVIEW DI ALCUNI APPROCCI

agosto 17, 2019

0 Commenti

Il settore dello sviluppo software è stato per diverso tempo fortemente criticato per le scarse performance dei suoi progetti. Per risolvere le cause alla base di queste difficoltà, a partire dagli anni ’90, diversi esperti hanno iniziato a sperimentare nuovi metodi e, in seguito al successo di alcuni di questi, vari altri professionisti hanno cominciato a studiarli e ordinarli per poterli divulgare alle altre organizzazioni. Questo processo di formalizzazione culmina tra l’11 e il 13 febbraio del 2001 al “Lodge at Snowbird ski resort”, sulle montagne Wasatch dello Utah, Stati Uniti, ad opera di 17 esperti¹ e fondatori di approcci e metodologie quali DSDM, SCRUM, Extreme Programming, ecc.
L’obiettivo dell’incontro era mettere a fattor comune le conoscenze e le esperienze sui vari approcci e definire una metodologia per gestire i progetti di sviluppo software in modo più agevole e che consentisse di limitare le criticità derivanti dalla variabilità dei requisiti tipica di questi progetti. Nacque così il famosissimo “Manifesto for Agile Software Development” che definiva i valori e i principi dell’approccio Agile.
L’Agile Project Management (APM) è considerato (e spesso anche rappresentato) come un ombrello che ha sotto di sé molte metodologie, che sono influenzate (chi più e chi meno) dai valori e principi descritti nell’Agile Manifesto.
L’Agile Project Management comprende quindi molti metodi utilizzati per gestire progetti dell’Information Technology e non solo, come DSDM, Scrum, Lean Software Development, DevOps, ecc.
Prima di proseguire nella descrizione di alcuni di questi metodi è utile ricordare alcuni concetti chiave dell’APM che costituiscono i fondamenti delle metodologie “agili”.
Centralità del cliente: il cliente ha un ruolo attivo in Agile. Dato che l’incertezza di un progetto software deriva anche dalla difficoltà da parte del cliente nel definire con esattezza i propri bisogni e dunque a descrivere con precisione il modo in cui interagirà con il software. Per questo è fondamentale che il cliente sia presente durante il progetto, cosi che possa valutare i rilasci progressivi delle funzionalità del prodotto e arrivare a comprendere sempre meglio i propri bisogni.
Rilascio incrementale: in Agile vi è la consegna frequente al cliente di prodotti funzionanti, il rilascio incrementale di piccole funzionalità. Ciò riduce la complessità del progetto, permette di testare, approvare o modificare le funzionalità sviluppate e attraverso una valutazione dei deliverable è possibile capire se quanto sviluppato corrisponde alla realtà.
Collaborazione tra piccoli gruppi: le squadre devono lavorare possibilmente nello stesso luogo. Questo approccio facilita la comunicazione e aumenta il coordinamento. Si predilige pertanto una comunicazione diretta (faccia a faccia) a scapito di una comunicazione scritta.
Abbracciare il cambiamento: in Agile si ammette che è impossibile predire con esattezza i deliverable da produrre, pertanto le modifiche da apportare durante l’intero ciclo di vita del progetto sono considerate la naturale conseguenza di questa accettazione. Il gruppo di lavoro impara e si adatta al cambiamento.

OVERVIEW DI ALCUNI APPROCCI AGILI
Come riportato nella figura di seguito, esistono molti approcci Agile. Qui descriviamo brevemente i più interessanti, in particolare alcuni metodi che hanno iniziato ad attirare l’attenzione, tra cui il Scaled Agile Framework (SAFe) di Dean Leffingwell, Disciplined Agile Development (DAD), di Scott Ambler e Large Scale Scrum (LeSS), di Craig Larman e Bas Vodde.

Approcci Agili

DSDM® (Dynamic Systems Development Method) fa riferimento all’Agile Project Framework promosso e distribuito gratuitamente dal DSDM® Consortium. DSDM è una metodologia molto interessante poiché si integra facilmente con metodologie quali PRINCE2®, corpi di conoscenza come PMBOK® e altri framework agili come Scrum. DSDM® non è legato all’utilizzo di strumenti e tecniche particolari, ma offre un framework all’interno del quale adottare la metodologia Agile. L’ultima versione del framework è denominata Atern.
Il metodo DSDM Atern, si basa su 8 principi. Tali principi, che sono la base della filosofia del framework e guidano il team all’utilizzo e all’adattamento di DSDM, sono:
1 – Focus on the business need – Focalizzazione sulle necessità di business.
2 – Deliver on time – Consegnare nei tempi
3 – Collaborate – Collaborare
4 – Never compromise quality – Non compromettere mai la qualità
5 – Build incrementally from firm foundations – Creare il prodotto in maniera incrementale da solide basi.
6 – Develop Iteratively – Sviluppare in maniera iterativa
7 – Communicate continuously and clearly – Comunicare in modo continuo e chiaro
8 – Demonstrate control – Dimostrare controllo

Una differenza sostanziale con gli altri metodi agili risiede nella definizione dei ruoli degli stakeholder di progetto, ognuno dei quali può essere coperto da più persone, o viceversa, una persona può coprire più ruoli. In DSDM le figure proposte sono raggruppate per area di riferimento: l’area business, l’area Project Management e l’area di implementazione della soluzione.
Il DSDM Consortium nel 2016 ha deciso, dopo il successo riscontrato in tutto il mondo, di estendere la propria attività e portare i valori e la filosofia Agile nel mondo del business. A seguito di questa decisione il DSDM Consortium è diventato Agile Business Consortium e ha lanciato la prima versione dell’Agile Business Change Framework.

DevOps® Il termine nasce dall’unione di “Development” e “Operations”, sviluppo da un lato e produzione, servizio dall’altro. DevOps® è una metodologia di sviluppo software che utilizza i nuovi strumenti di condivisione e collaborazione con l’obiettivo di aiutare le aziende a sviluppare in modo più rapido prodotti software di qualità, enfatizzando la comunicazione e la collaborazione tra gli sviluppatori e i professionisti delle operation IT.
DevOps® punta infatti a una condivisione e un’integrazione tra gli sviluppatori e gli addetti alle operation per accelerare i tempi di progettazione, testing e di rilascio delle soluzioni applicative sia in ambienti tradizionali che in ambienti cloud, il tutto garantendo qualità e sicurezza del software sviluppato. DevOps® è un set di pratiche, supportate da strumenti automatici e processi di Lean Management, che permettono di automatizzare il rilascio del software rispetto alla sua catena di produzione, consentendo in questo modo alle organizzazioni di contare su applicazioni software di qualità in modo più rapido.

Large-Scale SCRUM (LeSS): Large Scale Scrum è stato messo a punto da Bas Vodde e Craig Larman. Anche se si è iniziato a parlare di LeSS solo a partire dal 2013, in realtà esiste da prima ed è diventato noto al termine di un lungo processo di sperimentazione eseguito “sul campo”. LeSS è un framework Agile per scalare Scrum attraverso più team. Ma diversamente dagli altri framework di scaling fornisce una struttura minimalista che permette l’empirismo su larga scala e consente ai team e all’organizzazione di controllare, adattare l’implementazione in base al contesto e alle loro esperienze. Il framework LeSS è diviso in due sezioni LeSS di base per 2-8 squadre e LeSS Huge per 8+ squadre. Il primo si applica a situazioni in cui è presente un Product Owner, 1 product backlog e da 2 a 8 team di sviluppo che lavorano sul medesimo prodotto. LeSS Huge si applica in contesti ancora più ampi, fino all’intera organizzazione, e solo nel caso di LeSS Huge è previsto un ruolo aggiuntivo rispetto a Scrum: l’Area Product Owner che si occupa dei requisiti di una specifica area. Inoltre viene introdotto un nuovo evento, l’Overall Retrospective, svolta generalmente al termine dello Sprint a seguito delle Retrospective dei singoli Team.

DAD – Disciplined Agile Delivery: Annunciato da Scott Ambler e Mark Lines nel 2012, questo framework di processo è un approccio agile ibrido orientato all’apprendimento, alle persone e alla fornitura di soluzioni IT. Infatti le sue quattro priorità principali sono: le persone, orientamento all’apprendimento, ibrido. Ibrido significa che DAD si basa su pratiche “agili”, tra cui Scrum, Agile Modeling, Lean Software Development, anche se è stato identificato come mezzo per muoversi oltre le pratiche “agili” tradizionali. Rispetto a Scrum, ad esempio, DAD pone maggiormente l’accento sull’architettura e sulla riduzione del rischio tecnico attraverso la designazione di un proprietario dell’architettura. (DAD cambia anche molti dei nomi di Scrum, come lo Scrum Master che è ora il “Team Lead”). DAD raccomanda tre fasi: Inizio (Inception), Costruzione (Construction) e Transizione (Transition). Mentre molti framework Agili fanno riferimento a quanto DAD specifica nella fase di Construction, DAD va oltre e fornisce indicazioni sia riguardo i processi che vengono prima del progetto (Inception) sia quando il team si prepara per il delivery (Transition). DAD è considerato da più parti un’interessantissima evoluzione dell’agile in quanto potrebbe rappresentare un giusto equilibrio tra metodi più tradizionali e quelli agili, avendo ripreso alcuni dei concetti classici quali il ciclo di vita di progetto.

Scaled Agile Framework (SAFe®) è stato lanciato nel 2011 da Dean Leffingwell che ha attinto a una serie di principi Lean e Agile, combinandoli in modo da creare una metodologia adatta a progetti su larga scala. Infatti l’obiettivo di questo approccio Agile è di aiutare le organizzazioni ad affrontare progetti significativi di sviluppo e fornitura di software di classe enterprise nel minor tempo di realizzazione sostenibile. SAFe presenta soluzioni adatte per organizzazioni che potrebbero impegnare tra i 50-100 professionisti, e soluzioni per sistemi complessi che impiegano migliaia di persone. La prima soluzione è composta dai livelli di Team, Program e Portfolio. Nella seconda si aggiunge un ulteriore livello di Value Stream. SAFe dunque include processi per la gestione dei team e per la gestione dei programmi e la gestione del Portfolio per aiutare dirigenti e leader a identificare e classificare le macro funzionalità (in gergo Agile, Epic) e le funzionalità che possono essere scomposte a livello di Program. L’utilizzo di SAFe richiede una maturità nell’adozione di pratiche agili e una volontà diffusa, e supportata dall’alto, di abbracciare il cambiamento. Pertanto la sua adozione può avvenire solo in seguito ad una crescita culturale aziendale in chiave Agile/Lean.

Nexus™ è un framework che permette di scalare Scrum. Nexus estende Scrum per guidare più Scrum Team su come collaborare per fornire software funzionante in ogni Sprint. L’obiettivo di Nexus è quindi aiutare i team a fornire un prodotto software complesso, multipiattaforma e basato su cicli brevi e frequenti, senza sacrificare la qualità e senza allontanarsi da principi chiave di Scrum. Nexus mostra dunque il viaggio che questi team intraprendono quando si incontrano, come condividono il lavoro e come gestiscono e minimizzano le dipendenze. Nexus è stato ideato da Ken Schwaber, co-creatore di Scrum, e rilasciato da Scrum.org insieme a un corpus di conoscenze, Nexus™ Guide, nel 2015 e aggiornato nel 2018.

Scrum@Scale Sebbene Scrum sia un framework per lo sviluppo, la consegna e il supporto di prodotti complessi da parte di un singolo team, fin dall’inizio il suo utilizzo si è esteso alla creazione di prodotti, processi, servizi e sistemi che richiedono gli sforzi di più team. In seguito fu notato che all’aumentare dei team Scrum, la produzione (di prodotto funzionante) e la velocity di questi team iniziava a decadere a causa di problemi come le dipendenze tra team e la duplicazione del lavoro. Diventò quindi naturale pensare ad un framework per coordinare efficacemente questi team in modo da ottenere una scalabilità lineare. Scrum@Scale è stato ideato per raggiungere questo obiettivo grazie alla sua architettura scale-free. Utilizzando una architettura scale-free, l’organizzazione non ha vincoli di crescere in un particolare modo può invece crescere in base ai suoi personali bisogni e ad un ritmo di cambiamento sostenibile che può essere accettato dalle persone che compongono l’organizzazione.
Scrum@Scale è stato sviluppato da Jeff Sutherland basandosi sui principi fondamentali alla base di Scrum, sulla teoria dei sistemi adattativi complessi, la teoria dei giochi e le tecnologie orientata agli oggetti.

Al termine di questa breve esposizione dei metodi agili appare chiaro come negli ultimi anni i modelli di gestione aziendale si siano dovuti adattare alle nuove condizioni “turbolente” di produzione, ai mercati caratterizzati da un’altissima competizione e alle continue richieste di maggiore velocità e qualità di produzione. Per far fronte a questi nuove esigenze organizzative e gestionali aziendali sono stati sviluppati nuovi approcci agili, nuove metodologie e tecniche di project management che supportano i team nella realizzazione di prodotti innovativi.

_____________
¹(Alistair Cockburn, Andrew Hunt, Arie van Bennekum, Brian Marik, Dave Thomas, James Grenning, Jeff Sutherland, Jim Highsmith, Jon Kern, Ken Schwaber, Kent Beck, Martin Fowler, Mike Beedle, Robert C. Martin, Ron Jeffries, Steve Mellor, Ward Cunningham.)