Modellazione di processo iterativo su una scheda kanban

Penso che lo scopo di una scheda Kanban sia quello di visualizzare molto rapidamente dove è tutto in questo momento insieme a un modo semplice per spostare le cose da un'area all'altra.

Ci sono alcuni dettagli in particolare sulla storia o il percorso di una determinata storia. Potresti volere una funzione separata sulla tua scheda che è più una storia di un diario.

Qui ci sono due storie che diciamo che entrambi hanno iniziato il punto # 2 (Very first development) allo stesso tempo. Esempio: storia "A"

1. Pianificazione
2. sviluppo
3. Test
4. sviluppo
5. Test
6. sviluppo

Esempio: storia "B"

1. Pianificazione
2. sviluppo

Entrambe le storie "A" e "B" sono in fase di sviluppo, ma c'è chiaramente qualcosa di diverso in corso con entrambe queste storie. La storia A viene inviata a test troppo velocemente o è molto più complicata? Quando un'altra persona viene coinvolta in queste storie in ritardo, la scheda kanban fornisce solo informazioni sufficienti per indicare che sono ancora in fase di sviluppo, ma non mostra i dettagli dell'iterazione tra test e sviluppo.

Se questo è un problema, potresti aver bisogno di un altro tipo di rapporto. Sfortunatamente con un sistema cartaceo, è necessario tenere traccia della data / ora in cui le storie vengono spostate da un luogo a un altro. Potrebbe essere più pratico chiedere semplicemente alle persone coinvolte: "Come va?"

Da quello che dici in entrambe le situazioni, l'elemento di lavoro sarà ancora nella colonna "Fare", sembra che ci siano diverse fasi di "Fare".

Forse, se vuoi tenere traccia di questo livello di dettaglio, potresti avere schede per ogni livello. Quindi una scheda di pianificazione può essere simile a:

|| Write Story  ||     Refine   || Customer Feedback ||
|| Doing | Done || Doing | Done || Doing | Done      ||

Quindi sposta i tuoi elementi di lavoro avanti e indietro in queste schede lasciando quelli di livello alto nella colonna di esecuzione finché le schede inferiori non sono complete?

Should you model iterative processes using Kanban?

If so, how? If not, why not?

Che cosa ottieni da modellazione / monitoraggio? A meno che lo sviluppo non inizi su storie che non sono ancora pronte (mai viste dai clienti, ambigue, ecc.), Dovresti risolvere un problema che non hai.

In pratica: non è necessario tenere traccia di ogni singola fase della codifica (ha scritto test, scritto API, scritto codice, scritto più test, convalida locale, spinto, CI in corso, risultati CI verificati) perché ci si aspetta chi è in carica della storia per prendersi cura di ciò correttamente. Perché non avere lo stesso tipo di aspettativa sul PO?

Ci sono due modi per gestire i processi iterativi su una scheda KanBan:

1. La progressione sulle colonne sul pannello da sinistra a destra indica il flusso ideale di un'attività. Se un'attività non può seguire il flusso ideale (ad esempio, se il test di verifica ha avuto esito negativo), il marker dell'attività può essere spostato in una colonna a sinistra, indicando che quella fase del processo non è stata completata.

2. Per le iterazioni in loop limitato, puoi semplicemente rendere la granularità della colonna tale che l'intero loop rimanga all'interno di quella colonna. Ad esempio, la preparazione di una storia per l'implementazione potrebbe essere una singola fase del processo, indipendentemente dalla frequenza con cui si va avanti e indietro con il cliente.

Con questo in mente, penso che la tua scheda 'semplicistica' sia già troppo complessa. Lo cambierei in

||          TO DO              ||                            DOING                   || DONE ||
||   Planning | Ready for      ||  Development | Ready for | Test | Tested | Deploy  ||      ||
||            | Implementation ||              | Test      |      |        |         ||      ||

Qui, le colonne "Ready for XXX" e "Tested" sono buffer in modo che le diverse fasi di sviluppo possano funzionare in un relativo isolamento l'una dall'altra. Su questa bacheca, un'attività non deve essere spostata su "Pronto per XXX" o "Testato" fino a quando non può essere prelevato da quel buffer dalla squadra successiva. Se, ad esempio, un test fallisce, allora quell'attività dovrebbe essere spostata in "Pronto per l'implementazione" in modo che possa essere nuovamente rilevata dal team di sviluppo.