THE AGILE CORNER

Agile Configuration Management, la gestione dei processi con la metodologia Agile

Che cosa succede quando al Configuration Management si affianca la metodologia Agile? Quali sono i passi da seguire per permettere le gestione della configurazione in un progetto, in che modo si categorizzano i requisiti su cui intervenire? Ecco il modello per risponde alle necessità operative e adeguarsi alle norme di settore

Pubblicato il 03 Ott 2019

Gianluca Bonasegale

Senior Project Manager, Italiana Assicurazioni

Daniele Di Lorenzo

Senior Project Manager, Sterline

Luca Sturaro

Senior Agile Coach, Connexxo Italia

platformization

Molte aziende oggi stanno abbracciando la disciplina dell’Agile Configuration Management, ovvero la gestione della configurazione in un progetto che si basi su framework agili. È, ad esempio, il caso delle realtà che vogliono o devono adeguarsi a delle regolamentazioni/norme specifiche. Il Configuration Management in pratica ha lo scopo di permettere la gestione e il controllo degli oggetti (documentali e non) di sistemi complessi come i software, i sistemi militari, i sistemi ingegneristici, ecc.

In particolare è volto a garantire:

  • la tracciabilità,
  • la rintracciabilità,
  • la possibilità di cambiare parte dei requisiti del prodotto/servizio,
  • la presenza sistematica di test, l’integrità di prodotto/servizio,
  • il soddisfacimento delle norme di qualità di settore,
  • la garanzia delle autorizzazioni necessarie e un ciclo di vita del prodotto ben delineato.

Questi requisiti devono essere assicurati per tutti gli elementi oggetto delle attività di gestione della configurazione, detti item. Per le aziende che utilizzano framework agili si parla di Agile Configuration Management, per cui sono indispensabili il soddisfacimento della configurazione di progetto e la garanzia di governarla per tutto il lifecycle di prodotto, così da favorire l’agilità.

Agile Configuration Management: da dove partire

Ogni elemento oggetto delle attività di gestione della configurazione viene normalmente chiamato configuration item. Per farlo si fa riferimento alle tre aree CA-BA-RA (Configuration, Body e Rules), che rendono ‘consistente’ l’item all’interno della configurazione e, nel contempo, assicurano la natura Agile del framework che si sta utilizzando. È in questo modo che si garantisce l’applicabilità del Configuration Management all’interno della realtà organizzativa. Ovviamente si parte dal presupposto che per quanto l’azienda abbia già processi ben definiti sia disposta a rimodellarli per soddisfare il mercato in cui vuole posizionarsi.

Non è così inusuale che una modifica a un requisito, nata magari da un problema rilevato sul campo oppure da una richiesta del cliente, abbia un impatto su diversi ambiti legati al prodotto. Pensiamo alla modifica del controllo di velocità del rotore di un elicottero, certamente porta con sé valutazioni sulla sicurezza, sul prodotto (organi collegati e quindi sollecitati), sugli apparati elettronici per il controllo, ecc. Tutto questo per dire che anche se un requisito appartiene a una categoria specifica, ha comunque impatti anche su quelle secondarie.

Di seguito affrontiamo proprio il tema della modellazione delle categorie, definendo cosa includono e gli elementi che devono essere presi in considerazione per facilitare l’automatismo nell’utilizzo dei Configuration items.

Le categorie di requisiti su cui intervenire: quali sono e cosa serve per gestirle

