Caratteristiche, funzionamento e processo di Scrumban

Scrumban

Il metodo Scrumban è stato introdotto da Corey Ladas nel suo libro “Scrumban: Essays on Kanban Systems for Lean Software Development”; in questo testo l’autore afferma di aver pensato Scrumban come un percorso evolutivo per permettere a un team di sviluppatori di cambiare il proprio metodo da Scrum a Kanban, o più in generale ai metodi Lean. Il passaggio a un nuovo metodo non è mai semplice e questi cambiamenti avvengono meglio se non vengono effettuati in modo drastico, ma introdotti gradualmente. In questo contesto Scrumban si propone come una valida via di mezzo tra i due metodi per poter abbandonare gli strumenti e i principi di Scrum e adottare quelli di Kanban.

Scrumban privilegia lo sviluppo just-in-time e riduce i tempi di rilascio, queste caratteristiche lo rendono vantaggioso in alcune situazioni in cui il team trova Scrum troppo rigido rispetto alla flessibilità richiesta dai compiti da svolgere.

Nel caso di progetti che hanno già terminato la fase di sviluppo e sono ormai in fase di manutenzione, Scrumban può essere usato per gestire una situazione dove gli interventi richiesti sono di tipo event-driven (come la risoluzione di bug) oppure se è necessario fornire un supporto ai clienti; ricordando che la fase di manutenzione corrisponde a circa metà del processo di sviluppo del progetto. Questo avviene perchè il software richiede cambiamenti dovuti all’evoluzione dell’ambiente in cui opera (aggiornamento del sistema operativo o delle librerie o del database sono tra i motivi più comuni); quando il software non viene più aggiornato può essere considerato deprecato, se questo avviene perchè il software è troppo difficile da modificare allora sono state sprecate delle risorse.

Un altro caso in cui Scrumban può risultare vantaggioso è quando un progetto è nelle fasi di hardening e packaging, poichè in questi stadi dello sviluppo non avviene l’introduzione di nuove feature.

Esistono, però, anche casi in cui un progetto è in fase di sviluppo, ma un metodo meno rigido e con una gestione più lasca dei tempi di sviluppo può aiutare il team a recuperare la situazione e riportare il progetto sui binari: per esempio quando un progetto riscontra molti più errori rispetto a quanto preventivato o ha la necessità di introdurre continuamente nuove User Story nel processo di sviluppo; oppure quando uno Scrum Team ha problemi a gestire il flusso di lavoro o a sfruttare correttamente le risorse disponibili, oppure il processo di sviluppo riscontra spesso degli stalli.

Un’altra situazione in cui è possibile applicare Scrumban è quello di gestire le fasi che precedono e seguono uno Sprint con questo metodo, mentre durante lo Sprint si continua a usare Scrum.

Per capire se l’adozione di un metodo meno rigido sia utile al progetto è possibile osservare dove avvengono più spesso dei cambiamenti all’interno uno sviluppo iterativo, questo è un valido punto di partenza per capire dove il sistema richieda maggiore flessibilità. Inoltre, se alcune aree del software richiedono continue modifiche nel corso dello sviluppo, molto probabilmente le stesse aree saranno oggetto di interventi in fase di manutenzione.

Processo Scrumban

Non è difficile aggiungere a Scrum alcune pratiche tipiche dei metodi Lean. La pratica più semplice da integrare è quella di ridurre i tempi delle iterazioni, anche se il processo non è privo di problemi.
L’approccio più semplice è quello di cominciare con delle iterazioni e una pianificazione à la Scrum per poi aggiungere caratteristiche dei sistemi di tipo pull nel processo di sviluppo.

