O diferencial Ágil

sábado, 5 de fevereiro de 2011

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 você trabalhou ou a forma de trabalhar. Não culpe a Engenharia de Software porque você 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. Não fale do que não conhece, e principalmente, não fale mal.

Abraço a todos!

Bookmark and Share

4 comentários:

Postar um comentário

 
addthis_config = { data_ga_tracker: pageTracker }