Nel nostro team tutti i passaggi dell'attività sono sempre eseguiti dallo stesso sviluppatore. I.e per l'attività 1, la persona A progetta, sviluppa e verifica; per l'attività 2, la persona B non progetta, sviluppa e verifica, ecc. Ha senso usare Kanban in questo caso?
Suggerirei di utilizzare ancora Kanban modificando leggermente il processo:
Person A does design Person B does design
Person B Reviews A's Design Person A Review's B's design
Person A does development and Person B Does Development and Initial Testing.
initial testing
Person B QA's person A's work Person A QA's Person B's work.
Mettere tutte le attività con 1 sviluppatore, come ha sottolineato Chad, è una ricetta per il disastro mentre non era nella fase iniziale, ma sicuramente lungo la strada quando sarebbe necessaria la manutenzione del progetto.
In una certa misura, dobbiamo rispondere con "... dipende". Mi piace personalmente iniziare con "Come sta funzionando per te?" Del Dr. Phil.
Ci sono alcuni "paraurti" di base per tenerti sulla buona strada, con ciò intendo best practice e / o pratiche kanban.
Come altri hanno menzionato: le migliori pratiche sono che gli sviluppatori non testano il proprio codice. Penso che tutti siano d'accordo.
L'altro è ridurre WIP e spostare il codice su DONE. In agile, non esiste uno "sviluppo fatto". Il codice è fatto quando è sviluppato, testato e approvato. Tutto sommato è "In corso".
Kanban è incentrato su VALUE FLOW . Spinge a concentrarsi sul "completamento del lavoro", invece di avere molti "lavori in corso". Pertanto, le squadre sono ALTAMENTE incoraggiate a sciamare.
Le fasi di progettazione, revisione, sviluppo, test, approvazione approvate non tengono conto del fatto che lo sviluppo può comprendere molti passaggi, alcuni dei quali possono essere eseguiti simultaneamente da persone diverse. (Non in tutti i casi, concesso)
Mi piace sottolineare ai miei team la differenza tra un processo a thread singolo, in cui i lavori devono essere eseguiti in modo seriale, rispetto ai sistemi a più thread, in cui i lavori possono essere eseguiti contemporaneamente. Gli sviluppatori sembrano comprendere facilmente la differenza nella potenza di elaborazione usando quell'analogia e li aiuta a guidarli nei prossimi passi.
Le metriche kanban includono il tempo di ciclo e il tempo di tocco. Il tempo di ciclo è la durata totale dal momento in cui il lavoro viene avviato fino alla sua fine. Touch Time è quanto tempo è necessario per farlo, e può essere lo sforzo sommato di tutte le risorse che toccano il compito.
L'obiettivo è aumentare il flusso di valore in ogni modo possibile, e questo si tradurrà in una riduzione di questi parametri che dimostrano efficienza acquisita e aumento della produttività.
Pertanto, è più efficiente eseguire il multi-thread (sciame) del processo e ridurre il tempo di ciclo.
Esempio: un'attività ha 20 ore di lavoro su 10 fasi. Se una persona lavora ogni attività in modo seriale, 8 ore al giorno, senza problemi, il lavoro può essere completato in 2,5 giorni. Tempo di ciclo = 2,5 giorni, tempo di tocco = 20 ore.
Lo stesso compito, uniformemente sciamato. Dev 1 fa 10 ore di lavoro, Dev 2 fa lo stesso. Tempo di ciclo = 1,5 giorni, tempo di tocco = 20 ore.
L'attività è pronta per approvare in 1,5 giorni rispetto a 2,5 giorni.
Quindi nel tuo esempio, ha senso usare Kanban nel caso che hai descritto, ma il processo che hai descritto potrebbe essere migliorato per aumentare l'efficienza e la qualità.
* Se qualcuno vede qualche difetto nella mia logica fammelo sapere!
Leggi altre domande sui tag kanban