Uma coisa que aprendi ao longo do tempo é que, em especial em seu primeiro Scrum, você não deve inventar muito nem complicar as coisas. Nós, nerds, temos a característica de querer buscar ferramentas de TI para coisas que funcionam muito melhor com ferramentas mais tradicionais, como lápis coloridos, notas adesivas e uma parede ou um quadro branco.
O 看板, ou KanBan, é literalmente um quadro de avisos ou tarefas e a forma como o utilizamos hoje, em métodos ágeis, vem de um estudo iniciado em 1940 pela Toyota. Na prática, você divide um quadro em três colunas: a fazer; em execução; feito. Nessas colunas, você cola suas notas adesivas com as histórias, e nas próprias notas adesivas, as anotações relativas às histórias. Essas notas vão avançando pelas colunas do quadro na medida da progressão das histórias.
Há muitas variações possíveis para as divisões do KanBan. Em Sprints mais longos, por exemplo, você pode subdividir a coluna “em execução” nos percentuais 25%, 50% e 75%, indicando a progressão das histórias. Eu prefiro, simplesmente, escrever nas notas adesivas destaques importantes da progressão de cada história e fazer com que os Sprints tenham a duração máxima de uma ou duas semanas.
Outra coisa que gosto de fazer é manter uma cópia do Product Backlog completo à esquerda do quadro KanBan e, à direita da coluna Feito (Done) incluir a coluna Aceito, para a qual o Product Owner moverá as histórias quando as considerar prontas na reunião Sprint Review. A Figura 6.3 mostra um KanBan montado com a ferramenta online Trello.com para o primeiro Sprint de desenvolvimento de um aplicativo fictício chamado Pega-Totó!
Figura 6.3 – Exemplo de um quadro KanBan criado com a ferramenta Trello.com
| Ode ao KanBanJustiça seja feita: o KanBan é muito mais do que um quadro usado para o acompanhamento da progressão das histórias no Scrum. Muitos preferem chamar esse quadro de Scrum Board o que, para mim, é um tanto desrespeitoso à influência do KanBan no Scrum e na aplicação de métodos ágeis em geral. E, diga-se de passagem, o KanBan em si constitui-se em um método ágil que pode ser usado de maneira independente de outros. Para entender melhor o KanBan, uma ótima referência é o livro livre Essential Kanban Condensed, de David J. Anderson e Andy Carmichael, com menos de 100 páginas e publicado, em 2016, pela Lean Kanban University Press. Uso muito o KanBan como resposta a afirmações do tipo “só conseguimos trabalhar ad-hoc, sob demanda, é impossível planejar o trabalho de um Sprint, mesmo que ele só dure uma semana”. Nesse caso, o KanBan propõe algo muito simples: comece com o que é possível fazer agora e assuma que buscará evoluir, passo a passo. O quadro que dá a transparência à progressão do trabalho é fundamental e deve servir para gerenciar o trabalho como um todo, permitindo que as pessoas se auto-organizem para a sua realização. Por isso é importante manter a quantidade de tarefas que são demandadas no quadro dentro de um limite visível e gerenciável (WIP – Work in Progress), sempre com foco na satisfação de quem irá usar o produto. Compreender os princípios e práticas do KanBan (que possuem muita intersecção com o Scrum) ajuda na percepção de que, com transparência, inspeção e adaptação, nem tudo é tão sob demanda quanto parece ser. |
