Metodologia Agile, come gestirla in contesti regolamentati

Molto spesso leggiamo articoli o mail, sentiamo parlare i colleghi durante le pause caffè o in lunghissime riunioni, che usano espressioni del tipo “facciamolo usando la metodologia Agile!” o “risolveremo tutto usando le tecniche agili”. Ma in pratica, di cosa si tratta? Che cosa è “questo Agile” di cui molti parlano?

La metodologia nasce e si sviluppa in ambito software e successivamente viene adottata in ambito di Project Management, a inizio Anni Duemila e si fonda su un insieme di principi comuni, direttamente o indirettamente derivati da quelli del “Manifesto per lo sviluppo agile del software”, impropriamente chiamato anche “Manifesto Agile”, pubblicato nel 2001 da Kent Beck, Robert C. Martin, Martin Fowler e altri.

La metodologia Agile si affianca al modello a cascata (waterfall model) e ad altri modelli di sviluppo tradizionali, proponendo un approccio meno prescrittivo e focalizzato sull’obiettivo di consegnare al cliente, in tempi brevi e frequentemente, prodotti o servizi funzionanti e con un livello qualitativo elevato. Il metodo è stato considerato innovativo sin dai suoi albori, anche perché si basa sull’interazione continua con gli stakeholder, la cui soddisfazione è determinante per la buona riuscita del progetto e per lo sviluppo dell’organizzazione. Altre pratiche promosse dalla metodologia Agile sono la formazione di team di sviluppo piccoli, poli-funzionali e auto-organizzati, lo sviluppo iterativo e incrementale, la pianificazione adattiva, e il coinvolgimento diretto e continuo del cliente nel processo di sviluppo.

Come la metodologia Agile si adegua agli ambiti sottoposti alla normativa

Ai giorni nostri, i framework agili stanno facendo la loro comparsa anche in ambiti sottoposti a norma e in cui esiste il Configuration Management – ovvero la gestione della configurazione in un progetto -: in questi mondi, normalmente, i processi sono già stabiliti da regolamentazioni tipiche del settore e da un impianto di processo volto a ottenere una maturità aziendale definita. Ciò implica un necessario adeguamento del framework Agile.

Dall’altro lato, è altresì vero che per quelle realtà organizzate, già agili, è possibile proporre un modello di Configuration Management che, pur garantendo il presidio di tutti gli elementi del dominio di questa disciplina, non snaturi il framework stesso e nel contempo garantisca la possibilità di ingresso nel business che questi mondi sottoposti a norma offrono.

Rimane comunque chiaro che la scelta strategica che porta all’introduzione del Configuration Management necessita di una consapevolezza aziendale ben chiara. In tal senso lo sforzo è creare nel tempo una metodologia che fornisca ai team elementi quali template, categorizzazione degli items, e in generale un knowledge condiviso, che supporti il day-by-day e le scelte che ogni persona deve effettuare giornalmente.

Per sfruttare la metodologia agile bisogna puntare sulle sue peculiarità, partendo da quattro capisaldi:

• considerare i requisiti come entry point;
• utilizzare tecniche note;
• il flusso del processo garantisce il “collante” tra le tecniche;
• il framework viene utilizzato come base portante su cui appoggiare il Configuration Management.

Facendo leva su questo approccio, è necessario considerare due dimensioni complementari da colmare: quella del processo, che deve avere come pilastri le tecniche agili, e quello degli “items” obbligatoriamente caratterizzati in un mondo fortemente normato. L’approccio è incentrato sul prodotto: il progetto esiste perchè si dovrà realizzare tale prodotto (o servizio). A seguire con la fase di ideazione si definiscono i requisiti, secondo quattro tecniche specifiche, attraverso la creazione di un process flow:

• Elevator Pitch: prevede l’esplicitazione dell’idea che sottende il prodotto che si vuol proporre, focalizzandosi sulla vision che lo caratterizza;
• Lean Canvas: ideato da Maurya, consente di entrare nello specifico dei key benefit e market differentiation, e nel contempo rappresenta lo strumento di comunicazione verso gli stakeholder;
• Lean Project Canvas: è il trasposto verso la dimensione di progetto nell’ottica di proporre soluzioni legate ai possibili vantaggi che il prodotto promette di erogare. Nel contempo si iniziano a valutare aspetti di costo di progetto;
• Story Mapping: si tratta della mappatura della storia degli utenti in un modello utile per aiutare a comprendere la funzionalità del sistema, individuare buchi e omissioni nel backlog, e pianificare in modo efficace rilasci che offrono valore agli utenti e alle imprese con ogni versione

