Semana passada, enquanto estava na integração no onboard do novo trabalho \o/, um dos sócios da empresa comentou sobre o modelo Waterfall, também chamado de Cascata, e perguntou se já havíamos lido o paper original. Eu pensei: Não. Ele continuou, a grande maioria talvez não e os que leram devem saber que o Winston W. Royce não criou o modelo e depois continuou a sua explicação sobre agilidade. Após isso, fiquei bem curiosa em saber mais sobre o Waterfall e seu paper original.
Ao ler a primeira linha já fiquei com aquela sensação, julguei o livro pela capa, ou melhor, nem pela capa, pelo o que os outros disseram sobre a capa de um livro, ou seja, fofoca.
Royce comenta sobre a experiência dele em gerenciamento de software e apresenta sugestões de melhorias para as formas de trabalho presenciadas ao longo da sua carreira. Ele começa com um padrão de desenvolvimento de software, onde há análise e, em seguida, codificação. Royce afirma que isso está fadado a falhar para software de grande porte, porém se for para implementar algo suficientemente pequeno e seja utilizado por quem o fez, esse conceito atende – um ponderamento muito do seu ágil.
Exemplo 01 de Wilson Royce em seu paper.
Posteriormente, ele apresenta aquela figurinha conhecida, o suposto modelo Waterfall – ao ler não vi esse termo no paper. Royce explica a imagem como um outro padrão de desenvolvimento de software com as fases já bem conhecida por todos.
Método Tradicional Waterfall, será mesmo?
E ao continuar a leitura, um trecho chamou me a atenção:
I believe in this concept, but the implementation described above is risky and invites failure.
O cara sabia que esse jeito tinha falhas, sabia que desenvolver software era, e ainda é, complexo, isso em 1970!!! E o melhor, o objetivo do paper dele era apresentar sugestões de melhorar esse padrão. E essas sugestões, ao meu ver, são os primeiros passos de bebê (engatinhar) para o mindset ágil. Segue as sugestões de forma resumida e com minha interpretação.
Program design comes first
Em linhas gerais, o autor sugere que antes de chegar na fase de análise, fazer uma versão preliminar do programa, ou seja, algo semelhante a um protótipo, com o objetivo de reduzir diversos riscos. De alguma forma, ele já começa a criticar que só desenvolver e achar que tudo estará certo não é o melhor caminho.
Documentation the design
Bem, essa sugestão é relativa a documentação do projeto ser atualizada ao longo do desenvolvimento, o que gera diversos documentos no final (o paper ilustra bem isso), diferentemente da abordagem de somente as fases iniciais serem específicas para documentação. Ao ler, tive a impressão de documentação massiva, mas se avaliarmos como atualização gradual de algo necessário e suficiente, aí tem um viés levemente ágil.
Do it twice
Ele defende o uso de um desenvolvimento do software em um tempo menor para obter uma simulação do produto final antes do término estipulado para o projeto. Uma versão embrionária do modelo iterativo voltado para validar hipóteses técnicas e obter o julgamento humano, o que para mim é feedback do cliente. Isso lembra algo?
Plan, control and monitor testing
O argumento dele é relativo ao uso de teste para validar as informações geradas ao longo do projeto com a ideia de minimizar falhas de entendimento e riscos futuros. Em que momento utilizamos isso no mundo ágil? 🙂
Involve the customer
Envolver o cliente! Essa foi a qual mais gostei. Royce defende a importância de envolver o cliente de maneira formal e que ele seja comprometido em ver as versões iniciais do produto antes da entrega final. Olha aí, a semente para a sprint review.
Wilson Royce nunca definiu o termo Waterfall, aliás, até o Wikipédia fala sobre isso, veja:
A origem do termo cascata é frequentemente citado como sendo um artigo publicado em 1970 por W. W. Royce; ironicamente, Royce defendia um abordagem iterativa para o desenvolvimento de software e nem mesmo usou o termo cascata.
E ainda não encontrei nenhuma fonte sobre onde surgiu o termo Waterfall. Será que alguém não terminou a leitura do paper do Royce? Royce era ágil? Não sei, mas tem um viés de melhoria contínua o seu paper, o que possibilita a rever o padrão utilizado naquela época.
Com isso, compreendi a frase “uma mentira contada mil vezes vira uma verdade”. Vamos ler mais e validar as informações antes de compartilhar poraí como verdade. E isso vale para tudo na vida.
Abraços.
Rodrigo Yoshima também comentou em um post que a agilidade não compete com tradicional, pois tradicional não existe. Para quem curte podcast, o Hipster já comentou sobre essa confusão. O pessoal convidado para o post é só fera!
Outros textos que falaram sobre erro de interpretação sobre o modelo Waterfall, em inglês. Why Waterfall was a big misunderstanding from the beginning – reading the original paper
Excelente, e como eu já disse algumas vezes o problema não está no suposto “waterfall” mas sim nas pessoas que interpretam, aplicam e defendem uma verdade delas próprias. Show de bola, parabéns pelo post!
Obrigada, Fábio.
Concordo com suas palavras.