Ágil vs waterfall é uma escolha entre planear tudo primeiro e depois construir de uma só vez (waterfall, ou em cascata), ou construir em ciclos curtos e ajustar o plano à medida que se aprende (ágil). Na maioria dos projetos de apps e websites, a resposta honesta fica entre os dois: uma fase fixa de descoberta e design, seguida de ciclos curtos de construção com um orçamento claro. Este guia explica os dois métodos em palavras simples, compara-os lado a lado, mostra qual serve websites, apps e trabalho de marca, e termina com os contratos adequados a cada um e uma lista de verificação para escolher.
O que são ágil e waterfall, em palavras simples?
Antes de os comparar, convém tirar o jargão às duas palavras. Nenhum é uma religião. Cada um é uma forma de decidir quando se compromete com o que está a construir, e quanto custa mudar de ideias mais tarde.
Waterfall: decidir, depois construir
O waterfall conduz um projeto como uma sequência de etapas. Os requisitos são recolhidos e aprovados, depois vem o design, depois a construção, depois os testes, depois o lançamento. Cada etapa começa quando a anterior termina, e voltar atrás custa tempo e dinheiro.
A sua força é a previsibilidade. Conhece o âmbito, o preço e a data antes de se escrever a primeira linha de código. A sua fraqueza é partir do princípio de que se sabe tudo no início. Quando um utilizador real encontra o produto pela primeira vez, perto do fim, é tarde para descobrir que um ecrã essencial não funciona para ele.
Ágil: construir, aprender, ajustar
O ágil divide o trabalho em ciclos curtos, normalmente de uma ou duas semanas, muitas vezes chamados sprints. Cada ciclo termina com algo a funcionar que pode ver e testar. A lista do que construir a seguir (o backlog) é reordenada depois de cada ciclo, com base no que se aprendeu.
A sua força é a adaptabilidade. Os erros aparecem cedo, quando são baratos, e pode parar a qualquer momento com algo utilizável. A sua fraqueza é que o âmbito e o custo finais não ficam fixos no início, o que deixa alguns compradores nervosos e torna um responsável fraco do lado do cliente um risco real: o ágil precisa de alguém do seu lado que tome decisões todas as semanas.
Ágil vs waterfall lado a lado
A tabela abaixo apresenta as diferenças práticas que um comprador vai sentir, não a teoria.
| Waterfall | Ágil | |
|---|---|---|
| Âmbito | Fixo no início | Evolui ciclo a ciclo |
| Orçamento | Preço fixo para um âmbito fixo | Fixo por ciclo; o total acompanha o âmbito |
| Quando vê trabalho a funcionar | Perto do fim | A cada uma ou duas semanas |
| Custo de uma alteração | Alto, através de pedidos de alteração | Baixo, absorvido no ciclo seguinte |
| O seu tempo necessário | Intenso no início e na aprovação | Regular, todas as semanas |
| Documentação | Detalhada, escrita à partida | Mais leve, atualizada ao longo do projeto |
| Ideal quando | Os requisitos são claros e estáveis | Os requisitos vão mudar com o que se aprende |
| Principal risco | Construir bem a coisa errada | Derrapagem do âmbito e do orçamento |
Repare que nenhuma das colunas é “melhor”. O waterfall troca flexibilidade por certeza; o ágil troca certeza por flexibilidade. A escolha certa depende de quanto já sabe.
Que método serve websites, apps e trabalho de marca?
O tipo de projeto decide o método mais do que qualquer preferência da agência. Eis como costumam ficar os três em que mais trabalhamos.
Websites
Um website institucional ou de marketing tem normalmente uma forma bem conhecida: um conjunto de páginas, um sistema de gestão de conteúdos, formulários, visibilidade na pesquisa. Grande parte pode ser planeada à partida, o que se presta a uma estrutura próxima do waterfall para a descoberta, o mapa do site e o design.
É na construção que a agilidade ajuda. Os conteúdos chegam tarde, uma página precisa de uma secção nova, o cliente vê a página inicial no browser e quer que o destaque funcione de outra forma. Construir em ciclos curtos num ambiente de testes permite que essas alterações entrem sem um pedido de alteração formal para cada uma. Se está a fazer o orçamento, o nosso guia sobre quanto custa um site mostra para onde vai o dinheiro em cada etapa da criação de websites.
Apps
As apps, sejam uma app móvel ou uma aplicação web com contas, dados e lógica de negócio, são onde o waterfall puro falha mais vezes. Os utilizadores comportam-se de formas que nenhuma especificação prevê, as plataformas mudam as regras, e a funcionalidade mais valiosa é muitas vezes uma que ninguém escreveu no início.
Numa app, o ágil é quase a opção por defeito. Uma primeira versão utilizável (o produto mínimo viável) chega a utilizadores reais o mais cedo possível, e os ciclos seguintes são orientados pelo que eles fazem. O waterfall continua a ter lugar nas partes fixas: o modelo de dados, os requisitos de segurança, as integrações com sistemas existentes e tudo o que um regulador vá ler.
Trabalho de marca
A identidade de marca é outra história. Passa pela estratégia, pelo conceito e pela execução, e cada passo depende da decisão anterior. Não faz sentido fazer um logótipo “em sprints”: uma identidade escolhe-se como um todo, a partir de um pequeno número de caminhos bem pensados.
Por isso o trabalho de marca tende a seguir uma sequência por etapas, próxima do waterfall, com pontos de revisão, mas com margem para recuar um passo quando um conceito não se aguenta. Quando criámos a identidade da Nothing To Eat, o símbolo e a sua construção ficaram decididos primeiro, e o website e os seus ecrãs vieram depois, construídos sobre decisões já tomadas. Se está a pensar onde acaba a identidade e começa a perceção, o nosso artigo Imagem de marca vs identidade de marca vai mais longe.
Abordagens híbridas que funcionam
A maioria dos projetos reais são híbridos, quer alguém lhes chame assim ou não. A pergunta útil é que partes são fixas e que partes são flexíveis. Há três padrões que aparecem uma e outra vez.
Descoberta fixa, depois sprints
É o padrão que mais recomendamos. A primeira fase é uma descoberta de âmbito e preço fixos: objetivos, utilizadores, conteúdos, escolhas técnicas, um mapa do site ou de funcionalidades, e os ecrãs principais desenhados. Sabe exatamente quanto custa e o que vai receber.
Depois a construção decorre em sprints a partir de um backlog priorizado, com um orçamento por sprint e uma estimativa para o conjunto. Mantém a certeza onde ela importa (a direção e o design) e a flexibilidade onde ela compensa (a construção e os detalhes).
Waterfall com ágil por dentro
Algumas organizações precisam de um contrato fixo e de uma data de lançamento fixa: um organismo público, um lançamento ligado a um evento, um produto regulado. Aqui a estrutura exterior é waterfall, com um âmbito assinado e marcos, mas cada marco é construído em ciclos internos curtos, com demonstrações. O cliente vê trabalho a funcionar a cada duas semanas sem o contrato mudar de forma.
Ágil com um núcleo fixo
Numa app, um padrão comum é fixar as partes caras de mudar (arquitetura, modelo de dados, segurança, o sistema de design) e manter ágil tudo o que fica por cima. As funcionalidades sobem e descem no backlog à vontade, porque as fundações não se mexem com elas.
Que contratos servem cada método?
O método que escolhe tem de corresponder ao contrato que assina. Um desajuste, como um processo ágil dentro de um contrato rígido de preço fixo, é a fonte de litígios mais comum que vemos.
Preço fixo
Um preço fixo serve o waterfall e as fases de âmbito fixo, como a descoberta ou a identidade de marca. A agência assume o risco da estimativa, por isso o âmbito tem de ficar escrito com precisão: páginas, funcionalidades, rondas de revisão, o que está incluído e o que não está.
Tudo o que fica fora desse âmbito escrito torna-se um pedido de alteração: um documento curto que descreve a alteração, o seu custo e o efeito na data, assinado antes de o trabalho começar. Os pedidos de alteração não são um truque. São o que mantém um preço fixo justo para os dois lados.
Tempo e materiais
O modelo de tempo e materiais serve o ágil. Paga o tempo efetivamente gasto, normalmente por sprint ou por mês, a uma tarifa acordada. O âmbito pode mexer-se livremente, porque o preço acompanha o trabalho.
A sua proteção é a visibilidade, não um total fixo: um backlog que consegue ler, uma demonstração no fim de cada ciclo, um total acumulado face à estimativa, e o direito de parar depois de qualquer sprint com tudo o que já foi construído. Um teto por mês ou por fase é um pedido razoável.
Preço fixo por sprint
Uma via intermédia é um preço fixo para cada sprint, com uma equipa fixa e uma duração fixa, e uma lista flexível do que entra em cada um. Sabe quanto custa cada quinzena; a agência sabe com o que se compromete; o conteúdo de cada sprint é acordado no seu início.
Se está a pesar quem contratar para o trabalho, além de como o contratar, o nosso artigo Agência nova ou agência estabelecida: qual escolher? explica o que perguntar a ambas.
Como muda a IA o equilíbrio?
Parte do velho argumento a favor do waterfall era o custo: mudar de direção obrigava a refazer trabalho à mão. Isso é menos verdade do que era. Na Odduel, a IA assegura grande parte da produção repetitiva (componentes do sistema de design, código front-end, primeiras versões, casos de teste, primeiras versões das traduções), por isso um ciclo produz mais trabalho a funcionar e uma mudança de direção custa menos a absorver.
O que não fica mais barato é o critério. A estratégia, o conceito, a direção de arte, a voz da marca e a revisão final continuam a ser trabalho humano, e é aí que vai o orçamento. Na nossa experiência, isto inclina mais projetos para ciclos curtos: quando construir é rápido, mais vale ver ecrãs reais cedo do que aperfeiçoar uma especificação que nenhum utilizador testou. É assim que conduzimos, a partir de Barcelona e São Paulo, os projetos de desenvolvimento de aplicações e de design UX/UI.
Como escolher? Uma lista de verificação
Responda a estas perguntas com honestidade. Quanto mais respostas caírem à esquerda, mais o waterfall lhe serve; quanto mais à direita, mais lhe serve o ágil.
- Requisitos. Consegue escrever hoje tudo o que o produto tem de fazer (waterfall), ou vai aprender a maior parte com os utilizadores (ágil)?
- Orçamento. Precisa de um valor fixo assinado antes de o trabalho começar (waterfall), ou consegue trabalhar com um orçamento mensal e um total acumulado (ágil)?
- Prazo. A data é imposta por algo fora do seu controlo (estrutura waterfall), ou é um objetivo que pode trocar por âmbito (ágil)?
- O seu tempo. Alguém do seu lado consegue rever o trabalho e decidir todas as semanas (ágil), ou só em alguns marcos (waterfall)?
- Utilizadores. Consegue pôr uma versão inicial à frente de utilizadores reais (ágil), ou nada sai até tudo estar terminado (waterfall)?
- Conformidade. Um regulador, uma regra de contratação pública ou uma administração exige uma especificação completa à partida (waterfall, pelo menos na estrutura exterior)?
- Tipo de trabalho. É identidade de marca (por etapas), um website de marketing (híbrido) ou uma app (ágil com um núcleo fixo)?
Se as suas respostas são mistas, é normal. Escolha um modelo híbrido e decida, parte a parte, o que é fixo e o que é livre.
Perguntas frequentes
O ágil é sempre mais caro do que o waterfall?
Não. O ágil pode parecer mais caro porque o total não fica fixo no início, mas os projetos em waterfall acabam muitas vezes a pagar pedidos de alteração e retrabalho depois do lançamento. O ágil gasta o orçamento naquilo de que os utilizadores precisam de facto, e pode parar quando o produto estiver suficientemente bom. A verdadeira diferença de custo vem da forma como cada um é gerido.
Um contrato de preço fixo pode ser ágil?
Em parte. Um preço fixo por fase ou por sprint funciona bem com o ágil, desde que o âmbito de cada um seja acordado no seu início. O que falha é um preço fixo único para uma lista fixa de funcionalidades combinado com uma promessa de flexibilidade: uma das duas cede, normalmente num litígio.
Que método é melhor para um redesign de website?
Normalmente um híbrido. A descoberta, o mapa do site e o design das páginas principais ganham em ficar fixos e aprovados; a construção, a introdução de conteúdos e os afinamentos ganham com ciclos curtos num ambiente de testes. O website existente dá-lhe muito conhecimento à partida, o que torna mais fácil definir o âmbito da parte fixa.
Quanto dura um sprint num projeto de app?
A maioria das equipas usa uma ou duas semanas. Uma semana mantém o feedback apertado mas deixa pouco espaço para funcionalidades maiores; duas semanas é o equilíbrio habitual. Mais do que a duração, importa que cada sprint termine com algo a funcionar que possa ver e experimentar.
O que tenho de assegurar num projeto ágil?
Um product owner do seu lado: uma pessoa que conhece o negócio, consegue definir prioridades e está disponível todas as semanas para rever o trabalho e responder a perguntas. Sem essa pessoa, o ágil abranda, porque a equipa fica à espera de decisões que ninguém tem autoridade para tomar.
Se tem uma app ou um website em mente e não sabe bem como o estruturar, comece por uma descoberta curta e fixa: dá-lhe um preço para a construção, um design a que reagir e a informação para escolher o método com confiança. Veja como abordamos o desenvolvimento de aplicações, ou fale-nos do seu projeto.
