5 metodologias ágeis mais usadas em projetos de software

Conheça Scrum, Kanban, Scrumban, XP e Lean Startup: as principais metodologias ágeis utilizadas nas empresas

Gestão ágil não é ciência exata. Há várias maneiras de ser ágil. Daí não haver apenas uma metodologia considerada realmente ágil em detrimento de todas as outras, e sim inúmeras metodologias ágeis. 

Apesar do mundo corporativo dizer que algumas são ultrapassadas e outras é que são as modernas, quem diz o que funciona realmente é aquela empresa e aquele time específicos, com aquela gestão particular e aquele modelo de trabalho. 

Os frameworks ágeis só existem em suas apropriações reais pelos times. E é dentro do time que eles também se transformam, gerando configurações únicas que não raro se transformam no mais novo método ágil.

Mas, para esse processo de apropriação acontecer, ele precisa ser consciente. A simples reprodução mecânica de cerimônias ou rituais não leva à criação. Pois na base da criação estão:

1. Valores ágeis: aqueles lá do Manifesto Ágil, que devem ser vividos e praticados pela equipe, e
2. Conhecimento profundo das principais metodologias ágeis. 

É sobre esse segundo ponto que vamos nos debruçar neste artigo. Faremos um resumão das principais metodologias ágeis utilizadas no mundo. 

Para a escolha das metodologias que estarão neste artigo, usamos o 15th State of Agile Report, que traz, em ordem de uso, as seguintes metodologias:

• Scrum
• Scrumbam
• Kanban
• XP e
• Lean startup.

Conheça as 5 principais metodologias ágeis

1. Scrum

O Scrum é o framework ágil mais usado pelas organizações. Para muitas é também a porta de entrada na agilidade. 

Criado em 1993, por Ken Schwaber e Jeff Sutherland, como um contraponto ao desenvolvimento em cascata de softwares, o Scrum é uma metodologia de com mecânica simples, baseada em um modelo incremental e iterativo, aliada à prática de valores ágeis. 

Equipes Scrum tem três papéis básicos: product owner, scrum master e membros da operação. Vejamos as responsabilidades de cada um deles:

• Product owner (PO): compreende as necessidades dos stakeholders e conecta esse conhecimento com a equipe. Comanda as sprints planning, determina as prioridades e cria o backlog de produto, atua junto ao time para se certificar que o andamento dos trabalhos corresponde ao esperado, faz ajustes de rota na sprint, aprova funcionalidades desenvolvidas e dialoga com os stakeholders. 
• Scrum master: guia o projeto em termos de agilidade, dá suporte e apoio a sua construção em comum com o time e eleva a prática do Scrum. 
• Membros: profissionais da execução. Pode incluir desenvolvedores, designers UI e UX, arquitetos, entre outros profissionais.

A mecânica do Scrum se centra dentro do conceito de sprint: uma iteração limitada no tempo, normalmente entre 20 e 30 dias. Dentro de uma sprint, acontecem as seguintes cerimônias:

• Sprint planning: reunião da equipe com o objetivo de construir o backlog da sprint, sequenciar, estimar o tempo e distribuir as demandas.  
• Daily Scrum: reunião curta diária (15 minutos) para inspeção (o que fez, o que vai fazer e obstáculos) e ajustes de última hora.
• Sprint review: reunião ao final da sprint em que as funcionalidades são mostradas ao PO, a usuários e stakeholders para a obtenção de feedbacks. 
• Retrospectiva: reunião do time ao final de cada sprint com o objetivo de fazer uma análise do que passou. 

Todo o andamento do backlog da sprint é gerenciado em um Scrum board, inspiração do kanban. Ele mostra a evolução das tarefas até a conclusão.

Mas para que o Scrum funcione, não basta ter apenas papéis, cerimônias e um board. Na base disso, os criadores do Scrum colocaram cinco valores cruciais para a metodologia produzir resultados:

