Debito tecnico decompresso: strategie Agile per un ciclo di sviluppo senza debiti

I programmi software tradizionali hanno un approccio allo sviluppo basato su fasi: sviluppo di funzioni, alfa, beta e Golden Master (GM).

Ogni rilascio inizia con una fase in cui vengono create nuove funzioni e, idealmente, vengono risolti i ticket residui rimasti dall'ultimo rilascio (ma, parlando con franchezza: questo accade raramente). Il ciclo di sviluppo raggiunge la fase "alfa" quando ogni funzione è implementata e pronta per i test. La fase beta subentra quando il numero di bug corretti è tale da consentire il feedback dei clienti. Purtroppo, mentre il team è impegnato nella correzione di un numero di bug sufficiente per raggiungere la fase beta, compaiono nuovi bug. È un classico: correggi un bug e ne compaiono altri due. Infine, il rilascio raggiunge la milestone della Golden Master quando non sono più presenti bug aperti. Di solito si raggiunge l'azzeramento dei bug aperti quando si correggono alcuni problemi noti e si rimanda il resto (la maggior parte?) al rilascio successivo.

Procrastinare costantemente i bug che devono essere corretti è un modo pericoloso di creare software. Man mano che il numero di bug aumenta, gestirlo diventa sempre più difficile, provocando un circolo vizioso di debito tecnico. A peggiorare le cose, contribuisce il fatto che le programmazioni saltano perché la codifica relativa ai bug rallenta lo sviluppo. Nel frattempo, i clienti vivono una lenta agonia a causa dei difetti non corretti. E, di fatto, alcuni di loro ti abbandoneranno.

Deve esserci un modo migliore.

Agile integra la qualità nell'approccio di sviluppo iterativo in modo che il team possa mantenere un livello di qualità costante, rilascio dopo il rilascio. Se una funzione non ottimale, non viene rilasciata. Stenti a crederci? Beh, c'è un trucco: definire, o ridefinire, la definizione di "completato".

Per i team tradizionali, "completato" significa di qualità sufficiente per iniziare il controllo di qualità. Il problema di questa definizione è che i bug si insinuano all'inizio del ciclo di rilascio e continuano a insinuarsi. Quindi, quando interviene il controllo di qualità, il prodotto è pieno zeppo di difetti. Per i team Agile, invece, "completato" significa pronto per il rilascio, il che significa che gli sviluppatori non passano alla story o alla funzione successiva finché ciò a cui stanno lavorando non è praticamente nelle mani dei clienti. Per velocizzare il processo, utilizzano tecniche come i flussi di lavoro della creazione di branch di funzioni, test automatizzati e continuous integration durante tutto il ciclo di sviluppo.

Il branch principale della base del codice deve essere sempre pronto per il rilascio. Questa è la priorità numero uno. Quindi, le nuove funzioni iniziano a essere utilizzate su un branch di task contenente il codice per la funzione stessa, oltre ai relativi test automatizzati. Una volta completata la funzionalità e superati i test automatizzati, il branch può quindi essere sottoposto a merge nel branch principale. Poiché lo standard di qualità è sempre molto alto, il debito tecnico rimane sotto controllo.

Per molte organizzazioni si tratta di un enorme cambiamento culturale. Con Agile, l'attenzione si sposta dalla programmazione verso software dimostrabile di alta qualità. L'owner di prodotto ha il potere di chiedere al team di concentrarsi prima sul lavoro più prezioso, riducendo l'ambito del rilascio invece di compromettere la qualità.

Perché non possiamo dimenticarlo: quanto più a lungo persistono i bug, tanto più difficile è correggerli.

Se stai lavorando con codice legacy, è probabile che tu abbia ereditato qualche debito tecnico. I seguenti argomenti ti aiuteranno a controllare il debito esistente e consentiranno al tuo team di concentrarsi su aspetti divertenti come lo sviluppo di nuove funzioni.

A volte gli sviluppatori e i responsabili di prodotto non hanno la stessa opinione su cosa sia il debito tecnico. Chiudiamo qui la diatriba:

Include eventuali scorciatoie tecniche che sono state create per rispettare le scadenze di consegna!

Dal lato dello sviluppo c'è la tentazione di caratterizzare il lavoro relativo all'architettura come debito tecnico. Potrebbe anche essere tale, a seconda della natura della modifica (ad esempio, la sostituzione di una scorciatoia con la "soluzione" reale rispetto alla suddivisione di una base del codice monolitica in microservizi). D'altra parte, dal punto di vista della gestione dei prodotti spesso la creazione di nuove funzioni è avvertita come più urgente rispetto alla correzione di bug o al rallentamento delle prestazioni. Per evitare che una parte si stanchi dell'opinione dell'altra parte, tutti devono comprendere la distinzione tra debito tecnico, modifiche dell'architettura desiderate nella base del codice e nuove funzioni. Una comunicazione chiara tra sviluppo e gestione del prodotto è fondamentale per dare priorità al backlog e far evolvere la base del codice.

Resisti all'impulso di compromettere la definizione di "completato" aggiungendo un task di test separato alla storia utente originale. Rinviare i test è sin troppo facile e apre le porte al debito tecnico. Se i test non vengono eseguiti come parte della story originale o della correzione di bug, la story originale o la correzione dei bug non vengono completati. Mantieni una definizione rigorosa di "completato" nel tuo programma e assicurati che includa test automatizzati completi. Nulla compromette l'agilità del team più dei test manuali e di una base del codice piena di bug.

Quando qualcuno scopre un bug nel software, prenditi il tempo necessario per aggiungere un test automatizzato che lo dimostri. Una volta corretto il bug, ripeti il test per assicurarti che sia superato. Questo è il fulcro dello sviluppo basato sui test, una metodologia consolidata per mantenere la qualità nello sviluppo Agile.

Cambiare la filosofia del team (e quella degli stakeholder del team) su come gestire il debito tecnico non è facile. A causa delle esigenze aziendali a volte i tempi di sviluppo riducono, allo scopo di accelerare l'introduzione sul mercato. Tenendo presente questo aspetto, facciamo un riepilogo di alcune azioni che permettono di controllare il debito tecnico:

• Informa l'owner di prodotto del costo reale del debito tecnico. Assicurati che i valori degli story point siano precisi per le story future che richiedono la risoluzione del debito tecnico esistente.
• Rendi modulare la tua architettura e prendi una posizione ferma sul debito tecnico in nuovi componenti o librerie nell'applicazione. Man mano che il team e l'azienda vedono l'agilità di questi nuovi componenti, vorranno naturalmente estendere tali pratiche ad altre parti del codice.
• Scrivi test automatizzati! Per prevenire i bug, non c'è nulla di meglio dei test automatizzati e della continuous integration. Quando viene trovato un nuovo bug, scrivi un nuovo test per riprodurlo e poi correggi il problema. Se il bug dovesse riemergere, il test automatizzato lo rileverà prima che lo facciano i clienti.

Ricorda: il debito tecnico è una realtà per tutti i team software. Nessuno è in grado di evitarlo del tutto: l'importante è evitare che vada fuori controllo.