Metodologia Ágil: Scrum X Kanban

19/07/18

Qualquer pessoa que se interessa por desenvolvimento de software já deve ter ouvido falar na Metodologia Ágil. De uma maneira geral, trata-se de uma forma de simplificar os processos envolvidos durante um projeto de desenvolvimento, ter maior flexibilidade para atender as demandas que surgem no meio do caminho e melhorar a integração e o desempenho da equipe.

A Metodologia Ágil com certeza mudou bastante coisa no mundo da computação, utilizando técnicas de gestão diferentes das tradicionais para garantir mais dinamismo ao desenvolvimento de softwares. Dois dos métodos mais populares a seguir o Ágil são o Scrum e Kanban. Embora os dois também possam ser utilizados em conjunto, há muito debate sobre qual deles é melhor para um projeto. Para chegar na resposta, vamos analisar todos os detalhes de cada um.


Metodologia Ágil: o Manifesto Ágil

Para entender como funcionam o Scrum e o Kanban, precisamos voltar até o ano de 2001, quando um grupo de 17 programadores publicou um documento intitulado Manifesto Ágil. Depois de observar as principais dificuldades enfrentadas pela comunidade dos desenvolvedores, eles juntaram suas visões sobre o tema e dividiram em 4 valores e 12 princípios.

Valores:

Os indivíduos e sua interação são prioridade sobre procedimentos e ferramentas.
Ter o software em funcionamento é prioridade sobre a documentação completa.
A colaboração com o cliente é mais importante que negociações e contratos.
A capacidade de responder a mudanças é mais importante que um plano pré-estabelecido.

Princípios:

Garantir a satisfação do cliente por meio da entrega contínua de softwares funcionais.
Mudanças são bem-vindas, mesmo que tardiamente, visando vantagem competitiva para o cliente.
Entregar software funcionando frequentemente, de poucas semanas a poucos meses, com preferência à menor escala de tempo.
Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto.
Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessários e confie neles para fazer o trabalho.
O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.
Software funcionando é a medida primária de progresso.
Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante.
Contínua atenção à excelência técnica e bom design aumenta a agilidade.
Simplicidade é essencial.
As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

Mais do que um mero conjunto de diretrizes, a Metodologia Ágil apresentou uma nova forma de pensar o desenvolvimento de software. Um dos principais benefícios é a sua capacidade de se adaptar a mudanças. Hoje, inclusive, existe uma série de frameworks ágeis que também podem ser adotados em outras áreas da empresa.

Scrum

O Scrum é um dos frameworks ágeis mais utilizados no mundo. Isso porque além de ser fácil de compreender, ele pode ser utilizado em qualquer tipo de projeto. O objetivo é entregar produtos de alto valor agregado em prazos menores. Seu nome foi tirado do jogo de rúgbi, de uma jogada em que o trabalho em equipe é essencial. Por isso, os papéis são bem divididos no Scrum:

• Scrum master: o líder da equipe, responsável por manter o projeto em andamento e realizar as mudanças necessárias para a sua conclusão.

• Product owner: é quem traduz as demandas em recursos e funcionalidades para o software. É o cliente dentro da equipe.

A organização da metodologia Scrum é bastante simples e se divide, basicamente, em três atividades principais:

Planejamento do Sprint: o Sprint é um ciclo em que as tarefas são desenvolvidas e pode durar de 2 a 4 semanas. Aqui ficam definidas quais as tarefas são realizadas e em quanto tempo.

Daily Scrum: pequena reunião diária para acompanhar o andamento do projeto e levantar possíveis problemas. É importante ressaltar que não se trata de um check-in diário dos gerentes, mas uma forma para a equipe se ajudar.

Retrospectiva do Sprint: reunião realizada ao final de um Sprint para colher feedbacks.

Nele, o trabalho é organizado por Sprints, com tempo determinado. Ao final de cada Sprints, é realizada uma reunião para revisar tudo que foi feito e aprender com base na experiência.

Apesar da documentação não ser a maior prioridade no Scrum, três documentos são seguidos para organizar o trabalho:

• Product backlog: documento criado pelo Product owner com todas as tarefas que precisam ser concluídas. Novas demandas sempre podem ser adicionadas.