• Comprometimento: todos são donos do projeto, o que implica uma tomada de decisão mais horizontal, mas também responsabilidade. O sucesso da entrega está sempre em primeiro plano.
• Abertura: alto nível de transparência é uma premissa e uma busca constante no Scrum. Todos precisam estar na mesma página sempre.
• Coragem: times Scrum não escondem a sujeira para debaixo do tapete, mas miram e lidam com as adversidades com o peito aberto. 
• Respeito: equipes Scrum funcionam com base na boa-fé.
• Foco: pelo período da sprint, o backlog é o único trabalho da equipe. Há um cuidado em se manter fiel às demandas, fazendo os ajustes tão logo quanto possível.

O Scrum, quando alia práticas a valores, pode alterar radicalmente estruturas organizacionais tradicionais, baseadas em silos e hierarquia rígida, por exemplo. O desafio é aliar ambas, saindo de uma reprodução irrefletida dos rituais e destravando todo o potencial da metodologia ágil mais consagrada nas empresas.

Leia mais: Guia Scrum: tudo o que você precisa saber para praticar

2. Scrumban

Scrumban é a segunda metodologia ágil mais usada pelas organizações. Ela está relacionada, além de aos criadores das respectivas metodologias originárias, a Corey Ladas. Ele formaliza a junção no livro Scrumban: Essays on Kanban Systems for Lean Software Development. 

Ladas desenvolve a relação entre Scrum e Kanban que está posta por Jeff & J. Sutherland na metodologia desde o início. Os criadores do Scrum mencionam o lean thinking como uma fonte de inspiração. Eles se referiam à ideia de sistema puxado por um fluxo contínuo de uma peça só, gestão de desperdícios e de gestão visual. 

O Scrumban é a junção da ideia de fluxo contínuo com a de ciclos de incremento definidos, isto é, com sprints. 

Na prática, não muda muita coisa em relação ao Scrum. Ladas mantém os mesmos papéis e não adiciona rituais novos. Toda sprint continua a ser iniciada com a planning, que será inspecionada e ajustada nas dailies, que será validada com stakeholders na review e analisada pela equipe na retrospectiva. Métricas típicas do Lean podem ser incorporadas, como o CFD, por exemplo. 

Além do próprio Scrum board, práticas típicas do kanban também são incorporadas, como:

• Dar visibilidade ao fluxo
• Limitar o WIP (work in progress)
• Gerenciar ativamente o WIP, criando mecanismos para desbloquear o backlog e resolver gargalos, estabelecer critérios para que cards sejam puxados etc.

Veja mais: Scrum com kanban: como aplicar o Scrumban?

3. Kanban

Um kanban nada mais é do que um cartão. A ideia de traduzir fluxos por meio de cartões surgiu na Toyota, na década de 1950, da mente do engenheiro mecânico Taiichi Ohno. O objetivo era eliminar os desperdícios e aumentar o nível de flexibilidade na indústria.

No universo de desenvolvimento de softwares, foi em 2007 que David Anderson consagrou a prática como uma metodologia ágil.

O Kanban, assim como o Scrum, funciona em um quadro. A forma mais básica dele tem três listas com os kanban (cartões): a de tarefas por fazer, a de tarefas em andamento e a de tarefas concluídas. Cada cartão é uma atividade a ser puxada para a lista seguinte sempre que atender aos requisitos, como uma fila. Simples, mas poderoso. Por quê? Anderson responde com os seguintes pontos:

• Permite a visualização de todo o fluxo de trabalho: o kanban dá tangibilidade a fluxos de desenvolvimento. Basta um olhar para saber o que está acontecendo a qualquer momento, sem precisar perguntar para ninguém. 
• Torna as políticas do processo explícitas: o kanban força a equipe a esclarecer quando uma demanda se dá por finalizada e pode seguir adiante no fluxo. 
• Limita o trabalho em progresso (WIP): não se guarda trabalho inacabado no Kanban, daí a ideia de criar fluxos contínuos tanto quanto possível, estabelecendo ritmos.
• Entregas frequentes: o time consegue visualizar melhor suas entregas e, com base na gestão visual, melhorar sua performance, o que leva a entregas frequentes.
• Facilita a mensuração e o gerenciamento do fluxo de trabalho: métricas como as contidas no CFD dão direção a contramedidas.
• Estabelece cadências de comunicação: a prática fortalece a corresponsabilização, o respeito e o foco da equipe, que estará propensa a colaborar.

