Kanban / Scrum Boards [chiuso]

Question

Sono curioso di sapere cosa usano gli altri per le schede fisiche Kanban / Scrum nelle loro aziende. Mi rendo conto che a causa di informazioni commerciali riservate potresti non essere in grado di fornire una foto della scheda. Sto cercando di scoprire che aspetto ha la tua board e come organizzi le storie e le attività degli utenti mentre passano attraverso uno sprint / iterazione tipico?

In genere ho lavorato in luoghi che organizzano il consiglio come segue con ciascuno

User Story   | Todo                   | In Progress  | Ready for QA     | Done   |
UC-001       | Domain Object, Service | DAO(Bob)     |                  |        |
UC-002       | Payment UI Screen      |              | Payment Srv (Don)|        |
UC-003       |                        |              | UC-003           |        |
             |                        |              |                  | UC-004 |
             |                        |              |                  | UC-005 |

Quindi, per riassumere:

• È in corso un'attività per UC-001 da un membro del team (Bob). Un elenco di compiti che altre persone possono raccogliere sono in attesa nella colonna di Todo, ma questo può essere raccolto da un altro membro del team che coordina con Bob per portare a termine il lavoro.
• Per UC-002 l'attività di servizio di pagamento è stata completata ed è stato completato un cablaggio di test automatizzato per il QA che consente loro di testare il servizio senza un'interfaccia utente. Se il test ha esito negativo, viene sollevato un bug e spostato insieme all'attività Servizio di pagamento nella fase QA
• Tutte le attività per UC-003 sono state completate e spostate in Pronto per il QA.
• Tutte le attività per Uc-004 e UC-005 sono state completate, quindi la user story è stata spostata su Fine.

Funziona come una lavagna bianca tangibile che coinvolge le persone che interagiscono con ciascuna delle attività / storie degli utenti (rappresentate come post-it). Una versione elettronica viene creata prima dello sprint / iterazione e viene aggiornata solo al termine dello sprint / iterazione corrispondente alla situazione attuale. Commenti e critiche sono i benvenuti:)

Answer 1

Usiamo qualcosa ispirato al famoso Scrum e XP from the Trenches da Henrik Kniberg, le colonne vengono adattate in base al contesto (spesso: TODO, ON GOING, TO TESTED, DONE):

alt text http://blog.realcoderscoding.com/ wp-content / uploads / 2008/09 / hk.png

Gli articoli di arretrato prodotto (PBI) sono stampati come "schede fisiche" (Formato A5) per lo Sprint Planning Meeting (almeno il più importante). Una volta che il team ha raccolto i PBI per la successiva iterazione, gli elementi vengono suddivisi in compiti / attività (su foglietti adesivi). Dopo l'incontro, tutto va sullo Scrum Board e suggerisco di usare nastro adesivo o puntine da disegno o magneti. I PBI sono ordinati per importanza, il più importante nella parte superiore della scheda, meno importante nella parte inferiore. Il team dovrebbe lavorare sull'elemento più importante prima di farlo. In primo luogo, l'attività post-spostamento si sposta da sinistra a destra. Quindi, il PBI passa a Fine. Le attività impreviste vengono aggiunte a un " Articoli non pianificati " zona (per tenerne conto nel grafico di burndown). I PBI futuri resteranno visibili in un "Avanti" zona (se tutti gli elementi sono stati completati durante l'iterazione, ne scegliamo uno nuovo da lì). Abbastanza semplice.

Queste pratiche consentono di rilevare visivamente gli odori, ad esempio:

• compiti bloccati (cioè compiti che non si muovono) che mostrano un potenziale impedimento
• team che fa le cose nell'ordine sbagliato e non si concentra su elementi prioritari, come nel tuo campione :)
• troppi lavori in corso, nulla di fatto
• oggetti non pianificati che stanno uccidendo uno sprint

Funziona alla grande.

Se stai cercando più "kanban orientati" cose, forse dai un'occhiata a Kanban vs Scrum , Un giorno nella terra di Kanban e Kanban e Scrum - una guida pratica dello stesso Henrik Kniberg. Grandi cose anche.

E, per altre foto, prova Google Immagini con scrum + board , kanban , scrumban , scrum + kanban .

Answer 2

Ecco la nostra Kanban Board che usiamo su TargetProcess . Non lavoriamo a livello di attività, ma solo a livello di storie utente e bug. A volte creiamo attività, ma non vengono tracciate esplicitamente sulla lavagna.

Non stimiamo le storie utente e i bug, ma proviamo a dividere le storie in più piccole (con successo misto). Le colonne si spiegano da sole. Accumuliamo oggetti nella colonna Testato , quindi creiamo un ramo, fumiamo test e rilasciamo una nuova build. Di solito rilasciamo una nuova build ogni due settimane.

