Metodi Agili: Kanban in Vivido – Quando e come iniziò

Metodi Agili: Kanban in Vivido – Quando e come iniziò

Vivido ha compiuto ad ottobre 12 anni.

Il concetto di miglioramento continuo, con tutto il suo carico di potenzialità e difficoltà, lo sperimentiamo da anni in varie forme, come ISO9001 che se correttamente inserita all’interno dell’azienda porta sicuramente dei benefici, primo fra i quali evidenziare l’esistenza di processi e quindi di procedure che devono gestirli, la qualcosa  sembra scontata,  ma garantisco che non lo è.
In modo del tutto spontaneo sono nati due appuntamenti più o meno costanti ; VividoSiForma e VividoLab, il primo è un momento dove chi ha fatto esperienze personali condivide le sue impressioni e la conoscenza con i colleghi (al momento è in stand-by) e VividoLab – idea nata da un Manifesto del nostro Pietro – intorno al quale vengono realizzati progetti, basati anche in questo caso su interessi personali  alcuni dei quali sono descritti all’interno di questa Blogzine.

Negli ultimi anni, ma più precisamente dal 2009 quando a Firenze si è tenuta la prima edizione del Better Software, è cresciuto l’interesse nei confronti dei Metodi Agili e alla fine quest’anno ci siamo decisi a iniziare un percorso per introdurre “cultura Agile” in Vivido.
Analizzando i percorsi fatti da altre aziende del nostro settore, abbiamo capito che era necessario essere guidati da chi conosce bene l’argomento, non solo dal punto di vista della metodologia, ma che abbia dimestichezza con le logiche e le tecniche dell’apprendimento e con la complessità delle relazioni interne ad un’azienda, che oltre allo Sviluppo Software comprenda le connessioni con le altre aree aziendali, come commerciale, amministrativa, controllo di gestione, che sono egualmente importanti perchè il “flusso” del lavoro circoli in modo equilibrato all’interno delle varie fasi e persone che compongono la quotidianetà del lavoro.

Scegliere un coach è un pò come scegliere lo psicoterapeuta, se sbagli il minimo danno che puoi subire è una perdita di tempo e di denaro lascio a voi immaginare il maggior danno 🙂 , quindi si deve andare sul sicuro, per fortuna la scelta è stata facile e a Rischio Zero, perchè Alberto Brandolini aka @zioBrando è per noi una persona conosciuta, seguiamo il suo lavoro da molto tempo.

Quello che riporto di seguito non è una disquisizione sul mondo dell’Agile – per quello il web è pieno di informazioni di ottimo livello -, ma sono le note corredate da foto che ho preso durante i tre giorni di corso.

Interessante sarà condividere in che modo  i Metodi Agile – e più nello specifico Kanban  -, farà il suo ingresso nella cultura di Vivido, evidenziandone successi e difficoltà.

Da parte mia mi sono ripromesso di monitorare con attenzione, quali saranno i benefici in termini economici che l’introduzione di Kanban porterà in azienda. Sono convinto che lavorare in team oltre che migliorare la qualità del lavoro e del tempo passato insieme, debba avere necessariamente – al di là di ogni ipocrisia – un riscontro positivo anche sul conto economico di una azienda, e sarà mio compito rendere disponibili queste informazioni alla comunità.
Anche perchè a tutti i talk ai quali ho assistito sull’argomento, molti dei quali estremamente interessanti, nessuno ha mai presentato metriche di tipo economico legate all’introduzione nelle rispettive aziende dei Metodi Agili. E spesso mi domando qual’è il motivo.

Passiamo alle Note Brute 🙂

Giorno 1

Sviluppo finisce quando cliente accetta (parafrasando Boskov) cit. @zioBrando

07

Al Cliente cerco di fargli vedere il prototipo il prima possibile, anche dopo 2 o 3 giorni dall’inizio.

Primo esempio di Kanban board

 

02

Domanda: E’ buona norma che i componenti dei team cambino spesso.
Risposta:In genere sarebbe meglio di no

Da sviluppatori sottovalutiamo le cose mezze fatte.

Il Product Owner se si lavora su commissione , è difficile che sia del cliente, è meglio che sia al nostro interno e che quella persona abbia (buoni) rapporti con il cliente.

Un po’ di storia
All’inizio era Waterfall

03

Nel 2001 , 17 persone si incontrano e gettano le basi dell’Agile.

Nella slide c’è scritto:  “I Team che praticano Scrum possono arrivare ad uno stato di iper-produttività corrispondente al +600% rispetto alle performance precedenti”.

04

Giorno 2

06 08

Lo Sviluppo è apprendimento.
Col gioco si impara meglio.
Lo stress impedisce l’apprendimento

——

Si può costruire anche una Board Commerciale agganciata alla board di produzione.

——

Una proposta di board che rappresenta la situazione attuale Vivido, dove ad oggi non ci sono veri e propri team, ma singoli sviluppatori che lavorano ad uno o più progetti (in questa prima board non vengono messi i limiti al wip, verranno da se).

