Parto quotanto la parte incriminata

Per ogni fase ci possono essere un numero limitato di user stories, in questo modo si possono facilmente identificare eventuali stalli, fasi problematiche, sprechi di vario genere ecc…, peccato che tutto questo sia molto lontano dall’essere Agile… perchè? Semplice il limite è imposto sulle fasi, si presuppone quindi che ogni fase sia un sottosistema dimensionabile a piacere per equilibrare il flusso delle user stories fino al loro completamento, una fabbrica insomma, alla fine siamo tornati al waterfall (il cravattato ci prova sempre, non c’è niente da fare)

Molto più Agile e sensato sarebbe limitare la capacità produttiva del team sulle dimensioni del team stesso, banalmente una user story per sviluppatore, al limite per coppia di sviluppatori. Ad ogni sviluppatore assegnamo una calamita, le user story appese alla lavagna sono in lavorazione, una user story può essere appesa usando solo una di quelle calamite, una calamita può essere usata solo con una user story alla volta ed il gioco è fatto. Le fasi possono essere ancora conservate, possono essere utili per stanare certi problemi, ma l’enfasi dovrebbe essere sugli sviluppatori e non sulle fasi (“Individuals and interactions over processes and tools” vi ricorda qualcosa?)

Premettendo che ognuno può fare quello che vuole (ammesso che ne paghi direttamente le conseguenze), sarebbe meglio che lo facesse sapendo quello che sta facendo e perchè lo fa. Quello che ho notato è che chi ha adottato le Kanban Board lo ha fatto senza porsi delle domande fondamentali: qual’è l’oggetto della limitazione? Qual’è la misura del miglioramento? Come misuro la capacità produttiva del mio sistema? Ecc…

Ok lo ammetto, è una mia supposizione il fatto che la maggior parte non si ponga queste domande. Questa supposizione derivata dal fatto che mi sembra applicata troppo “by the book”, dove il “book” non riguarda affatto la produzione del software ma una catena produttiva manifatturiera.

Le Kanban Board nel mondo del software generalmente sono divise per fasi e la limitazione è applicata appunto su queste fasi, perchè? Partendo dal presupposto che lo scopo è quello di stabilizzare e velocizzare il flusso delle user story nelle varie fasi, stiamo dicendo che è possibile “dimensionare” ogni fase a piacere? Quindi, per esempio, chi sviluppa non fa deploy di quello che ha sviluppato? Evidentemente, altrimenti non si spiega perchè la fase dello sviluppo è dimensionato a 5 user story e il deployment a 1

Sempre a proposito delle fasi, negli impianti manifatturieri il fatto che ogni fase sia limitata è una coseguenza banale del fatto che le linee produttive sono per loro natura limitate, ma vale la stessa cosa nel software? Nel nostro team siamo in 5, non possiamo essere nella fase di test tutti e 5? O non possiamo fare deploy tutti e 5? Perchè? A meno che non ci siano 3 analisti che si occupano della fase di analisi, 5 sviluppatori che si occupano della fase di sviluppo, 2 persone che si occupano dei test, ecc… Allora sarebbe un’altra storia, ma trattare il team a dipartimenti specializzati e ridimensionabili a piacere è quello che vogliamo? Personalmente mi fa venire la nausea, ma basta esserne consapevoli

Domanda ancora più importante: il total flow in questo caso come lo si immagina? O meglio, qualcuno misura il Lead Time? Domanda lecita visto che non ne sento molto parlare, almeno non tanto quanto sento parlare di Kanban Board, e visto che la riduzione del Lead Time dovrebbe essere l’obiettivo finale…

Insomma, non vorrei che il seguire una moda possa fare più male che bene, sopratutto quando non ci si prende la briga di studiarla, di comprenderne il funzionamento e sopratutto senza domandarsi come misurare il miglioramento secondo i propri obiettivi. In particolare l’applicazione classica per fasi mi sembra pericolosa da questo punto di vista e suggerivo un’alternativa che mi sembrava meno rischiosa. Dato che l’approccio è di tipo sistemico, una volta messa in campo una Kanban Board “storta” si corre il rischio di stortare tutto :-)

Prima si è iniziato a parlare di Lean, poi qualcuno ha iniziato ad usare e a parlare di Kanban Board, infine adesso Kanban è diventato quasi il nome di una metodologia. Adesso quando uno parla di Kanban non so a cosa pensare:

• Starà parlando di Kanban come sinonimo di Lean? Si ma Lean come sinonimo di Lean Thinking, ovvero la filosofia Lean o Lean Development, ovvero l’applicazione della filosofia Lean allo sviluppo del software?
• Starà parlando di Kanban come sinonimo delle board che adesso vanno tanto di moda negli Agile shop?
• Starà parlando di Kanban come di una non meglio precisata metodologia? Come lo ScrumBan, ovvero uno Scrum che fa uso di Kanban Board o come Kanban, ovvero l’uso delle Kanban Board misto a qualche pratica presa da XP?

Insomma un delirio, la salvezza come al solito sta nella conoscenza: bisogna tornare alle origini della parola, studiarne l’evoluzione per capirne le implicazioni ed un eventuale contesto d’uso

Kanban si traduce in cartellino: I giardini imperiali giapponesi sono curati all’ossessione e sono considerati un patrimonio del giappone, per questo solo poche (supponiamo 100) persone alla volta sono autorizzate ad entrare, per garantirlo vengono usate delle tessere di plastica bianche, ne esistono solo 100, una persona può entrare solo se possiede una di queste tessere che possono essere prelevate da un contenitore all’ingresso, quando il contenitore è vuoto nessuno può entrare, quando una persona esce deposita la sua tessera che verrà automaticamente trasferita nel contenitore all’ingresso consentendo a qualcuno di prelevarla ed entrare. Le tessere di plastica sono Kanban

Quindi i Kanban sono la rappresentazione sistemica del vincolo sulla capacità produttiva dell’impianto. Cosa significa quesa frase e come può tornare utile allo sviluppo del software lo spiego subito

L’applicazione del pensiero Lean porta ad eliminare una classe di problemi e/o di sprechi nell’attività produttiva attraverso un approccio sistemico ovvero creando un ambiente di lavoro che rende difficile commettere errori. Un esempio tipico sono i connettori la cui forma impedisce fisicamente di sbagliare verso. Un altro bell’esempio ce lo forniscono gli ospedali in cui si applica il pensiero Lean, nei quali tutte le attrezzature hanno un posto dedicato che solitamente viene marcato con un’immagine stilizzata del tipo di attrezzo che dovrebbe occupare quello spazio, in questo modo

• E’ molto semplice accorgersi se uno strumento è fuori posto perchè ci sarebbe l’immagine dello strumento senza lo strumento stesso
• Nei momenti d’emergenza non devi metterti a pensare dove si trova uno strumento perchè sta sempre nello stesso posto
• L’ordine non è più una questione di gusto personale :-)
• Essendo la distribuzione degli strumenti così rigorosa è possibile fare esperimenti per capire se un’eventuale riorganizzazione (che è quasi sempre microscopica seguendo il principio del Kayzen) produce un miglioramento o meno

Quando si ha a che fare con dei sistemi complessi è molto più efficiente ed efficace applicare un controllo indiretto invece che tentare di forzare le singole parti al proprio volere, basta pensare all’acqua, le singole particelle costituiscono un sistema complesso con proprietà emergenti, come fai a trasportare l’acqua? tenti di convincere le singole particelle? La sposti fisicamente? O crei un canale e lasci che felicemente scorra seguendo le proprie leggi ma finendo esattamente dove vogliamo Quest’ultimo può essere definito un approccio sistemico

Ahhhh se solo la maggior parte dei manager sapesse… il mondo girerebbe diversamente, ma la resa dei conti arriverà presto caro cravattato dall’ignoranza bovina… ma sto divagando

Le Kanban Board creano un ambiente di lavoro dove è difficile commettere una serie di errori classici della produzione: avere molte user stories in lavorazione (semilavorati) che non portano valore al sistema, evitare il sovraccarico di lavoro del team, individuare molto velocemente eventuali parti critiche dello sviluppo di una user story, ecc… Bene, ma dove sono i Kanban nelle Kanban Board che si usano nella produzione di software? Non sono le carte delle user stories (come banalmente si potrebbe pensare), i kanban rappresentano i limiti della produttività del sistema, in questo caso il limite è sul numero delle user stories che possono essere in lavorazione ovvero i kanban sono i singoli “posti” che possono essere occupati dalle carte delle user stories.