Anche la scheda mostra il carico degli sviluppatori e dei tester e le classi di servizi tramite la codifica a colori.

UPD. Ora abbiamo diversi piccoli team e utilizziamo una singola scheda per tenere traccia dei progressi di tutti i team in http: //www.targetprocess. com / 3

Answer 3

Storyboard di programmazione Scrum / Extreme.

http://www.flickr.com/photos/dafydd_ll_rees/4138686549/

Il lavoro appare sulla seconda colonna da sinistra e avanza attraverso le diverse fasi di completezza.

Nomi delle colonne: non iniziato, appena iniziato, a metà strada, quasi completato, pronto per la presentazione (superato il QA)

La prima riga è appositamente riservata per la correzione dei bug, come una priorità fissa per la risoluzione dei bug.

I personaggi dei Simpson rappresentano ogni membro della squadra. Vengono spostati in modo da poter vedere chi sta lavorando su cosa.

Answer 4

Ti consiglio di dare un'occhiata alla tavola di Eylean. http://www.eylean.com/?utm_source=geffort&utm_medium=content&utm_campaign = geffort può soddisfare tutte le tue esigenze grazie a un'interfaccia intuitiva, statistiche, dashboard. Inoltre si adatta a qualsiasi processo e la cosa più importante è molto facile da usare. Questa scheda consente di rappresentare più progetti su una scheda utilizzando le righe. Tutte le righe possono essere visibili contemporaneamente o è possibile rimuovere quelle selezionate dall'ambito. Un'altra soluzione può essere il raggruppamento e il filtro delle attività per categorie - quindi tutte le attività possono essere rappresentate su una scheda e riga, ma collegate a categorie diverse.

Answer 5

In pratica, l'organizzazione del consiglio di amministrazione dei lavori in corso è meglio che il team decida in base alle circostanze e all'ambiente. (Agile == autogestione.)

Detto questo, ecco cosa abbiamo fatto nel mio team precedente, parte di un impegno di oltre 300 sviluppatori che era relativamente nuovo per Agile e Scum:

Avevamo due schede: una con le schede per le storie imminenti in modo da poter dire cosa stava per succedere e una con il lavoro dello sprint corrente. Le nostre colonne sull'attuale sprint board erano semplicemente

Not Started
Under Development
Dev Done 
In QA
Complete ("Done Done")

e una casella nell'angolo per Blocked .

Una nota di post-it rappresentava ogni storia.

Gli sviluppatori avevano ciascuno una piccola calamita che ogni mattina usavano in piedi per indicare chi stava lavorando su cosa. Il nostro team era piuttosto grande (~ 12 a un certo punto), quindi questo ha davvero aiutato a capire chi fosse accoppiato con chi.

Non ci siamo preoccupati di una versione elettronica (nessun punto), sebbene il nostro Product Owner avesse un sistema Scrumworks che doveva essere aggiornato. Ci siamo tenuti il ??più lontano possibile!

Answer 6

Sono piuttosto appassionato di Lean / Kanban e abbiamo ripetuto il nostro processo per un po ', inizialmente attraverso un flusso di lavoro personalizzato in JIRA, ma non è esattamente privo di attriti data la complessità dell'amministratore nella versione aziendale. Ora abbiamo ampliato il nostro uso di una lavagna e abbiamo deciso di ripetere il processo usando la lavagna per un po 'prima di ricodificarlo in JIRA. Ecco un esempio del nostro layout:

• Siamo 6 sviluppatori
• Quando una storia è in sviluppo, è sulla scrivania di uno sviluppatore. Allo stesso modo con la revisione, il QA, ecc. Ciò significa che ogni carta sul tabellone rappresenta e l'oggetto utilizzabile, e fornisce anche un'istantanea abbastanza accurata dei progressi dell'iterazione. La regola è che solo in circostanze eccezionali hai più di una carta sulla tua scrivania.
• Abbiamo accettato di non avere più di due carte "impilate" nella colonna In attesa di revisione. Ciò mantiene un certo grado di "flusso".

Backlog   | Awaiting Dev   | Awaiting Review   | Awaiting Design  | Awaiting Deployment | Awaiting QA | Done |
Story11   |    Story2      |    Story9         |     Story 6      |   Story1            |    Story9   |
Story3    |    Story7      |                   |                  |                     |    Story12  |
Story8    |    Story10     |                   |                  |                     |             |
          |                |                   |                  |                     |             |
          |                |                   |                  |                     |             |

