Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Kanban é um termo japonês que significa cartaz ou outdoor. Um engenheiro industrial chamado Taiichi Ohno desenvolveu Kanban na Toyota Motor Corporation para melhorar a eficiência da fabricação.
Embora a Kanban tenha sido criada para fabricação, o desenvolvimento de software compartilha muitas das mesmas metas, como o aumento do fluxo e da taxa de transferência. As equipes de desenvolvimento de software podem melhorar sua eficiência e fornecer valor aos usuários mais rapidamente usando princípios e métodos orientadores kanban.
Princípios kanban
A adoção de Kanban requer a adesão a algumas práticas fundamentais que podem variar dos métodos anteriores das equipes.
Visualizar trabalho
Entender o status da equipe de desenvolvimento e o progresso do trabalho pode ser desafiador. O progresso do trabalho e o estado atual são mais fáceis de entender quando apresentados visualmente, em vez de como uma lista de itens de trabalho ou um documento.
A visualização do trabalho é um princípio fundamental que Kanban aborda principalmente por meio de placas Kanban. Essas placas usam cartões organizados pelo progresso para comunicar o status geral. Visualizar o trabalho como cartões em diferentes estados em um quadro ajuda a ver facilmente o panorama geral de onde um projeto se encontra atualmente, bem como identificar gargalos potenciais que poderiam afetar a produtividade.
Usar um modelo de pull
Historicamente, os stakeholders solicitaram funcionalidades sobrecarregando as equipes de desenvolvimento, muitas vezes com prazos apertados. A qualidade sofreria se as equipes tivessem que usar atalhos para entregar a funcionalidade no prazo.
Kanban concentra-se na manutenção de um nível acordado de qualidade que deve ser atendido antes de considerar o trabalho feito. Para dar suporte a esse modelo, os stakeholders não sobrecarregam as equipes com trabalho quando elas já estão no limite. Em vez disso, os stakeholders adicionam solicitações a uma lista de pendências que uma equipe incorpora ao seu fluxo de trabalho à medida que a capacidade fica disponível.
Impor um limite de WIP
As equipes que tentam trabalhar em muitas coisas ao mesmo tempo podem sofrer com a redução da produtividade devido à troca de contexto frequente e dispendiosa. A equipe está ocupada, mas o trabalho não é concluído, resultando em prazos de entrega inaceitavelmente altos. Limitar o número de itens de lista de pendências em que uma equipe pode trabalhar por vez ajuda a aumentar o foco, reduzindo a alternância de contexto. Os itens nos quais a equipe está trabalhando atualmente são chamados de WIP (trabalho em andamento).
As equipes decidem um limite WIP (trabalho em progresso), ou um número máximo de itens em que podem trabalhar ao mesmo tempo. Uma equipe bem disciplinada garante não exceder o limite da WIP. Se as equipes excederem seus limites de WIP, investigarão o motivo e trabalharão para resolver a causa raiz.
Medir o aprimoramento contínuo
Para praticar a melhoria contínua, as equipes de desenvolvimento precisam de uma maneira de medir a efetividade e a produtividade. Os quadros kanban fornecem uma visão dinâmica dos estados de trabalho em um fluxo de trabalho, para que as equipes possam experimentar processos e avaliar com mais facilidade o impacto nos fluxos de trabalho. As equipes que adotam o Kanban para melhoria contínua usam medidas como tempo de entrega e tempo de ciclo.
Quadros Kanban
O quadro Kanban é uma das ferramentas que as equipes usam para implementar práticas kanban. Uma placa Kanban pode ser uma placa física ou um aplicativo de software que mostra cartões organizados em colunas. Os nomes de coluna típicos são To-do, Doing e Done, mas as equipes podem personalizar os nomes para corresponder aos estados de fluxo de trabalho. Por exemplo, uma equipe pode preferir usar New, Development, Testing, UAT e Done.
Placas Kanban baseadas em desenvolvimento de software exibem cartões que correspondem aos itens de lista de pendências do produto. Os cartões incluem links para outros itens, como tarefas e casos de teste. As equipes podem personalizar os cartões para incluir informações relevantes para seus processos.
Em um quadro Kanban, o limite de WIP aplica-se a todas as colunas em progresso. Os limites de WIP não se aplicam às primeiras e últimas colunas, pois essas colunas representam um trabalho que não foi iniciado ou concluído. As placas kanban ajudam as equipes a permanecer dentro dos limites da WIP chamando a atenção para colunas que excedem os limites. Em seguida, as equipes podem determinar um curso de ação para remover o gargalo.
Diagramas de fluxo cumulativo
Uma adição comum a placas Kanban baseadas em desenvolvimento de software é um gráfico chamado CFD (diagrama de fluxo cumulativo). O CFD ilustra o número de itens em cada estado ao longo do tempo, normalmente ao longo de várias semanas. O eixo horizontal mostra a linha do tempo, enquanto o eixo vertical mostra o número de itens de lista de pendências do produto. Áreas coloridas indicam os estados ou colunas em que os cartões estão atualmente.
O CFD é particularmente útil para identificar tendências ao longo do tempo, incluindo gargalos e outras interrupções na velocidade de progresso. Um bom CFD mostra uma tendência de alta consistente enquanto uma equipe está trabalhando em um projeto. As áreas coloridas em todo o gráfico devem ser aproximadamente paralelas se a equipe estiver trabalhando dentro de seus limites de WIP.
Uma protuberância em uma ou mais das áreas coloridas geralmente indica um gargalo ou impedimento no fluxo da equipe. No CFD a seguir, o trabalho concluído em verde é plano, enquanto o estado de teste em azul está crescendo, provavelmente devido a um gargalo.
Kanban e Scrum no desenvolvimento agile
Embora amplamente encaixados no contexto do desenvolvimento Agile, Scrum e Kanban são bastante diferentes.
- O Scrum se concentra em sprints de comprimento fixo, enquanto Kanban é um modelo de fluxo contínuo.
- O Scrum tem funções definidas, enquanto Kanban não define nenhuma função de equipe.
- O Scrum usa a velocidade como uma métrica chave, enquanto Kanban usa o tempo de ciclo.
As equipes geralmente adotam aspectos do Scrum e do Kanban para ajudá-los a trabalhar com mais eficiência. Independentemente de quais características escolherem, as equipes sempre podem revisar e se adaptar até encontrarem o melhor ajuste. As equipes devem começar simples e não perder de vista a importância de entregar valor regularmente aos usuários.
Kanban com GitHub
O GitHub oferece uma experiência kanban por meio de placas de projeto (clássico). Esses quadros ajudam você a organizar e priorizar o trabalho para desenvolvimento de recursos específicos, roteiros abrangentes ou listas de verificação de versão. Você pode automatizar as placas de projeto (clássicas) para sincronizar o status do cartão com problemas associados e solicitações de pull.
Kanban com Quadros do Azure
O Azure Boards fornece uma solução Kanban abrangente para o planejamento do DevOps. O Azure Boards tem integração profunda no Azure DevOps e também pode fazer parte da integração do Azure Boards-GitHub.
- Para obter mais informações, consulte Os motivos para usar o Azure Boards para planejar e acompanhar seu trabalho.
- O módulo Learn Escolher uma abordagem Agile para o desenvolvimento de software fornece experiência prática do Kanban no Azure Boards.