In generale le categorie individuabili a cui un requisito può appartenere sono:

  • Product: in questo caso le modifiche sono esplicitamente tecniche sul prodotto;
  • Quality: intendendo la qualità di prodotto (si pensi ad esempio alle norme di buona fabbricazione GMP, o alla linea guida DO178 per alcuni sistemi aerei relativa alla sicurezza dei software critici, ecc.);
  • Process: asset aziendale che ha impatto sul processo di realizzazione del prodotto (si parla in questo caso della verifica e/o della validazione, facendo riferimento ad esempio al Capability Maturity Model (CMMI), l’approccio per il miglioramento delle prestazioni di un’organizzazione, o lo standard ISO 26262, che disciplina la sicurezza funzionale nel settore automotive;
  • Risk: cioè gli elementi che nascono dall’analisi dei rischi applicata allo specifico requisito;
  • Economics: requisiti di business o budget che vincolano la realizzazione del prodotto.

Considerando che questa lista potrebbe non essere esaustiva, comunque per ognuna di queste categorie devono essere presenti i documenti che ne governano le scelte (guideline), così da facilitare e automatizzare la gestione del requisito a livello di Team di progetto. In termini operativi ciò si traduce nella diffusione di template di utilizzo attraverso cui si garantisce l’aderenza alle guideline stesse.

In particolare i documenti dovrebbero indicare anche:

  • azioni e possibili decisioni a fronte di scenari noti aziendalmente;
  • risposte a rischi noti;
  • modalità preferenziali di stime economiche;
  • tipologia di aggregazione economica;
  • modalità di definizione delle priorità delle User Story o task;
  • ruoli e responsabilità;
  • ecc.

Inoltre è importante anche riportare nei documenti quali strumenti si è scelto di utilizzare (Story Mapping, User Story, Elevator Pitch, Kanban board, ecc), le motivazioni di ogni scelta e le relative caratterizzazioni CA-BA-RA.

Una possibile modellazione della specifica tipologia di item, potrebbe essere:

  • CA: ID item, links per tracciabilità, link alle guideline, link a change o deviation;
  • BA: corpo del requisito (dipende dalla tecnica utilizzata);
  • RA: regole di categoria e specifiche:
    • Categoria principale di appartenenza;
    • Azioni specifiche relative alla categoria principale;
    • Altre categorie secondarie impattate;
    • Per ogni categoria secondaria, azioni specifiche di categoria;
    • Criteri di accettazione.

Il ruolo del team di progetto

Senza ombra di dubbio affinché l’Agile Configuration Management funzioni è necessario innanzitutto un effort importante da parte dell’azienda nell’individuare e implementare le guideline. È comunque altresì importante la fase di definizione delle tecniche aziendali che verranno utilizzate (User Story, Lean Canvas, ecc.), delle relative modalità preferenziali di utilizzo e dei metodi di prioritizzazione.

Dal punto di vista del team di progetto e, supponendo di adottare il framework Scrum – affrontato in un precedente articolo -, il Product Owner (il responsabile della qualità e delle funzionalità) e lo Scrum Master (il mediatore dei team agili) devono sistematicamente completare le informazioni di ogni specifico item già all’atto della presa in carico dal team.

scrum team agileway

Le figure professionali per l’esecuzione di un Progetto Scrum

Fatto questo, per garantire il rilascio on-time e secondo le regole necessarie dei deliverable, è importante che il team metta in campo le sue competenze “cross functionality”, avvalendosi anche del supporto del Quality Assurance, per la valutazione nel day-by-day degli item prodotti. È solo così infatti che si possono intercettare immediatamente le eventuali deviazioni e rimetterle in lavorazione all’interno dell’iterazione stessa. Ovviamente l’overhead dettato dalle necessità del mondo normato ha un impatto sul tempo di delivery. Il suggerimento è quindi di prevedere iterazioni più lunghe di una settimana rispetto alla durata in assenza di regulation.

In estrema sintesi il deliverable del team potrebbe includere:

  1. l’item;
  2. il report di verifica e validazione (in carico al Quality Assurance) dell’item;
  3. la demo verso il cliente che includa gli aspetti tecnici e quelli inerenti la regulation (da mostrare, ad esempio, ad enti quali l’FDA).

Agile Configuration Management: un esempio dal mondo della farmaceutica

Per capire meglio come funziona nella pratica la disciplina dell’Agile Configuration Management prendiamo in considerazione l’ambito delle macchine automatiche nel settore farmaceutico. Le principali guideline di riferimento sono le GMP V (Good Manufacturing Practices), ed in particolare l’Annex 1 (“Manufacture of Sterile Medicinal Products”). Ipotizziamo che l’azienda abbia da poco definito un proprio asset di processo, che conosca il mondo normato ma non abbia un approccio strutturato al Configuration Management ed utilizzi un framework agile.

Come sopra riportato, le categorie di requisiti sono Product, Quality, Process, Risk ed Economics. Supponiamo che vi sia necessità di modificare un requisito di qualità. A tal proposito, e tanto per fissare meglio le potenzialità di impatto, ipotizziamo di dover sostituire un sensore in quanto la conformazione ad arco può favorire la presenza di particelle potenzialmente contaminatrici del prodotto all’interno dei flaconi appena riempiti. Questa richiesta certamente genera una richiesta di cambio (Change Request), sfocia in una User Story e sarà riportata in una specifica baseline.

La categoria principale è quella della qualità, ma gli impatti riguardano anche categorie secondarie quali il prodotto, il rischio e gli economics.

La caratterizzazione dell’item diviene quindi:

  • CA: Identificativo item, link al documento GMP V Annex 1, link all’identificativo della richiesta di cambio, Baseline di rilascio pianificata, versione;
  • BA: la conformazione ad arco del sensore in ingresso al device, può favorire l’ingresso di particelle potenzialmente contaminatrici del prodotto all’interno dei flaconi appena riempiti che vi passano sotto. Tale rischio oltre ad essere evidenziato dalla normativa, induce il probabile scarto dell’intera produzione, per un valore di migliaia di euro. Per tale motivo si richiede la sostituzione con una soluzione che risolva il problema.
  • RA:
    • Categoria di appartenenza: Quality
      • Analisi (azione da asset): Valutazione della normativa di riferimento
      • Impatto (azione da asset): valutazione impatti potenziali sulla produzione;
    • Categoria secondaria: Product
      • Analisi tecnica (azione da asset): Individuare una soluzione tecnica che, pur garantendo la funzione che il sensore attualmente ha, abbia una conformazione differente ed eviti che “passi sopra” al flacone;
    • Categoria secondaria: Risk
      • Rischio specifico (azione da asset): Valutazione del potenziale impatto aziendale dell’utilizzabilità della macchina automatica;
      • Rischio aziendale (azione da asset): Valutazione delle ripercussioni sulle altre macchine realizzate ed in fase di realizzazione;
      • Rischio economico (azione da asset): Valutazioni di potenziale perdita di prodotto se l’ente di controllo (FDA) dovesse invalidare il lotto;
    • Categoria secondaria: Economics
      • Stima costi diretti (azione da asset): su base storica, costo della progettazione ed implementazione. Stima intervento presso il cliente;
      • Stima costi di verifica e validazione (azione caso specifico): Stima per la fase di verifica e validazione della soluzione realizzata ed installata;
    • Criteri di accettazione:
      • Quality: I flaconi non devono passare sotto il sensore;
      • Products: La funzionalità del sensore e la corrente logica devono essere garantite;
      • Customer: Approvazione della soluzione da parte della Qualità;
      • Customer: “Run” della linea per 15 minuti in condizione di produzione, passato con successo e testimoniato dal report del sistema di supervisione (compliant alla normativa denominata 21CFR part 11).

Conclusioni

Le ipotesi di partenza sono quelle che prevedono l’utilizzo di framework agili come modello di gestione, la presenza di processi aziendali e l’ausilio di una specifica modellazione degli item.

Su questa infrastruttura organizzativa, siamo partiti dall’idea di fornire una consistenza operativa a fronte di una decisione strategica aziendale di adeguamento a ciò che la regulation, in uno specifico settore, chiede. Siamo quindi di fronte a una scelta di ampliamento di business allo scopo di entrare in un nuovo mercato di tipo regolamentato.

Abbiamo constatato come attraverso una opportuna categorizzazione delle tipologie di requisiti, possiamo garantire un insieme di elementi quali: azioni previste per categoria, template disponibili per facilitare il lavoro, gestione del rischio, configurazione degli item e tanto altro in ottica regolamentata. Abbiamo inoltre portato in evidenza gli impatti che una richiesta può causare sotto molteplici punti di vista (categorie).

Tutto quanto appena riassunto, è stato trasposto ed assorbito dalla caratterizzazione CA-BA-RA a livello di item. Quest’ultimo sarà l’oggetto sottoposto a verifica e validazione da parte del Quality Assurance del cross functionality team che il mondo agile prevede. Possiamo quindi concludere affermando che l’innovazione espressa, risiede nell’introdurre in un sistema agile, un impianto che garantisca la gestione opportuna del mondo normato e, conseguentemente, l’aderenza dei deliverable rilasciati ad ogni iterazione ai criteri di prodotto e a quelli di qualità. A ciò uniamo la garanzia di miglioramento dell’asset aziendale che da una parte risponde alle necessità operative (ad esempio template), e dall’altra la rispondenza alle norme di settore (ad esempio guideline).

Valuta la qualità di questo articolo

La tua opinione è importante per noi!

Articoli correlati

Articolo 1 di 3