Kanban / scrum Placas [fechado]

https://stackoverflow.com/questions/1807100

05-07-2019
|

Pergunta

Estou curioso para saber o que as outras pessoas usam para placas físicas Kanban / Scrum em suas empresas. Compreendo que por causa de informações comerciais sensíveis você pode não ser capaz de fornecer uma foto da placa. I "m olhando para descobrir o o que faz a sua aparência de tabuleiro como e como você organiza as histórias de usuário e tarefas como eles se movem através de um sprint típica / iteração?

Normalmente eu trabalhei em um lugares que organizar a bordo como segue com cada

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 |

Assim, para resumir:

Uma tarefa para a UC-001 está em andamento por um membro da equipe (Bob). Uma lista de tarefas para outras pessoas para pegar estão esperando na coluna Todo, mas isso pode ser pego por um outro membro da equipe que coordenar com Bob para começar o trabalho feito.
Para UC-002 tarefa de serviço que o pagamento foi concluído e um equipamento de teste automatizado foi concluída para QA permitindo-lhes para testar o serviço sem uma UI. Se o teste falhar um erro é levantado e mudou-se juntamente com a tarefa de volta serviço de pagamento para a fase de QA
Todas as tarefas para UC-003 foi concluída e se mudou para Pronto para controle de qualidade.
Todas as tarefas para UC-004 e UC-005 foram completo para a história do usuário foi transferido para Pronto.

Isso funciona como um quadro branco tangível que envolve pessoas interagindo com cada uma das tarefas / user stories (representado como post-it). Uma versão eletrônica é criada antes da Sprint / iteração e só é actualizado no final do sprint / iteração correspondente à situação atual. Comentários e críticas são bem-vindas:)

Solução

Nós usamos algo inspirado no famoso Scrum e XP direto das Trincheiras de Henrik Kniberg, as colunas a ser adaptados, dependendo do contexto (frequentemente: TODO, em curso, a ser testado, DONE):

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

itens do Product Backlog (PBIS) são impressos como "cartões físicos" (formato A5) para a Reunião de Planejamento da Sprint (pelo menos o mais importante). Assim que a equipe tenha pego PBIS para a próxima iteração, itens são quebrar em tarefas / actividades (em notas adesivas). Após a reunião, tudo dá no Conselho Scrum e eu sugiro a fita de uso ou tachinhas ou ímãs. PBIS são ordenados por importância, mais importante, na parte superior do tabuleiro, menos importante na parte inferior. A equipe deve trabalhar sobre o item mais importante em primeiro lugar até que ele é feito. Primeiro, post-its atividade movimento da esquerda para a direita. Em seguida, o PBI salta para Pronto. tarefas inesperadas são adicionados a um "itens não planejados" zona (para levá-los em conta no gráfico de burndown). PBIS futuras ficar visível em uma zona "Next" (se todos os itens estão concluídas durante a iteração, nós escolhemos um novo de lá). simples bonito.

Estas práticas permitem detectar cheiros visualmente, por exemplo:

tarefas stucked (ou seja, tarefas que não estão em movimento) que mostram um potencial impedimento
equipe de fazer as coisas na ordem errada e não se concentrar em itens de alta prioridade, como no seu exemplo:)
muito trabalho em andamento, nada feito
itens não planejados que estão matando um sprint

Funciona muito bem.

Se você está procurando por mais "orientada kanban" coisas, talvez dar uma olhada em Kanban vs Scrum , Um dia, em Kanban Terra e Kanban e Scrum - um guia prático do mesmo Henrik Kniberg. Grandes coisas também.

E, para mais fotos, dar Google Images uma tentativa com scrum + bordo , kanban , scrumban , scrum + kanban .

Outras dicas

Aqui está nosso Conselho Kanban que usamos em TargetProcess . Nós não funcionam no nível de Tarefas, apenas em histórias de usuários e Bugs nível. Às vezes nós criar tarefas, mas eles não são rastreados explicitamente no tabuleiro.

Não estimar User Stories e erros, mas tentar Stories dividir em partes menores (com sucesso misto). Colunas são auto-explicativos. Nós acumulamos itens coluna Testado, então, criar um ramo, teste de fumaça-lo e liberar nova compilação. Normalmente, nós liberamos nova compilação cada duas semanas.

