O diferencial Ágil
Autor: Peter Lupo | Publicado: 2011-02-05T18:24:00-02:00

Desenvolvimento iterativo e incremental em ciclos curtos. Só isso?


Em todas as palestras que já fui até hoje sobre metodologias ágeis, seja quais forem (XP, Scrum, FDD, etc), é sempre a mesma história:

Métodos Ágeis são melhores que cascata porque ...
ou
Métodos Ágeis são melhores que métodos tradicionais (ou engenharia de software tradicional) porque...

Invariavelmente a frase segue comparando o modelo de ciclo de vida iterativo e incremental com o modelo cascata. Este último, sempre conhecido por altíssimos índices de fracasso foi introduzido à comunidade em um artigo de 1970 que dizia que seguí-lo era normalmente um tiro no pé e já falando de absorver feedback ao longo do projeto.

Então vamos a alguns pontos para melhorar o discurso Ágil:


Ainda estou para ver uma metodologia Ágil que preconize o uso de cascata. São todas iterativas e incrementais. Sendo assim, dizer que metodologia A ou B é legal porque é iterativa e incremental é chover no molhado. Este é o mínimo. Quando for apresentar uma metodologia, enfatize o seu diferencial.
Só mostrar as vantagens do uso do ciclo de vida iterativo e incremental não é nem de longe o suficiente para dizer que uma metodologia é boa ou é ágil, visto que pode-se usar o mesmo modelo de ciclo de vida associado a qualquer metodologia ou processo, ainda que totalmente "tradicional".
"Métodos tradicionais" ou "Engenharia de Software tradicional" NÃO são sinônimos de cascata. Se você teve uma péssima experiência na empresa onde trabalhou porque usou cascata, o problema foi onde&nbsp;você&nbsp;trabalhou ou a forma de trabalhar. Não culpe a Engenharia de Software porque&nbsp;você&nbsp;trabalhou em algum lugar onde as pessoas tinham pouco conhecimento sobre o assunto. No máximo você pode por a culpa nas universidades que não preparam direito ou que não deixam claro para o formado que ele não sabe o suficiente para fazer determinadas coisas, como montar um processo de desenvolvimento. O fato de você ter feito de uma maneira incompatível com as necessidades, contexto e restrições do projeto não significa que a Engenharia de Software está errada.
E quanto ao "tradicional", se você acha que o modelo de ciclo de vida iterativo-incremental, revisão por pares/pair programming, escrever testes antes de desenvolver/testar enquanto se desenvolve, e outras práticas são super modernas... well, think again...
Falar bem de A comparando com um B que você escolheu por ser pior é fácil. Faça diferente. Diga porque você acha bom, compare com coisas similares. Mostre vantagens mas mostre também as desvantagens.
Por último, PMBOK não é um processo nem uma metodologia. É um conjunto de práticas apenas. RUP não é um processo específico, é um framework para construção de processos. Muito menos é cascata. Do site do RUP: "RUP promotes iterative development and organizes the development (...)". Da wikipedia: "The Rational Unified Process (RUP) is an iterative software development process framework (...)". CMMI e MPS.BR, não são processos, não exigem que seja utilizado cascata e não restringem o uso de métodos Ágeis. De fato, se você segue um destes modelos e escolheu um ciclo de vida, vai ter que apresentar uma justificativa, o que pode tornar um pouco difícil a adoção de cascata. Sem falar de inúmeros relatos de adoção bem sucedida destes modelos juntamente com metodologias ágeis.&nbsp;Não fale do que não conhece, e principalmente, não fale mal.


Abraço a todos!