Nei progetti adozione della metodologia Kanban si cerca di minimizzare i cambiamenti dei singoli ruoli che intervengono lungo il value stream. I titoli assegnati rimangono gli stessi e pure le responsabilità quotidiane.

Quello che cambia, principalmente, è il modo in cui un team che adotta Kanban si relaziona con gli altri.

Si è, infatti, molto meno interessati al fatto che un certo progetto sia "puntuale" o che un determinato piano stia andando come inizialmente pianificato.

Il focus principale è sul mostrare quanto il team sia stato in grado di creare un sistema stabile, predicibile e adattivo.

Ecco le entità principali da tracciare e su cui costruire report:

• WIP, work-in-progress. Quanto lavoro sta attraversando il sistema e come?
• Lead time: quanto ci mette una richiesta a essere evasa dal momento in cui viene presa in carico?
• Quanto rispettiamo le scadenze? Per i work-item che hanno data di scadenza tassativa, quante volte siamo puntuali?
• Throughput: quanti item vengono portato in produzione in un certo periodo di tempo?
• Issue e item bloccati: quali work-item attivi hanno dei blocchi e quali sono?
• Qualità: quanti bug processiamo sul totale dei work-item in un certo periodo?

Nei prossimi messaggi entrerò nei dettagli di ogni metrica.

Sharing is caring

Se conosci qualcuno che potrebbe trovare utile ricevere e-mail per migliorare l'organizzazione dei team di sviluppo software, DevOps e software engineering in generale inoltragli questo post! Qui può iscriversi e cominciare a ricevere subito!

Rispondo alle tue e-mail

Nessuno ci fa mai caso nelle newsletter ma puoi rispondere a questo messaggio e io lo leggerò! Fammi sapere cosa ne pensi!