Você está lendo este artigo e esperando que ao final dele eu te conte qual framework ágil é o melhor de todos? Preciso ser sincero e te informar que essa não será a resposta.
Já te explico o motivo:
Escuto muito as pessoas colocarem Scrum e Kanban em uma batalha no mundo ágil em que precisa ter um vencedor, mas isso não é verdade.
Antes de compararmos as duas ferramentas mais populares para desenvolvimento de software hoje, precisamos entender melhor sobre ambas. Para entender o que significa cada uma delas e suas diferenças continue lendo o artigo.
Framework Scrum vs Framework Kanban
Entendendo a duração e os objetivos de cada um deles
O Scrum é uma ferramenta time-boxed, com duração igual das Sprints (ex: 2 semanas), em que as equipes definem quais estórias devem ser desenvolvidas naquele Sprint.
Durante esse período de tempo, a equipe ficará focada em desenvolver aquelas estórias, para que ao final da Sprint, algo de valor seja entregue.
Diferente do Scrum, o Kanban não possui time-box de desenvolvimento e seu trabalho deve ser constante. Um dos principais objetivos do Kanban é a eliminação de desperdício, ajudando equipes a ajustar seu fluxo de valor para que o trabalho seja entregue o mais rápido possível – e com qualidade.
Planejamento Scrum e planejamento Kanban
Em times Scrum, o planejamento acontece sempre antes de cada Sprint. As estórias que estão no backlog são estimadas pelo time utilizando Story Points (ou qualquer outro método de estimativa) e são selecionados de acordo com prioridade e com a capacidade do time de produção.
No Kanban, não há um rito fixo para planejamento. As estórias são adicionadas ao fluxo de valor conforme vão sendo priorizadas e repriorizadas. Esse processo ajuda a evitar os desperdícios, uma vez que as tarefas vão sendo adicionadas de acordo com a necessidade.
Métricas & Gráficos
As principais métricas medidas em times que rodam o Scrum são Velocity (produtividade de cada Sprint) e Projected Capacity (capacidade do time projetada – baseado no seu time atual). Para acompanhamento dos times, utiliza-se os gráficos de Burndown ou Burnup e também a Velocity Chart, como apresentado abaixo.
No Kanban, as métricas são diferentes. Entre as principais métricas, estão o Lead Time – tempo entre a entrada da demanda no board até a sua entrega – e Cycle Time – tempo entre dois status pré-selecionados.
Além das métricas, os gráficos também são diferentes. Os times costumam utilizar o CFD (Cumulative Flow Diagram) para entender gargalos e métricas.
Board & Acompanhamento
No Scrum, os times costumam utilizar apenas 3 status para as tarefas do Sprint: To do, In progress, Done. Eles são o termômetro para saber o trabalho que está sendo feito, o que ainda temos pendente e o que já foi realizado. O board é reiniciado toda vez que uma nova Sprint é iniciada para que o seu controle seja apenas da Sprint atual, tornando seu controle muito mais simples e organizado.
Já no Kanban, o board deve refletir a vida de uma demanda, desde a sua criação até o término. O board nunca é resetado (como no Scrum) e ele vai sendo alimentado com novas estórias. Para uma melhor utilização do Kanban, o board deve ser sempre lido da direita para a esquerda (o que está mais próximo de ser finalizado, deve ter prioridade).
São exemplos de status no Kanban: To do, Prototyping, Developing, Testing, Done, por exemplo. Esse fluxo é chamado de Value Stream Map.
Por conter cada estado do seu fluxo, é muito mais fácil enxergar gargalos no Kanban. Se você tem muitas tarefas na coluna de Prototyping, você pode fazer um deep-dive para entender por qual motivo as tarefas estão demorando muito tempo para saírem dessa coluna.
Leia também Java vs Kotlin: Vantagens, Desvantagens e Performance
Concluindo…
A verdade é que, não existe um framework melhor que o outro em todas as situações. Suas utilizações são situacionais e dependem muito do contexto. Importante é que nenhum desses frameworks seja imposto por algum líder dentro dos times. Quem deve tomar a decisão do que é melhor para a organização do time é o próprio time. Qualquer framework que seja “instalado” pode gerar desconforto e burocratizar o processo de desenvolvimento.
Para cada situação é preciso entender sua necessidade
Em times onde as demandas são melhores organizadas e planejadas, acredito que o Scrum saia na frente do Kanban. Digo isso pois o Kanban é um framework que precisa de muita maturidade do próprio time para sua utilização.
No Scrum, o trabalho torna-se mais organizado com as sprints e a gestão da equipe é mais fácil. Contudo, em times que as demandas são mais voláteis, o Kanban larga na frente, pois a entrega é contínua e a repriorização também.
Vale lembrar que a adesão do time é o principal fator na escolha de um framework. Se a equipe não está feliz com a metodologia de trabalho adotada, tenho certeza de que a produtividade jamais será otimizada, qualquer que seja o framework.
A equipe precisa entender os benefícios da metodologia adotada, para que façam o melhor uso e possam evoluir seu dia a dia.
Por fim, evoluir e criticar o processo é o principal fator de sucesso das equipes. Não importa o framework que você esteja utilizando, procure sempre pontos que podem ser melhorados no seu processo, de acordo com feedback da sua equipe.
Eles são a chave do sucesso – não o framework que você utiliza.
E você, qual sua experiência com esses dois frameworks? Conta pra gente nos comentários!
É um profissional da área?
Veja aqui nossas vagas abertas de desenvolvimento.
