Por que só agilidade funciona?

Baseado neste post do Yoshima, iniciei uma discussão com o pessoal da empresa. Este post é baseado na minha última resposta, com algumas adaptações para que tome o corpo de um artigo.


Também discordo da desqualificação do modelo tradicional, pois acho óbvio que ele existe. O modelo tradicional, waterfall, é levantamento de requisitos, desenvolvimento, testes e deploy. Uma vez na atividade seguinte, não há retornos a atividade anterior.

Entretanto, concordo com ele que só agilidade funciona. Mas temos que ter em mente a definição, nesse contexto, do que é "funciona". Funciona não é apenas correção. Funciona é "entregar software no prazo e com qualidade". Dos três pilares desta frase - entregar, prazo e qualidade - o único que ainda questionam é qualidade. Mas para mim é claro que a qualidade é importante para todos os envolvidos no processo (analista, consultoria e cliente). Meus argumentos estão em diversos artigos neste blog, mas principalmente aqui.

Destes três pilares deduzimos os pilares da engenharia de software: escopo, prazo e qualidade. Para a flexibilidade no processo, um dos três pilares precisa variar, enquanto os outros ficam fixos. O que é feito normalmente, é variar a qualidade e manter os outros dois fixos, o que caracteriza o foco na entrega.

A consequência de variar a qualidade é, na grande maioria das vezes, variar o prazo, pois já na fase de construção, manter é difícil e qualquer alteração é um parto, pois você vai degradando a qualidade e, consequentemente, fica mais difícil alterar, devido a complexidade do design e da codificação.

Assim, o foco na entrega, produz software de baixa qualidade e, normalmente, atrasado.

Com isso, chegamos à uma conclusão lógica. Não podemos variar a qualidade. Variar prazo intencionalmente é inconcebível, por motivos óbvios. O que sobra é variar o escopo. E os métodos ágeis permitem isso.

Permitem isso por seis motivos:

1. O "product owner" presente: é ele quem decide o que pode agregar mais valor para o negócio dele. Ninguém melhor que o PO para definir isso. http://agilenomundoreal.wordpress.com/2010/03/30/um-produto-por-semana/
2. Iterações: O desenvolvimento iterativo possibilita a constante revisão dos requisitos. A preocupação com a qualidade do design e do código fazem com que alterações não sejam um problema para a equipe. E isso nos leva ao próximo motivo:
3. TDD: Nas palavras de Ron Jeffries, no prefácio do livro TDD by example, do Kent Beck, "Clean code that works" é o objetivo do TDD. Com testes automatizados, alteramos o código sem medo e agilizamos os testes necessários. Se analisarmos bem, o tempo usado na construção de uma boa suite de testes é bem inferior ao tempo que levaríamos para, a cada mudança importante, testar todas as features no processo de "gera pacote-deploy-usa". Por ser um processo complexo e demorado, é normal não testarmos todas as features a cada alteração. Tentamos prever as features impactadas, mas sempre passa alguma coisa. Qual a conseqüência? Se não pegar na UAT, bug em produção. Com o TDD, a cada mudança, rodamos a suite e se todas as barras estão verdes, vamos para as nossas casas e dormimos tranqüilo. TI e TS vão se preocupar com erros funcionais e não uma falha decorrente da mudança do tipo de um campo, por exemplo;
4. Integração contínua: normalmente diária, visa garantir que o todo está funcionando, sempre. Fowler tem um excelente artigo sobre isso.
5. Programação em pares: Um executa e o outro pensa de forma mais estratégica. Enquanto um está escrevendo o teste, o outro está pensando na classe que vai satisfazer o teste, por exemplo.
6. Stand-up meetings: Permite o controle do projeto, procurando saber, diariamente, o que cada programador está fazendo. São reuniões rápidas, de quinze minutos, para todos saberem como está o andamento das histórias.
   

As práticas principais das metodologias ágeis, permitem desenvolver um software com mais qualidade e com mais possibilidades de entregar no prazo. Depois de nove anos da assinatura do manifesto ágil, existem vários casos de sucesso.

É preciso preparar as equipes para "respirar agilidade", de preferência com um bom treinamento. Os cabeças devem ser agilistas também.

Não é um processo fácil, mas possível e com boas garantias de bons frutos para todos. A passividade não é boa para ninguém. Se temos possibilidades de melhores opções, vamos experimenta-las. Não experimentar é falta de coragem. Se não der certo na primeira vez, vamos procurar identificar quais práticas não foram seguidas devidamente, e tentar novamente. Estamos tentando o waterfall há décadas, sempre caindo nos mesmos problemas, entregando software de má qualidade e fora do prazo. Está na hora de tentarmos outra coisa.