Scrum e Kanban

Os métodos ágeis apresentam muitas vantagens para o desenvolvimento ou gestão de projetos. Mas cada método apresenta o seu modelos de implementação e diferentes etapas. Apesar das diferenças a maioria dos princípios são os mesmos, entregar com maior rapidez, assertividade e satisfação dos usuários.

O Scrum e Kanban são amplamente encontrados em empresas de tecnologia por reconhecer a volatilidade do desenvolvimento de produtos, proporcionando uma metodologia para equipes efetuarem mudanças para atingir o objetivo final de forma mais rápida e precisa.

Kanban possui uma representação mais visual, onde busca apresentar o trabalho em um quadro dividido em colunas que representam os estágios de trabalho. Busca limitar o trabalho em andamento e maximizar o fluxo de entregas, com um foco em reduzir o tempo que o projeto leva para ir do início ao fim. É uma estratégia para gerenciar a criação de produtos com entregas de forma contínua.

Já o Scrum se compromete a desenvolver produtos ou features funcionais em intervalos definidos (sprints), é uma ferramenta time-boxed. O principal objetivo é criar ciclos para coleta de feedback e de aprendizagem para reunir e integrar rapidamente as mudanças necessárias no produto. Enquanto no Kanban não há um rito fixo para o planejamento, no Scrum o planejamento é feito sempre antes de cada sprint. O time utiliza do backlog de estórias para avaliar o que deve ser selecionado para o desenvolvimento de acordo com as prioridades do momento e com a capacidade do time de execução.

O framework Scrum

O Scrum busca avançar de forma rápida, com sprints de duas a, no máximo, quatro semanas com as datas de início e término definidas. Por ter essa característica de período de tempo curto, a equipe é forçada a dividir as histórias mais complexas em tarefas menores e ajuda o time a evoluir e aprender mais rápido.

Dentro de cada sprint encontramos alguns papéis predefinidos, como Scrum Master e Product Owner, e uma série de ritos a serem cumpridos. O Scrum Master é o responsável por transmitir os valores e ensinamentos da metodologia Scrum, busca facilitar o trabalho de toda a equipe, principalmente em relação à compreensão dos conceitos do Scrum. Já o Product Owner é o responsável por guiar o produto a ser desenvolvido para atingir as necessidades do cliente e das demais partes interessadas. É a única pessoa que define o que é necessário para o produto, solicitando alterações e incrementos conforme o andamento do projeto.

Em relação ao ritos, os sprints são pontuados pelas reuniões de planejamento da sprint, reunião de revisão do que foi desenvolvido durante a sprint, reunião de retrospectiva sobre o que pode ser melhorado para as próximas sprints e a daily scrum, que são reuniões diárias rápidas para pontuar o que cada pessoa do time trabalhou no dia anterior e o que será feito durante o dia.

As principais métricas utilizadas são relacionadas a velocidade, sendo a métrica central o número de pontos da história concluídos em um sprint. É essa métrica que apresenta a produtividade da equipe e orienta futuros compromissos de sprint ou a capacidade da equipe Scrum de assumir pontos de história. Para o acompanhamento dos times, pode ser utilizado os gráficos de Burndown ou Burnup que apresentam o trabalho concluído por dia em relação à taxa de conclusão prevista para o projeto. Também pode ser utilizado o Velocity Chart, onde apresenta a relação de pontos de história planejados e entregues em cada sprint.

O framework Kanban

Kanban busca ajudar na visualização do trabalho, limitar o trabalho que está em andamento (WIP) e alterar o que está sendo desenvolvido de "fazendo" para "concluído" com rapidez. É uma metodologia que se encaixa muito bem com equipes que recebem muitas demandas que variam de tamanho e prioridade. Ao contrário do Scrum que exige um controle elevado no que está no escopo, Kanban busca seguir o fluxo.

Cada item de trabalho é representado por cartões que são organizados em um quadro Kanban, onde mudam de um estágio do fluxo de trabalho para o próximo. Cada estágio é representado por uma coluna, sendo que cada cartão deve ser movido ao longo das colunas para indicar a situação atual de desenvolvimento. É usual classificar as tarefas em três categorias: a fazer, em andamento e concluído. Entretanto, costuma ser adaptado conforme a necessidade do projeto.

Em teoria, não se prescreve um tempo para entregar uma tarefa, as entregas são liberadas sempre que estiverem prontas, sem uma programação regular ou datas predeterminadas. As tarefas podem ser lançadas conforme a necessidade sem precisar esperar um determinado marco, como a revisão de sprint no caso do Scrum.

Ao contrário do Scrum que apresenta um "mestre do Scrum" que mantem tudo funcionando, a equipe Kanban possui a responsabilidade das entregas e organizar as tarefas no quadro, não há uma única pessoa responsável pelo projeto.

Entre as principais métricas no Kanban, estão o tempo de espera (Lead Time) - o tempo que leva para uma demanda que entrou no quadro ser entregue - e tempo de ciclo (Cycle Time) - tempo em que uma história do backlog leva para ser implementada. Melhorar os tempos de ciclo das equipes Kanban afeta diretamente no sucesso da equipe.

Uma ferramenta analítica utilizada por equipes Kanban para acompanhar a quantidade de itens de trabalho em cada estado do quadro é o Diagrama de Fluxo Cumulativo (CFD). Muito utilizado para identificação de gargalos no fluxo que precisam ser atendidos para melhorar a taxa de transferência. Também é usual utilizar um limite de trabalho em andamento (Work in Progress, WIP) referente ao número de cartões que podem estar em uma coluna ao mesmo tempo. Quando o limite é atingido, a equipe concentra os esforços no avanço dessas atividades.

Scrum ou Kanban

Tanto o Scrum quanto o Kanban são metodologias ágeis que buscam melhorar a eficiência das equipes, qual dos dois utilizar depende da fase e maturidade que a equipe se encontra. Algumas equipes preferem o Kanban por possuir demandas mais voláteis e não ser necessário o grande número de reuniões, enquanto outras preferem as interações com reuniões e a previsibilidade dos sprints.

Isso não significa que são totalmente excludentes, em alguns casos é possível implementar mais de um modelo ao mesmo tempo. Ao aprender o que funciona para cada equipe e entender como a equipe trabalha em conjunto é possível estabelecer o que deve ser implementado.

Nenhum dos frameworks deve ser imposto por algum líder dentro dos times, quem deve tomar a decisão de qual se encaixa melhor na organização do time é o próprio time. O mais importante é sempre lembrar de incentivar e manter uma cultura de melhoria contínua tanto nos times quanto na empresa.