Questo è abbastanza vicino a mappatura del flusso di valori ad eccezione della parte di distribuzione in attesa, che è un trucco per risolvere il problema in cui il QA non può QA un elemento fino a quando non lo abbiamo distribuito sul suo server - lo distribuiamo 3/4 volte durante un'iterazione di 2 settimane.

Una cosa che ho notato mappando il flusso di valori su un " radiatore " è che focalizza magicamente le persone sull'effettivo lavoro a valore aggiunto che deve essere svolto e che sembra accelerare lo sviluppo del valore aziendale e mantenere lo slancio.

Spero che ti aiuti!

Answer 7

Stiamo sperimentando un paio di diverse strutture di bordo attraverso alcuni diversi progetti che stiamo eseguendo. Un progetto ha la struttura più semplice che possiamo usare:

| (Sprint) Backlog | In Progress | Done |

Per quanto possibile, proviamo ad avere un singolo post-it per rappresentare sia le attività di sviluppo che di controllo qualità per una storia.

La struttura sopra sembra funzionare bene per gli sviluppatori del progetto, ma i membri del QA hanno faticato a sapere quando una storia ha completato il lavoro di sviluppo in modo da poter eseguire i test per quella storia. Ci siamo ritrovati a spostare le storie sul "lato lontano". della sezione In Progress per indicare che il lavoro Dev è stato svolto e che il QA potrebbe riprendere quella storia. Questo è diventato molto rapidamente ingestibile quando la sezione In Progress si è riempita.

Ciò ha portato alla seconda iterazione della struttura del board per un altro progetto che è:

| (Sprint) Backlog | In Progress | Ready for Test | Done |

La sezione appena aggiunta Pronto per il test è diventata essenzialmente una sezione formale della scheda che in precedenza era la "parte lontana". della sezione In corso . A prima vista, ciò avrebbe dovuto rendere le cose più chiare per i membri del QA, ma ciò ha comunque creato confusione poiché le persone avevano interpretazioni diverse sul significato di Pronto per il test (non ti annoierò con il interpretazioni diverse qui).

Ciò ha portato all'ultima iterazione della struttura della scheda che stiamo utilizzando su un altro progetto:

| (Sprint) Backlog | Dev in Progress | Dev Done | QA in Progress | Done |

Questo è certamente molto lontano dalle semplici sezioni Backlog , In Progress e Fine della prima iterazione, ma questo sembra lavorare bene per la squadra. Hanno una chiara comprensione di cosa significhi spostare una storia attraverso varie sezioni del tabellone e per ogni storia, fornisce un quadro chiaro di dove si trova quella storia nel ciclo di vita. Usiamo questa struttura solo dall'inizio dello sprint corrente (siamo in 9 giorni in uno sprint di 10 giorni), quindi esploreremo questa struttura in modo più dettagliato domani nella nostra retrospettiva. Non è perfetto, ne sono sicuro, ma se continua a funzionare per il team che lo sta pilotando, proveremo a distribuirlo su altri team della nostra organizzazione.

Answer 8

La nostra lavagna è suddivisa in queste colonne:

Story, Not Started, Req / Des / Dev *, Peer Review, QA, Done

Le storie con la massima priorità vanno dall'alto verso il basso. Ogni storia può avere più compiti, quindi usiamo un post grande per la storia e quelli più piccoli per i compiti. Le attività si spostano da sinistra a destra. Ogni giorno controlliamo per assicurarci di lavorare sulle storie con la massima priorità.

Usiamo una scheda bianca appiccicosa su ogni attività in cui la persona che ci lavora mette le proprie iniziali. Quando hanno finito e spostalo lungo una nuova scheda bianca viene posizionata su quella vecchia per mostrare che è disponibile per chiunque. Quando tutte le attività sono terminate, la storia viene spostata anche nella colonna Fine e in stand-by, tutto il lavoro Fatto viene raccolto e spostato in alto nel tabellone per fare spazio in fondo per altre storie.

