Close

kanban

Como a metodologia Kanban é aplicada ao desenvolvimento de software

Browse topics

O que é o Kanban?

O Kanban é uma estrutura popular usada para implementar o desenvolvimento do software Agile. Ele requer comunicação de capacidade em tempo real e transparência total de trabalho. Os itens de trabalho são representados visualmente em um quadro Kanban, permitindo que os membros da equipe vejam o estado de cada parte do trabalho a qualquer momento.

Artigos do kanban

[CONTINUAÇÃO]

O Kanban é extremamente proeminente entre as equipes de software Agile de hoje, mas sua metodologia de trabalho remonta há mais de 50 anos. No fim dos anos 1940, a Toyota começou a otimizar seus processos de engenharia com base no mesmo modelo que os supermercados usavam para abastecer suas prateleiras. Os supermercados abastecem apenas a quantidade de produtos suficiente para atender à demanda dos consumidores, uma prática que otimiza o fluxo entre o supermercado e o consumidor. Como os níveis de estoque correspondem a padrões de consumo, o supermercado ganha uma eficiência significativa na gestão de estoques, reduzindo a quantidade excessiva de produtos a ser mantida sempre. Enquanto isso, o supermercado ainda consegue garantir que determinado produto do qual um consumidor precisa esteja sempre em estoque.

Quando a Toyota aplicou esse mesmo sistema em seu chão de fábrica, o objetivo era alinhar melhor seus níveis enormes de estoque com o consumo real de materiais. Para comunicar níveis de capacidade em tempo real no chão de fábrica (e aos fornecedores), os trabalhadores passavam um cartão, ou "kanban", entre as equipes. Quando um contêiner de materiais usados na linha de produção era esvaziado, um kanban era passado para o depósito, descrevendo o material que era necessário, a quantidade exata dessa material e assim por diante. O depósito contava com um novo contêiner desse material em espera, o qual era enviado para o chão de fábrica, que, por sua vez , enviava seu próprio kanban para o fornecedor. O fornecedor também tinha um contêiner desse material particular em espera, que deveria ser enviado para o depósito. Embora a tecnologia de sinalização desse processo tenha evoluído desde a década de 1940, esse mesmo processo de fabricação "just in time" (ou JIT) continua no centro do processo.

Kanban para equipes de software

Hoje, as equipes de desenvolvimento de software Agile são capazes de aproveitar esses mesmos princípios do JIT combinando a quantidade de trabalho em andamento (WIP) com a capacidade da equipe. Isso proporciona às equipes opções de planejamento mais flexíveis, saída mais rápida, foco mais claro e transparência ao longo do ciclo de desenvolvimento.

Quadro Kanban | Coach Agile da Atlassian

Embora os princípios centrais da estrutura sejam atemporais e aplicáveis a quase todos os setores, as equipes de desenvolvimento de software encontraram um sucesso especial com a prática do Agile. Isso ocorre, em parte, porque as equipes de software podem começar a praticar com pouca ou nenhuma sobrecarga, uma vez que entendem os princípios básicos. Ao contrário da implementação do Kanban em um chão de fábrica, que envolveria mudanças nos processos físicos e a adição de materiais substanciais, as únicas coisas físicas que as equipes de software precisam são um quadro e cartões, que podem até mesmo ser virtuais.

Quadros do Kanban

O trabalho de todas as equipes Kanban gira em torno de um quadro Kanban, uma ferramenta usada para visualizar o trabalho e otimizar o fluxo do trabalho entre a equipe. Embora os quadros físicos sejam populares entre algumas equipes, os quadros virtuais são um recurso crucial em qualquer ferramenta de desenvolvimento de software Agile para sua rastreabilidade, colaboração mais fácil e acessibilidade de vários locais.

Independentemente de o quadro de uma equipe ser físico ou digital, sua função é assegurar que o trabalho da equipe seja visualizado, que o fluxo de trabalho seja padronizado e que todos os bloqueadores e dependências sejam imediatamente identificados e resolvidos. Um quadro Kanban básico tem um fluxo de trabalho de três etapas: A fazer, Em andamento e Feito. No entanto, dependendo do tamanho, da estrutura e dos objetivos de uma equipe, o fluxo de trabalho pode ser mapeado para atender ao processo exclusivo de qualquer equipe específica.

