Kanban chegou aos times de desenvolvimento de software depois de décadas rodando nas linhas de produção da Toyota, mas a versão usada por programadores hoje é mais simples do que a origem industrial sugere. Não exige certificação, não tem papel fixo pra ninguém no time e cabe em qualquer fluxo de trabalho que já exista, do suporte técnico ao time de produto. O que segue é o essencial pra entender o método sem precisar ler um livro inteiro sobre ele.
Na forma como chegou à engenharia de software, Kanban é um método pra visualizar e limitar o trabalho em andamento, não uma metodologia completa de gestão de projeto. O nome vem do japonês e significa algo como "cartão visual", referência aos cartões que a Toyota usava pra sinalizar reposição de peças na linha de montagem. David Anderson adaptou a ideia pra times de TI em 2007, num projeto dentro da Microsoft, e formalizou o método no livro Kanban: Successful Evolutionary Change for Your Technology Business, publicado em 2010.
Na prática, um quadro Kanban tem três elementos obrigatórios: colunas que representam etapas do fluxo de trabalho, cartões que representam unidades de trabalho (uma tarefa, um bug, uma história de usuário) e um limite de quantos cartões podem estar em cada coluna ao mesmo tempo. Esse limite, chamado de WIP (work in progress, trabalho em andamento), é o único elemento realmente essencial do método. Sem ele, o quadro vira só uma lista de tarefas bonita, sem nenhum efeito real sobre como o time entrega.
Colunas variam de time pra time. Um time de backend pode usar "A fazer", "Em desenvolvimento", "Em revisão" e "Pronto". Um time de suporte pode ter "Triagem", "Investigando", "Aguardando cliente" e "Resolvido". O nome e a quantidade de colunas não têm regra fixa, e adaptar demais o quadro logo no início costuma ser perda de tempo.
O limite de WIP é diferente: ele existe justamente pra forçar uma decisão difícil. Se a coluna "Em desenvolvimento" tem limite de três cartões e já está cheia, ninguém pode puxar uma tarefa nova pra ela, mesmo que essa pessoa esteja livre no momento. A alternativa é ajudar a terminar algo que já está em andamento, o que reduz o número de tarefas abertas ao mesmo tempo e, na prática, faz o trabalho fluir mais rápido do início ao fim. É o oposto do instinto de "começar mais uma coisa enquanto espero resposta de outra", hábito que costuma gerar acúmulo de tarefas inacabadas.
Um limite bom costuma ser desconfortavelmente baixo no começo. Se ninguém no time nunca esbarrou nele, o limite provavelmente está alto demais pra cumprir a função de gerar essa pressão.
Um cartão de Kanban útil carrega menos informação do que a maioria dos times coloca nele. O essencial é um título que descreve o resultado esperado, não a tarefa técnica isolada, quem está com a tarefa no momento e, se possível, há quanto tempo o cartão está parado naquela coluna. Ferramentas como Trello, Jira e Azure Boards mostram esse tempo automaticamente; num quadro físico, basta anotar a data em que o cartão entrou na coluna.
Cartões grandes demais são o problema mais comum. Uma tarefa que carrega "refatorar o módulo de pagamentos" não dá pra estimar nem pra revisar direito. Quebrar isso em cartões menores, cada um entregável em no máximo um ou dois dias, é o que faz o limite de WIP funcionar de verdade.
Duas métricas resumem se o Kanban está funcionando: lead time e throughput.
Lead time é o tempo entre o momento em que um cartão entra no quadro e o momento em que ele é entregue. Throughput é quantos cartões o time entrega por semana ou por mês. Nenhuma das duas depende de estimativa em horas ou story points, diferença prática importante em relação a métodos baseados em sprint: dá pra medir as duas olhando só pra data de entrada e saída de cada cartão, sem precisar que ninguém estime nada antes de começar.
Um gráfico de fluxo cumulativo (cumulative flow diagram) mostra a quantidade de cartões em cada coluna ao longo do tempo e é a ferramenta mais direta pra enxergar gargalo: se uma coluna está engordando enquanto as outras ficam estáveis, o problema está ali.
É comum confundir os dois porque ambos usam quadro e cartões, mas a lógica é diferente. Scrum organiza o trabalho em sprints de duração fixa, normalmente de uma a quatro semanas, com papéis definidos (Scrum Master, Product Owner) e cerimônias obrigatórias (planning, daily, review, retrospectiva). Kanban não tem sprint, não tem papel obrigatório e não exige nenhuma cerimônia específica: o fluxo é contínuo, e cartões entram e saem do quadro a qualquer momento, sem esperar o início de um ciclo novo.
Na prática, muitos times de desenvolvimento usam uma combinação dos dois, mantendo as cerimônias do Scrum mas adotando o limite de WIP e as métricas de fluxo do Kanban. Essa combinação costuma ser chamada de Scrumban, embora o nome não apareça em nenhum dos dois métodos originais.
Nenhum comentário ainda. Seja o primeiro.
Ao trabalhar com migrations no Laravel, uma tarefa comum é definir valores padrão para colunas em tabelas de banco de dados. Uma situação específica é definir o ano atual como valor padrão para uma coluna. Este tutorial…
Avançados, Banco de dados, Iniciantes, Intermediários, Laravel, php, Postgres
Vamos lá! Em um dia qualquer estava eu a rolar o feed do Linked-In e um determinado post me chamou a atenção e achei válida a idéia de compartilhar fontes de cursos gratuitos e até mesmo pagos para ajudar a quem quer…
Artigo, FrontEnd, JavaScript, React