Kanban – Planning Board: A Arte de Bater o Olho

Com a popularidade do Agile Manifesto^[1], a procura pelo conhecimento de tecnologias que auxiliem o desenvolvimento ágil e flexível de projetos e produtos tem aumentado. Treinamentos Scrum^[2], Agile, XP^[3] , Kanban e afins têm sido bastante procurados por profissionais de TI.

Promessas de “resolver todos os problemas  em pouco tempo” não são difíceis de encontrar nos anúncios dos cursos oferecidos no mercado,  que incluem algumas  ferramentas e práticas consideradas “excêntricas” no mundo corporativo.

Entre elas, está o Kanban. Longe de ser uma mera brincadeira de mover post-its em uma parede rabiscada, agrega princípios antigos e básicos para um único fim: mostrar como está a situação do projeto em um olhar, através de abstrações induzidas por simplicidade e sinestesia.

Kanban(看板/カンバン方式) ^[4], em português  “Placa Visível”,  também conhecido como Planning Board, é uma ferramenta de desenvolvimento Just-in-time, criada por Tai-ichi Ono^[5], considerado o pai do Sistema  Toyota de Produção^[6].  O principal objetivo do Kanban é o de passar a visão geral sobre o andamento do projeto/produto de forma rápida, at first glance, ou “ao bater o olho”.  Independente de quem “bata o olho” no kanban,  seja um CEO, um membro da equipe, ou até mesmo o pessoal da  limpeza, a imagem de seu estado dará uma boa noção do status das atividades, e do quanto o produto está distante (ou próximo) de ser concluído. A transparência sobre o que e quanto cada membro da equipe faz fica explícita no quadro, permitindo assim, que o grupo todo seja responsável por saber como estão os projetos, e com ele, contribuir de alguma forma.

Porém, não é apenas de visão geral que uma equipe conseguirá acompanhar os status de suas atividades e o andamento de cada membro da equipe. Naturalmente, cada envolvido deverá saber sobre sua respectiva tarefa, suas dependências, e o que seus colegas estão desenvolvendo.  Dentro da equipe, que tem um conhecimento mais aprofundado sobre o projeto (seja técnico-específico de área, ou conceitual/negócios), haverá uma forma de representar esses itens de forma resumida, mas que induza à visão mais detalhada, contendo representações de complexidade, status de execução, e a situação do projeto como um todo. Como isso é feito?

Há um conceito de artes marciais japonesas chamado Tooyama-no-metsuke(遠山の目付け, O “olhar de enxergar a montanha distante”), que geralmente é traduzido como “Não enxergue a folha, primeiro, procure enxergar a árvore. Não enxergue a árvore, antes disso, visualize a floresta.”. Como dito anteriormente, o primeiro objetivo do quadro  é a visão geral. A floresta (o quadro/tabela  toda), depois a árvore (status das linhas e colunas), e no final, cada item correspondente às linhas e colunas, que podem ser também auxiliadas por um gráfico de andamento (Burndown Chart^[7]).

Existem várias versões de Kanban utilizadas no mercado, explicarei de forma resumida, uma versão bastante simplificada. Como Agile incentiva as Adaptações à Mudanças em seu Manifesto, cada time acabará personalizando seu kanban, adicionando mais colunas, ou outros símbolos.

Símbolos: Retângulos. Cada retângulo móvel (pode ser um post-it, ou qualquer objeto em que seja possível escrever algo em cima) representa uma tarefa, e identifica um membro do time.

O Quadro: Consiste em uma tabela de quatro colunas e N linhas. Cada linha corresponde a um Item do Produto. Exemplo:  Vamos construir um Carro, e teremos as linhas, Motor, Chassis,  Porta, Painel.

Quatro colunas: Backlog Item,  A Fazer, Em Progresso, Feito.

Backlog Item– É a coluna que indicará o item do projeto  em questão, pode ser um User Story^[8] ou algo similar. Exemplos: No projeto Site de Pizzaria, poderemos ter  Tela de Login de Usuários, Interface de Integração de Serviços, e Página de Cardápio.  Para que a informação fique resumida, apenas os seus títulos serão utilizados.

Figura 3 – Exemplo: Site de Pizzaria

