Mary e Tom Poppendieck, nel loro best seller "Implementing lean software development", hanno proposto una utile corrispondenza tra i sette sprechi del manufactoring e quelli del software.
| Manufactoring | Software Development |
| Inventory | Partially Done Work |
| Over Production | Extra Features |
| Over Processing | Relearning |
| Transportation | Handoffs |
| Motion | Task Switching |
| Waiting | Delays |
| Defects | Defects |
La prima colonna di questa tabellina è proprio quella che abbiamo approfondito nella prima parte.
Qui ci concentriamo sulla seconda.
Partially Done Work. Nello sviluppo del software l'Inventory è tutto ciò che non è completo, non deployato dal cliente, ma non solo. Alcuni esempi: requisiti o design che non sono stati implementati, codice non sincronizzato (ovvero il codice che si trova nell'area privata dello sviluppatore, branch che devono essere portati in merge con gli altri), codice non testato o non documentato (anche se idealmente il codice migliore è quello che si auto-documenta !).
E' interessante evidenziare che, in un progetto gestito con la classica metodologia waterfall, il work-in-progress (WIP) aumenta pericolosamente con il tempo, esponendo, l'azienda che lo implementa, a rischi davvero importanti.
Il grafico che segue riassume una ricerca di SolutionsIQ.com , in cui è possibile osservare come il WIP aumenta con le classiche fasi, in un progetto waterfall.
Nelle metodologie agili, la riduzione del WIP viene indirizzata attraverso l'organizzazione del lavoro in iterazioni che rilasiciano progressivamente, incrementi di prodotto potenzialmente vendibili (PSPI). Gli effetti di questo approccio sono evidenziati nel seguente grafico.
Ma non lasciamoci ingannare dai cicli che possono somigliare a micro-waterfall. Sono solo indicativi. L'idea è che ogni iterazione si conclude con un rilascio (R1,...R7) di valore per il cliente.
Extra Features. Si tratta delle funzionalità disponibili ma mai (o raramente) usate dai clienti che, appunto, non ne hanno effettivo bisogno. Viste le implicazioni, si tratta di uno dei peggiori sprechi nel software. Autorevoli ricerche asseriscono che l' 80% dei benefici di un software vengono realizzati dal 20% delle sue feature. Jim Johnson, Chairman di Standish Group, riportò, alla Third International Conference on Extreme Programming, che il 64% delle feature del software sono raramente o mai usate.
Questo punto però merita una riflessione. Potremmo dire che le feature le chiede il cliente e quindi noi non possiamo farci nulla. In effetti, nelle nostre tipiche dinamiche di contrattazione cliente-fornitore accade che i contenuti vengano contrattualizzati all'inizio e, lasciatemi dire, "blindati" con tanto di penali.
Per un cliente, la fase iniziale di contrattazione è probabilmente l'unica finestra di opportunità che consente di chiedere feature a "costo ragionevole", a meno di non entrare, in futuro, in un tunnel di change management, dove una feature potrebbe implicare una serie di costi inattesi e non sostenibili. Un cliente, nel dubbio, ti chiede tutto ciò che gli viene in mente all'inizio, anche se non userà mai quelle feature.
Credo che un modo per indirizzare queste dinamiche sia quello di instaurare una diversa relazione contrattuale con il cliente.
Qui parlo di "cliente" in senso lato. Questa dinamica negativa si rinnova anche all'interno delle stesse aziende, tra i gruppi Sales / Marketing e la R&D. A tal proposito, il mio amico Craig Larman, nei suoi libri, parla della necessità di uno shift da Competitive Game a Collaborative Game. Vi invito a dare un'occhiata.
Relearning. Ultimamente, nel mio ambiente di lavoro, alcuni team hanno affrontato una serie di problematiche abbastanza complesse. Durante la retrospettiva, ho chiesto: "come avete fatto tesoro dell'esperienza accumulata ?". Ecco... qui ho avuto le risposte più disparate. Ho osservato attentamente le persone ed ho trovato diversi modi di "knowledge management". Il sistemista ha, tipicamente, un suo file "txt" con i log dei comandi, lo sviluppatore "se lo ricorda" (e solo talvolta introduce un nuovo test case), l'hardwarista ha la lista di tutti gli interventi, etc. Ho inoltre osservato che, documentare tutte le scelte/azioni risolutive, crea un volume di documentazione che nessuno leggerà mai. Bene: il relearning è proprio l'effort che verrà nuovamente (e quindi è un waste) speso in futuro per riscoprire le cose che, in qualche modo, erano già noto.
In generale, consiglio sempre di anticipare e gestire i problemi via TDD. In caso di nuove anomalie, aggiungere casi di test. I Test Case custodiscono, documentano la conoscenza. Un buon set di test case garantisce che quel problema non accadrà più.
Handoffs. All'interno dei vari "passaggi di consegne" tra persone che lavorano in gruppi diversi, si cela uno degli sprechi più evidenti. Ad esempio: il passaggio di un documento di requisiti dal gruppo di analisti a quello di sviluppatori. Oppure la consegna degli artifatti dagli sviluppatori ai tester.
Mi viene in mente una vignetta che trovo spesso negli uffici dei colleghi. Eccola:
Carina, no ? E' simpatica e rende l'idea. E se la troviamo in giro, vuol dire che ne siamo consapevoli. Peccato che le nostre aziende sono spesso organizzate in gruppi che - by design - contribuiscono ad alimentare questo fenomeno negativo. E' evidente che questo tipo di waste è legato alla gestione della conoscenza nelle varie fasi del progetto.
In generale l'handoff avviene con la consegna di artifatti (e responsabilità) che descrivono una rappresentazione solo parziale della realtà. Fatta 100 la quantità di informazioni da passare, esistono ricerche che dimostrano che, ad ogni passaggio, si perde almeno il 50% delle informazioni utili.
Se poi pensiamo che in un contesto waterfall ci possono essere 4 fasi: requirements, design, code, test, allora si capisce che nella fase di test si è perso oltre il 90% delle informazioni utili...
Per questa ragione, nelle metodologie agili, il tema viene indirizzato con la creazione di team cross-funzionali che seguono tutte le fasi (requirement-2-deploy), con feedback frequenti e miglioramento continuo (Kaizen).
Task Switching. E' probabilmente la cosa che gli sviluppatori, ma non solo, odiano di più. Essere interrotti e passare su un altro task, probabilmente (spero) a maggiore priorità. Il task switching introduce un tempo di cambio di contesto che, all'aumentare del numero di task, risulta essere superiore al tempo richiesto per la soluzione di un task. Per non parlare degli effetti collaterali, misurabili in termini di bug, che questa mancata focalizzazione e concentrazione comporta. E' curioso notare che spesso i project manager "tradizionali", spinti dal miraggio dell'ottimizzazione dell'uso delle risorse e relativa pianificazione, contribuiscono ad alimentare una dinamica negativa ed al tempo stesso così semplice da capire. Mi è capitato di leggere report che dicono che una persona segue un'attività al 30%, una al 10%, una al 50% ed un'altra con "priorità background". Cosa ci aspettiamo ? :)
Qualcuno dirà che a volte si tratta di emergenze provenienti dall'ambiente di produzione. Ebbene, ci sono veramente diversi modi per indirizzare e gestire questi fenomeni. Anche a tal proposito ho trovato molto utili i consigli che il mio caro amico Craig Larman riporta nei suoi 2 libri.
Delays. Le attese. Quelle tipiche sono: ho bisogno della disponibilità di una persona che lavora in un altro team. Sono in attesa di informazioni / indicazioni, etc. Cosa fa una persona in attesa ? Cerca di risolvere da sola, passa su un altro task (!), naviga :) .Nessuna di queste dinamiche è positiva. Ancora una volta, le attese vengono diminuite grazie ai team cross-funzionali e colocati. Un ruolo fondamentale è giocato dalla qualità del PBR (Product Backlog Refinement) che intercetta anche le necessità dei team in termini di competenze, impianti, materiali.
Defects. Questa è facile. E' naturale associare il concetto di spreco alla difettosità. Un team agile ha il focus proprio su questo tema. Il pane quotidiano di un team agile è il Test Driven Development. Per questa ragione, un team agile ha un numero di difettosità tipicamente basso. Ma può accadere che i difetti possano essere rilevati in produzione. Quando capita, il team reagisce creando un nuovo test case che, accoppiato agli sviluppi, scongiurerà il ripetersi di quel particolare evento. Un team agile progetta il prodotto software attraverso la progettazione dei test case di accettazione.
Abbiamo visto un parallelo tra il mondo del Lean e quello dell'Agile. Ci siamo limitati ai sette waste e potremmo già spingerci a concludere che la filosofia Agile è praticamente basata sugli stessi principi del Lean, che è nato prima.
Charlie Rudd, CEO di SolutionsIQ (azienda attiva nella formazione e consulenza in campo agile) afferma: "[...] when one explains how iterative development reduces WIP, they are describing how the principle of (Lean) waste reduction is implemented in an Agile practice".
Lean ed Agile condividono dunque gli stessi principi. Discorso a parte meritano le applicazioni dell'agile, intese come i vari framework che implementano tali princìpi (es. Scrum, XP, ...). Si tratta, appunto, applicazioni pratiche.
Spero di aver contributo a fare un po' di chiarezza su queste tematiche.
Nessun commento:
Posta un commento