Roberto Cappelletti Blog

Dove vogliamo andare?
Quest'anno in azienda tra gli obbiettivi che ci siamo dati per il 2012 c'è la necessità di migliorare il processo di sviluppo software.
Due aspetti su cui vogliamo concentrarci sono la visibilità delle informazioni e la gestione del cambiamento perché sono quelli che ci danno maggiori difficoltà.

Dove siamo?
Facciamo un passo indietro; quale metodologia e quali strumenti utilizziamo?
La metodologia è incrementale adattativa, basata sul nostro modello di business, prende spunto per la parte di project management da Scrum e per la parte di sviluppo dalle pratiche di Xp (Continuous Integration, Testing …).
Lo strumento principe è ovviamente Tfs (Source Control, Work Item Tracking, Build) a cui si agganciano altri strumenti creati ad hoc.
Tfs è veramente eccezionale sul tracking ma, purtroppo è dentro un pc, NON lo vedo e NON lo tocco, perciò ci serviva qualcosa su cui “sbattere la faccia”.
Scrum è una ottima metodologia ma, ci siamo resi conto di non riuscire a mantenere Sprint con time box fisso e Sprint Backlog rigidi.
Quindi pur essendo Scrum poco prescrittivo abbiamo avuto il timore di snaturare la metodologia.

Cosa è Kanban?
Kanban letteralmente significa Cartellino e arriva dal mondo Lean Development.
Si basa su 3 concetti base:
- Rendere il lavoro visibile
- Limitare il work in process
- Aiutare il flusso a scorrere

Solitamente viene utilizzata una Kanban Board cioè una lavagna suddivisa in colonne che rappresentano gli stati.
Il lavoro viene diviso in parti e scritto sulle card, e queste sono appese sulla board.
Agli stati vengono assegnati dei limiti che vincolano il lavoro contemporaneo.
L’obbiettivo è ottimizzare il processo per rendere il lead time (il tempo di attraversamento) quanto più piccolo e prevedibile possibile.

Come vogliamo adottarlo?
L’idea è di partire con una sperimentazione su alcuni team e di estendere poi il modello a tutti i team dell’azienda.
Non volevamo stravolgere il modo di lavorare quindi tutti gli strumenti e i processi nella prima fase resteranno invariati. Per fare una esempio chiarificatore i work item saranno ancora presenti in tfs, semplicemente saranno visibili anche sulla Kanban bord.
Ogni team avrà la sua board.
I post-it saranno di più colori e ogni colore rappresenterà una iterazione. Accade infatti che nel nostro modello di business, un team lavori per più clienti contemporaneamente o anche su più iterazioni contemporanee magari legate a branches differenti.
La board ci consentirà visualmente di monitorare l’avanzamento, le code e i colli di bottiglia, limitando i continui cambi di contesto sulle attività parallele.
Ricordo una bella sessione di Brandolini che mostrava come il costo di una funzionalità crescesse quanto più questa rimaneva bloccata e al tempo stesso impediva di fare crescere il Roi derivato.

Sulla card abbiamo deciso di riportare il numero di work item, una descrizione sintetica della richiesta, dei pallini neri che visivamente ci indicano che quella richiesta è stata soggetta a dei bug, e un peso indicativo in ore.
Durante l’incontro che abbiamo fatto insieme al team, che è partito per primo, abbiamo definito quali erano i limiti per ogni stato partendo dalla formula (numero dei componenti del team * 2 -1) e fatto piccoli adattamenti al modello della bord generale che avevamo preparato.

Per trarre conclusioni è presto ma, sicuramente sono emerse due evidenze:
Una pratica all’apparenza semplice (carta su una lavagna) in poco tempo fa emergere problemi invisibili prima e attira la non facile attenzione del management.