Em http://www.infoq.com/br/articles/doing-kanban-wrong

Armadilhas do Kanban: a culpa não está na técnica

Postado por Tim Wingfield , traduzido por Leonardo Campos em 26 Jun 2012

O Kanban está se popularizando por vários bons motivos. Contudo, quanto mais pessoas o adotam, mais haverá implementações feitas de maneira errada, cujo fracassoàs vezes será atribuído simplesmente ao uso do Kanban. Neste artigo, apresento algumas situações que vivenciei e que podem contribuir para uma má reputação do Kanban. Esperamos que alguns exemplos citados aqui possam ajudar o leitor a evitar armadilhas parecidas.

Dê importância à cadeia de valor

A cadeia de valor é um conceito importante nas práticas do desenvolvimento Lean. Em resumo, é constituída dos vários estágios pelos quais passa o trabalho, desde a concepção até a entrega. É analisada por meio de um exercício chamado Mapeamento da Cadeia de Valor (MCV, ou VSM na sigla em inglês). Com o MCV busca-se visualizar como o trabalho progride pelo sistema, ajudando a identificar possíveis desperdícios e gargalos.

Com o uso desse mapeamento, geralmente grandes filas ou acúmulos ficam evidenciados, trazendo à tona gargalos do sistema utilizado. Ou se pode identificar que partes do sistema encontram-se ociosas, aguardando por trabalho de outras fases. Há também outros tipos de desperdício, e é fundamental identificá-los o mais breve possível.

Um exemplo típico de cadeia de valor para o desenvolvimento de software seria: Pronto para desenvolvimento -> Desenvolvimento -> Revisão de código -> Testes -> Demonstração para o cliente.

Em um projeto de que participei, tivemos a ideia de acrescentar os estágios da análise de negócio no quadro Kanban, antes da fase de desenvolvimento. O problema foi que não analisamos corretamente a cadeia de valor de Análise de Negócio. Na montagem do quadro agimos rápido demais, com pouco planejamento. Quando terminamos tínhamos cerca de cinco estágios anteriores ao "Pronto para o Desenvolvimento". Conforme o projeto progredia, no entanto, percebemos que os itens passavam por apenas dois desses cinco estágios previstos.

A correção foi simples. Paramos o que estávamos fazendo, juntamos toda a equipe e refizemos o mapa de valor com base no que havíamos aprendido nas primeiras semanas de trabalho. Foi um exercício de uma hora; ao final tínhamos uma visão muito melhor da cadeia de valor, especialmente do lado do analista de negócio. Corrigimos a primeira metade do quadro e conseguimos visualizar melhor nosso processo de desenvolvimento, podendo ainda fazer melhorias nele.

Não coloque todo seu processo no quadro

É grande a tentação de afixar na parede um quadro gigante e colocar nele cada pequeno passo do processo. Aconteceu conosco e acabamos com um quadro complicado demais (veja a figura abaixo). Na parte superior, estavam os cartões de história; embaixo ficavam os itens de trabalho. Estes últimos se juntavam aos itens de cima no momento dos testes e de demonstração para o cliente.

Era muito mais do que o necessário. Trazer um novo integrante para a equipe e explicar para ele o funcionamento daquele quadro exigia uma sessão de treinamento. Tínhamos acabado com a facilidade de uso do Kanban.

Como era complicado entender como um item deveria ser movido dentro do quadro, as pessoas simplesmente não o moviam. Perdíamos, assim, o efeito psicológico positivo obtido ao se andar até o quadro e mover um item para o próximo estágio. Ia-se por terra um dos principais benefícios do quadro, que é a visibilidade do projeto e da equipe.

O dimensionamento é fundamental

No projeto citado, tínhamos também dimensionado incorretamente nosso trabalho, o que não é um problema raro no desenvolvimento ágil de software. Havia histórias muito grandes no quadro, por simples falta de coragem de parar o trabalho e dizer: "Esta história é grande demais; precisamos quebrá-la."

Na linha superior do quadro estavam as funcionalidades para as "funcionalidades mínimas" (MMF; Minimum Marketable Features), mas na verdade estas não atendiam ao critério "mínimo", pois representavam grandes partes do sistema. Em alguns casos, deveriam ter sido criadas funcionalidades exploratórias, com o objetivo de responder a questões sobre como proceder para entregar o que o cliente precisava.

Além disso, estávamos medindo nosso tempo de ciclo a partir dos cartões de MMF; mas como estávamos deixando-os com escopo muito grande, havia algumas funcionalidades desconhecidas e nosso tempo de ciclo variava muito de uma funcionalidade para outra.

Deveríamos ter nos esforçado mais para responder a algumas questões, e ter uma ideia melhor sobre as funcionalidades desconhecidas; ou seja, poderíamos ter gerenciado melhor o tamanho de nosso trabalho e, em consequência, o tempo de ciclo.

Trabalhe com um objetivo comum

Outra lição aprendida no projeto foi relacionada à quebra de nossas funcionalidades em tarefas. Como já citado, na parte superior do quadro estavam nossas funcionalidades maiores e na parte de baixo ficavam as tarefas de desenvolvimento.

Mas as tarefas de desenvolvimento estavam particionadas horizontalmente, por exemplo, tarefas de interface gráfica, de banco de dados etc. Com isso, ao terminar uma tarefa, não estávamos entregando ainda valor para o cliente. Além do mais, para passar a aparência de "mais trabalho feito", a equipe às vezes puxava uma nova funcionalidade para a fase de desenvolvimento e atacava suas tarefas, sem antes concluir outra funcionalidade já iniciada e assim entregar valor para o cliente.

A equipe como um todo queria entregar valor, mas o foco de curto prazo em entregar o maior número possível de tarefas estava prejudicando os resultados.

Não se esconda atrás de filas e Conclusões em http://www.infoq.com/br/articles/doing-kanban-wrong