O que é o Kanban?

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

It is enormously prominent among today's agile software teams, but the kanban methodology of work dates back more than 50 years. In the late 1940s Toyota began optimizing its engineering processes based on the same model that supermarkets were using to stock their shelves. Supermarkets stock just enough product to meet consumer demand, a practice that optimizes the flow between the supermarket and the consumer. Because inventory levels match consumption patterns, the supermarket gains significant efficiency in inventory management by decreasing the amount of excess stock it must hold at any given time. Meanwhile, the supermarket can still ensure that the given product a consumer needs is always in stock.

Quando a Toyota aplicou esse mesmo sistema no 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", por 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 do qual se precisava, sua quantia exata 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 com esse material em espera, o qual seria 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.

>> Teste este tutorial para criar um projeto Kanban com o Jira 

Kanban para equipes de software

Hoje, as equipes de desenvolvimento ágil de software são capazes de aproveitar esses mesmos princípios do JIT, combinando a quantia do 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.

Embora os princípios centrais da estrutura sejam atemporais e aplicáveis a quase todas as indústrias, as equipes de desenvolvimento de software encontraram um sucesso especial com a prática ágil. 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 no 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 do 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 ágil de software 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 seu fluxo de trabalho seja padronizado e que todos os bloqueadores e dependências sejam imediatamente identificados e resolvidos. Um quadro básico do Kanban tem um fluxo de trabalho de três etapas: "To Do", "In Progress" e "Done" (a fazer, em andamento e feito). No entanto, dependendo do tamanho, da estrutura e dos objetivos da equipe, o fluxo de trabalho pode ser mapeado para atender ao processo exclusivo de qualquer equipe específica.

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

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 do Kanban é permitir que os membros da equipe acompanhem seu andamento por meio do fluxo de trabalho e de uma maneira altamente visual. Os cartões Kanban apresentam informações cruciais sobre determinado item de trabalho, dando visibilidade total à equipe sobre quem é o responsável por ele, uma breve descrição da tarefa sendo feita, qual a estimativa de tempo para essa parte do trabalho e assim por diante. Muitas vezes, os cartões nos quadros virtuais do Kanban também apresentarão capturas de tela e outros detalhes técnicos valiosos para o destinatário. Ao permitir que os membros da equipe visualizem não só a situação de cada item de trabalho a qualquer momento, mas também todos os detalhes associados, garante-se 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 ágeis atualmente. Ele oferece várias vantagens adicionais para o planejamento e a transferência de tarefas para equipes de todos os tamanhos.

Flexibilidade de planejamento

Uma equipe Kanban concentra-se apenas no trabalho ativamente em andamento. Depois que a equipe conclui um item de trabalho, retira-se o próximo item de trabalho do topo da lista de pendências. O proprietário do produto é livre para priorizar o trabalho na lista de pendências sem interromper a equipe, porque qualquer alteração fora dos itens de trabalho atuais não impactam a equipe. Contanto que o proprietário do produto mantenha os itens de trabalho mais importantes no topo da lista de pendências, a equipe de desenvolvimento tem certeza de que está retornando o valor máximo para o negócio. Portanto, não há necessidade de iterações de extensão fixa que você encontra no scrum.

Dica profissional: proprietários de produtos experientes sempre se envolvem com a equipe de desenvolvimento ao levarem em consideração as mudanças na lista de pendências. Por exemplo, se o históricos dos usuário 1 a 6 estão na lista de pendências, a estimativa do histórico 6 pode ser baseada na conclusão dos históricos 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 ciclo reduzidos

O tempo de ciclo é uma métrica-chave 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 seu envio. 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 disseminar 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 pode se mover 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 assegurar que o trabalho esteja avançando perfeitamente pelo processo.

Menos gargalos

Multitarefa mata eficiência. Quanto mais itens de trabalho em movimento, em um determinado momento, mais troca de contexto, o que dificulta o caminho para a conclusão. É por isso que um usuário-chave do Kanban serve para limitar a quantidade de trabalho em andamento (WIP, work in progress). O trabalho em andamento 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: "To Do", "In Progress", "Code Review" e "Done". 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 razão 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 aos problemas no estado de revisão e a rever o trabalho de outros 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 robusto na melhoria continua da eficiência e eficácia da equipe com cada iteração do trabalho. Os gráficos fornecem um mecanismo visual para as equipes garantirem a continuidade da 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 os de diagramas de fluxo cumulativos.

Um gráfico de controle mostra o tempo de ciclo para cada problema, bem como uma média contínua para a equipe.

Dica Pro: O objetivo da equipe é reduzir a quantia de tempo que um problema leva para passar por todo o processo.Visualizar a queda da média do tempo de ciclo no gráfico de controle é um indicador de sucesso. 

Um diagrama de fluxo cumulativo mostra o número de problemas em cada estado. A equipe pode facilmente detectar bloqueios, visualizando o número de aumento de problemas em um determinado estado. Problemas em estados intermediários como "In Progress" (em progresso) ou "In Review" (em revisão) ainda não foram enviados aos  clientes, e um bloqueio nesses estados pode aumentar a probabilidade de conflitos de integração em massa quando o trabalho é incorporado a montante. 

Serviço constante

Sabemos que a integração contínua— a prática automática de criar e testar código incrementalmente ao longo do dia — é essencial para manter a qualidade. Agora é hora de atender à entrega contínua (CD,continuous delivery). A CD é a prática de liberar o trabalho aos clientes com determinada frequência: diariamente ou de hora em hora. O Kanban e a CD se complementam perfeitamente, porque ambas as técnicas se concentram 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 o produto estará no marketplace. E as equipes Kanban focam exatamente isto: otimizar o fluxo de trabalho para clientes.

Scrum vs. Kanban

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

  Scrum Kanban
Ritmo Sprints regulares com extensão fixa (2 semanas) Fluxo contínuo
Metodologia da versão 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, mestre scrum, equipe de desenvolvimento Sem funções existentes. Algumas equipes recorrerem à ajuda de um agile coach.
Principais métricas Velocidade Tempo de ciclo
Filosofia de mudança As equipes devem se esforçar para não fazer alterações na previsão de sprint durante o sprint. Ao fazer isso, o aprendizado em torno da estimativa fica comprometido. Mudanças podem ocorrer a qualquer momento

Algumas equipes misturaram os ideais do Kanban e scrum para o "scrumban." Eles tomam os sprints de extensão fixa e as funções a partir do scrum, e o foco nos limites de trabalho em progresso e tempo de ciclo a partir do Kanban. Porém, para as equipes que acabaram de começar com o agile, é altamente recomendável escolher uma metodologia ou outra e usá-la por um tempo. Você sempre pode iniciar aquela que for ideal mais tarde. 

Produto discutido
Logo do Jira Software
Rastreamento de problema e projeto