[fsn_row][fsn_column width=”12″][fsn_text]
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
[/fsn_text][/fsn_column][/fsn_row]