A metodologia Kanban se baseia na transparência total do trabalho e na comunicação da capacidade em tempo real, portanto, o quadro Kanban deve ser visto como a única fonte de verdade para o trabalho da equipe.

Quadro Kanban Agile | Coach Agile da Atlassian

Cartões Kanban

Em japonês, kanban é traduzido literalmente como "sinal visual". Para as equipes Kanban, cada item de trabalho é representado como um cartão separado no quadro.

A principal finalidade de representar o trabalho como um cartão no quadro kanban é permitir que os membros da equipe acompanhem o andamento do trabalho por meio do fluxo de trabalho de maneira altamente visual. Os cartões Kanban apresentam informações cruciais sobre esse item de trabalho específico, dando visibilidade total à equipe inteira sobre quem é responsável por ele, uma breve descrição da tarefa que está sendo realizada, qual é a estimativa de tempo para essa parte do trabalho e assim por diante. Os cartões nos quadros Kanban virtuais também apresentarão, com frequência, capturas de tela e outros detalhes técnicos valiosos para o responsável. Permitir que os membros da equipe vejam o estado de cada item de trabalho a qualquer momento, e também todos os detalhes associados, garante maior foco, total rastreabilidade e identificação rápida de bloqueadores e dependências.

Os benefícios do Kanban

O Kanban é uma das metodologias de desenvolvimento de software mais populares adotadas por equipes Agile atualmente. Ele oferece várias vantagens adicionais para o planejamento e o rendimento de tarefas para equipes de todos os tamanhos.

Flexibilidade de planejamento

Uma equipe Kanban concentra-se apenas no trabalho que está ativamente em andamento. Depois que a equipe conclui um item de trabalho, ela retira o próximo item de trabalho do topo do  backlog. O proprietário do produto é livre para priorizar novamente o trabalho no backlog sem interromper a equipe, porque uma alteração fora dos itens de trabalho atuais não afeta a equipe. Contanto que o proprietário do produto mantenha os itens de trabalho mais importantes no topo do backlog, a equipe de desenvolvimento tem certeza de que está entregando o valor máximo para o negócio. Portanto, não há necessidade de iterações de comprimento fixo que você encontra no Scrum.

Dica profissional:

Proprietários experientes de produtos sempre envolvem a equipe de desenvolvimento ao considerar as mudanças no backlog. Por exemplo, se as histórias dos usuários 1 a 6 estiverem no backlog, a  estimativa da história do usuário 6 poderá ser baseada na conclusão das histórias dos usuários 1 a 5. É sempre uma boa prática confirmar as mudanças com a equipe de engenharia para garantir que não haja surpresas. 

Tempos de ciclos reduzidos

O tempo de ciclo é uma métrica essencial para as equipes Kanban. O tempo de ciclo é a quantidade de tempo que uma unidade de trabalho leva para passar pelo fluxo de trabalho da equipe–desde o momento que o trabalho é iniciado até o momento que ele é lançado. Ao otimizar o tempo de ciclo, a equipe pode prever com confiança a entrega do trabalho futuro.

A sobreposição de conjuntos de habilidades leva a tempos de ciclo menores. Quando apenas uma pessoa detém um conjunto de habilidades, ela se torna um gargalo no fluxo de trabalho. Dessa forma, as equipes empregam as melhores práticas básicas, como revisão de código e ajuda em mentoria para difundir o conhecimento. Habilidades compartilhadas significam que os membros da equipe podem assumir um trabalho heterogêneo, o que otimiza ainda mais o tempo de ciclo. Isso também significa que, se houver um backup do trabalho, toda a equipe poderá se movimentar para que o processo flua perfeitamente outra vez. Por exemplo, o teste não é feito apenas por engenheiros de controle de qualidade. Os desenvolvedores também o fazem.

Em uma estrutura Kanban, é responsabilidade de toda a equipe garantir que o trabalho esteja avançando perfeitamente pelo processo.

Menos gargalos

Ser multitarefas mata a eficiência. Quanto mais itens de trabalho em curso em um determinado momento, mais troca de contexto, o que dificulta o caminho para a conclusão. É por isso que um dos princípios básicos do Kanban é limitar a quantidade de tarefas em andamento (WIP). Esse recurso limita gargalos e backups em destaques no processo da equipe devido à falta de foco, pessoas ou conjunto de habilidades.