Alla fine di questo processo, ogni tipologia item individuato deve essere caratterizzato in base alle sue proprietà: ad esempio, è un configuration item, ha un identificativo univoco, è soggetto a ciclo approvativo, è elemento della baseline, ecc. Possiamo definire questo primo step come la statica del flusso. Su questa base vengono sancite anche le relazioni gerarchiche tra item ed item, garantendo la tracciabilità.

Il secondo step definisce la dinamica del flusso, invece, permette di caratterizzare ogni configuration item (CI), secondo tre aree di caratterizzazione che, durante il lifecycle di realizzazione e trasformazione del prodotto, saranno dinamicamente popolate:

1. Configuration Area (CA) in cui univocamente identifichiamo il CI rendendolo dinamico e tracciabile nel tempo;
2. Body Area (BA) che ne esplicita il contenuto informativo del requisito;
3. Rules Area (RA) dove vengono garantite le regole che caratterizzano il requisito, come la non interdipendenza dei requisiti di alto livello, la caratterizzazione INVEST a livello di Story e SMART a livello di Task, l’eventuale appartenenza a categorie ed i criteri di accettazione.

Affinché si possa garantire l’integrità del CI e conseguentemente dell’intero prodotto, queste tre aree son da intendersi come “atomiche”.

La caratterizzazione CA-BA-RA permette di fornire completezza a un item secondo quantiotipicamente richiesto dalle norme. Il supporto informatico, ovviamente, può facilitare in modo importante l’ausilio della possibilità proposta.

A titolo di esempio, consideriamo l’Elevator Pitch e supponiamo sia stata caratterizzata la statica del flusso del CI come segue:

• CA
  • IIdentificativo univoco
  • Numero di versione
  • Change request associati
  • Stato
  • Approved by
  • …
• BA
  • Descrizione del requisito per la specifica tecnica
• RA
  • Regole di naming
  • Linguaggio naturale
  • Criteri di accettazione e relativo formato
  • Garanzia SMART/INVEST (in caso di User Story)
  • …

La dinamica del flusso si riduce al popolamento di tutti i campi sopra individuati, garantendo che le transizioni siano memorizzate:

Il CI così gestito garantisce:

1. L’individuazione ad ogni iterazione;
2. La tracciabilità e la rintracciabilità tra le iterazioni;
3. Lo sviluppo della dinamica secondo regole definite;
4. Il ciclo approvativo;
5. Criteri di accettazione definiti.

Siamo partiti dalla volontà di comprendere in che modo l’agilità può rispondere a mondi fortemente regolamentati. La conseguenza di questa idea è da una parte la possibilità di introdurre i framework Agile in ambienti lavorativi in cui i modelli predittivi sono preponderanti, dall’altra la possibilità per le aziende già agili di entrare in un mondo normato.

Per fare ciò abbiamo posto delle ipotesi di mantenimento della natura dei framework agili e, dall’altra parte, l’ausilio di tecniche noti e già presenti in letteratura che rappresentino con dettaglio crescente i requisiti da garantire.

Abbiamo quindi approcciato secondo due dimensioni:

1. le proprietà delle categorie degli items che risponda alle necessità della disciplina del Configuration Management (statica del flusso);
2. l’applicazione delle aree di caratterizzazione CA-BA-RA ed il relativo sviluppo della dinamica attraverso le iterazioni (dinamica del flusso).

Il risultato ottenuto è la possibilità di garantire la configurazione di progetto (di prodotto) e la tracciabilità di quanto realizzato. Ancor più rilevante è la possibilità di garanzia di questi goal continuando a sfruttare le caratteristiche dei framework agili, agganciando quanto esposto a peculiarità quali la cadenza). Si tratta quindi di una addizione che, con l’ausilio di apposite scelte informatiche, possono risultare a basso impatto metodico ed alto beneficio aziendale.

Who's Who

Gianluca Bonasegale

Who's Who

Luca Sturaro

Who's Who

Daniele Di Lorenzo