Lean Software Development 101
Tempo di lettura: 10 minuti
La metodologia Lean trae origine dal concetto di Lean manufacturing implementato da Toyota negli anni ’80 con l’obiettivo di eliminare gli sprechi, semplificare la catena del valore, realizzare una produzione just in time e dare risalto alle persone che forniscono valore. Il fine è quello di portare un miglioramento continuo facendo le cose nella maniera in cui andrebbero fatte (kaizen) e facendo in modo che tutte le persone coinvolte si impegnino in maniera proattiva per un miglioramento proprio e dell’azienda. Per migliorarsi, non sempre bisogna comprare macchinari più veloci; spesso basta concentrarsi sui piccoli e continui sprechi di risorse e di energia. Ogni miglioramento può essere realizzato mediante ciclo continui di Plan – Do – Check – Act.
I princìpi e pratiche di Lean
Da questa base culturale Mary e Tom Poppendieck, nel 2003, sono partiti per realizzare qualcosa di simile nel mondo dello sviluppo software. I due hanno definito sette princìpi e ventidue pratiche che, come già visto in precedenza, devono essere applicate per concretizzare i princìpi ai quali si ispirano. Per una migliore comprensione, le pratiche saranno spiegate direttamente dopo l’enunciato del principio al quale sono collegate.
Il primo principio è fondamentale nella metodologia Lean:
eliminare gli sprechi.
Questo non significa togliere elementi marginali, ma avere più tempo per ciò che realmente fornisce valore al progetto. Le pratiche che si collegano a questo sono:
riconoscimento degli sprechi: essi possono essere legati ad un lavoro svolto in maniera parziale (che può diventare obsoleto e immobilizzare capitali), ed un eccesso di lavoro (sovra elaborazione non richiesta dal cliente o che non porta valore a quest’ultimo), a una sovrapproduzione (aggiunta di requisiti non richiesti dal cliente), ad un’allocazione di risorse su più progetti in contemporanea (il multitasking porta le persone a distrarsi e ad impiegare molto tempo nel passare da un’attività all’altra, soprattutto quando i compiti da svolgere in “parallelo” sono più di due), ad un’attesa (nel sapere cosa fare, come procedere), ad un movimento (spostamenti da realizzare, documentazione da creare per interagire con altre persone) e, ovviamente, a dei difetti (è meglio testare tutto subito in modo da trovarli il più velocemente possibile);
value stream mapping: mappare tutto il flusso che porta alla realizzazione di un particolare prodotto e valutare tutto ciò nel suo insieme in modo da poter trasformare la situazione odierna (as is) in un qualcosa che abbia globalmente prestazioni migliori (to be); si andrà ad agire togliendo tutto ciò che fa parte degli sprechi evidenziati in precedenza e che non crea valore per il cliente finale.
Il secondo principio afferma la necessità di
amplificare l’apprendimento.
Bisogna aumentare il dialogo quando ci si trova davanti ad un problema e non procrastinare. Le pratiche utilizzate a questo proposito sono:
feedback: come è già stato possibile osservare in precedenza, anche per questo framework è molto importante il concetto di feedback, che permette di verificare e controllare continuamente ciò che viene realizzato, mostrare nuove soluzioni ed eseguire test appena viene realizzata una parte del prodotto;
iterazioni: la metodologia Agile si basa sempre su periodi di tempo limitati al termine dei quali le parti si riuniscono per allinearsi e valutare il lavoro svolto;
sincronizzazione: è importante che, all’interno del team, il lavoro proceda in maniera sincrona per portare il maggior beneficio possibile; per fare ciò, si istituiscono momenti di verifica quotidiana e anche di integrazione settimanale tra gruppi differenti;
sviluppo set-based: la comunicazione deve essere utilizzata per trasmettere i vincoli del progetto e non le scelte che vengono effettuate. In questo modo si riduce il numero di dati da trasmettere mantenendo comunque elevata l’informazione e le scelte possono essere rinviate mantenendo più soluzioni alternative possibili, sempre rimanendo all’interno dei vincoli di interesse per il progetto.
Il terzo principio è legato all’ultima pratica che abbiamo presentato:
decidere il più tardi possibile.
Mantenere più possibilità aperte permette di rispondere meglio ad eventuali cambiamenti ed esigenze del cliente. Pratiche che favoriscono questo modo di agire sono:
option thinking: cercare di resistere alla tentazione di fornire decisioni irrevocabili a fronte di elementi di incertezza. Soprattutto nella fase iniziale, è bene cercare di ridurre queste scelte in modo che eventuali problematiche risultino meno impattanti per il progetto nel suo insieme;
last responsible moment: ritardare l’assunzione di decisioni il più possibile perché questo porta all’eliminazione di ogni possibile alternativa;
making decisions: prendere decisioni non deve portare ad isolare il problema del quale si sta discutendo, ma deve piuttosto essere un processo guidato continuamente da feedback derivanti da informazioni in tempo reale.
Il quarto principio evidenzia la necessità di effettuare rilasci di valore il prima possibile, in quanto afferma che si deve
consegnare il più velocemente possibile.
In questo modo il cliente può sfruttare maggiormente i rilasci come opportunità di business e il fornitore riesce ad avere sempre un punto fermo che eviti continui cambi di idea lato cliente e quindi eccessivi stravolgimenti. Questo principio risulta quindi essere complementare al precedente, perché accorciare i tempi di consegna permette di rimandare le decisioni il più possibile ma comunque a tempi vicini a quello di inizio dell’iterazione in esame. Le pratiche che aiutano ad implementare ciò sono:
pull system: sviluppo di un progetto cercando di ridurre gli elementi in coda, procedere con l’utilizzo di kanban che indicano le diverse attività da svolgere e limitare il numero di elementi che si possono trovare contemporaneamente in una determinata fase di elaborazione (come già visto nella sezione dedicata allo Scrum-ban);
queuing theory: cercare di rendere il flusso di lavoro il più uniforme possibile. Questo è possibile grazie all’elaborazione di piccoli pacchetti di lavoro e allo studio dei colli di bottiglia della fase realizzativa. Sarà così possibile allocare meglio le risorse con particolare attenzione alle attività maggiormente critiche;
cost of delay: la condivisione rapida di parti di prodotto permette di esprimere al meglio le potenzialità di quanto creato e di prendere decisioni nella maniera più condivisa possibile.
Il quinto principio sposta il focus sul gruppo affermando la necessità di
“dare forza al team” (empower the team).
Ogni membro del gruppo deve essere messo nella condizione di poter sfruttare al meglio il suo potenziale e aumentare anche il grado di soddisfazione sul lavoro. Con questa idea di fondo, può essere utile cercare di abbassare il grado delle persone che prendono decisioni, cosicché queste risultino più condivise e, allo stesso tempo, si sviluppi la capacità di questi soggetti di effettuare scelte via via più complesse. Legate a questi concetti esistono le seguenti quattro pratiche:
self-determination: definire il design della soluzione grazie a tutte quelle persone che possono portare idee di miglioramento per la soluzione stessa;
motivation: un team fortemente motivato sarà portato ad avere elevate performance e grande coesione, oltre a fornire ed avere sicurezza (parametro che deriva anche dalle competenze possedute e coltivate andando incontro a sfide sempre più probanti ma non impossibili da superare);
leadership: ogni membro deve sentirsi leader nel proprio lavoro, secondo le proprie capacità e responsabilità, sapendo che tutto deve essere condiviso e che il gruppo deve muoversi costantemente nella stessa direzione;
expertise: documentare la conoscenza tacita per rendere standard quello che in precedenza veniva condiviso solo oralmente o mediante riunioni e incontri.
Il sesto principio afferma la necessità di
costruire nell’integrità.
Il design deve essere il più semplice possibile per permettere modifiche che, però, non stravolgano mai l’integrità esterna (capacità del sistema di raggiungere un equilibrio) ed interna (sinergia e coesione nel lavoro) dell’intero sistema. Tutto questo è favorito da eccellenti flussi informativi. Le pratiche che favoriscono ciò sono:
perceived integrity: mantenere costantemente il valore dei clienti davanti a posizioni prettamente tecniche;
conceptual integrity: tutti i membri del gruppo devono lavorare in maniera sinergica e coesa, in quanto il risultato è un efficace equilibrio tra flessibilità, manutenibilità, efficienza e reattività. Il mezzo migliore per favorire ciò è la comunicazione faccia-a-faccia, che permette un migliore flusso dei feedback;
refactoring: migliorare il design del prodotto in modo da renderlo sempre più adeguato alle richieste del cliente, vale a dire migliorare i componenti interni senza modificare le funzionalità interne del sistema;
testing: testare il prodotto permette di garantire costantemente la qualità ricercata dal cliente che è una variabile non negoziabile.
Il settimo principio richiama l’attenzione sul
guardare l’intero.
Bisogna evitare di ottimizzare una parte specifica del sistema, bensì osservarlo e migliorarlo nel proprio complesso. Una delle tecniche utilizzate per ricercare un problema e analizzarlo a fondo è quella delle Five whys che consta nel chiedersi il perché di una determinata situazione fermandosi solo quando si è giunti alla radice del problema. Le pratiche legate a quest’ultimo principio sono:
measurements: effettuare la misura di dati aggregati in modo da analizzare situazioni di alto livello e non ricercare il dato specifico di ridotto ampiezza e interesse;
contracts: utilizzare contratti ad ambito negoziabile permette al cliente di incrementare la probabilità di implementare funzionalità ad alto valore lasciando a fasi successive (o anche tralasciando) il completamento di quelle di minore interesse.
