Armadilhas do Kanban: a culpa no est na tcnica

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

O Kanban est se popularizando por vrios bons motivos. Contudo, quanto mais pessoas o adotam, mais haver implementaes feitas de maneira errada, cujo fracassos vezes ser atribudo simplesmente ao uso do Kanban. Neste artigo, apresento algumas situaes que vivenciei e que podem contribuir para uma m reputao do Kanban. Esperamos que alguns exemplos citados aqui possam ajudar o leitor a evitar armadilhas parecidas.

D importncia cadeia de valor

A cadeia de valor um conceito importante nas prticas do desenvolvimento Lean. Em resumo, constituda dos vrios estgios pelos quais passa o trabalho, desde a concepo at a entrega. analisada por meio de um exerccio chamado Mapeamento da Cadeia de Valor (MCV, ou VSM na sigla em ingls). Com o MCV busca-se visualizar como o trabalho progride pelo sistema, ajudando a identificar possveis desperdcios e gargalos. Com o uso desse mapeamento, geralmente grandes filas ou acmulos 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 tambm outros tipos de desperdcio, e fundamental identific-los o mais breve possvel. Contedo relacionado de patrocinadores
Agile e Lean no QCon SP 2013: resolvendo problemas reais e adotando as prticas com efetividade

Um exemplo tpico de cadeia de valor para o desenvolvimento de software seria: Pronto para desenvolvimento -> Desenvolvimento -> Reviso de cdigo -> Testes -> Demonstrao para o cliente. Em um projeto de que participei, tivemos a ideia de acrescentar os estgios da anlise de negcio no quadro Kanban, antes da fase de desenvolvimento. O problema foi que no analisamos corretamente a cadeia de valor de Anlise de Negcio. Na montagem do quadro agimos rpido demais, com pouco planejamento. Quando terminamos tnhamos cerca de cinco estgios anteriores ao "Pronto para o Desenvolvimento". Conforme o projeto progredia, no entanto, percebemos que os itens passavam por apenas dois desses cinco estgios previstos. A correo foi simples. Paramos o que estvamos fazendo, juntamos toda a equipe e refizemos o mapa de valor com base no que havamos aprendido nas primeiras semanas de trabalho. Foi um exerccio de uma hora; ao final tnhamos uma viso muito melhor da cadeia de valor, especialmente do lado do analista de negcio. Corrigimos a primeira metade do quadro e conseguimos visualizar melhor nosso processo de desenvolvimento, podendo ainda fazer melhorias nele.

No coloque todo seu processo no quadro grande a tentao 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 cartes de histria; embaixo ficavam os itens de trabalho. Estes ltimos se juntavam aos itens de cima no momento dos testes e de demonstrao para o cliente. Era muito mais do que o necessrio. Trazer um novo integrante para a equipe e explicar para ele o funcionamento daquele quadro exigia uma sesso de treinamento. Tnhamos acabado com a facilidade de uso do Kanban.

Como era complicado entender como um item deveria ser movido dentro do quadro, as pessoas simplesmente no o moviam. Perdamos, assim, o efeito psicolgico positivo obtido ao se andar at o quadro e mover um item para o prximo estgio. Ia-se por terra um dos principais benefcios do quadro, que a visibilidade do projeto e da equipe. O dimensionamento fundamental No projeto citado, tnhamos tambm dimensionado incorretamente nosso trabalho, o que no um problema raro no desenvolvimento gil de software. Havia histrias muito grandes no quadro, por simples falta de coragem de parar o trabalho e dizer: "Esta histria grande demais; precisamos quebr-la." Na linha superior do quadro estavam as funcionalidades para as "funcionalidades mnimas" (MMF; Minimum Marketable Features), mas na verdade estas no atendiam ao critrio "mnimo", pois representavam grandes partes do sistema. Em alguns casos, deveriam ter sido criadasfuncionalidades exploratrias, com o objetivo de responder a questes sobre como proceder para entregar o que o cliente precisava.

Alm disso, estvamos medindo nosso tempo de ciclo a partir dos cartes de MMF; mas como estvamos deixando-os com escopo muito grande, havia algumas funcionalidades desconhecidas e nosso tempo de ciclo variava muito de uma funcionalidade para outra. Deveramos ter nos esforado mais para responder a algumas questes, e ter uma ideia melhor sobre as funcionalidades desconhecidas; ou seja, poderamos ter gerenciado melhor o tamanho de nosso trabalho e, em consequncia, o tempo de ciclo. Trabalhe com um objetivo comum Outra lio 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 grfica, de banco de dados etc. Com isso, ao terminar uma tarefa, no estvamos entregando ainda valor para o cliente. Alm do mais, para passar a aparncia 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 nmero possvel de tarefas estava prejudicando os resultados. No se esconda atrs de filas Outro princpio fundamental do Lean e do Kanban a ideia de limitar o trabalho em cada fila, como uma forma de garantir que no haver trabalho demais no sistema. s vezes isso pode parecer tentador, mas permitir que sua equipe despreze os limites, ou que simplesmente os ignore, leva a mudanas de contexto e outros tipos de desperdcio que diminuem a velocidade em que funcionalidades so entregues aos clientes. Os limites de trabalho em progresso so uma das ferramentas mais poderosas do Kanban, mas importante usar essa tcnica com critrio. Desprezar um limite para "fazer mais" enganar-se a si mesmo. Afinal, uma funcionalidade s est pronta quando est nas mos do usurio. fcil falar em uma palestra ou em um livro que devemos respeitar os limites, mas na prtica, em um projeto sob presso, difcil resistir de passar um carto a mais para uma coluna de "Pronto para testes", por exemplo. No final das contas, somos pagos para escrever cdigo, e estamos falando de um "simples pedao de papel" em um quadro branco. Este exato problema estava acontecendo com uma equipe em que trabalhei. Nosso primeiro passo na busca de uma soluo foi adicionar mais uma coluna ao quadro, dedicada a testes, onde ficavam as funcionalidades que no haviam passado pelos testes. Mas com isso no tnhamos aumentado a capacidade na realizao de testes, nem identificado uma forma de diminuir a fila de testes. O que fizemos foi simplesmente aumentar a quantidade de itens que poderiam ficar aguardando naquela fase. Em vez de melhorar, pioramos o nosso gargalo.

Havamos adicionado a coluna pelas razes erradas (ego, poltica, vontade de ter mais cdigo escrito), mas acabamos permitindo que as funcionalidades esperassem mais tempo no sistema antes que ficassem de fato prontas. Havamos adicionado desperdcio. No final, sentamos e nos perguntamos por que as funcionalidades no estavam sendo demonstradas para o cliente. Constatando a existncia do gargalo, alocamos um profissional para trabalhar nos testes e assim aumentar a vazo nessa fase. Algo a destacar aqui que j sabamos do comeo que teramos um gargalo em testes, devido estrutura e formao da equipe. A soluo definitiva foi a contratao de mais uma pessoa com a funo correta. Aprendemos uma lio valiosa em Kanban: que devemos aumentar a capacidade do sistema, em vez de simplesmente aumentar a capacidade da equipe, sem critrio. Concluses Neste artigo foram analisadas algumas formas em que apliquei o Kanban de forma errada. Todos os projetos citados, no entanto, foram bem sucedidos para nossas equipes e clientes. Inclumos retrospectivas em vrios momentos, para obter uma viso do que estava sendo feito corretamente e o que precisava ser mudado. Se estiver usando Kanban agora e alguma coisa no estiver indo como esperado, pare, analise a situao e faa mudanas. O problema pode estar apenas na forma de usar a tcnica.