Agile and The Matrix

Foi lendo o Fragmental que me deparei com essa comparação, em um dos comentários:

Por fim, quem já viu o “making the matrix” que vem no DVD do Matrix? O produtor (GP) explica como eles conseguiram fazer o filme a um custo tão baixo. Porque os diretores conseguiram ver todo o filme no storyboard. Não precisaram ir filmando para irem apurando a idéia. Foi um Waterfall. Matrix!

Adoro analogias, mas também acho que essa deixou um pouco a desejar. A resposta do Philip, sintetizando bem grosseiramente, foi:

- Documentos são caros;
- É difícil prever o futuro;
- Filmar é muito caro, pode valer a pena o preço para tentar adivinhar o futuro;
- Software é flexível;

Não descordo de nenhum dos pontos dele (embora tenha achado o terceiro meio confuso), mas gostaria de fazer as minhas considerações também. Como adoro analogias, achei que o assunto merecia um post só pra mim. ;-) [ licença Philip, licença Augusto. ]


O meu ponto de vista:

Em primeiro lugar, não acho que o story-board por si só configure um waterfall. Story-boards são uma ferramenta maravilhosa, pois conseguem expressar o projeto de forma âmpla. Mas apenas de forma âmpla, não detalhada.

Os detalhes serão, sim, pensados just-in-time. Quanta luz será usada? Incidindo em que posição/direção? Como os atores devem se posicionar? Devem falar essa frase mais ou menos rápido? Com que expressão? Com que tom de voz? E o penteado? Muitos e muitos detalhes são deixados pra última hora, não tem jeito. Ninguém consegue imaginar todos os detalhes com antecedência. E nem seria muito inteligente fazer, pense um pouco...

Esse não é um caso BDUF (Big Design Up-Front), mas de EDUF (Enough Design Up-Front). A diferença é sutil. (Engraçado, olha o primeiro resultado que o Google traz para enough: good enough)

O Philip escreveu que, "[no caso do filme,] pode ser mais barato pagar o preço de tentar adivinhar o futuro e modelá-lo completamente em uma ferramenta gráfica." Mas acho que, no caso do software, o problema é ainda mais crítico. Pois um pequeno detalhe, descoberto em cima da hora, pode acarretar uma mudança gigantesca no custo do projeto (guardadas as proporções).

É como se, na hora de analisar a iluminação da última cena, descobríssemos que o filme todo precisará ser filmado novamente porque senão ninguém vai assistir o filme, e o dinheiro terá sido praticamente jogado no lixo.

No caso do filme, é até difícil imaginar um cenário desses. Mas em software, esse tipo de coisa acontece praticamente todo dia. Não há como evitar as mudanças, pelo menos se estamos querendo desenvolver algo que realmente tenha qualidade, no sentido de maximizar o retorno do investimento.

O problema é mais simples que isso: não dá pra adivinhar o futuro e pronto. Não importa quanto dinheiro se esteja disposto a gastar.

Se não podemos prever as mudanças, e evitá-las é contra-producente (pra não dizer estúpido), a única solução possível é se preparar para a adaptação às mudanças (Embrace Changes): um dos pilares do desenvolvimento de software moderno.