Uns anos atrás comecei a me interessar mais por desenvolvimento de software. Não tanto na parte de algoritmos ou linguagens especificamente, mas em metodologias e no relacionamento entre os programadores e os administradores de sistemas.

Depois de ler “The Phoenix project” comecei a entender um pouco melhor que aquelas boas práticas que eu tentei implementar em um momento ou outro na minha carreira nada mais eram do que a famosa DevOps.

Avançando um pouco no tempo caiu nas minhas mãos um livro de SCRUM, que é uma metodologia ágil usado por diversas empresas e times de desenvolvedores, incluindo meu empregador atual.

É uma metodologia muito bacana e realmente resolve diversos problemas relacionados ao desenvolvimento de software que vemos em outras metodologias.

Lá na empresa o compromisso de usar metodologias ágeis é forte o suficiente que todo mundo tem que passar por um treinamento de 2 dias. Eles esperam juntar gente o suficiente (umas 15 pessoas por turma) e nos mandam pra um hotel pra aprender “agile”. Fui feliz fazer o curso, querendo aprender mais de SCRUM.

A minha surpresa, porém, foi aprender um pouco sobre Kanban. Eu já tinha ouvido falar e visto uma referência aqui ou ali, mas o instrutor gastou umas 2hrs destilando um pouco melhor a metodologia e vou dizer o seguinte: Se você está do lados “Ops” de DevOps, Kanban provavelmente é mais interessante do que SCRUM. E aqui a principal razão:

É impossível planejar “Sprints” num ambiente de operações. As interrupções são constantes, problemas surgem do nada, somos constantemente puxados de uma atividade para outra com o objetivo de suportar outros departamentos e via-de-regra temos bem pouco controle do nosso tempo.

Só para clarificar, “Sprints”, na metodologia SCRUM são períodos de 2 semanas (geralmente) onde o time se compromete a trabalhar num número determinado de tarefas e no qual, ao final, vão ter um produto utilizável como resultado desse esforço dedicado. Fácil de ver que isso funciona pro pessoal de “Dev”, mas não pra “Ops”

Entra Kanban

Kanban é bem mais adaptável para Ops. Basicamente você divide suas tarefas em 3 colunas:

  • A ser feito (ToDo)
  • Em andamento (Doing)
  • Feito (Done)

Exatamente como na imagem acima, uma simples lousa com sitcky notes é o suficiente para manter controle do trabalho do time. Lógico que versões digitais são bem melhores e podem ser compartilhadas mesmo por quem trabalha remotamente.

Fluxo de trabalho

O fluxo de trabalho é o seguinte: Tenham uma sessão onde todo mundo anota o que precisa ser feito em sticky notes individuais. Depois que todos fizeram isso individualmente removam os duplicados e discutam a prioridade da lista final.

Com a lista final já priorizada em mãos decidam quais problemas vão abordar nos próximos dias. Isso basicamente significa escolher os sticky notes priorizados e colar eles na coluna “ToDo”. Não existe um número mágico, mas aparentemente multiplicar o número de membros dos time por 3 é um bom palpite inicial. Se seu time tem 4 pessoas, coloque no máximo 12 tarefas na coluna “ToDo”.

Todos os sticks que não foram eleitos para os próximos dias é o que chamamos de “backlog”.

Cada pessoa pode então pegar uma tarefa e mover para a coluna “Doing”. Coloque suas iniciais ou outra clara indicação de quem é o “dono” da tarefa.

Se o seu time de operações é semelhante à maioria é bem provável que antes de conseguir terminar suas tarefas alguma coisa vai surgir e te interromper, precisando de atenção imediata. Sem problemas. Pegue um sticky, coloque o nome dessa nova tarefa e coloque na coluna “Doing”.

A ideia de Kanban é limitar a quantidade de trabalho sendo feito ao mesmo tempo, portanto comece limitando o número de tarefas a 2 por pessoa. Mas nesse caso é por pessoa mesmo e não 8 ao todo (2×4).

Mova as tarefas que são terminadas para a coluna “done” conforme necessário.

Mas e se você depende dos outros? É muito comum não conseguir fazer progresso porquê você está dependendo de outras pessoas, times, terceiros, etc. Nesse caso a tarefa continua na coluna “Doing”, mas deve ser marcada como “Bloqueada”. Marque com caneta vermelha ou algo que deixe claro o status atual.

Mantenha em mente que uma tarefa bloqueada ainda está utilizando um dos slots de tarefas em andamento e você não deve iniciar uma tarefa nova.

Uma tarefa bloqueada por mais de 2 ou 3 dias precisa de atenção do time inteiro. Gerentes ou diretores podem ser envolvidos. Ou talvez deve-se reavaliar se essa tarefa não deve voltar para o backlog ou ser quebrada em tarefas menores. Ela não deve ser ignorada.

Conforme o número de tarefas na coluna “ToDo” vai diminuindo o time pode voltar para a lista de itens priorizados e puxar alguma coisa do “backlog” e adicionar na coluna “ToDo”.

Essa abordagem é muito boa também para deixar claro para a gerência porque um determinado projeto não está sendo feito. Talvez você tenha uma coisa sentada ali na sua coluna “ToDo” faz muito tempo, mas o número de tarefas que aparecem do nada “pulando a fila” e indo direto pra coluna “Doing” estão te impedindo de trabalhar naquilo.

Fica fácil mostrar que depois da reunião seu time identificou, digamos, 10 projetos que precisam ser feitos, colocou na coluna “ToDo”. Mas desde então mais de 30 tarefas apareceram do nada e foram resolvidas. Mas não existe oportunidade de trabalhar na coluna “ToDo”.

Aliás, isso é um problema comum que todos nós deveríamos manter em mente e endereçar com a gerência assim que possível.

Em resumo

Isso foi só uma introdução muito simplificada, insuficiente – e talvez até errada – sobre Kanban.

Se a ideia parece interessante eu sugiro pesquisar mais a respeito. Eu mudei a abordagem do meu time de SCRUM para Kanban faz umas 2 semanas e parece que está dando bem certo.

Alguém por ai usando Kanban? Alguma sugestão de bons recursos em pt_BR? Eu ainda não tenho nada muito bom em inglês também. Ainda estou aprendendo, mas gostei tanto que já quis compartilhar logo de cara.