Sulla sinistra le persone e sulle colonne il WiP

10

Dare forma al flusso mediante la board fa emergere il tempo speso male.

Una delle regole base del Kanban è “visualizza il reale workflow”.
Questo ha portato in alcune realtà al miglioramento nella prima settimana del 20%-30%.

Per gli Stand up meeting massimo 15 minuti.

KANBAN: INTANTO INIZIAMO E SPERIMENTIAMO E FACCIAMOLA EVOLVERE VIA VIA CHE CONOSCIAMO IL NOSTRO SISTEMA.

12

 

Un sistema diventa bloccato se tutti sono specialisti ed allocati. Per essere efficiente CI devono essere persone NON impegnate.

La Specializzazione è un collo di bottiglia.

Preallocare è spreco.

Stima e Prioritizzazione è un operazione poco interessante. Si deve essere veloci a scegliere che cosa si deve fare, il resto della coda è meno – o quasi per niente – interessante.

E’ importante poter misurare il tempo in cui una persona diventa produttiva in un progetto che non ha mai visto.

Definire una matrice delle competenze.

13

La cosa migliore sarebbe mettere la persona che ha il problema vicino a quella che ha la soluzione.

Descrizione del nostro normale FLUSSO di lavoro. (Value Stream)

In Alto  attività che danno VALORE, in basso (rosso) quelle che lo tolgono, normalmente i tempi di ATTESA

 

14 15

 

Ci sono tre (quattro con le EMERGENZE) tipi di PROGETTI / ATTIVITA’

  1. Quelle che devi garantire la consegna, ma anche se sfori di un po’ è tollerabile
  2. Quelle che devi consegnare obbligatoriamente ad una data certa (ex: Natale)
  3. Quelle INTANGIBILI , sono quelle a bassa priorità , sono quella dalle quali puoi prelevare le risorse per gestire quelle in alto (card Rossa, che sono le emergenze, al massimo 5%, si parla di attività di qualche ora)

 

16

Giorno 3

“Un magazzino può prendere fuoco, il software no, anche se a volte sarebbe meglio” cit. @zioBrando

Nel backlog mettere solo le cose necessarie, il resto è solo “rumore”

Quando si approccia un progetto conviene definire un codice minimo, ma fin da subito andare a “toccare” tutti gli ambienti con i quali andremo a collegarci, simulando gli ambienti, e quindi testando come si comportano in tutti i casi.

Andare sempre a “vedere” dove è il problema.

Quindi il concetto è quanto si è veloci a imparare. L’Apprendimento è buona parte della soluzione dei problemi.

La Matematica del Mucchio è semplice “Un Mucchio – 1 è sempre un Mucchio”

 

->>>> Altro concetto importante è DARE FORMA ai problemi <<<<-

 

Il mercato non è detto debba sapere che noi stiamo utilizzando metodi Agili, il risultato del miglioramento lo utilizzeremo per altre attività (apprendimento, gioco, lab, etc)

——-

Teoria dei Vincoli (Theory of Constraints) – il libro che la descrive è The Goal – Eliyahu M. Goldratt

Fondamentalmente si tratta di individuare il Collo di Bottiglia, ma risolto quello si sposta ed avrò un nuovo Collo di Bottiglia. Quindi avrò sempre un Collo di Bottiglia.

Identificare  vincoli del sistema

  1. Decidiamo come sfruttare al massimo i vincoli del sistema
  2. Subordinare tutto il resto alla decisione
  3. Elevare i vincoli del sistema
  4. Se un vincolo è saltato, identificare il nuovo vincolo

18 19 20

La Matematica del Mucchio è semplice “Un Mucchio – 1 è sempre un Mucchio”

 

->>>> Altro concetto importante è DARE FORMA ai problemi <<<<-

 

IL mercato non è detto debba sapere che noi stiamo utilizzando metodi Agili, il risultato del miglioramento lo utilizzeremo per altre attività (apprendimento, gioco, lab, etc)

——-

Teoria dei Vincoli (Theory of Constraints) – il libro che la descrive è The Goal – Eliyahu M. Goldratt

Fondamentalmente si tratta di individuare il Collo di Bottiglia, ma risolto quello si sposta ed avrò un nuovo Collo di Bottiglia. Quindi avrò sempre un Collo di Bottiglia.

  1. Identificare  vincoli del sistema
  2. Decidiamo come sfruttare al massimo i vincoli del sistema
  3. Subordinare tutto il resto alla decisione
  4. Elevare i vincoli del sistema
  5. Se un vincolo è saltato, identificare il nuovo vincolo

 

21

5 Perché descritti (andare al paragrafo LA SAGGEZZA DEI CINQUE PERCHE) da Eric Ries in Lean Startup  e ripresi dal Toyota Lean Production sono importanti, ma si deve alla fine soprattutto trovare la FORMA del problema

22

 

Altre foto le trovate qui

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *