Blocco del codice: sono ancora rilevanti per i product manager agili?

Sembra un caso aperto e chiuso.

I blocchi di codice sono una reliquia. Un avanzo dei giorni in cui le rigide metodologie a cascata offrivano l’unica opzione per lo sviluppo e il rilascio del prodotto. L’intero concetto di fermare la produzione e ritardare il rilascio-solo per testare bug e altri problemi funzionali-non ha posto nella moderna e agile gestione del prodotto.

Almeno questa sembra essere la visione del consenso tra molti guru Agili.

Ma regge? Una volta che si gratta la superficie degli argomenti più comuni contro l’incorporazione di blocchi di codice nella gestione del prodotto agile, sembreranno ancora arcaici?

In questo articolo, esploreremo i tre argomenti principali contro l’incorporazione di blocchi di codice nella gestione del prodotto agile e analizzeremo dove tali argomenti cadono a pezzi, il tutto per aiutarti a prendere una decisione migliore sull’opportunità o meno di incorporare blocchi di codice nella gestione del prodotto Agile.

Argomento 1: I blocchi di codice sono irrilevanti e non necessari

Questo argomento è piuttosto semplice e concreto: le moderne metodologie e strumenti Agili hanno eliminato la necessità di una finestra di QA e test dedicata.

Metodologie agili come peer code reviews, pair programming e il monitoraggio costante dello stato del sistema offrono una visibilità molto maggiore sulle prestazioni di un’applicazione o di una funzionalità durante lo sviluppo. Bug e problemi sono più facili e più probabili da rilevare durante lo sviluppo stesso e risolti prima di qualsiasi attività di test e QA dedicata.

Nuovi strumenti hanno anche automatizzato molti test. Valutano costantemente il codice per assicurarsi che sia pulito e pronto per la produzione in ogni momento. I problemi vengono identificati in tempo reale e gli avvisi vengono immediatamente inviati per risolverli al più presto. Il numero di test che sono stati automatizzati è già ampio e continua a crescere, riducendo drasticamente il volume di test manuali che devono essere eseguiti.

Il risultato di queste nuove metodologie e strumenti Agili è facile da vedere. La maggior parte delle attività di test e QA di base eseguite durante un blocco del codice vengono eseguite durante lo sviluppo o eseguite dal software. In Agile, il software e le funzionalità ora escono dallo sviluppo a un livello di sicurezza molto più elevato rispetto a un tempo, rendendo sempre più difficile giustificare un blocco del codice dedicato.

Argomento 2: I blocchi di codice interrompono un principio Agile di base

Questo secondo argomento è un po ‘ più alto. Fondamentalmente, sostiene che i blocchi di codice non hanno una casa nella metodologia Agile perché infrangono uno dei principi fondamentali della metodologia Agile, riducendo il tempo tra lo sviluppo e il rilascio.

Più raffinato è il tuo approccio all’Agile, più proverai a ridurre questa finestra di tempo. Gli approcci attuali più raffinati all’Agile sono l’integrazione continua e lo sviluppo continuo (CICD) e mirano a suddividere lo sviluppo in piccole modifiche incrementali al fine di “rilasciare” le modifiche al codice il più rapidamente possibile. Nell’applicazione più pura di CICD, lo sviluppo e il rilascio esistono a malapena come fasi distinte— il nuovo codice viene integrato nell’applicazione quasi non appena viene completato.

Al contrario, è necessario mantenere distinte fasi di sviluppo e rilascio se si intende distribuire blocchi di codice. Dopotutto, è qui che vive il blocco del codice, tra queste due fasi distinte. Invece di cercare di ridurre al minimo o eliminare quella finestra di tempo tra lo sviluppo e il rilascio come la maggior parte della metodologia Agile, i blocchi di codice ti costringono a formalizzare questa finestra al punto che devi creare i tuoi programmi di sviluppo e rilascio attorno ad essa.

Se i blocchi di codice non si allineano con i principi Agile di base, è difficile fare in modo che appartengano ancora alla metodologia.

Argomento 3: I blocchi di codice portano a rilasci più lenti e di qualità inferiore

Questo argomento finale è grande e include alcune angolazioni diverse.

Per iniziare, sostiene che i blocchi di codice aggiungono molta complessità e parti mobili aggiuntive alla tua tabella di marcia, e naturalmente aumentano le probabilità che qualcosa vada storto e butti via la tua timeline. Anche se nulla va storto, il lavoro coinvolto nei blocchi di codice è dispendioso in termini di tempo e imprevedibile (poiché non sai quali bug troverai o quanto tempo ci vorrà per risolverli), che semplicemente aggiungendo blocchi di codice alla tua roadmap creerai cicli di sviluppo e rilascio più lenti.

Successivamente, sostiene che il blocco del codice ridurrà la produttività del team di sviluppo. Mentre Agile in generale e CICD in particolare, mantengono gli sviluppatori costantemente al lavoro in una catena ininterrotta di produttività, i blocchi del codice costringono gli sviluppatori a interrompere il lavoro a intervalli predefiniti. In questo modo, romperai il loro ritmo e li costringerai a cercare di aggirare le politiche di blocco del codice, invece di trovare e mantenere qualsiasi flusso li renda più produttivi.

Infine, sostiene che la creazione di finestre dedicate in cui si smette di ricevere requisiti aziendali limiterà le caratteristiche e le funzionalità delle versioni a tutto ciò che può essere completato prima del congelamento, il che porterà a software e applicazioni di qualità inferiore e meno complete.

Fare il caso per il blocco del codice: una battaglia persa?