Além disso, os desenvolvedores mostra de tabuleiro e de carga testadores e classes de serviços via código de cores.

UPD. Agora, temos várias equipes pequenas e usar uma única placa para acompanhar o progresso de todas as equipas em http: //www.targetprocess. com / 3

storyboard programação Scrum / Extreme.

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

O trabalho aparece na segunda-de esquerda Colum, e progride através da placa através de diferentes estágios de completude.

Coluna nomes: Não Iniciada, apenas começou, Half-Way, quase pronto, pronto para Showcase (passado QA)

A primeira linha é especialmente reservado para correção de bugs -. Como um fixo, a prioridade para bugs de compensação

Os personagens dos Simpsons representam cada membro da equipe. Eles são movimentados para que possamos ver quem está trabalhando em quê.

Eu sugiro que você dê uma olhada na placa Eylean. http://www.eylean.com/?utm_source=geffort&utm_medium=content&utm_campaign=geffort ele pode caber todas as suas necessidades por causa da interface intuitiva, estatísticas, painel de instrumentos. Também se adapta a qualquer processo e a coisa mais importante é muito fácil de usar. Esta placa permite representar vários projetos em uma placa usando linhas. Todas as linhas podem ser visíveis em um momento ou você pode remover os selecionados a partir da solução scope.Another pode ser tarefa de agrupamento e filtrar por categorias -., Em seguida, todas as tarefas podem ser representados em uma placa e linha, mas ligado a diferentes categorias

Na prática, a organização do conselho work-in-progress é melhor deixar para a equipe para determinar dependendo de suas circunstâncias e ambiente. (Agile == autogestão.)

Dito isto, aqui está o que fiz na minha equipe anterior, parte de um esforço mais de 300 desenvolvedor que era relativamente novo para o Agile e Scum:

Tivemos dois placas - uma com cartões de índice para as próximas histórias para que pudéssemos dizer o que estava chegando, e um com o trabalho do sprint atual. Nossas colunas na atual placa de Sprint eram simplesmente

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

e uma caixa no canto para Blocked.

Um post-it representada cada história.

Os desenvolvedores cada um tinha um pequeno imã que eles usaram no standup todas as manhãs para significar que estava trabalhando em quê. Nossa equipe foi muito grande (~ 12 em um ponto) para que esta figura realmente ajudou que foi emparelhado com quem.

Nós não nos incomodou com uma versão eletrônica (nenhum ponto), embora o nosso Product Owner tinha um sistema Scrumworks que precisava manter-se atualizado. Mantivemos o mais longe que, como nós poderíamos!

Eu estou muito afiado sobre o Lean / Kanban e nós temos a iteração de nosso processo por um tempo, inicialmente através de um fluxo de trabalho personalizado no JIRA, mas isso não é exatamente o atrito dada a complexidade de administração na versão da empresa. Nós já expandiu o uso de um quadro branco e decidiram iterate nosso processo usando o quadro por um tempo antes de voltar a codificação-lo no JIRA. Aqui está um exemplo de nosso layout:

Estamos a 6 desenvolvedores

Quando uma história é no dev, é na mesa de um dev. Da mesma forma com que está sendo revisado, sendo QA'd, etc. Isso significa que cada carta na mesa representa e item de acionável, e também fornece um instantâneo decentemente preciso do progresso iteração. A regra é que só em circunstâncias excepcionais que você tem mais de um cartão em sua mesa.

Nós já concordaram em não ter mais do que dois cartões "pilha-up" no Aguardando coluna Review. Isso mantém um grau de "fluxo".

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

Isso é muito perto mapeamento do fluxo de valor exceto a parte de implantação aguardando, que é um hack para corrigir o problema onde QA não pode QA um item até que tenhamos implantado em seu servidor -. nós implantar 3/4 vezes durante uma semana 2 iteração

Uma coisa que tenho notado desde o mapeamento do fluxo de valor em um " radiador informações " é que ele magicamente concentrar as pessoas no trabalho valor agregado real que precisa ser feito, e que parece o ritmo de desenvolvimento de negócios de valor e manter a dinâmica.