A Fazer: Serão as tarefas a serem feitas, planejadas e discutidas dentro de cada Backlog Item. Exemplo: Na tela de login, é preciso fazer o design visual, o layout, implementar as TextBoxes e Botões. Cada um desses itens será simbolizado por um retângulo, que terá escrito o nome da tarefa, complexidade (discutida pelo time), e uma identificação de QUEM executará a tarefa.  A célula “A Fazer “ será a mais preenchida, antes do Kickoff^[13]  de seu respectivo Backlog Item.

Em Progresso: Após o Kickoff, cada membro do time move seu respectivo retângulo para a célula “Em Progresso”.  Ao visualizar essa célula, saberemos quem está fazendo, e o quê está sendo feito.

Feito: Quando alguém concluir a tarefa, o retângulo correspondente é movido para essa célula. Se houver mais tarefas para essa pessoa em “A Fazer”, ela moverá um retângulo para a coluna “Em Progresso”. Se não houver, cabe ao responsável pelo projeto decidir qual atividade ela realizará (auxiliar alguém que atrasou, revisar algo, etc.) .

De imediato, podemos ver que temos  a visão geral do projeto:  No exemplo do Carro(figura 2), sabemos que para a o item Motor, há nove tarefas (nove retângulos no total),  sendo que quatro delas estão para ser executadas,  duas estão sendo feitas, e três foram concluídas. O “cara azul” foi designado para duas tarefas, não está fazendo nada no momento, e terminou uma. O “cara laranja também tem duas” , está executando uma, e há em sua lista uma outra que será feita na sequência(que o time escolheu). O marrom está na mesma situação que o azul. E o verde, teve mais tarefas atribuídas: já terminou uma tarefa, está executando outra, e após essa, terá mais uma para realizar.

Como apenas “batemos o olho”,  não temos idéia sobre O QUE cada um está fazendo. Provavelmente, em uma semana  haverá mudanças no quadro;  se nada mudar, algo nos fará perguntar  a algum membro do time sobre o que está  acontecendo.

Outro detalhe faltante: O status de entrega do projeto todo por período. Para auxiliar essa visão, podemos utilizar o Burndown Chart, que poderá ser explicado em outra oportunidade.

 Um Exemplo de Aplicação

O Kanban não é usado apenas em projetos de TI, pode ser aplicado em outras áreas. Quatro amigos Atrapalhados têm um encontro anual tradicional. Eles se reúnem com suas famílias para uma feijoada, a qual é preparada por eles mesmos. Em todos os anos, eles encontravam suas dificuldades, às vezes repetiam os mesmos erros, mas de certa forma, concluíam a feijoada, que ficava um pouco diferente do que eles haviam idealizado.  Então, para a Feijoada 2011, eles aprenderam a utilizar o Kanban e viram uma boa oportunidade para praticar os conceitos.

Os Atrapalhados: Renato A.,  um exímio piadista;  Antônio Carlos, que se auto-intitula “Mestre do Feijão” e “Rei do Samba”;  Manfred , expert em fatiar; e Mauro Zack, que gosta de preparar temperos. Perfis  distintos, expertises diferentes, mas amigos que se dão muito bem entre si. Compraram os ingredientes no supermercado, se reuniram, e antes de começar, fizeram o planejamento.

Cada um escolheu uma cor de preferência, e utilizaram a seguinte legenda:

Na reunião de planejamento[i], o grupo levantou as seguintes atividades:

Prato Principal

• Fatiar a Couve-manteiga
• Preparar a Couve
• Escolher o Feijão
• Preparar  o Feijão
• Cortar as carnes de porco
• Fazer a Farofa
• Fazer o Arroz
• Fazer  o Molho de Pimenta

Bebidas

•  Fazer as Compras na Venda da Esquina(Cerveja, limão, cachaça, açúcar, gelo)
•  Fazer a Caipirinha

Após um tempo de discussão, risadas e controvérsia, todos chegaram a um consenso sobre a complexidade das atividades, e  elegeram/escolheram quem seria responsável por cada tarefa, com base no expertise de cada um. Em seus post-its coloridos, cada um escreveu sua atividade, com o grau de complexidade de 1 a 10, que eles intitularam “Escala Trapalhônica”, sendo 1 o nível de complexidade mais baixa.  Rabiscaram a parede da cozinha com a estrutura do Planning Board , que começou da seguinte maneira:

Figura 5 – Kanban da “Feijoada dos Atrapalhados”

