Este artigo é o último artigo de uma série de quatro. Leia aqui o anterior: “Scrum & Kanban: no cerne do processo“

Chegamos à última fase da nossa aventura pelas metodologias de Project Management. E com ela chega a decisão de qual metodologia se adapta melhor

Agile vs Waterfall

De uma forma geral, a grande diferença entre o Agile e a Waterfall resume à flexibilidade versus rigidez de processos, encontrando-se nos dois extremos do espectro.

Adotar Agile quando/se:

• Antecipa possíveis mudanças;
• Projeto complexo;
• Necessidade de incluir requisitos novos a qualquer altura do projeto.

Adotar Waterfall quando/se:

• Tem uma visão clara do produto final;
• Requisitos fixos que não podem ser alterados;
• Projeto relativamente simples.

Agile vs Scrum

O Scrum é um framework dentro da metodologia Agile, por isso a linha que define qual é o melhor para um projeto é ténue. Por norma, o Agile é uma ótima base inicial, e o Scrum funciona bem em projetos com vários elementos desconhecidos e que podem evoluir ao longo do tempo, visto que lida de forma eficaz com estas mudanças, integrando informação e features novos ao longo do processo.

Adotar Agile quando/se:

• O produto final não está bem definido;
• Os clientes necessitam de poder mudar o âmbito do produto/projeto;
• As mudanças devem ser implementadas durante o processo;
• Os developers conseguem adaptar-se e trabalhar de forma independente.

Adotar Scrum quando/se:

• Os requisitos do projeto podem mudar e evoluir;
• O feedback contínuo é requerido;
• Não existe uma data de entrega fixa;
• A equipa quer autonomia;
• É necessário entregar o software com regularidade.

Agile vs Kanban

Agile e Kanban têm algumas semelhanças entre si, como o facto de dividirem o projeto em partes mais pequenas e de se focarem na melhoria contínua e na transparência. Para decidir qual escolher, deve ter-se em conta o nível de mudança que se deseja introduzir na equipa – se o objetivo for realizar uma grande mudança no processo, o Agile é a melhor opção, enquanto que se for uma mudança incremental, o Kanban é o ideal.

Adotar Agile quando/se:

• O produto final não está bem definido;
• Os clientes necessitam de poder mudar o âmbito do produto/projeto;
• As mudanças devem ser implementadas durante o processo;
• Os developers conseguem adaptar-se e trabalhar de forma independente.

Adotar Scrum quando/se:

• Os requisitos do projeto podem mudar e evoluir;
• O feedback contínuo é requerido;
• Não existe uma data de entrega fixa;
• A equipa quer autonomia;
• É necessário entregar o software com regularidade.

Agile vs Kanban

Agile e Kanban têm algumas semelhanças entre si, como o facto de dividirem o projeto em partes mais pequenas e de se focarem na melhoria contínua e na transparência. Para decidir qual escolher, deve ter-se em conta o nível de mudança que se deseja introduzir na equipa – se o objetivo for realizar uma grande mudança no processo, o Agile é a melhor opção, enquanto que se for uma mudança incremental, o Kanban é o ideal.

Adotar Agile quando/se:

• O produto final não está bem definido;
• É necessário implementar mudanças durante todo o processo;
• Os developers conseguem adaptar-se facilmente e trabalhar de forma autónoma;
• Se procura fazer uma mudança substancial.

Adotar Kanban quando/se:

• É necessário poder entregar o produto a qualquer altura;
• A equipa prefere uma mudança incremental e trabalha bem com elementos visuais;
• Se procura um sistema fácil de compreender e a mudança tem de ser rápida.

Scrum vs Kanban

Apesar de serem duas vertentes da metodologia Agile, apresentam diferenças entre si. O Scrum pode ser menos flexível que o Kanban, devido ao tempo necessário para sprints. Além disso, o Scrum tem papéis e fases definidas, enquanto que o Kanban é mais intuitivo – desta forma, a transição para o Scrum será sempre maior e a equipa deve aprender os diferentes papéis e reuniões envolvidos.

Adotar Scrum quando/se:

• É necessária uma abordagem;
• As equipas são multifuncionais;
• Necessidade de uma mudança mais aprofundada

Adotar Kanban quando/se:

• É necessário acrescentar ou alterar tarefas durante o processo;
• Não são necessárias iterações;
• A melhoria contínua é uma preocupação constante;
• A equipa não responde bem a mudanças drásticas;
• O sistema deve ser fácil de compreender