Hoje em dia é comum empresas de desenvolvimento de software utilizarem um quadro kanban, para gerenciar as atividades do seu time. Porém, na maioria das vezes, as equipes acreditam que basta distribuir os cartões nas colunas do board seja na parede ou virtual e seguir pelo fluxo, e acabam se esquecendo dos princípios do método Kanban.
Neste artigo vou citar alguns dos princípios deste método simples e prático, que pode contribuir e muito com o gerenciamento do seu projeto.
Origem
Inicialmente vou falar um pouco sobre a origem do Kanban. O método foi inspirado no sistema de produção da Toyota – “Just in Time” e seu pioneiro foi David J. Anderson, que utilizou o método Kanban dentro da Corbis (empresa fundada por Bill Gates), onde fez algumas evoluções no processo. Os resultados positivos iniciais do uso do quadro kanban, como a melhora na visualização do trabalho em andamento, e entregas com mais cadência foram apresentados por David J. Anderson no “Agile 2007”.
Conceitos
Como citei no início do artigo, não basta criar um board com algumas colunas para utilizar o Kanban no desenvolvimento de software da maneira ideal. Confira abaixo algumas das principais recomendações desse método:
Definir bem o que representa cada coluna
É importante que cada coluna do board tenha uma definição clara do que representa dentro do seu workflow. E isso precisa ficar explícito para toda a equipe. A coluna “Ready to Dev” por exemplo, é nomeada desta forma pois significa que os cards que estão colocados ali são de atividades que estão realmente “prontas para serem desenvolvidas”, de acordo com aquilo que o time definiu. E o mesmo deve ser considerado para todo o restante do quadro kanban.
Olhar mais o board da direita para a esquerda
É comum que equipes de desenvolvimento sempre olhem para a coluna de “To do”, “Ready to Dev” ou qualquer outro nome que leve a coluna de itens “a fazer” e preocupem-se apenas em puxar novos itens desta coluna para o fluxo do board.
No entanto, uma das principais recomendações do Kanban é olhar o quadro mais da direita (final do fluxo) para a esquerda (início do fluxo). Ou seja, focar em terminar mais ao invés de começar coisas novas. Isso ajuda a manter o fluxo do board e gerar uma entrega de valor maior para o cliente. Além de dar para a equipe a visão de que estão finalizando as atividades.
Limitar o trabalhar em progresso (WIP – WORK IN PROGRESS)
Outra recomendação importante ao se utilizar o método Kanban no desenvolvimento de software, é limitar seus itens de trabalho em progresso. Essa limitação pode ser aplicada nas colunas do board, como por exemplo: a coluna “Ready to QA” tem um WIP de 3 itens, ou seja, a capacidade máxima dessa coluna é de 3 cards, então a equipe deve sempre ficar atenta a ela e não deixar que atinja seu limite. Isso normalmente é feito quando uma etapa do fluxo, neste caso a de tarefas a serem testadas, está gerando gargalo, aumentando o WIP do quadro e consequentemente o tempo das entregas.
E como o time pode agir neste caso? Realizando sempre os testes dos itens que estão prontos para serem testados, antes de começar a desenvolver algo novo, por exemplo. Isso vai de encontro com o princípio citado anteriormente, de olhar mais o board da direita para a esquerda. Vale ressaltar que para David J. Anderson, pioneiro do método, todas as etapas do Kanban devem possuir o WIP limitado de forma explícita.
Afinal, limitar a quantidade de itens de trabalho, ajuda a equipe a ter um foco maior na entrega. Pode minimizar ou evitar GAPs existentes no fluxo, contribuir com uma maior cadência nas entregas e gerar mais qualidade.
Uma última observação neste item, é que mesmo sendo um princípio do Kanban, defendido pelo próprio David Anderson, devemos ficar atentos ao limitar o WIP em times com maturidade baixa. O indicado é começar limitando as etapas que estão gerando gargalo e aumentar esse limite quando as entregas estiverem sendo feitas com qualidade. Devemos sempre considerar que o Kanban também preza por aplicar conceitos que contribuam para a melhora do processo.
Fluxo puxado
Ao contrário de outras metodologias ágeis como o Scrum por exemplo, que utiliza o fluxo empurrado. O Kanban é baseado no “sistema de produção puxado” ou fluxo puxado, isso significa que cada etapa do processo “puxa” uma demanda da etapa anterior. O próprio board “pede” mais demanda, conforme a equipe realiza as entregas.
Visualização dos itens de trabalho / Trabalho em andamento
Uma das principais vantagens ao utilizar um quadro kanban no desenvolvimento de software é que tanto o gerente do projeto, quanto a própria equipe consegue visualizar todos os itens de trabalho. Seja aquilo que está pendente, em andamento, ou tudo que já foi entregue. Isso contribui positivamente de várias formas com o time e com o gerenciamento do projeto.
Visualizar todos os itens que já foram entregues, dá a equipe e ao cliente a visão de que o projeto está evoluindo. Observar tudo que está em andamento, dá uma ideia da capacidade produtiva de um time de alta performance. E a relação dos itens pendentes pode ser considerada para medir o esforço necessário para finalizar o projeto.
Contudo, essas visões só tornam-se possíveis se o item abaixo for realizado pelo time.
Atualização em tempo real
É vital que o time mantenha o kanban atualizado. Sempre que uma atividade mudar de etapa no fluxo, ela também deve ser alterada no board.
Em boards online é possível fazer algumas automatizações que auxiliam neste processo de atualização. Já no quadro que fica na parede, é necessário que alguém vá até lá e mova o card. Mas de qualquer forma, o importante é que o responsável sempre atualize o status das atividades.
Toda vez que alguém olhar para o kanban, ele precisa refletir o status atual de todas as atividades do projeto.
Conclusão
Esses são alguns dos princípios do método Kanban, que é uma ferramenta incrível. Utilizá-la pode contribuir muito com o gerenciamento de projetos, não só de software, mas de qualquer outra área.
Entender os princípios do Kanban é o primeiro passo para começar a utilizá-lo. Por isso, é sempre importante lembrar que o Kanban é um processo evolucionário!
Então devemos começar com um quadro básico, praticando os princípios recomendados. E depois evoluir isso aos poucos de acordo com as necessidades do projeto e maturidade do time.
Tem alguma dúvida? Deixe seu comentário abaixo.
Quer aplicar o Kanban com o seu time? Então leia nosso artigo sobre STATIK, clicando aqui!
E se precisar de ajuda para escalar o seu produto através de um time de alta performance de maneira rápida, pode contar conosco. Basta entrar em contato por aqui.