Terminado o quadro, eles resolvem iniciar o Kickoff do projeto. Cada um escolhe qual atividade iniciar, considerando a complexidade e inter-dependência entre tarefas. Afinal, Antônio Carlos jamais conseguiria preparar a couve se Manfred não a fatiasse. Assim, os amigos pegam seus post-its e reconfiguram o status:

Claramente, todos podem ver que Antônio Carlos é o membro da equipe mais atarefado, e que executa as tarefas mais complexas. E que Renato, o exímio piadista, está com a tarefa mais simples, e apenas com uma. Mas todos se contentam com as escolhas, e começam a executar o trabalho.

Passada uma hora: Como era de se esperar, Mauro e Renato terminaram suas atividades, enquanto que Antônio Carlos e Manfred ainda estão ocupados. Renato e Mauro atualizam suas atividades movendo seus post-its para a coluna “Feito”. Como Renato já está sem atividades, ele se senta com os convidados e começa a contar suas piadas a eles. Manfred, Mauro e Antônio continuam as demais tarefas, naturalmente, notando a falta de seu companheiro.

Após mais uma hora de trabalho, Antônio e Manfred terminam suas atividades e ambos atualizam a tabela.  Mauro está na metade de sua atividade:

Alguns convidados passam a visitar a cozinha, pois estão famintos. E visualizam o quadro, rabiscado na parede com vários post-its coloridos grudados. Um deles, pergunta “O que é isso?”. Brevemente, Renato explica sobre o Kanban, que cada retângulo representa uma atividade, cada cor representa um membro da equipe, e sobre as colunas. De imediato, um dos convidados, faz uma piada: “Bonito, hein Renato? Os três se matando de fazer as coisas, e você folgando aqui! O Antônio é o que mais trabalha nessa cozinha!”. Em meio aos vários risos de todos e demais piadas que surgem no momento, a visão do convidado leigo não está distante do que está acontecendo: De fato, Renato é o que menos contribuiu com as atividades primárias do primeiro item do Backlog,  Antônio é o que mais  executa tarefas, e as suas são as mais complexas. Lembrem que foi o próprio time que decidiu trabalhar assim, baseado nas aptidões de cada um e nas possibilidades  também. O time pode ter suposto intuitivamente que Renato poderia contribuir mais ao ficar na sala distraindo os convidados famintos para evitar que eles entrassem toda hora na cozinha perguntando “Tá pronto?” a cada 5 minutos,  enquanto seus amigos continuavam a executar a tarefa sem serem interrompidos. Ou talvez a “hiper-pró-atividade” dele poderia ser danosa aos outros, que preferem se concentrar nas tarefas. E por ser piadista, ele poderia também ser o “embaixador/diplomata” entre cozinheiros e convidados. De qualquer  forma, não é o nosso enfoque discutir sobre quem faz mais ou menos, mas o de enxergar a situação como terceiro, e como membro do time. Expor a situação dessa forma abre várias possibilidades, análises, intervenções, melhorias, etc.

Passada mais uma hora, Mauro e Manfred terminam suas tarefas, mas ambos se esquecem de atualizar o quadro. Em momentos, Antônio termina sua tarefa, atualiza o status, visualiza o quadro, e não encontra seus colegas.

Então, confuso, vai à sala, onde todos estão reunidos e entretendo seus convidados, e pergunta “Ei! Cadê as carnes de porco? Mauro, você já fez lá o molho de pimenta? Vi o quadro e lá estava que vocês não terminaram!”. Ambos respondem que sim, e  após uma breve indagação sobre ”não estar no quadro”, ambos correm para atualizar e comunicar Antônio, que volta às suas atividades, em meio a xingamentos descontraídos.

Figura 10 – Kanban Atualizado

E após os últimos momentos, finalmente, Antônio termina sua atividade, e a Feijoada está pronta!

Reparem que temos  outras linhas no quadro,  com atividades que podem ser planejadas após a conclusão do primeiro item do Backlog; Ou durante o planejamento das tarefas em uma reunião geral. Tudo depende de como o time trabalha (Scrum, “Scrum Butt”^[12], Agile, XP, etc.) e da forma que os responsáveis pelo projeto acham melhor.

Como principiantes em ferramentas Agile, os Quatro Amigos aprenderam com os erros, conheceram mais sobre as peculiaridades de seus colegas, e provavelmente, a feijoada de 2012 será feita de forma mais eficiente e organizada. Sobre o particionamento do problema, talvez seja menos complicado criar, classificar e eleger as tarefas em uma próxima reunião.