Un modo per introdurre il team alla filosofia Lean è quella di imporre dei limiti al multitasking a cui gli sviluppatori possono essere sottoposti; la regola può anche essere molto semplice: meglio terminare lavori già in stato avanzato di sviluppo piuttosto che cominciarne di nuovi, oppure, si può portare avanti una sola attività alla volta.
Anche se chiunque può farsi carico di più di un’attività alla volta, se tutti gli sviluppatori lavorano su più feature contemporaneamente allora il sistema diventa meno stabile. Il problema è che imporre una regola solo sul singolo sviluppatore ottimizza il problema localmente, ma non globalmente; invece, se si setta anche un limite al numero massimo di feature in lavorazione per tutto il team, si permettono solo alcune eccezioni alla regola generale, questo metodo è più flessibile e, allo stesso tempo, disincentiva comportamenti viene naturale aggiungere uno strumento per misurarlo: il Cumulative Flow Diagram (CFD). Una semplice Burndown Chart ci informa sul fatto che il team stia o meno rilasciando delle feature, ma non spiega il perchè il team stia fallendo o avendo successo nello sviluppo del software. Invece, la CFD comunica molte informazioni riguardo ai tempi di consegna e alla quantità di feature che stazionano nei buffer; queste informazioni sono utili per individuare le fasi problematiche dello sviluppo.

Inoltre, se si definisce il flusso di lavoro in modo più preciso, è possibile sfruttare anche le specializzazioni degli sviluppatori. Infatti, è importante notare che i sistemi di tipo pull non incoraggiano la specializzazione, ma ne traggono vantaggio quando possibile. In fondo è il team che gestisce il flusso di lavoro, quindi è compito del team stabilire quale sia il modo per renderlo più efficiente.

Arrivati a questo punto, le fasi di revisione al termine dell’iterazione e la pianificazione avvengono come nel metodo Scrum, ma con un sistema di tipo pull si è reso il flusso di sviluppo più lineare e lo si è migliorato. Inoltre, è possibile avvantaggiarsi dei buffer e del CFD per individuare le opportunità di miglioramento. Mano a mano che si prende dimestichezza con il nuovo metodo, il team si troverà a concentrarsi sempre di più sulla durata delle iterazioni piuttosto che sulla Burndown Chart, poichè la capacità di rilasciare le feature velocemente è la conseguenza e non la causa derivante da un migliore processo di sviluppo.

Il tempo medio dei rilasci e la durata dei cicli diventano le prime aree in cui intervenire per migliorare i risultati. Infatti, se il team controlla la durata delle iterazioni e la capacità del team di rilasciare feature è ben bilanciata rispetto alle richieste, allora i tempi dei rilasci sono sotto controllo. Inoltre, se il team controlla la durata delle iterazioni, anche la quantità di feature completate è predicibile, quindi non verranno richiesti sforzi eccessivi e lavoro extra al team di sviluppo. A questo punto lo Sprint Backlog diventa un semplice “magazzino” con lo scopo di introdurre nuove richieste nel sistema, per cui deve essere minimizzato il più possibile al fine di ottimizzare i costi di pianificazione (pianificare più del dovuto diventa tempo sprecato perchè le stesse feature verranno pianificate nuovamente nella successiva iterazione). Dal punto di vista del team di sviluppo l’utilità dello Sprint Backlog è solo quella di fornire compiti che hanno un alto valore aggiunto. Quindi per controllare la durata delle iterazioni è sufficiente imporre un limite fisso allo Sprint Backlog, invece di valutare quanto tempo richiede ogni feature che viene inserita nel backlog. Infatti, contando il numero medio di feature rilasciate ad ogni iterazione non è più necessario stimare i tempi per le feature nel backlog, ma è sufficiente calcolare la quantità media di feature presenti in esso.

Dopo questi ultimi accorgimenti, la pianificazione delle iterazioni avviene ancora a intervalli regolari, insieme alle fasi di revisione e retrospettiva, ma l’obiettivo della pianificazione è quello di aggiungere feature nel backlog in base alla quantità media e non più quello di determinare quante feature è possibile implementare in base alle stime delle singole attività. Questa nuovo approccio riduce enormemente la quantità di tempo dedicata alla pianificazione.

Arrivati a questo punto rimane solo lo scheletro di Scrum, mentre il processo di sviluppo è stato modificato e ottimizzato.
In conclusione, una volta che il processo di sviluppo viene gestito come uno flusso e tutti gli strumenti Kanban vengono usati dal team, quest’ultimo è in grado di abbandonare il metodo Scrum e adottare Kanban.