Espero que ajude!

Estamos experimentando um par de diferentes estruturas de administração através de alguns projetos diferentes que estamos correndo. Um projecto tem a estrutura mais básica que pode usar:

| (Sprint) Backlog | In Progress | Done |

Tanto quanto possível, tentamos ter um único post-it para representar ambas as atividades dev e QA para uma história.

A estrutura acima tem parecia ok trabalho para os desenvolvedores do projeto, mas os membros do QA têm lutado para saber quando uma história teve o trabalho de desenvolvimento completo de tal forma que eles pudessem executar os seus testes para essa história. Nós encontramo-nos mover as histórias para o "outro lado" do In Progress secção para indicar que o trabalho Dev foi feito e que QA poderia pegar essa história. Esta rapidamente se tornou bastante incontrolável como o In Progress seção preenchido.

Isto levou à segunda iteração da estrutura de administração para um outro projeto que é:

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

A seção recém-adicionada pronto para o teste , essencialmente, tornou-se uma seção formal da placa que anteriormente era o "outro lado" do In Progress seção. Na superfície do mesmo, isto deveria ter feito as coisas mais claras para os membros de QA, mas isso ainda causou alguma confusão como as pessoas tinham diferentes interpretações do que pronto para o teste significava (eu vou não aborrecê-lo com o diferentes interpretações aqui).

Este tem, em seguida, levou a mais recente iteração da estrutura de administração que estamos usando em outro projeto:

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

Esta é certamente uma maneira muito longe da simples Backlog , In Progress e Concluído secções da primeira iteração, mas isto parece estar funcionando bem para a equipe. Eles têm uma compreensão clara do que significa para mover uma história através de várias seções do conselho e para qualquer uma história, ele dá uma imagem clara de onde no ciclo de vida que determinada história é. Nós só tenho usado essa estrutura desde o início do sprint atual (nós somos 9 dias em um sprint 10 dia), por isso vamos estar explorando essa estrutura com mais detalhes no nosso amanhã retrospectiva. Não perfeito, eu tenho certeza, mas se continuar a trabalhar para a equipe que está pilotando-lo, vamos tentar estendê-lo através de outras equipes na nossa organização.

O quadro é dividido em estas colunas:

história, não Iniciado, Req / Des / Dev *, Peer Review, QA, Feito

As maiores histórias prioritárias ir de cima para baixo. Cada história pode ter várias tarefas por isso usamos um grande post-it para a história e os menores para as tarefas. Tarefas mover da esquerda para a direita. Todos os dias nós certifique-se de que estamos trabalhando os mais altos histórias prioritárias.

Nós usamos uma aba branca pegajosa em cada tarefa em que a pessoa trabalhar nele coloca suas iniciais. Quando estiver pronto e movê-lo ao longo de uma nova guia branco é colocado sobre o antigo para mostrar que é disponível para qualquer um pegar. Quando todas as tarefas são feitas, a história é movido para a coluna Feito também e, ao standup, todo o trabalho feito é computados até e subiu a bordo para dar espaço na parte inferior para mais histórias.

Temos também abas coloridas para as histórias e tarefas para indicar bloqueios ao progresso (azul, indicando um bloqueio de outra equipe, vermelho solicitando assistência Scrum Master). Falamos sobre os obstáculos em cada standup.

Podemos ver quando há muitas tarefas em uma coluna e mudança de ênfase particular para obter mais para Pronto. Nós deliberadamente adicionado a coluna revisão para enfatizar que o trabalho necessário revisado por alguém que não seja a pessoa a fazê-lo antes de chegar a QA.

* Requisitos / Desenvolvimento / Design

O nosso parece bastante similar. Cada desenvolvedor tem uma coluna e temos linhas para 'Concluído', 'nos testes', 'Work in Progress', 'Backlog'.

E usamos post-it notas reais de estilo que se movem fisicamente, uma vez que passa por cada fase.

Pessoalmente, acho que o sistema a ser falta ...

manualmente movimento post-its chega a ser uma dor depois de um tempo. Nossa equipe de QA principalmente gere o bilhete em movimento -. e é um esforço constante para mantê-los sincronizados com o TFS

