Transizione da Waterfall a DevOps: banche tradizionali vs fintech

Durante il QA Financial Forum del 3 febbraio 2021 si è parlato di come fare una transizione da Waterfall a DevOps nel modo corretto. Le lezioni apprese durante l'evento sono state applicate, nella ricerca di QA Media qui di seguito, a banche e assicurazioni tradizionali, fintech e challenger bank.

Qualità, costo e velocità: Waterfall vs Devops 

Le istituzioni tradizionali stanno prendendo parte a un processo di transizione: hanno processi e sistemi costruiti e testati in waterfall che si collegano a nuovi sviluppi i quali spesso usano l’Agile. Dall’altra troviamo le challenger bank e fintech costruite da zero in DevOps.
Ecco allora alcune lezioni chiave e best practice della comunità Devops dalle quali le aziende tradizionali potranno trarre ispirazione.

Il grafico di seguito rappresenta il classico trade off tra velocità, qualità e costi.

Anche se è opinione diffusa che non si possono avere il meglio di velocità, qualità e costo allo stesso tempo (bisogna scegliere due di questi tre), quello che il grafico mostra è che in realtà non è così. Con il giusto bilanciamento si ottengono tutti e tre.

Abbiamo quindi diversi scenari:

• da una parte le fintech e challenger bank (cerchio verde) ottengono la velocità di commercializzazione, gestiscono efficacemente i loro costi e ottengono la migliore qualità,
• dall'altro, quando le istituzioni tradizionali passano da Waterfall a DevOps, ciò che vedono all’inizio è in realtà un declino in tutti e tre i fattori, quindi meno qualità, rallentano i tempi e spendono di più.

Perché succede?

Cosa devono aspettarsi le banche tradizionali dalla transizione a DevOps?

In questo secondo grafico vediamo il confronto tra la qualità complessiva (sull’asse delle Y) con l'asse delle X che rappresenta la proporzione di spesa allocata al test e alla creazione dei bug contro l'efficienza complessiva della qualità rappresentata dalla dimensione delle bolle. In poche parole: quanta qualità si sta ottenendo per spesa.

Come si può avere il rapporto più efficiente? Le challanger banks raggiungono circa lo stesso rapporto di spesa per una migliore qualità rispetto alle aziende tradizionali. Al contrario, le aziende tradizionali quando adottano DevOps raggiungono una qualità simile ma spendono di più rispetto a quando applicano waterfall. Significa che quindi stanno spedendo il loro budget in modo meno efficiente e non ottengono miglioramenti e qualità (come si può vedere dal divario tra la bolla gialla e la bolla verde).

Una prima lezione è che le aziende tradizionali non dovrebbero aspettarsi di spendere meno sulla qualità passando a DevOps. Questo succede quando le banche e le assicurazioni tradizionali rinunciano agli specialisti della qualità e pensando di ottenere una qualità a un costa inferiore e con gli stessi sviluppatori semplicemente lavorando con una metodologia scrum. Le aziende tradizionali dovrebbero invece mantenere gli stessi costi per la qualità e usare il budget in modo più efficiente, ovvero istruire gli sviluppatori e il management ad avere un approccio diverso alla gestione dei difetti e alla loro risoluzione.

La gestione dei bug: banche tradizionali vs fintech

Nel complesso, le fintech che le challenger bank che usano devops hanno un defect ratio paragonabile alle banche e assicurazioni tradizionali.

Un punteggio più alto su questo grafico ha un valore positivo, ma quando i bug vengono divisi fra bug critici e bug minori vediamo che le pratiche DevOps permettono di più ai bug critici di essere portati alla fase di produzione rispetto a quelli minori.

Gli sviluppatori del mondo fintech e delle Challenger Banks sono abituati a raccogliere gli errori minori prima che raggiungano la produzione. D’altra parte, le banche e assicurazioni tradizionali sembrano più inclini a lasciarsi sfuggire i difetti importanti e permettere ai loro utenti di essere tester. Hanno però processi molto efficienti per rimediare a quei bug e portare la soluzione corretta in produzione. Challenger banks e fintech risolvono i bug più rapidamente e in modo relativamente meno costoso. La sfida, quindi sta nello spingere gli sviluppatori a evitare bug minori ma allo stesso tempo anche cambiare il modo di affrontare un richiesta di cambiamento quando c'è un difetto significativo che colpisce la produzione in modo che sia risolto in modo rapido ed efficiente.

Le due lezioni per una corretta transizione

Per implementare una buona transizione da waterfall a DevOps bisogna:

1. Aspettarsi di mantenere le spese, ma usarle in modo più saggio ed efficiente
2. Adottare un approccio diverso nei confronti dei bug in produzione: non sono necessariamente un disastro, basta che vengano corretti in modo rapido ed efficiente.
   
   
   

Come scovare i bug in tempi brevissimi

Gli sviluppatori non sempre hanno abbastanza tempo da dedicare alla ricerca di bug. Sarebbe ideale, infatti, che si concentrassero su sviluppo e correzione dei bachi. E chi li trova, allora, i bug?

In AppQuality mettiamo a disposizione una community di tester (più di 20.000 solo in Italia) che scova i bug, li segnalano con descrizioni esaustive e li segnalano ai nostri Quality Leader che ne verificano la qualità e completezza. Per risparmiare ancora di più il tempo degli sviluppatori, i bug vengono trasmessi grazie all'integrazione con i più comuni Bug Tracker. 

Per risultati ancora più efficienti, si può integrare questa metodologia, il Crowdtesting, alla Test Automation. Puoi vedere con i tuoi occhi i risultati in termini di tempo e bug.