Para concluir, falaremos dos requisitos para que o Kanban contribua com o projeto:

1. Comprometimento.  O time tem que ser comprometido com o projeto, assim como os demais stakeholders. Afinal, todos querem que os projetos dêem certo, e fazem o melhor para isso.
2. Agir de Boa Fé. Atualizar o kanban sem mentir, questionar sobre os status sem querer intimidar.
3. Deixar que o Kanban ilustre as deficiências, eficiências, erros e acertos. Como saberemos quem é realmente bom em o quê, quando perguntar se alguém precisa de ajuda, etc., sem que isso tudo seja revelado? Todo mundo erra em algum momento.
4. Fiscalização Construtiva:  detectar os problemas do time,  impedimentos, ou explicações para melhorar a situação. Por mais que as situações de projeto sejam críticas e urgentes, usar resultados negativos como forma de repressão não encorajará ninguém a trabalhar para corrigir as falhas pessoais e profissionais.
5. Evitar hostilidades. É natural que haja cobranças em um projeto, assim como atrasos, e erros. Mas não é necessário agir de forma agressiva quando alguém erra, pois essa pessoa já está frustrada por não ter conseguido cumprir com o objetivo que ela propôs.
6. O mais importante: TRABALHAR PARA O TIME. Isso vale para todos. Nem sempre será possível distribuir de forma uniforme as tarefas entre os membros do time, mas de alguma forma, todos podem contribuir. No conto da feijoada, o Renato é um piadista e só sabe fazer arroz, e aparentemente, “Não fez nada, porque não tá no quadro”. Mas ele estava com os convidados famintos, entretendo-os e evitando que os mesmos fossem à cozinha “cobrar” os cozinheiros.
7. Os conceitos de “A Fazer”, “Fazendo” e “Feito” têm que estar claros para o time e stakeholders. “…when it’s done” (“Quando estiver pronto.”), como dizia John Carmack^[9] disse quando lhe pergutavam quando a idSoftware^[10] iria lançar um jogo. Ou como dizia Steve Jobs(RIP)^[11], “…real artists ship.” (“Os verdadeiros artistas entregam suas obras de arte”).

Existem diversos modelos de Kanban mundo afora, mais sofisticados que o nosso exemplo. Pesquisem, experimentem, personalizem, mas sem esquecer do conceito de “Passar a situação geral ao bater o olho”,” e dos sete  itens mencionados.

Espero ter ajudado, e até a próxima!

Referências

[1] –Manifesto for Agile Software(Agile Manifesto) – http://agilemanifesto.org/

[2] –  Scrum – http://www.scrumalliance.org

http://www.scrum.org/originsofscrumorg/

[3] – Extreme Programming (XP) – Beck, Kent & Fowler, Martin(2000): Planning Extreme Programming, Addison Wesley. ISBN: 0-201-71091-9

[4] – Kanban – Procurar pela grafia “カンバン方式”　. （Kanban Houshiki）Hiranabe, Kenji (2008): Kanban Applied to Software Development: from Agile to Lean http://www.infoq.com/articles/hiranabe-lean-agile-kanban#ftn.id1

[5] – Tai-ichi Ono (Taiichi Ohno)- http://en.wikipedia.org/wiki/Taiichi_Ohno

[6] – Sistema  Toyota de Produção(Toyota Production System) – Ohno, Taiichi : “Toyota Seisan Houshiki”, 1978 (Em inglês: “Toyota Production System – Beyond Large Scale Production”, 1988. Productivity Press, ISBN 0-915299-14-3).

[7] – Burndown Chart  – http://en.wikipedia.org/wiki/Burn_down_chart

[8] – User Story : Kohn, Mike: “User Stories Applied”, 2004, Adison Wesley: ISBN 0-13-047381-2

[9] – John Carmack – Kushner, David(2003). Masters Of Doom: How Two Guys Created An Empire And Transformed Pop Culture. New York: Random House. ISBN 0-375-50524-5

[10] – idSoftware http://www.idsoftware.com/business/history/

[11] – Steve Jobs http://en.wikipedia.org/wiki/Steve_Jobs

[12] – “Scrum Butt”, do original “Scrum, but…” – “Scrum, but…” é trabalhar com Scrum seguindo parcialmente os seus princípios. “Butt”, de nádegas. “Scrum Butt” é a minha versão “abrasileirada”.

[13] – Kickoff, ou “pontapé inicial”, ação que inicia um ciclo.