Disciplined Agile e Devops: definire il proprio WoW

I benefici del DevOps e del Disciplined Agile in un contesto di forte transizione tecnologica

Contesto

In un periodo di forte trasformazione digitale, il cliente, un importante player italiano in ambito assicurativo, ha avviato un progetto finalizzato al raggiungimento di due obiettivi primari, atti a migliorare l’efficienza dei propri processi di business:
- Availability 24/7 dei servizi assicurativi
- Miglioramento performance
La metodologia di progetto scelta per ridurre il time-to-market ed ottenere rapidamente i benefici derivanti dalle implementazioni è l’Agile, condotto secondo i principi del framework Scrum.

Challenge

In qualità di principale fornitore di competenze, la business unit Claims & Motor di Blue Reply è stata chiamata a comporre un team di progetto definito con la giusta commistione di esperienza e skill, definendo un gruppo cross-funzionale, auto-organizzato e focalizzato sugli obiettivi, in grado di poter raggiungere in autonomia i goal di Sprint e Release, assicurando il delivery dei MVP definiti con il business.

Tra i principali compiti del team di progetto:
- Minimizzare gli impatti nei processi core;
- Reverse engineering del sistema di gestione polizze Motor, in favore di una transizione tecnologica a infrastruttura Docker garantendo isofunzionalità;
- Progettazione della nuova struttura architetturale;
- Transizione dei processi di release AS-IS in favore della metodologia DevOps
- Definizione delle nuove linee guida architetturali e funzionali da condividere con gli stakeholder;
- Adozione delle tecnologie, dei tool e dei modelli di lavoro più idonei al soddisfacimento degli obiettivi del progetto;
- Necessità di far coesistere una profonda pianificazione upfront con il modello di pianificazione iterativa dettata dalla metodologia Scrum.

Dovendo intervenire sui processi core del cliente, oltre a garantire l’attesa evoluzione tecnologica, il gruppo di lavoro ha dovuto studiare un piano di rollout e rollback trasparente agli utilizzatori dell’applicativo, così da evitare interruzioni e anomalie durante il normale svolgimento delle attività quotidiane.

Modello di lavoro: i principi

Il Development Team ha definito alcuni principi metodologici su cui fare leva per raggiungere gli obiettivi progettuali. I key factor presentati di seguito sono stati raffinati durante lo svolgimento del progetto stesso, favorendo la flessibilità del modello di lavoro assecondando la prioritizzazione degli obiettivi, anticipando i rischi e consolidando ruoli e responsabilità.

Discliplined Agile

Definizione di una WOW (Way of Working) partendo dai principi del framework Scrum, al fine di affrontare con maggiore efficacia le challenge di progetto.

Microservizi

Adozione di un modello architetturale basato su microservizi Docker, puntando sul disaccoppiamento delle logiche funzionali e sull’interoperabilità delle componenti.

Devops

Approccio al software development secondo i principi del DevOps, in favore dei modelli CI/CD: Continuous Integration, Continuous Deploy, Continuous Delivery.

Quality Assurance

Definizione di una test strategy volta a monitorare la code quality e favorire la test automation su incrementi di prodotto tra i vari ambienti (dal collaudo alla Produzione).

Rollout

Il modello di rilascio iterativo a incrementi di prodotto è stato affiancato ad un sistema di attivazione progressiva delle feature su tutta la rete assicurativa del cliente, adattato all’architettura microservizi, sfruttando i principi DevOps.

Il WoW

Partendo dai principi individuati sulla base degli obiettivi di progetto, lo Scrum Team ha personalizzato il proprio modello di lavoro definendo la sua Way of Working, attraverso 4 punti chiave.

Tailored Scaled Scrum

Il Development Team è stato suddiviso in due gruppi, bilanciando competenze ed epserienza, con risorse dedicate al controllo dello stato dei lavori.

Dopo i primi Sprint di rodaggio, una volta a regime il progetto ha visto la collaborazione di circa venti tra membri effettivi dello Scrum Team, esperti di dominio e stakeholder. Considerando la grandezza del team di lavoro, si è deciso di suddividere il gruppo in due virtual team (secondo la two-pizza rule). Lo Scrum Team ha mantenuto obiettivi comuni, come la partecipazione alla medesima release e la cooperazione per realizzare un unico Minimal Marketable Product (MMP), ma ciascun team virtuale è stato indirizzato verso goal di Sprint specifici.

A livello di processo agile, è stata adottata una metodologia di scaling simile allo Scrum of Scrums, ma con qualche differenza rispetto alla letteratura. Il daily meeting, in base ai vari momenti di progetto, è stato condotto secondo due modalità:
- Daily meeting globale, con la partecipazione di entrambi i virtual team
- Daily meeting dedicato al singolo gruppo di lavoro.
In particolare, la prima soluzione è stata privilegiata durante gli Sprint in cui si è ritenuto fondamentale mantenere costante allineamento dello Scrum Team rispetto agli obiettivi di release. Al contrario, è stata adottata la seconda soluzione nei momenti in cui i due gruppi di lavoro, focalizzati su obiettivi distinti, necessitavano di momenti di allineamento meno frequenti.

