Archivi tag: lean

Tempo di attesa

Perché è necessario visualizzare il lavoro e controllare il WIP? Per questo semplice motivo.

Se lavoro 50% del mio tempo si ha che sono libero il 50% del mio tempo. Dato che la definizione di tempo di attesa è data da % tempo occupato / % tempo libero ottengo che => 50% / 50% = 1 unità di tempo è il mio wait time come risorsa se sono occupato al 50%.

Se lavoro il 90% del mio tempo si ha che: 90 / 10 = 9 unità.

Attenzione al punto dell’80%! Da lì in poi si vola all’infinito e oltre!

clip_image004

Se definiamo la nostra unità di tempo come 1h abbiamo che quando chiediamo qualcosa a qualcuno che è impegnato (o libero) al 50% ci impiegherà 1h per prendere in mano la questione. Se la chiediamo a qualcuno che è occupato al 90% ci impiegherà 9h per dedicarsi al nostro problema. Un incremento del 40% del lavoro porta a moltiplicare per 9 il nostro tempo di attesa. Se supponiamo che la nostra richiesta a tale persona/risorsa sia per 1h di lavoro abbiamo che la percentuale di tempo a valore aggiunto (o touch time) è del 10%!

1 ora di lavoro  / (9 ore di attesa + 1 ora di lavoro) = 1h / 10h => 10 %

Per me questo grafico è disarmante per la sua semplicità e per quanto apra gli occhi sull’avere tutte le persone coinvolte in un processo sempre cariche di lavoro.
Pensiamo a un processo che coinvolge due sole persone per un’ora ciascuna e che entrambe siano occupate al 90%. Ottengo che per un lavoro di 2 ore uomo ci vogliono 20 ore di attesa.

Avete mai ragionato su tematiche simili? Qual è la vostra esperienza sui tempi di attesa e quali sono le tecniche che usate per ridurli?

Le tre vie

Archivio qui degli appunti che avevo preso per sintetizzare un po’ di concetti appresi dopo la lettura di The Phoenix Project.

Vengono elencati e brevemente spiegati tre principi cardine che sono alla base del DevOps. Per me DevOps è un termine un po’ troppo inflazionato: qualcosa che fa figo dire adesso perché va di moda. Restano comunque validi i principi enunciati e le pratiche esposte.

La prima via – il flusso

Riguarda il flusso di lavoro da sinistra a destra dal dipartimento Development alle IT Operations al cliente finale.
Per massimizzare il flusso bisogna ridurre le dimensioni dei batch e gli intervalli di lavoro, evitando di passare difetti ai centri di lavoro successivi.
Bisogna ottimizzare per obiettivi globali, non locali per reparto.

Le pratiche necessarie richiedono: continuous build, integration and deployment; creazione di ambienti a richiesta; limitare il WIP; costruire sistemi che sono sicuri e facili da cambiare.

La seconda via – i feedback

Riguarda il costante flusso di feedback da destra a sinistra, in tutti gli stadi del flusso del valore.
Amplificare i feedback per assicurarci di imparare dagli errori (e non ripeterli!). Migliorare i processi di raccolta feedback. Facendo questo si migliora la qualità alla fonte (o dove serve).

Le pratiche necessarie includono “fermare la linea di produzione” quando le build o i test falliscono. Impegnarsi costantemente per migliorare il lavoro oltre che lavorare. Creare test suite automatiche e rapide; creare telemetrie per ambienti di produzione.

La terza via – cultura

Creare una cultura che favorisca: sperimentazione continua che richiede prendere rischi e imparare dai successi e dai fallimenti; capire che ripetere e fare pratica è il prerequisito per la maestria. Rischiare permette di migliorare il nostro modo di lavorare, richiede spesso di fare cose diversamente da come la stiamo facendo da decenni. Il non cambiare non porta a una situazione piatta, ma di declino, perché interviene l’entropia.

Le pratiche necessarie includono creare una cultura orientata all’innovazione e al rischio (in maniera opposta alla paura o al “accettare ordini” senza pensarci); allocare almeno il 20% del tempo ai requisiti non funzionali; costantemente ricordare che i miglioramenti sono incoraggiati e celebrati.