In questo blog ho parlato relativamente poco di lean IT, ossia l’applicazione di lean thinking nello sviluppo di software. E nel feedback che ho ricevuto da uno di voi mi è stato chiesto se potevo un pò approfondire questo argomento.
Premetto che non sono un grande esperto di programmazione, ma i principi lean sono (e come se lo sono, basta leggere il bellissimo blog di Eric Ries Lessons Learned per capire i principi oppure del suo collega Timothy Fitz se siete un pò più tecnicamente dotati…) applicabilissimi nello sviluppo di software. Inoltre, due libri da non perdere assolutamente per gli sviluppatori e/o per chi vuole avvicinarsi alle tecniche lean nello sviluppo di software, di Mary e Tom Poppendieck: Lean Software Development: An Agile Toolkit e Leading Lean Software Development: Results are not the point.
Allora, cosa è che caratterizza lo sviluppo dello software?
Come prima cosa, si lavora per progetti generalmente non ripetitivi. Quindi ciò che sembra a prima vista è che non ci sono mai due lavori uguali.
La seconda caratteristica fondamentale è che le specifiche dettagliate del prodotto finito spesso non sono chiare, neanche al cliente che lo sta comprando (tranne che nel caso di un altro geek che sa esattamente cosa vuole realizzare con il sistema ma non ha tempo materiale per farlo…). Questa poca chiarezza dei requisiti spesso porta ai disaccordi con il cliente…
La terza caratteristica è che il lavoro è spesso personale e invisibile, davanti al proprio schermo, quindi è difficile da osservare il flusso del lavoro come nella produzione fisica.
Allora, come può essere applicato il lean thinking a questo ambiente?
Si parte dalla soddisfazione del cliente… E voi mi chiederete subito: Ma come, non avevi detto che il cliente non sa esattamente cosa vuole? E ve lo dirà se va bene solo a lavoro ultimato. E’ un problema grosso per i programmatori. Per questo motivo bisogna capire MOLTO BENE ciò che i clienti sono disposti a pagare (ciò che veramente ritengono valore) all’opposto di ciò che dicono che vogliono. E come si fa a capirlo? Dopo ogni implementazione bisogna fermarsi un attimo in una sessione di hansei (riflessione) e capire quanto abbiamo capito bene ciò che ci aveva chiesto il cliente. La domanda chiave è: Abbiamo azzeccato ciò che ci aveva chiesto il cliente? E se no, perché no? Dobbiamo imparare a capire quanto siamo bravi noi a capire ciò che ci chiede il cliente e implementare il miglioramento continuo (apprendimento più approfondito) su cosa capiamo e cosa possiamo fare per capire meglio i requisiti dei clienti. E come possiamo condividerlo meglio e capirlo prima nel nostro processo di comunicazione con il cliente.
Una delle risposte per questo tipo di ragionamento è il cosiddetto continuous deployment. Ossia implementazione continua. Cosa ci indica questo termine? Indica l’implementazione di piccoli pezzi del codice nell’applicativo live, praticamente in tempo reale, man mano che il codice viene creato. Ma il segreto non è solo nell’implementazione continua, ma anche nei test che vengono fatti in continuazione su questo codice e nel feedback che riceviamo dal cliente man mano che esso viene provato. Come si arriva a fare il continuous deployment? Attraverso la definizione delle fasi del progetto: più piccole la fasi e più spesso lo applicheremo dal vivo (anche più volte al giorno…) e più spesso avremo il feedback sia dal programma di testing (per scoprire i bug ed errori) sia da parte del cliente (per le caratteristiche che voleva avere). Possiamo applicare il tabellone visuale (ricordatevi che il lavoro del programmatore è generalmente poco visuale…) in tre parti (Da Fare, In Test, Finito/Applicato) dove vengono messe le parti del programma da codificare e vengono portate nella parte Finito una volta finiti tutti i test nell’applicativo live. Se si scoprono i bug nel codice, è immediato trovare degli errori in quanto stiamo implementando man mano che codifichiamo e dobbiamo guardare solo nell’ultimo pezzo del codice fatto, risparmiandoci così grandi perdite del tempo nel cercare dove si trova l’errore come succede spesso nella programmazione tradizionale (dove cavolo ho fatto l’errore?).
Il secondo principio lean è il Just-In-Time. Il tabellone di sopra ci serve, oltre che come indicazione visuale del flusso di lavoro, anche come suddivisione del progetto in pezzettini secondo il nostro takt time. Quale è il takt time che vogliamo? E’ la nostra frequenza di implementazione che scegliamo (giornaliera, oraria, settimanale ecc. – più frequente è, meglio è). In questo modo riusciamo a dividere il nostro progetto in parti del codice di dimensioni più o meno simili e di livellare la distribuzione dello stesso alle varie risorse (programmatori) che abbiamo a disposizione. Stabilire il takt time può sembrare difficile all’inizio, ma è il fondamento di lean IT come lo è nella produzione fisica in officina. Definisce il battito cardiaco delle consegne.
Il terzo principio fondamentale è jidoka: costruire in qualità. Sopra ne ho già fatto cenno: implementare in cicli brevi vuol dire scoprire gli errori man mano che vengono creati e risolverli immediatamente, senza proseguire fino a quando non vengono completamente risolti e trovate le adeguati contromisure.
Sommando, i punti chiave sono:
- visualizzare il processo
- implementare continuamente
- rivelare gli errori non appena si verificano con adeguati strumenti per testing
- risolverli uno ad uno immediatamente
- migliorare continuamente la gestione del processo con suggerimenti e miglioramenti delle persone (standardizzazione delle buone pratiche) soprattutto dopo la fase di hansei (riflessione)
- ricordarsi sempre del vero bisogno del cliente, di quello per cui esso è disposto a pagare, e fornirgli esattamente questo, quando lo vuole, nella forma in cui lo vuole e senza errori.
Qualche suggerimento? O vi piacerebbe avere qualche approfondimento sul tema trattato? Sono qui e vi ascolto… 😉