“They’re called KPI and not KPT because they are only key performance indicators, not truths.”
Bjarte Bogsnes at #BizAgility2017
Partiamo da questa domanda: in che misura l’approccio data-driven nel project management può essere applicato anche alla gestione Agile di progetto? È solo una questione di metriche e KPI, presumibilmente differenti, o c’è dell’altro?
Il Project Management tradizionale è “deterministico”. Prima definite bene cosa volete realizzare, quindi derivate tempi e costi necessari e vi fate in anticipo “il film” di tutte le attività che dovrete eseguire (aka Project Management Plan). Il “successo” consiste nel rilasciare al termine del progetto i deliverable previsti inizialmente, discostandovi il meno possibile dal piano di lavoro e stando dentro il budget.
L’Agile Project Management è invece “relativistico”. Prima definite le caratteristiche imprescindibili di quello che volete realizzare (aka Minimum Viable Product) con tempi e budget prefissati, rinunciando però a catturare tutti i particolari. Poi, più che il film, vi fate una sceneggiatura di massima del progetto (aka Product Roadmap). Il “successo” consiste nel rilasciare il maggior valore di business nel più breve tempo possibile, attraverso iterazioni di lavoro e costruzione incrementale del risultato.
Cambia completamente la filosofia di gestione e controllo. Il progetto “chiavi in mano”, dove stabilite tutto a priori e l’engagement del client/utente è rarefatto, si trasforma in vera e propria partnership tra product owner (cliente/business) e product creator (team), con engagement giornaliero.
Definite assieme al cliente requisiti e caratteristiche e ogni 2-3 settimane rilasciate in produzione incrementi di funzionalità, che assicurano un ritorno di business anticipato. Il fatto che tutti gli stakeholder, tecnici e di business, siano costantemente assieme “sul pezzo” vi consente di gestire le change come norma e non più come eccezione, concordando l’eliminazione in corso d’opera di requisiti che si rivelano poco utili e sostituendoli con altri più attuali.
Metriche per progetti deterministici e metriche per progetti agili
Le metriche preferite nei progetti deterministici sono quelle cosiddette di “predicibilità”, con cui potete misurare gli scostamenti tra l’andamento effettivo di progetto e quello pianificato (baseline). Su tutte, quelle previste dal metodo dell’Earned Value, con cui valutate periodicamente lo stato di avanzamento “reale” dei deliverable e dei costi effettivamente sostenuti.
In estrema sintesi, la visione classica è project-centered, dovete completare il progetto nel rispetto almeno del vincolo triplo (scope, time, cost). La visione Agile è invece product-centered, con un’unica filosofia di base: non completate semplicemente un progetto, ma realizzate e rilasciate un living product in costante evoluzione.
Il focus sul prodotto allarga lo spettro di misure che potete utilizzare. In un progetto di sviluppo software, ad esempio, le metriche di interesse non sono solo quelle derivabili dai classici tool di project management tracking. I dati sono ovunque, in differenti componenti e sistemi e non esiste una vista unificata.
Da sistemi di Agile Project Tracking come Jira, utilizzati per la gestione di issue (es. task, bug, …) e di task board, potete ricavare metriche come:
- Total done: numero totale di task completati. Indica il volume di lavoro svolto.
- Velocity: user story/task implementati dal team in una iterazione di lavoro. Indica la produttività del team.
- Bug: numero di bug censiti. Indica il livello di qualità e la necessità di fattorizzazioni del codice.
- Tag: servono ad etichettare due tipologie diverse di task: task di fattorizzazione e nuove funzionalità, in modo da mantenere valutazioni di effort separate per i due aspetti.
- Recidività: il tasso di spostamento all’indietro di una task card sulla task board. Ad esempio, con riferimento alla task board della figura seguente, una task card spostata nella colonna “Done” che torna indietro alla colonna “In Progress” per effetto di un bug riscontrato. Se B è il numero di spostamenti all’indietro e F il numero di spostamenti in avanti delle card, la recidività è espressa percentualmente come B/(F+B)*100.
Dal Source Control System (es. GitHub, Bitbucket, Mercurial, …), che utilizzate per la gestione collaborativa e il versionamento del codice, potete trarre indicatori che vi consentono di rispondere a questioni come:
- Chi sta lavorando su cosa?
- Quanto efficacemente stanno lavorando assieme i membri del team?
- Quanto sono state accurate le stime?
- Quanto accuramente sono stati dimensionati i task?
- Quanto realmemte è produttivo il team?
Dai tool di Continuous Integration (CI) e di deployment (es. Jenkins, …), con cui effettuate la build, eseguite i test automatici e di regressione, producete gli artefatti finali e attivate la predisposizione del codice sui diversi ambienti, potete trarre metriche che vi consentono di rispondere a questioni come:
- Quanto velocemente state rilasciando modifiche al cliente/utente e quanto velocemente potereste invece farlo?
- Con che livello di consistenza state rilasciando i risultati?
- State producendo codice di qualità?
Continuous data-driven
L’approccio data-driven nei progetti agili non si differenzia però solo per le diverse misure considerate (metriche product oriented vs. metriche project oriented) ma anche e soprattutto per la frequenza di raccolta delle informazioni.
Nella gestione classica, la raccolta dei dati per determinare lo status di progetto viene effettuata con cadenza regolare, in funzione del cosiddetto periodo di reporting (distanza tra 2 SAL – stati avanzamento lavori – consecutivi). L’enfasi è tutta sul determinare gli scostamenti alla data delle performance attuali da quelle pianificate, per adottare eventuali azioni correttive e cercare di riportare il progetto sui “binari” delle baseline.
Nella gestione Agile la parola d’ordine è invece “continuous“. Continuous integration, continuous delivery, continuous improvement, continuous testing, continuous-whatever-you-want. In altre parole, l’organizzazione iterativa del lavoro e la costruzione incrementale del risultato caratterizzano in maniera “continua” o “quasi-continua” tutta una serie di elementi, dalla pianificazione al monitoraggio e controllo di avanzamento, dai momenti di confronto e comunicazione alla raccolta e applicazione delle lesson learned.
In un progetto Agile spendete un effort di pianificazione anche superiore, in termini assoluti, a quello impiegato in un progetto tradizionale. Esso però risulta mimetizzato dalla “diluizione” sulle diverse iterazioni di lavoro, invece di essere concentrato nelle fasi iniziali del progetto.
Questo principio vale anche per il ciclo di raccolta e analisi dei dati a supporto delle decisioni, che viene effettuato su due loop innestati l’uno nell’altro.
La data collection, l’analisi e le eventuali azioni di aggiustamento sono effettuate e discusse dal team agile giornalmente (Daily Standup Meeting) e al termine di ciascuna iterazione di lavoro (Review e Retrospective Meeting). Le azioni sono circoscritte ad un perimetro più limitato (aka, i soli task lavorati durante l’iterazione) ma con una “frequenza di campionamento” molto più alta, ciò che in definitiva determina la vera natura “agile” di questo tipo di approccio.
Conclusioni
Focalizzandosi sulla realizzazione di un prodotto/risultato in costante evoluzione più che sul completamento dei lavori nel rispetto del vincolo triplo “scope-time-cost”, la gestione Agile di progetto è intrinsecamente data-driven. Alle classiche metriche di predicibilità (es. Earned Value) tipiche della gestione “deterministica” di progetto, si affiancano quelle derivate dai differenti componenti e sistemi utilizzati nella realizzazione del prodotto. Nel caso di progetti software, si ricavano KPI di interesse dai sistemi di versioning del codice e dall’infrastruttura di continuous integration e di deployment dell’applicazione.
Il vantaggio di avere un numero potenzialmente maggiore di misure, oltre tutto effettuate con maggiore frequenza sia a livello di singola iterazione di lavoro che giornalmente, viene in parte bilanciato dal fatto che i dati sono ovunque, in differenti componenti e sistemi e che in partenza non esiste una singola vista unificata. Siete pronti a costruirla nel vostro prossimo progetto agile?
Marco Caressa
Letture consigliate per approfondire
Borror, C. (2009). “The Define Measure Analyze Improve Control (DMAIC) Process.” Retrieved February 14, 2015, from http://asq.org/learn-about-quality/six-sigma/overview/dmaic.html
Ghera, B. (2011). “Project and Program Management Analytics.” Retrieved February 10, 2015, from http://www.pmi.org/~/media/PDF/Knowledge-Shelf/Gera_2011(2).ashx
Mavenlink. (2013). “Using Analytics for Project Management.” Retrieved February 11, 2015, from http://blog.mavenlink.com/using-analytics-for-project-management
Project Management Institute (2014). A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 5th ed. Newton Square, Pennsylvania: Project Management Institute (PMI).
C. W. H. Davis. “Agile Metrics in Action. How to measure and improve team performance” 2015, ed. Manning