Por exemplo, uma equipe de software típica pode ter quatro estados de fluxo de trabalho : A fazer, Em andamento, Revisão de código e Concluído. Eles poderiam optar por definir um limite WIP de 2 para o estado de revisão de código. Isso pode parecer um limite baixo, mas há um bom motivo para isso: muitas vezes, os desenvolvedores preferem escrever um novo código, em vez de gastar o tempo revendo o trabalho de outra pessoa. Um limite baixo encoraja a equipe a prestar atenção especial a problemas no estado de revisão e a rever o trabalho de outras pessoas antes de levantar suas próprias revisões de código. Isso, em última instância, reduz o tempo total de ciclo.

Métricas visuais

Um dos valores centrais é um foco forte na melhoria contínua da eficiência e eficácia da equipe com cada iteração de trabalho. Os gráficos fornecem um mecanismo visual para as equipes garantirem a continuidade de sua melhoria. Quando a equipe pode ver os dados, é mais fácil detectar os gargalos no processo (e removê-los). Dois relatórios comuns usados pelas equipes Kanban são os de gráficos de controle e de diagramas de fluxo cumulativos.

Um gráfico de controle mostra o tempo de ciclo para cada item e também uma média contínua para a equipe.

Dica profissional:

O objetivo da equipe é reduzir o período de tempo que um item leva para passar por todo o processo. Ver a queda do tempo médio do ciclo no gráfico de controle é um indicador de sucesso. 

Gráfico de controle Agile | Coach Agile da Atlassian

Um diagrama de fluxo cumulativo mostra o número de itens em cada estado. A equipe pode detectar bloqueios com facilidade vendo o número de aumento de itens em qualquer estado determinado. Os itens em estados intermediários, como "Em andamento" ou "Em revisão", ainda não foram enviados para clientes e um bloqueio nesses estados pode aumentar a probabilidade de conflitos de integração em massa quando o trabalho for incorporado a montante. 

Diagrama de fluxo cumulativo

Serviço constante

Sabemos que a integração contínua–a prática de criar e testar automaticamente o código de modo incremental ao longo do dia–é essencial para a manutenção da qualidade. Agora, é hora de atender à entrega contínua (CD). A CD é a prática de liberar o trabalho aos clientes com frequência–seja diariamente ou de hora em hora. O Kanban e a CD se complementam perfeitamente porque ambas as técnicas focam na entrega just-in-time (e one-at-a-time) de valor.

Quanto mais rápido uma equipe puder oferecer inovação para o mercado, mais competitivo seu produto será no marketplace. E as equipes Kanban focam exatamente nisso: otimizar o fluxo de trabalho para os clientes

Scrum vs. Kanban

O Kanban e o Scrum compartilham alguns dos mesmos conceitos, mas têm abordagens muito diferentes. Eles não devem ser confundidos um com o outro. 

 

SCRUM

KANBAN
Cadência

Regular sprints de comprimento fixo (ou seja, 2 semanas)

 Fluxo contínuo
Metodologia de lançamento No final de cada sprint se aprovado pelo proprietário do produto Entrega contínua ou a critério da equipe
Funções Proprietário do produto, scrum master, equipe de desenvolvimento Nenhuma função existente. Algumas equipes conseguem a ajuda de um técnico do Agile.
Métricas importantes Velocidade Tempo de ciclo
Mudança de filosofia As equipes devem se esforçar para não fazer mudanças na previsão do sprint durante o sprint. Fazer isso compromete as aprendizagens em torno da estimativa. A mudança pode acontecer a qualquer momento

 

Algumas equipes misturam os ideais do Kanban e do Scrum no "scrumban". Eles pegam os sprints de comprimento fixo e as funções do Scrum e o foco nos limites de trabalho em andamento e o tempo de ciclo do Kanban. Porém, para as equipes que acabaram de começar a usar o Agile, é altamente recomendável escolher uma metodologia ou outra e usá-la por um tempo. Você sempre pode adotar aquela que for ideal mais tarde. 

Dan Radigan
Dan Radigan

Agile has had a huge impact on me both professionally and personally as I've learned the best experiences are agile, both in code and in life. You'll often find me at the intersection of technology, photography, and motorcycling. 

Up Next
Boards