Per ogni fase ci possono essere un numero limitato di user stories, in questo modo si possono facilmente identificare eventuali stalli, fasi problematiche, sprechi di vario genere ecc…, peccato che tutto questo sia molto lontano dall’essere Agile… perchè? Semplice il limite è imposto sulle fasi, si presuppone quindi che ogni fase sia un sottosistema dimensionabile a piacere per equilibrare il flusso delle user stories fino al loro completamento, una fabbrica insomma, alla fine siamo tornati al waterfall (il cravattato ci prova sempre, non c’è niente da fare)

Molto più Agile e sensato sarebbe limitare la capacità produttiva del team sulle dimensioni del team stesso, banalmente una user story per sviluppatore, al limite per coppia di sviluppatori. Ad ogni sviluppatore assegnamo una calamita, le user story appese alla lavagna sono in lavorazione, una user story può essere appesa usando solo una di quelle calamite, una calamita può essere usata solo con una user story alla volta ed il gioco è fatto. Le fasi possono essere ancora conservate, possono essere utili per stanare certi problemi, ma l’enfasi dovrebbe essere sugli sviluppatori e non sulle fasi (“Individuals and interactions over processes and tools” vi ricorda qualcosa?)

Concludo dicendo una cosa ovvia: più si studia uno strumento/pratica/tecnica e più è facile utilizzarlo saggiamente nel contesto in cui ci si trova per raggiungere i nostri obiettivi, il pericolo è quello di abusarne o peggio essrne abusati :-)

L’articolo indica alcune pratiche che possono essere utilizzate dai programmatori per “mantenere un programma nella propria testa”, inizialmente sia l’obiettivo dell’articolo che alcune delle pratiche proposte mi hanno un po’ disorientato in quanto in apparente netto contrasto con quanto dettato dalle metodologie Agili: “Se Paul Graham è un mito, e ha ragione, allora hanno torto le metodologie Agili?” No, hanno ragione entrambi, i principi che stanno alla base sono gli stessi, come al solito tutto torna :-)

Prendiamo per esempio una delle pratiche più forti fra quelle proposte: “Keep rewriting your program”; come dargli torto? Capita spesso che durante la scrittura di un programma un programmatore arrivi ad un momento in cui la sua conoscenza attuale del problema e della relativa soluzione non sia più rispecchiata dal codice, riscrivendolo potremmo inserire nel codice tale conoscenza e quindi otterremmo del codice migliore. D’altra parte molti conosceranno la “Sindrome del secondo sistema” e sapranno quindi che la maggior parte delle riscritture dei progetti software risulta fallimentare. “Come è possibile che entrambe queste evidenze empiriche siano vere? Come risolvono la questione le metodologie Agili?”

Cos’è il refactoring se non un’attività di continua riscrittura del codice? Kent Beck spiega perchè eXtreme Programming è eXtreme: tutte quelle pratiche che hanno dimostrato nel tempo di essere valide sono state portate all’estremo. La revisione del codice funziona? Bene, revisioniamo il codice sempre! = Pair Programming. La riscrittura di programmi porta a dei programmi con un design migliore? Bene, riscriviamo i nostri programmi continuamente! = Refactoring

Attraverso la pratica del refactoring possiamo trasformare (riscrivere) continuamente il nostro codice affichè rispecchi nella maniera migliore possibile la conoscenza che attualmente abbiamo del dominio del problema e della sua soluzione. Continuamente! Il trucco è sempre quello: se un’attività è rischiosa, difficile, costosa, ma potenzialmente di grande valore, quello che dobbiamo fare non è evitarla o prevenirla, ma trovare un modo per renderla meno rischiosa, meno difficile e meno costosa, mantenendone il valore inalterato (pensate per esempio alla Continuous Integration)

Al solito ci sono pratiche a corollario che portano il codice ad essere rappresentazione della nostra conoscenza:

• Unit Tests: come specifica eseguibile del comportamento dei componenti del nostro software
• Acceptance Tests: come specifica eseguibile delle funzionalità esibite dal nostro software
• Shared Code: fare in modo che il nostro codice sia leggibile a tutti i componenti del team (lo considero un super set di “Write rereadable code” dell’articolo di Graham)
• Domain Driven Design: sviluppare un linguaggio di dominio (Ubiquitous Language) all’interno del codice. Questa pratica potrebbe essere portata all’estremo scrivendo un’interprete per un DSL (Graham come Lisper a questo proposito ne sa qualcosa)