O post-its realmente só pode ser movido tantas vezes antes eles não são pegajosos mais. Se um bilhete é enviado-back de testar e colocados em 'Em andamento' e, em seguida, voltou para testar, etc, etc ... não é preciso muito para que ele acabe no chão.

Às vezes, o grande volume de notas é esmagadora. Notas têm de ser empilhadas para ser ainda remotamente visível - que mergulhá-los de tal forma que podemos ver cada notas identificador único (o melhor que nós podemos) ... mas então você tem uma pilha de notas de 10 e você precisa para obter o 5ª fora da pilha e você está rapidamente contribuindo para a diminuição da viscosidade que vai acabar com as notas no chão.

Quando os bilhetes acabam no chão é razoavelmente chato para descobrir onde eles devem ir. Era que desenvolvedor bilhete de A? Ou B? E foi em Testing? Ou isso foi feito? Vamos voltar em TFS, procurar os bilhetes e, em seguida, mover o post-its em conformidade.

Pessoalmente, eu não acho que post-its são a ferramenta apropriada aqui. Há um punhado de ferramentas digitais que fazem esse tipo de coisa completamente livre de problemas. Nós usamos servidor fundação Team - e eu vi um par de realmente grandes, robustos, livres, e até mesmo abrir ferramentas de código que irá interagir com servidor Team Foundation e gerenciar tudo isso para você, em tempo real
.
http: / /www.telerik.com/community/labs/tfs-work-item-manager-and-tfs-project-dashboard.aspx

Nossas placas tendem a evoluir de horas extras à medida que progredimos como uma equipe. I tendem a favorecer placas de cartões físicos se você tiver um colocado a equipa, uma vez que incentiva uma melhor cara a comunicação face geralmente a partir de minha experiência. Obviamente, há mais sobrecarga, mas vale a pena para obter a equipe trabalhando em conjunto. Outra vantagem que tenho visto com placas físicas é que ele ajuda com o envolvimento das empresas. partes interessadas remotos não pode simplesmente entrar e ver o progresso dentro do sprint atual e levar as coisas fora de contexto como às vezes cartões não contar a história completa. Eles têm que ter uma conversa e chegar à placa que pode ser benéfico como as coisas podem ser explicadas e isso também significa que eles podem ser encorajados para ajudar a resolver com impedimentos. No entanto, este não é exclusivo de placas físicas mas ajuda.

Como mencionado nossos quadros evoluir horas extras com as necessidades das equipes. Muitas vezes começamos com livro scrum, mas incentivar a melhoria contínua e geralmente acabam com uma solução scrumban. Estas alterações são refletidas, visualizando o novo fluxo de trabalho através das placas. Recentemente, escrevi um post sobre a nossa última mudança se o seu interesse ter um olhar para o nosso ampulheta scrum / tábua de Kanban

Eu acho que a equipe deve envolver-se em fazer as placas, pois ajuda a equipe a entender o fluxo de trabalho e não se tornar silo de. Além disso, se a equipe ter tido uma mão em fazer a bordo eles policiar melhor os seus próprios processos que contribui com a auto-organização, pois é um produto que eles tiveram entrada para.

Nós fomos com seguinte estrutura de administração em nossa empresa.

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

Lanes são atribuídos a membros específicos. Cada membro tem emprego diferente em nosso escritório para as tarefas variar. Nós adicionamos o que temos para trabalhar no nosso Backlog, em seguida, movê-lo para a próxima Sprint se aproxima o fim do prazo. tarefas verdes bloqueados são usados ??para tarefas contínuas que têm de ser trabalhado diariamente. Cartões vermelhos indicam importância da tarefa e tem que ser concluído o mais rápido possível. Nosso conselho nos permite colaborar livremente e adicionar tarefas a cada outros raias se precisamos de algo a ser feito pelo departamento diferente.

Nós usamos KanbanTool (Kanbantool.com) para visualizar o nosso fluxo de trabalho e gerenciar projetos. É muito intuitivo e fácil de usar. Nossa comunicação da equipe melhorou tremendamente.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow