Cascata ou Scrum: como escolher a forma de executar o projeto

Em quase todas as primeiras conversas aparece a mesma pergunta, às vezes dita e às vezes não: isso vai ser feito em cascata ou de forma ágil? Por trás costuma haver uma experiência anterior. Ou um projeto em cascata que entregou, um ano depois, algo que já não servia; ou um projeto «ágil» que nunca terminou porque cada Sprint mudava de rumo.

As duas funcionam; o que falha é pedir a uma integração com o sistema central que se descubra pelo caminho, ou a um canal digital que seja assinado por fases. A escolha depende de três coisas: quão definido está o escopo, quem pode priorizar e como cada entrega será aceita. Este artigo serve para escolher bem.

A pergunta que decide

Antes de falar de etapas ou eventos, responda a isto: é possível escrever hoje, com precisão suficiente, o que o sistema precisa fazer quando estiver pronto?

• Se sim —porque é ditado por uma norma, um contrato, um processo que já existe ou um sistema que será substituído—, convém avançar por etapas. O valor está em não errar, e cada etapa reduz o risco da seguinte.
• Se não —porque é um produto novo, um canal digital ou uma ideia que precisa ser testada com usuários—, convém avançar por ciclos curtos. O valor está em aprender rápido, e cada ciclo corrige o rumo com o que já foi visto.

Há outros sinais que empurram para um lado:

Por etapas: modelo em V

É uma cascata: seis etapas, uma após a outra, cada uma com um entregável que é revisado antes de passar à seguinte. O que a torna um modelo em V é quando os testes são definidos: não no final, mas desde o início.

São seis etapas:

1. Origem. A necessidade de negócio é escrita como uma história: o que se quer alcançar, por quê, quais são os limites e quem decide. Parece formalidade e é a parte mais barata do projeto: aqui um mal-entendido custa uma conversa; mais adiante, o mesmo mal-entendido custa retrabalho.
2. Análise. Mede-se o que existe: processos, sistemas, dados e regras, inclusive as que só uma pessoa da equipe conhece. Nos sistemas antigos esta etapa é a que mais surpreende, porque costumam aparecer regras que ninguém havia escrito.
3. Design. Primeiro se modela o negócio e depois a tecnologia. Isso se chama design orientado ao domínio (DDD): as peças do sistema levam os nomes e as fronteiras do negócio, não os do banco de dados. Daqui saem a arquitetura, as matrizes de regras e os casos de teste com o resultado esperado. Esse é o ponto que mais importa a quem paga: desde o design já se sabe com quais critérios se vai aceitar.
4. Construção. Programa-se contra essa matriz. Cada peça chega com testes unitários e, quando se conecta a outro sistema, com testes dessa conexão que qualquer pessoa pode executar de novo, como coleções do Postman ou scripts, sem depender de nós. Esses testes ficam com o cliente.
5. Testes. Duas rodadas distintas. Na de qualidade (QA), uma revisão independente de quem programou executa a matriz completa. Na de aceitação (UAT, testes de aceitação), as pessoas do cliente validam no ambiente do próprio cliente, com casos reais. Não é desconfiança o fato de quem testa não ser quem fez: quem programou já decidiu o que era importante e, por isso, não vê o que deixou de fora.
6. Liberação. Entrada em operação com um plano de reversão acordado, manual de uso e de operação, e acompanhamento nos primeiros dias.

Por que se chama «em V»

Em uma cascata conduzida de forma linear, os testes costumam se concentrar depois da construção, quando um erro já sai caro. No modelo em V, cada teste é definido na etapa que o origina e executado mais adiante: os unitários e os de integração durante a construção; a matriz de qualidade e a aceitação, na etapa de testes, antes de liberar. O V é pela forma da letra, não um número:

Desenhado, a ida (origem, análise, design, construção) desce por um lado da letra V e os testes sobem pelo outro, cada um em frente à etapa que comprova. É o modelo que preferimos onde um erro custa caro, porque cada requisito fica ligado aos testes que o comprovam. Usamos uma versão leve: sem documentação que não agrega.

