Nos últimos meses tem-se falado bastante sobre Kanban, e em como as práticas de administração de produção podem ser aplicadas a desenvolvimento de software. David Anderson em suas palestras no Agile 2008 e no Falando em Agile apresentou algumas dessas ideias, que estão atualmente sendo aplicadas na Locaweb.
Antes, vale uma introdução ao tema.
Kanban (literalmente “cartão visual”) é uma metodologia de produção que utiliza controles visuais (cartões) como sinalizadores de estoque ou status de uma determinada etapa do processo. Os cartões podem ter diversos significados: problemas, atenção, quantidades em falta ou em excesso etc. É o Kanban que permite a aplicação dos conceitos de Just-In-Time (produção somente do necessário, na quantidade necessária e no momento necessário, sem estoques ou desperdícios) da metodologia Lean. Um bom exemplo de Kanban aplicado ao dia-a-dia é o apresentado por David Anderson: em uma visita a um lugar turístico no Japão, Anderson observou que na entrada eram distribuídos cartões em branco, sem nenhuma instrução ou número de controle. Esses cartões eram recolhidos na saída, e re-aproveitados para nova distribuição. A explicação: mais do que controlar a quantidade total de pessoas que entram, os cartões eram usados para controlar a quantidade de pessoas que estavam no lugar naquele exato momento - ou seja, a falta de cartões indica que há muitos turistas visitando o lugar e que deve-se diminuir o fluxo de entrada.
Na área de software, esse conceito está sendo usado para o mesmo propósito - controlar o fluxo de funcionalidades (histórias) em desenvolvimento.
Quadro de Kanban
O primeiro passo é definir a ferramenta a ser usada para a aplicação do Kanban. Com um simples quadro branco e post-its ou cartões já é possível criar um controle de fluxo de histórias buscando 100% de eficiência. O quadro deve conter colunas para identificar os diversos status de uma história (ex: Não Iniciado, Em Andamento, Impedimento, Em Publicação, Concluído). Observação: quanto menos status houver, mais fácil de manter o quadro; adicionem somente os status que não dependem da própria equipe resolver (ex: equipe não tem acesso de publicação em produção).
Antes de começar a falar sobre Kanban, vale fazer um comparativo: é muito comum equipes usarem planilhas ou sistemas para controle dos sprints. Apesar de serem boas ferramentas, muitas vezes não temos feedbacks visuais de como o sprint está andando. Com isso, é possível não percebermos que o sprint está dessa forma:
O primeiro passo é definir uma ordem de prioridade das histórias, deixando claro de alguma forma qual é a história mais importante que deve ser a primeira a ser desenvolvida.
Em seguida, ao primeiro dia do sprint, a equipe puxa a primeira história e a coloca como Em Andamento:
Na figura acima notem que adicionamos um traço que delimita o tamanho do espaço Em Andamento. Essa limitação é na verdade o segredo de todo o processo: como nesse espaço cabem um e somente um post-it, na prática limitamos a uma e somente uma única história em desenvolvimento. O simples fato de criarmos essa limitação física faz com que eliminemos alguns dos principais desperdícios Lean - trabalho não terminado, troca de tarefas etc.
Impedimentos
Uma boa metáfora para um quadro de Kanban é compará-lo com uma máquina qualquer, que transforma matéria-prima (histórias) em produtos (funcionalidades). Quando a máquina tem algum problema, normalmente uma luz vermelha é acesa, indicando qual é o problema e que algo deve ser feito para resolvê-lo.
Da mesma forma, podemos transpor essa ideia para o quadro. Caso haja algum problema que impeça o andamento da história, a equipe pode “acender a luz vermelha” com um post-it vermelho acima da história para indicar a todos que o problema existe e ainda não foi solucionado. Além disso, é importante movimentar a história para a coluna Em Impedimento - a razão disso é liberar espaço para a equipe puxar uma nova história Em Andamento enquanto o impedimento não for resolvido. Importante: esse procedimento só deve ser feito se o impedimento for algo que depende de terceiros e não pode ser resolvido no momento; se a própria equipe puder resolvê-lo, a história deve continuar Em Andamento.
De forma análoga, o status Em Publicação segue a mesma ideia: só deve ser usado se a publicação em produção depender de terceiros; se a própria equipe tiver acesso à produção, a história deve continuar Em Andamento. Uma observação: caso as histórias devam ser armazenadas para a publicação de um release futuro, é importante mostrar isso no quadro, aumentando o limite de acordo com a necessidade; muitos post-its armazenados podem indicar que o release está com muitas funcionalidades e que talvez deva ser publicado antes do previsto.
Feedback Visual
Com o Kanban em funcionamento, é possível começar a ler algumas informações. No exemplo abaixo, as três histórias que estavam no backlog no início foram consumidas pela fila, e os espaços em branco indicam que a equipe parou o sprint por falta de novas histórias.
O exemplo abaixo mostra uma situação crítica no Kanban: a história Em Andamento deveria ser movida para Em Publicação (ou Em Impedimento), mas não há espaço para esse movimento:
A solução para essa situação é publicar a história Em Publicação, ou remover o impedimento o mais rápido possível. Caso nenhum desses dois seja possível realizar no momento, vale reunir a equipe e analisar o sprint - por que o impedimento não pode ser resolvido naquele momento? Por que a história não pode ser publicada naquele momento? O que fazer para que a máquina não pare novamente? Devemos repensar esses limites (ex: duas histórias na fila de publicação)?
Com o impedimento resolvido, é importante guardá-lo em um espaço reservado, para analisar qual a raiz daquele problema e o que deve ser feito para que não ocorra novamente. Na prática, qualquer informação que passar pelo quadro serve como pauta para a Reunião de Retrospectiva de Sprint.
Eis um exemplo de um Kanban com problemas:
Os problemas que podemos identificar:
- Muitas histórias em andamento, gerando desperdícios;
- Muitas histórias em publicação, gerando atraso e acúmulo de trabalho;
- Nenhuma história foi finalizada ainda, apesar de todo o trabalho em andamento;
- Muitas atividades off-sprint, o que indica que a equipe está ocupada com atividades gerais (chamados, correções de bugs em produção etc);
- Muitos impedimentos - O que fazer para evitá-los?
- Histórias canceladas - Por que foram canceladas? Por que eram prioritárias antes? Como fazer para evitar essa situação? Como fazer para identificar histórias que deveriam ter sido canceladas e acabaram sendo implementadas, gerando desperdícios e complexidade?
Por fim, o quadro de Kanban pode ser usado para diversas outras informações que a equipe achar relevante:
Estamos implantando essas ideias em diversas equipes na Locaweb, e o resultado tem sido excelente. Em um próximo post daremos algumas dicas do que andamos observando. Até lá!