• Sprint backlog: feita pelo Scrum máster e pelo Product owner, estabelece todas as atividades que devem ser desenvolvidas durante um Sprint.

• Definição de pronto: critério de aceite de cada tarefa. O tempo/complexidade para conclusão da tarefa é dado com estimativas.

Kanban

Surgida no Japão na década de 1960 na fábrica da Toyota, o sistema Kanban era usado para definir cada uma das etapas de produção e levantar possíveis problemas que poderiam atrapalhar o processo.

O grande objetivo do Kanban é tornar o andamento do trabalho visível e otimizar o ciclo de entregas. O desenvolvimento de softwares foca sua utilização na Kanban Board, um quadro dividido em colunas que contém todas as etapas do projeto. Ali são definidas as atividades, que se dividem em três tipos:

• A fazer.
• Em desenvolvimento.
• Entregues.

Cada coluna indica um estado da tarefa, sendo que a ideia é iniciar uma tarefa e ir com ela até o fim. Assim, cada membro da equipe se encarrega de pegar a atividade que achar melhor, baseado com o seu perfil profissional e o prazo de entrega, e pode arrastá-las para as devidas colunas de acordo com o seu andamento.

Para controlar a realização das tarefas, o Kanban utiliza um conceito específico:

WiP (Work in Process): é um conceito que controlar o trabalho em andamento. O WiP estabelece que uma nova atividade só pode ser iniciada quando existe capacidade disponível no desenvolvimento. Uma forma de alcançar todo o potencial produtivo do Kanban é através da limitação do WiP, de forma que não ocorra nenhum gargalo nem sobrecarga no andamento do projeto.

Assim como no Scrum, no Kanban também existem rituais de Planejamento e Retrospectiva, mas eles não são forçados pelo time box da Sprint.

Scrum x Kanban

Por tanto o Scrum quanto o Kanban serem uma Metodologia Ágil, compartilham as mesmas bases:

Utilizam a transparência para garantir um processo melhor.
Dividem o trabalho em partes.
Tem foco na entrega rápida e frequente do software.
Utilizam times auto-organizados.
Dividem o trabalho em partes.

Mas é analisando suas diferenças que conseguimos entender melhor de que maneira eles podem ajudar no processo de desenvolvimento de software. Além do que já foi explicado, podemos destacar outros detalhes em que os dois métodos diferem:

Scrum:

Iterações com Time Box prescritas
Times multifuncionais prescritos
Estimativa prescrita
Iterações em andamento não podem receber novos itens
Scrum board reinicia a cada sprint
Velocidade é a métrica padrão para planejamento e melhorias

Kanban

Iterações com Time Box opcionais
Times multifuncionais opcionais. Times especialistas permitidos
Estimativa opcional
Novos itens podem ser adicionados se tiver capacidade
Kanban Board persistente
Lead Time é a métrica padrão para planejamento e melhorias

Então, qual é melhor? A resposta é simples: depende. Ambos tratam com incerteza (esse é um pré-requisito de métodos ágeis) e cada um se sai melhor com um tipo diferente de projeto. O Scrum é mais fácil de aplicar no período de mudança, visto que tem papéis bem definidos e mantém um pouco de estrutura para empresas mais tradicionais.
Outro ponto é que existe o conceito da sprint que foca no planejamento.

Já o Kanban é um passo além, uma espécie de “evolução do Scrum", onde você entende o trabalho como um fluxo de atividades, remove alguns ritos constantes e foca em diminuir o tempo de entrega.

É importante destacar que não existe uma metodologia “melhor”, ela é apenas um meio para que o trabalho possa ser finalizado. É importante levar sempre em consideração o primeiro valor do Ágil: indivíduos e suas interações mais do que processos e ferramentas. É muito comum ver a equipe surgir com uma espécie de mix de ambos, utilizando práticas de um e ritos do outro. Por outro lado, também é importante em um determinado momento utilizá-los como descrito na metodologia, para que a equipe se estruture e tenha mais maturidade.

E se você tiver interesse em aprender novas formas de otimizar processos e melhorar a gestão da sua Software House para alcançar resultados melhores, baixe nosso e-book, é gratuito.