Per la realizzazione di alcune componenti ben definite e con impatti limitati sugli obiettivi del Development Team, sono stati definiti gruppi di lavoro con incarichi “on demand”.
L’allineamento tra lo Scrum team ed i gruppi esterni (“feature team” o “substream”), coordinati dall’Agile PMO, è stato garantito attraverso:
- Partecipazione al daily meeting da parte di un referente di ciascun feature team
- Tracciamento delle attività nel Product Backlog e nello Sprint Backlog
- Condivisione della test strategy e delle linee guida del progetto (tecniche e di processo)

Agile PMO

Per l'esecuzione di tutte le attività di gestione e monitoraggio di progetto e condivisione delle informazioni interne ed esterne, è stato istituito un Agile Project Management Office.

Facendo leva sulla caratteristica di auto-organizzazione del Development Team, il framework Scrum non riconosce alcuna figura di gestione del progetto all’infuori dello Scrum Master (e del Product Owner, per particolari compiti). Tuttavia, dopo aver evidenziato la necessità di mitigare alcuni rischi legati ad attività di monitoraggio e condivisione degli obiettivi e della conoscenza, è stato definito un Agile PMO composto da focal point di ciascun team.

Alcuni dei compiti in carico all’Agile PMO:
- Assicurare la consistenza del MMP corrente
- Monitorare l’aderenza ed il raggiungimento degli obiettivi di release
- Definire la test strategy di Sprint e Release
- Sincronizzare le attività tra i due Development Team
- Condividere le informazioni (all’interno dello Scrum Team e verso l’esterno)
- Gestire tutte le attività fondamentali di release
- Pianificare ed eseguire il Product Backlog Grooming

Devops

L'aderenza ai principi DevOps ha visto la definizione di pipeline automation, branching strategy, test automation e monitoraggio di KPI.

La transizione del processo di rilascio dal waterfall all’agile, definita ed attuata durante la conduzione del progetto, ha permesso allo Scrum Team di individuare la migliore strategia per garantire l’aderenza ai principi DevOps. Tra le caratteristiche della metodologia definita, vi sono elementi chiave quali:
- Automazione del deploy tramite pipeline, affiancata a test automation a livello di integration e code quality (Continuous Integration)
- Deploy automatico in ambienti di test (Continuous Deploy) e di Produzione (Continuous Development)
- Adozione di branching strategy tramite feature branch
- Canary Deployment Strategy

I rilasci in Produzione hanno seguito un approccio ibrido in termini di tempistiche: il progetto ha mantenuto una pianificazione generale definita su major release di 3 mesi, in stile waterfall, intervallate da rilasci settimanali di piccoli incrementi di prodotto, a carattere agile.

La qualità del lavoro e le performance generali di progetto sono stati monitorati attraverso specifici KPI derivati da Jira, il software di Agile Project Management utilizzato per la gestione del progetto

Rollout

L'attivazione delle nuove funzionalità è stata controllata tramite una strategia di rollout che, progressivamente, ha abilitato le singole feature su tutta la rete aziendale del cliente.

Per evitare impatti su larga scala, tutti gli incrementi di prodotto sono stati attivati in Produzione secondo una precisa strategia di rollout, basata su:
- Switch “ON/OFF”, a caldo, delle singole feature
- Abilitazione progressiva, a caldo, per lotti di agenzie

La progressiva abilitazione delle nuove feature alla rete agenziale è stata coadiuvata da un insieme di “sfidatori”, soluzioni implementative con il compito di mettere a confronto (dunque, “in sfida”) il ramo logico-funzionale AS-IS attivo in Produzione con quello TO-BE, eseguito in background in forma silente. Grazie al monitoraggio della Produzione, le evidenze raccolte dagli sfidatori attivi sono state analizzate e classificate come anomalie (con rispettive priorità) o falsi positivi.

Tramite questi key factor è stato possibile monitorare lo stato della Produzione, attivando progressivamente, ed a piccoli step, tutta la rete della Compagnia Assicurativa. La possibilità di “spegnere” le funzionalità all’occorrenza ha inoltre permesso di mantenere isofunzionalità, evitando al contempo d'interrompere l’operatività degli agenti.

Nella stessa teoria ricade anche il concetto di Canary Development Strategy menzionata nel tema DevOps. Tale strategia di sviluppo è stata perseguita con l’intento d'incrementare la versione di un singolo microservizio disattivato in Produzione, per poi attivarlo al momento opportuno in modo trasparente all’agente e senza interromperne l’operatività.