O que exige da empresa: tempo na origem e na análise, e a assinatura da matriz de testes no design. Feito isso direito, a construção exige menos tempo da empresa, salvo decisões ou mudanças relevantes.

O risco: que o negócio mude enquanto se constrói. Mitiga-se com etapas curtas: é melhor entregar em partes de semanas do que em um único bloco de um ano.

Por ciclos: Scrum

O Scrum organiza o trabalho em Sprints de uma a quatro semanas; preferimos duas ou três. Em cada uma entrega-se um incremento concluído e testado, não avanços em uma apresentação.

Os eventos do Scrum são poucos, e cada um tem um propósito:

• Planejamento da Sprint. Toda a equipe acorda a Meta da Sprint, e quem constrói escolhe, do Backlog do Produto, o que consegue concluir para cumpri-la.
• Reunião Diária (Daily Scrum). Quinze minutos da equipe para revisar o andamento em relação à Meta da Sprint e ajustar o plano do dia. Serve para destravar, não para prestar contas a um chefe.
• Revisão da Sprint. Uma sessão de trabalho com o que foi construído funcionando, junto de quem vai usá-lo; com o que se aprende, o Product Owner ajusta a lista.
• Retrospectiva da Sprint. A equipe revisa como trabalhou e muda uma ou duas coisas para o próximo ciclo.

E duas coisas que exigem cuidado: o Backlog do Produto (a lista priorizada), cuja ordem é decidida pelo Product Owner e que fica à vista de todos, e a Definição de Pronto, que descreve a qualidade que cada incremento precisa cumprir para ser considerado pronto; cada história, além disso, entra com os próprios critérios de aceite.

O que exige da empresa: um Product Owner com tempo e com autoridade para decidir. É o requisito mais subestimado. Sem essa pessoa, o Scrum vira uma equipe que entrega a cada duas semanas coisas que ninguém revisa.

O risco: confundir ágil com improvisado. Ágil não elimina os testes nem os critérios de aceite: cada história entra com os dela e sai com testes, igual ao trabalho por etapas.

Quando convém usar as duas

Na prática, muitos projetos grandes têm as duas naturezas. Uma seguradora que lança um canal digital de vendas precisa por etapas da integração com o sistema central de apólices e com o ERP, onde um erro custa dinheiro e problemas regulatórios. E precisa por ciclos da experiência do cliente no canal, que só se acerta testando com usuários.

É possível combiná-las sem caos com três regras:

1. Uma fronteira clara. As interfaces entre as duas partes são desenhadas e congeladas por etapas; atrás dessa fronteira, cada lado avança no próprio ritmo.
2. Um único responsável, que veja as duas partes e as ponha no mesmo calendário.
3. A mesma régua de qualidade. As duas partes são aceitas contra testes escritos antes de construir cada peça.

O espaço compartilhado

Uma metodologia rende pouco se as perguntas levam uma semana para chegar a quem as resolve. Por isso, seja por etapas ou por ciclos, convém trabalhar em espaços compartilhados desde o primeiro dia: um canal de conversa direta com a equipe que constrói (Slack, Microsoft Teams ou o que a empresa já usar) e um quadro em que se vejam as tarefas, os responsáveis e o status (ClickUp, Jira ou outro). Assim o cliente vê o projeto ao vivo, não em um relatório no final, e as decisões ficam registradas com data e com quem as aprovou.

Como decidir no caso da empresa

Uma regra prática: reveja a tabela do início. Se a maioria das respostas cair em uma coluna, comece por essa forma; se se dividirem, provavelmente convém combiná-las. E se ainda não está claro qual convém, é normal: a resposta depende de qual parte do projeto pesa mais. Numa primeira conversa revisamos o caso com a empresa e dizemos como o executaríamos, parte por parte.