A questo punto, sembra piuttosto desolante per chiunque voglia ancora includere blocchi di codice nella metodologia Agile. Detrattori di questa pratica fare alcune molto convincente e, in generale, tinta caso che, dal momento che lo sviluppo della moderna metodologia Agile, il codice di gela sono diventati:

1. Obsoleti e del tutto irrilevante
2. Disallineati con le moderne pratiche di sviluppo
3. Un ostacolo ad una rapida e di alta qualità release

Ma anche se questi argomenti sono convincenti, e contengono un sacco di informazioni accurate, non sono a prova di proiettile. E ci sono difetti fondamentali all’interno di ciascuno che devono essere discussi prima di chiudere il libro sui blocchi di codice come elemento utile della gestione agile del prodotto.

Il problema con l’argomento 1: il test automatico non è completo

Le pratiche di QA e sviluppo agile automatizzate hanno aumentato la qualità del codice man mano che viene prodotto, questo è un dato di fatto. Ma solo perché un pezzo di codice ha superato il test delle unità, ciò non significa che sia effettivamente pronto per la produzione. Anche gli approcci CICD più raffinati non sempre includono passaggi critici, come il test di regressione, che assicurano che un pezzo di codice sia privo di difetti. Quando si tratta di esso, ci sono solo alcune cose che non puoi testare e risolvere mentre un pezzo di codice è in produzione.

Se si sceglie di utilizzare il blocco del codice, non si rinunceranno ai vantaggi del QA automatizzato e delle best practice agili. Tu e il tuo team catturerete semplicemente i problemi più piccoli e banali del codice durante la produzione, eliminando i ponti per concentrarvi sulla cattura di problemi più grandi e di maggiore impatto durante il blocco, come la stabilità generale e l’affidabilità del nuovo software o funzionalità.

Il problema con l’argomento 2: “Riduci”, non “Elimina”

Agile è progettato per ridurre il tempo tra lo sviluppo e il rilascio, anche questo è un dato di fatto. Ma c’è una grande differenza tra cercare di ridurre questa finestra e cercare di eliminarla completamente. Farlo sarebbe quasi impossibile, soprattutto per i progetti più grandi.

Il blocco del codice può essere molto breve in CICD— o può applicarsi solo a un ramo specifico mentre lo sviluppo continua su altri rami—ma esiste ancora. Non importa quanto sia diventato Agile raffinato, ci sarà quasi sempre un punto in tutte le roadmap di sviluppo e rilascio in cui un nuovo software o funzionalità verrà valutato in uno stato fisso prima che esca agli utenti del mondo reale.

Il problema con l’argomento 3: Ripensare velocità e qualità

Se si utilizzano blocchi di codice, si aggiungerà un nuovo passaggio al ciclo di sviluppo e rilascio. Non c’è dubbio. E ogni volta che si aggiunge un nuovo passaggio a qualsiasi processo, si rallenta quel processo e si crea un nuovo potenziale punto di errore. I blocchi di codice non fanno eccezione.

Ma è importante fare un passo indietro e avere una visione più ampia del rallentamento e della perdita di produttività.

Se la tua funzione presenta bug, dovrai correggerli, indipendentemente dal fatto che li abbia rilevati durante un blocco del codice o se si siano resi noti dopo il rilascio. Da una prospettiva di puro sviluppo, la quantità di tempo necessaria per risolverli sarà all’incirca la stessa in entrambi gli scenari.

Ma se hai a che fare con bug in un ambiente live, hai una serie di altri problemi che devi prendere il tempo di affrontare, tra cui:

• Decidere se ripristinare la funzione buggy o lasciarlo dal vivo.
• Togliere i tuoi sviluppatori dai loro nuovi progetti, dopo che hanno iniziato a lavorare.
• Rendendo fino ai vostri utenti del mondo reale che sono stati colpiti dai bug.
• Rispondere e gestire i tuoi stakeholder interni che non sono troppo felici del tuo rilascio problematico.

La lista continua. Non c’è niente di più complicato, dispendioso in termini di tempo e distruttivo per la produttività, per te e il tuo team, che rilasciare una funzionalità o un prodotto non funzionanti. Il blocco del codice riduce al minimo le possibilità che ciò accada.

E per quanto riguarda l’argomento che il blocco del codice porta a caratteristiche e prodotti di qualità inferiore perché riducono la quantità di requisiti aziendali che è possibile raccogliere? Le tue esigenze aziendali saranno sempre poco più di una” ipotesi migliore ” su come dovrebbe funzionare il tuo prodotto o funzionalità. I requisiti più importanti verranno sempre dagli utenti del mondo reale, distribuendo il tuo prodotto o funzionalità in scenari reali. E puoi raccogliere questi requisiti solo dando ai tuoi utenti rilasci funzionali che possono distribuire nel modo più fluido e privo di bug possibile.

Dovresti utilizzare i blocchi di codice nella gestione del prodotto agile?

In definitiva, i blocchi di codice svolgono ancora un ruolo importante per molti product manager Agili.

Ora, ci sono casi in cui svolgono un ruolo meno critico. Progetti molto piccoli potrebbero non aver bisogno di periodi di blocco del codice dedicati. Le nuove funzionalità che hanno conseguenze relativamente minori se spediscono imperfettamente potrebbero non valere il congelamento. Lo stesso vale per i piani di rilascio graduale—come le versioni Canary—quando vuoi solo testare nuove funzionalità con un pubblico caloroso che ti aspetta un’esperienza imperfetta e bacata.

Ma nella maggior parte dei casi, vale la pena prendere il tempo—anche un brevissimo periodo di tempo—per assicurarsi che le nuove funzionalità sono perfette come si pensa che siano prima di metterli nelle mani delle persone che contano di più: i tuoi utenti del mondo reale.

Questo articolo è stato inizialmente pubblicato su flagship.io