Nei mondi di Agile e di Scrum, non mancano le opinioni controverse sul tema degli sprint “indurenti” (hardening). In effetti, sulla questione dell’hardening sprint – troppo costoso? necessario? – ci sono evangelist, anche fanatici, di idea opposta. In questo articolo esploriamo una delle questioni aperte dello sviluppo software, andando a vedere perché sono nati gli hardening sprint e come alcuni analisti rispondono a una domanda: gli hardening sprint sono davvero necessari?
Ricordiamo che lo sprint è un’unità di base dello sviluppo in Scrum ed è di durata fissa, generalmente da una a quattro settimane. Ogni sprint è preceduto da una riunione di pianificazione in cui vengono identificati gli obiettivi e vengono stimati i tempi. Il termine hardening sprint da più di un decennio vede i sostenitori del framework Agile schierati spesso a favore del concetto. In realtà, coloro che sostengono un approccio più fedele all’Agile Manifesto e alla Scrum Guide identificano lo hardening sprint– e il suo compagno concettuale, lo sprint di stabilizzazione – un anti-modello Scrum, perché nella pratica va contro la natura stessa di Agile e Scrum.
Un hardening sprint è uno sprint aggiuntivo per finalizzare un oggetto prima che venga distribuito. Gli hardening sprint aggiunti sono tipici delle organizzazioni che spostano le correzioni di errori, insieme a regressione, integrazione, test end-to-end e di terze parti, alla fine di un progetto. L’idea di fondo è: se i team di sviluppo rimandano questo lavoro alla fine, possono completare una fase e passare a quella successiva più rapidamente, sicuri del fatto che tanto potranno tornare indietro per la correzione di errori e la stabilizzazione del progetto. C’è però chi considera questo andirivieni un mero lavoro aggiuntivo privo di funzioni o caratteristiche a valore aggiunto.
Perché esistono gli hardening sprint
Gli hardening sprint sono più comuni nei contesti di grandi dimensioni. Quando le organizzazioni IT più grandi adottano un framework Agile scaled, entrano in gioco più team Scrum, ognuno dei quali ha normalmente da otto a dieci membri. Lavorando contemporaneamente, questi team Scrum sfornano blocchi di funzionalità rilasciabili, sprint dopo sprint, fino a quando il sistema non è pronto per un hardening finale o per consentire agli sviluppatori di stabilizzare il software prima del suo rilascio pubblico.
Un tempo, lo Scaled Agile Framework (SAFe) richiedeva un hardening del tipo innovation and planning (HIP) alla fine di quello che veniva chiamato un incremento potenzialmente spedibile. Tuttavia, nella versione 5.1 Big Picture di SAFe datata febbraio 2021, si riduce l’enfasi sulla necessità di uno sprint hard a favore di approcci di sviluppo più continui che incorporano DevOps. Mentre altri framework Agile scaled, o approcci Agile alternativi, potrebbero anche non richiedere l’utilizzo di un vero e proprio hardening sprint. Tra questi ci sono:
- Large Scale Scrum (LeSS). È incentrato su sprint mirati a produrre prodotti potenzialmente spedibili che siano conformi a una stretta definizione di fatto. Se la definition of done non è soddisfatta, i team LeSS decidono come procedere.
- The Project Management Institute’s disciplined Agile (DA). Consente ai team di adottare qualsiasi metodo ritengano migliore alla situazione prendendone i concetti in prestito – incluso potenzialmente un hardening sprint – da Scrum, Lean Agile, Kanban e altri framework.
- Precedentemente noto come metodo di sviluppo dinamico del sistema, DSDM si basa sul concetto di sviluppo rapido delle applicazioni. È incentrato sulla gestione di un modello di progetto in cui le decisioni su cosa lasciare o togliere da un prodotto vengono prese quando si avvicina la scadenza.
- Svrappone un team di integrazione a più team Scrum per garantire che l’integrazione avvenga durante gli sprint piuttosto che fare affidamento su un hardening sprint alla fine.
Perché la definizione di “fatto” è importante?
Il modo in cui un’organizzazione definisce l’esecuzione di ogni singolo sprint – la definition of done – determina la quantità di lavoro residuo che si accumula per lo sprint di rafforzamento che avviene verso la fine di un progetto. A questo proposito esistono opinioni diverse: ci sono le definizioni di done rilassate e flessibili di team di sviluppo che cantano vittoria nella story card di uno sprint, però rischiano che sorgano piccoli difetti in produzione. E ci sono le definizioni più rigide e impegnative degli sviluppatori che, invece, vogliono essere sicuri di aver sviluppato e testato completamente tutti i requisiti, e sono certi che ci sia un rischio minimo che un difetto raggiunga la produzione.
In entrambi i casi, è importante accumulare il meno debito tecnico possibile. Maggiore è il technical debt che impantana un’applicazione, più si gonfia l’arretrato e più è probabile che sia necessario (almeno) un hardening sprint. Più a lungo un team di sviluppo non riesce ad affrontare il debito tecnico, più tempo tende a impiegare per identificare e correggere gli errori sottostanti. Quando uno sviluppatore ha bisogno di riabituarsi a un problema, ad esempio quando sceglie di affrontare il problema in uno sprint di rafforzamento anziché in modo più immediato, sbrogliare la matassa richiede più tempo. Il tempo aggiuntivo introdotto dal cambio di contesto è l’interesse dovuto per il pagamento del debito tecnico.
I grandi team di sviluppo hanno un certo margine di manovra nella definizione di fatto. Ma i team di piccole e medie dimensioni non hanno questo lusso. Ecco perché i team medi e piccoli dovrebbero fare il possibile per garantire che tutti gli elementi della story card abbiano una rigida definizione di done. L’approccio migliore per sviluppatori e tester è quello di affrontare i problemi quando si presentano per la prima volta, specialmente se il tempo incrementale di sviluppo e test non mette in pericolo le fasi successive.
Come evitare gli hardening sprint
Un modo per evitare gli hardening sprint è quello di restringere l’ambito delle user story nello sviluppo software. Supponiamo che una squadra sia alle prese con una story dove un requisito copre più condizioni o scenari. Il team dovrebbe dare priorità a ciò che è necessario per avere un prodotto minimamente redditizio. Attraverso la valutazione del rischio, il team di sviluppo dovrebbe identificare le condizioni e gli scenari utili a questo scopo. Gli elementi di DSDM utilizzano questo approccio.
Un altro modo è lo spillover o lavoro fuori ciclo. Può capitare che un team valuti di non poter completare lo sviluppo e il test per tutti i requisiti critici di una story nel tempo stabilito. In questo caso, piuttosto che definire il done in modo più rigido, il team dovrebbe continuare l’attività, ma riconoscere che il lavoro necessario rischia di “traboccare” nello sprint successivo. Un’altra opzione, simile, è quella di considerare il lavoro rimanente una release off-cycle, sempre che il team possa completare le attività assegnat prima della fine dello sprint successivo.
È evidente che, se un team conosce la propria velocità di sprint, può mettere da parte una quota di “story point”, come fosse una indennità, per sistemare gli spillover da uno sprint all’altro. Pianificare l’uso di questa opzione consente agli sviluppatori di decidere se è necessario fare pulizia dell’arretrato da un progetto e decidere cosa spingere nelle versioni future. I team che eseguono più test unitari o abbracciano lo sviluppo basato sui test potranno farsi un’idea migliore del numero di condizioni e scenari che è possibile sviluppare e testare completamente all’interno di uno sprint.
In definitiva, non si dovrebbe essere dogmatici e decidere di abbracciare gli hardening sprint solo in base a ciò che dice qualche evangelista o fanatico della materia. Piuttosto, si dovrebbero modificare in modo creativo i processi esistenti Agile e Scrum per rispondere meglio alle esigenze. Un consiglio condiviso dagli analisti: adottare i processi che funzionano meglio è preferibile al cercare di inserirsi in toto in un particolare framework.