Abbiamo anche schede colorate per le storie e le attività per indicare i blocchi da progredire (blu che indica un blocco da un'altra squadra, rosso che richiede assistenza da parte della mischia). Parliamo dei blocchi stradali ad ogni standup.

Possiamo vedere quando ci sono troppe attività in una particolare colonna e spostare l'enfasi per ottenere di più su Fatto. Abbiamo aggiunto deliberatamente la colonna di revisione per sottolineare che il lavoro necessario rivisto da qualcuno diverso dalla persona che lo ha fatto prima di arrivare al QA.

* Requisiti / Progettazione / Sviluppo

Answer 9

Il nostro sembra abbastanza simile. Ogni sviluppatore ha una colonna e abbiamo righe per "Fine", "In fase di test", "Lavori in corso", "Backlog".

E usiamo le note di stile post-it che ci muoviamo fisicamente durante ogni fase.

Personalmente trovo che manchi il sistema ...

• Post-it in movimento manuale diventa un dolore dopo un po '. Il nostro team addetto al controllo qualità gestisce principalmente lo spostamento dei biglietti ed è uno sforzo costante mantenerli sincronizzati con TFS.
• I post-it possono davvero essere spostati così tante volte prima che non siano più appiccicosi. Se un ticket viene rispedito dai test e inserito in "In corso" e poi spostato di nuovo ai test, ecc. Ecc. Non ci vuole molto perché finisca sul pavimento.
• A volte, il semplice volume di note è travolgente. Le note devono essere impilate per essere visibili anche in remoto - le sovrapponiamo in modo tale da poter vedere ogni identificativo univoco delle note (nel miglior modo possibile) ... ma poi hai una pila di 10 note e devi ottenere il 5 ° dalla pila e stai rapidamente contribuendo alla diminuzione della viscosità che si concluderà con le note sul pavimento.
• Quando i biglietti finiscono sul pavimento è abbastanza fastidioso scoprire dove dovrebbero andare. Quel biglietto dello sviluppatore A era? O B? Ed era in fase di test? O è stato fatto? Torniamo in TFS, cerchiamo quei biglietti e spostiamo i post-it di conseguenza.

Personalmente, non penso che le note di post-it siano lo strumento appropriato qui. Ci sono una manciata di strumenti digitali che rendono questo genere di cose completamente senza problemi. Usiamo il Team Foundation Server e ho visto un paio di strumenti davvero straordinari, robusti, gratuiti e persino open source che si interfacciano con il Team Foundation Server e gestiscono tutto ciò per te, in tempo reale.

http: / /www.telerik.com/community/labs/tfs-work-item-manager-and-tfs-project-dashboard.aspx

Answer 10

Le nostre commissioni tendono a evolversi in modo straordinario man mano che progrediamo in gruppo. Tendo a favorire i cartoncini fisici se hai una squadra collocata in quanto incoraggia una migliore comunicazione faccia a faccia in generale dalla mia esperienza. Ovviamente c'è un sovraccarico, ma ne vale la pena per far lavorare insieme il team. Un altro vantaggio che ho visto con le schede fisiche è che aiuta con l'impegno aziendale. Gli stakeholder remoti non possono semplicemente accedere e vedere i progressi all'interno dello sprint corrente e togliere le cose dal contesto poiché a volte le carte non raccontano l'intera storia. Devono avere una conversazione e venire in consiglio, il che può essere utile in quanto le cose possono essere spiegate e ciò significa anche che possono essere incoraggiati ad aiutare a risolvere con impedimenti. Tuttavia, questo non è esclusivo delle schede fisiche ma aiuta.

Come accennato, le nostre schede evolvono nel tempo con le esigenze dei team. Spesso iniziamo con la mischia dei libri di testo, ma incoraggiamo il miglioramento continuo e di solito finiamo con una soluzione scrumban. Queste modifiche si riflettono visualizzando il nuovo flusso di lavoro attraverso le schede. Di recente ho scritto un post sulla nostra ultima modifica se i tuoi interessati danno un'occhiata al nostro scrum clessidra / tavola Kanban

Penso che il team dovrebbe essere coinvolto nella creazione dei board in quanto aiuta il team a comprendere il flusso di lavoro e non a diventare silos. Inoltre, se il team ha contribuito a migliorare il consiglio di amministrazione, controlla meglio i propri processi, il che aiuta l'autorganizzazione in quanto è un prodotto a cui hanno contribuito.

Answer 11

Abbiamo seguito la seguente struttura del consiglio nella nostra azienda.

Backlog | Next sprint |      Current sprint         | Done
                         Buffer    |     Working

Le corsie sono assegnate a membri specifici. Ogni membro ha un lavoro diverso nel nostro ufficio, quindi le attività variano. Aggiungiamo ciò su cui dobbiamo lavorare al nostro Backlog, quindi lo spostiamo in Next Sprint se si avvicina alla scadenza. Le attività verdi bloccate vengono utilizzate per attività continue su cui è necessario lavorare quotidianamente. I cartellini rossi indicano l'importanza dell'attività e devono essere completati il ??prima possibile. Il nostro consiglio di amministrazione ci consente di collaborare liberamente e di aggiungere compiti a vicenda se dovessimo fare qualcosa da parte di un dipartimento diverso.

Utilizziamo KanbanTool (Kanbantool.com) per visualizzare il nostro flusso di lavoro e gestire i progetti. È davvero intuitivo e facile da usare. La comunicazione del nostro team è notevolmente migliorata.