Non tutte le aziende sono così grandi da poter dedicare un intero team su un singolo progetto.
Esistono invece innumerevoli piccole realtà che devono seguire (perlopiù contemporaneamente) più progetti di diversi clienti con lo stesso team di sviluppo e devono comunque garantire gli stessi risultati in termini tempi/costi/qualità di aziende più grandi. In questa fascia si posiziona DevInterface srl, azienda di sviluppo software di Verona.
Da anni realizziamo progetti web per molteplici clienti e spesso le tempistiche di sviluppo e rilascio si sovrappongono. Il nostro obiettivo è quello di poter garantire comunque continuità nelle release di ogni progetto senza ritardi e mantenendo alta la qualità del codice.
Vediamo come!
Tra i vari modelli di sviluppo Agile, quelli che abbiamo adottato nel corso di questi anni sono Scrum e Kanban. Grazie a Scrum abbiamo messo in produzione con successo numerose applicazioni, ma abbiamo dovuto dedicare un team esclusivamente per quei progetti. A lungo andare ci ha resi meno "agili" di quanto volevamo essere. Da qualche anno invece, abbiamo iniziato ad adottare Kanban per la nostra "pianificazione interna", semplificando enormemente il nostro workflow operativo. Prima di entrare nei dettagli, faccio notare che questa è la nostra rivisitazione "opinionated" di Kanban: la nostra è un'azienda di sviluppo e non un ambiente accademico, pertanto possiamo assumerci la responsabilità di modificare metodologie e pratiche sulla base delle nostre esigenze.
Ma torniamo a noi!
Sostanzialmente, il nostro flusso di lavoro si suddivide in:
- Backlog: contiene tutto l'insieme delle user stories del progetto, ancora in uno stato "grezzo". I requisiti sono abbozzati e non è nemmeno detto che tutto verrà mai implementato. Spesso accorpiamo le storie in Sprint, più che altro per una questione di rilasci e di pagamenti da parte del cliente.
- Ready for development: contiene le storie sufficientemente dettagliate per essere implementate: hanno al loro interno la lista dei task ed una valutazione sull'ampiezza di sviluppo e sulla priorità. Sono storie approvate dal Cliente e pronte per essere implementate.
- In progress: storie in fase di sviluppo e testing: non avendo un team dedicato di tester, chi sviluppa è responsabile della suite di test automatici (se richiesta dal progetto). Abbiamo smesso di fare TDD e nemmeno testiamo tutto di tutti i nostri progetti: se il budget/tempo/scope del progetto lo permettono lo facciamo volentieri, altrimenti hot fix successivo.
- Done: storie implementate e testate, pronte per essere deployate in un qualche ambiente.
- Staging: storie deployate in un ambiente di test, pronte per essere testate ed approvate dal Cliente.
- Production: storie messe in produzione.
Come da copione, anche noi misuriamo il tempo in cui una determinata storia rimane in ogni punto del workflow ed in particolare: Ready for development rappresenta il punto di partenza del conteggio del tempo; Done il punto finale.
Come potete notare, non prendiamo in considerazione il backlog, perché rappresenta solo un insieme di funzionalità magari ancora non approvate, in attesa di dettagli, nice to have, next release ecc.
Non prendiamo in considerazione nemmeno staging e produzione, perché? Perché spesso le tempistiche di messa in staging o in produzione non dipendono da noi ma sono conseguenza di test ritardati del cliente, cause di forza maggiore, ripensamenti ecc e noi non vogliamo che le nostre statistiche di sviluppo vengano alterate per questi inconvenienti. Quindi per farla breve, il nostro cumulative flow chart si basa solo su 3 stati.
Fin qui non abbiamo aggiunto nulla di nuovo o rivoluzionario rispetto a quanto è già stato ampiamente ribadito nella letteratura agile. Quindi, come facciamo a gestire multi progetti multi cliente? Innanzitutto inseriamo N righe nel grafico, una per ogni progetto, in modo da avere una visione globale del tutto.
Il nostro cumulative flow chart diventa pertanto multidimensionale: il grafico specifico del progetto va a contribuire al calcolo del grafico globale aziendale
In questo modo, abbiamo una visione dettagliata del singolo progetto e globale dell'insieme.
Manca però ancora qualche tassello per completare il quadro: nell'introduzione ho detto che il nostro è un unico team di sviluppo: significa che lo stesso sviluppatore deve probabilmente seguire contemporaneamente più progetti. Non abbiamo ancora menzionato il WIP, il work in progress limit... Ecco la nostra soluzione: anziché limitare ogni punto del workflow con un WIP, limitiamo ogni sviluppatore con un WIP.
Ogni sviluppatore di DevInterface ha un WIP di due storie contemporaneamente nella colonna "In Progress". Ecco che magari la mattina siamo su un progetto e il pomeriggio su un altro; l'importante è non eccedere il limite di storie in lavorazione.
Talvolta succede che progetti già in produzione presentino bachi o comportino fix immediati: come conciliamo queste attività? Queste sono "storie" ad altissima priorità che possono capitare e per cui ammettiamo che anche uno sviluppatore con il WIP pieno possa accantonare momentaneamente quello che stava facendo per seguire il problema.
Grazie a questo metodo, possiamo gestire numerosi progetti nello stesso tempo avendo comunque una visione globale data dal Global Cumulative Flow ed una visione specifica data dal Project Cumulative flow.
Il Project Cumulative flow ci fa notare se stiamo accantonando troppo le storie di uno specifico progetto, obbligandoci pertanto a prenderne in carico lo sviluppo. L'insieme di queste due misure ci permette quindi di stimare con precisione i tempi di rilascio di ogni insieme di feature perché siamo a conoscenza del tempo medio di sviluppo di ogni singola storia.
Dato un progetto e suddiviso in storie all'incirca stessa grandezza, possiamo prevedere abbastanza dettagliatamente i tempi di rilascio di ogni funzionalità. In questo modo, il Cliente vede uno sviluppo continuo e di qualità e noi possiamo comunque portare avanti contemporaneamente più progetti.
