Qualcuno usa Kanban (o scrumban) per le pratiche di gestione agili? Qual è la tua esperienza con Kanban? Come funziona in ambienti complessi di grandi dimensioni con dipendenze da progetti a cascata?Qualcuno sta usando Kanban?
So che la BBC lo usa abbastanza estesamente. Vedere il blog di David Joyce per ulteriori dettagli http://leanandkanban.wordpress.com/
Ha un mazzo di scivoli piuttosto pesante lì per setacciare.
Penso che la cosa da ricordare riguardo al pensiero Lean sia che devi considerare il flusso di valori nel suo complesso. Sebbene sia possibile ottimizzare il team di sviluppo utilizzando tecniche come Kanban, è più importante incorporare sia upstream (Management/Analysis) che downstream (QA/deployment/support) per raccogliere pienamente i frutti.
Pertanto, chiedere come si inserisce in una cascata o in un processo complesso (al di là del proprio effetto personale), non è la domanda giusta. Qual è una domanda più importante è chiedere come posso iniziare a effettuare l'intero flusso di valori. So che questo suona come l'inizio del fanatismo religioso Lean, ma è come realizzerete il vero valore di un processo snello.
Ad esempio, si consideri il seguente scenario per un tipico progetto:
Totale: 43 mesi
Se applicando Lean al processo di sviluppo si migliora del 100%, vale a dire un tempo di sviluppo di 4,5 mesi, portando un nuovo totale di 38,5 mesi. Hai solo aumentato il flusso del valore totale di poco più del 10% ... insignificante !!
È necessario iniziare a combattere il combattimento e portare il Lean a pensare al management superiore e dimostrare dove si trova il vero successo ... che è nella riprogettazione dell'intero processo.
Remember Lean NON è un processo di sviluppo, può essere applicato a tutti gli aspetti dell'attività.
Alcuni libri interessanti su come portare questa discussione oltre il team di sviluppo includono;
primo luogo, è importante rendersi conto dei problemi che Kanban nello sviluppo di software cerca di risolvere:
Principalmente, altre pratiche agili tentano anche di risolvere problemi simili con tecniche diverse.
grandi ambienti complessi con dipendenze da progetti cascata
Questo rende difficile se si dispone di una dipendenza da un progetto che non segue agile come allora la vostra coda di input non sarà prevedibile. Se un progetto non agile dipende da te, il problema potrebbe essere minore, ma potresti finire per produrre più di quello che può essere consumato ('muda' in termini lean). Quindi, idealmente vorrai che tutti i progetti dipendenti seguano almeno delle pratiche agili, se non lo stesso kanban.
Un bel articolo su Kanban, Flow e Cadence si trova here.
Qualcuno usa Kanban (o scrumban) per le pratiche di gestione agili?
Sì, sto usando :-)
Come funziona in grandi ambienti complessi con dipendenze progetti cascata?
Nel nostro ambiente abbiamo> 500 sviluppatori, quindi è abbastanza grande. Il mio team è stato il primo a utilizzare Kanban, principalmente per lavori di manutenzione e ora per lo sviluppo. Il nostro lavoro quotidiano è stato molto difficile, perché gli altri team dipendenti stavano seguendo le tecniche di sviluppo e gestione classiche e hanno gradito (lo fanno ancora) a spingere il lavoro e Kanban è circa pull.
Il nostro approccio era di comunicare il più possibile per rendere il nostro lavoro trasparente, ma a causa della riluttanza dell'ambiente ci siamo concentrati sul nostro lavoro interno. Il limite del WIP ci ha aiutato a rimanere concentrati e con il flusso di lavoro di visualizzazione sapevamo chi sta facendo cosa al momento.
Il nostro throughput prima di Kanban era del 90% (in altre parole, quando sono entrati 10 articoli, ne abbiamo consegnati solo 9), e dopo Kanban avevamo il 100,4% ed era in aumento. Come ulteriore risultato, altri team hanno iniziato a venire e chiedere di Kanban, perché amavano i nostri risultati e volevano implementare il loro sistema Kanban. Al momento conosco circa 5 team, che hanno avviato Kanban nella nostra organizzazione.
HTH,
Zsolt
da allora il libro Kanban da David Anderson è stato pubblicato, anche – Ingvald