Para Anderson, equipes que pretendem começar a praticar o Kanban devem seguir os seguintes princípios:

• Começar pelo que a equipe já faz: montar um kanban força a equipe a olhar para o que faz e a compreender por que faz.
• Respeitar a estrutura organizacional: responsabilidades e papéis podem ser mantidos com a vantagem de empoderar todos os praticantes.
• Incentivar atos de liderança em todos os níveis organizacionais: o Kanban explicita gargalos forçando todos a refletir sobre seus processos.
• Buscar mudanças incrementais e contínuas: o kanban leva a melhorias pontuais com efeitos sobre o fluxo global, o chamado kaizen, e a prática constante dessa busca.

Leia mais: Kanban: conceito, princípios e boas pr´´aticas

4. Extreme programming

A XP (Extreme Programming) é uma metodologia ágil que ajuda times de desenvolvimento a fazer códigos flexíveis, que se prestam à mudança. A premissa é a de que a mudança é, de longe, constante em projetos de software e, no entanto, a causa-raiz de spaghetti code. 

É nisso que também está a particularidade do XP em relação ao Scrum e ao Kanban, por exemplo, e o motivo de ele ser combinado a elas: muitas de suas práticas são bem focadas em programação. Mas não se enganem, pois essa metodologia não é apenas para programadores experientes. 

As práticas XP são agrupadas em quatro. Vamos ver cada um deles:

1. Práticas de programação

• Test-first programming ou test-driven development (TDD): recomenda a escrita de testes automatizados antes da produção do código que será testado.
• Pair programming: com dois desenvolvedores trabalhando juntos, para estimular o code review.

2. Práticas de integração 

• 10-minute build: recomenda a criação de uma build automatizada para o código base inteiro, que rode em menos de 10 minutos, incluindo os testes e gerando relatórios dos que passaram e falharam. O objetivo é que ela seja rodada frequentemente para revelar o nível de qualidade do código.
• Integração contínua: para evitar mudanças conflitantes no código, recomenda que o time rode a build constantemente e monitore erros.

3. Práticas de planejamento

• Ciclos semanais: iterações de uma semana.
• Stories: mesmo conceito de user stories.
• Ciclos trimestrais: planejamento de longo prazo, com uma visão mais geral sobre os temas que vão direcionar o projeto, mas também um olhar para trás, sobre o progresso feito e problemas internos e externos, bugs recorrentes e ajustes.
• Slack: tarefas ligadas a histórias com baixa prioridade deixadas para o final da iteração, para, no caso de problemas inesperados, poderem ser cortadas sem afetar as entregas.

4. Prática do time

• Sentar juntos: manter o acesso fácil aos colegas do time para consultas, aconselhamento e trocas.
• Ambiente de trabalho informativo: o espaço comunica informações sobre o projeto, por meio de quadros e burndown charts, por exemplo, para que todos estejam sempre na mesma página.
• Abraçar a mudança: assunção das mudanças como algo natural a um projeto, mas criando mecanismos para gerenciá-la, para minimizar impactos tanto no escopo do projeto quanto na qualidade do código.

Ná prática, como o XP funciona. Cada ciclo começa com uma reunião de planning, na qual o time revisa o progresso do projeto, trabalha com os clientes na seleção das histórias para a iteração e as quebra em tarefas que serão estimadas e distribuídas entre os desenvolvedores. Bem similar ao Scrum.

Na primeira parte da iteração a equipe escreve os testes automatizados para as histórias e, na segunda, o código. Ao final do ciclo de iteração, há uma espécie de review, para coleta de feedback.

Assim como o Scrum, as práticas XP e mecânicas só ganham propósito com os valores da metodologia:

• Comunicação: todos sabem o que os demais estão fazendo e por quê.
• Simplicidade: foco em manter o software em sua versão mais simples possível.
• Feedback: obtenção constante de avaliações de usuários e stakeholders.
• Coragem: descartar soluções falhas, mesmo que consagradas, e exercitar abordagens diferentes.
• Respeito: todos os membros têm relevância na equipe.

Abaixo dos valores, o XP ainda tem vários princípios que guiam a aplicação das práticas. Vejamos:

• Humanidade: equilíbrio entre as necessidades do projeto e as necessidades das pessoas.
• Economia: sempre se ater ao budget do projeto.
• Benefícios mútuos: time e profissionais, assim como clientes, precisam ser beneficiados pelo projeto.
• Similaridade: o padrão de um ciclo mensal, semanal ou diário é sempre o mesmo. 
• Melhoria: fazer o melhor hoje e continuar a trabalhar para fazer melhor ainda amanhã.
• Diversidade: opiniões e visões diferentes levam a soluções melhores.
• Reflexão: pensar tanto sobre o que funciona quanto sobre o que não funciona no processo.
• Flow: delivery constante, sem fases distintas.
• Oportunidade: cada projeto é uma chance de aprender algo novo sobre desenvolvimento.
• Redundância: ajuda a evitar problemas de qualidade.
• Falhar: nossos erros podem ser uma boa fonte de aprendizado.
• Qualidade: um produto ruim não é aceitável.
• Responsabilidade: se alguém é responsável por algo tem a autoridade para entregá-lo.
• Passos de bebê: pequenos passos na direção correta.

5. Lean startup

Lean startup, criada por Eric Ries no livro homônimo, pode ser duvidosa enquanto método, isto é, um caminho ou passo a passo para a agilidade. Mas, como um contraponto ao desenvolvimento tradicional em cascata e baseada no lean thinking, certamente tem como resultado a agilidade.

Ries desenvolve o que chama de “ciclo construir-medir-aprender” aplicado ao empreendedorismo, ou seja, à transformação de ideias em produtos. Para isso, desenvolve o conceito de MVP, que vai cumprir um papel fundamental para esse encurtamento e aceleração. 

MVP é o core de um produto novo, só que mais avançado que um protótipo, porque é funcional, desperta o interesse e gera valor real para os usuários. No entanto, sua premissa é ter o mínimo de complexidade, o menor esforço e o menor custo de desenvolvimento possíveis.

O objetivo é lançar e testar o produto o mais rápido possível com adotantes iniciais, para coletar feedbacks sobre as hipóteses assumidas pelos criadores. Tais feedbacks vão ajudar a continuar a incrementar o produto ou, no limite, a pivotar a estratégia. Com a vantagem de ter um projeto enxuto e barato suficiente para ser facilmente modificado. 

Ries prevê vários tipos de MVP, entre os quais o protótipo, o fumaça, o concierge e o mágico de Oz. No entanto, não cria um método para determinar como o MVP tem que ser. 

Outros autores, partindo da abordagem de Lean startup, criam metodologias que auxiliam a desenvolver o roadmap de um MVP. A mais conhecida delas é a Lean Inception, criada por Paulo Caroli.

A Lean Inception é um workshop colaborativo de cinco dias com profissionais de produto e stakeholders que avalia a visão do produto, personas, funcionalidades e jornadas dos usuários, cujo resultado é um MVP Canvas.

Metodologias ágeis: eleve o nível dos processos de desenvolvimento

As metodologias ágeis surgem para corrigir problemas ligados ao desenvolvimento tradicional de projetos. Scrum, Kanban, Scrumban, Extreme Programming e Lean Spartup, cada um dos frameworks que trouxemos neste post os endereçam de uma maneira, ressaltando o planejamento, o fluxo e a qualidade do código.

Não é à toa que junções de frameworks acontecem, para os times obterem o melhor de vários mundos.

Ainda não aplica metodologias ágeis aos processos de desenvolvimento? A Supero Soluções ajuda você a fazer isso: com squads ágeis alocadas a sua organização ou remotas, você tem uma célula de agilidade em pleno funcionamento dentro da organização.

Fale com um dos nossos consultores para saber mais.