quinta-feira, 8 de abril de 2010

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.

2 comentários:

  1. Celso,

    Vc só esqueceu de destacar uma coisa muito importante que as Metodologias Ageis também pregam, o Ritmo Sustentável.

    Segue a definição:

    Ritmo Sustentável (Sustainable Pace): Trabalhar com qualidade, buscando ter ritmo de trabalho saudável (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas quando trouxerem produtividade para a execução do projeto. Outra prática que se verifica neste processo é a prática de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o ambiente de trabalho e a motivação da equipe devem estar sempre em harmonia.

    Fonte: http://pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_extrema

    Portanto, não basta usar metodologias ageis se o ritmo ou o ambiente de trabalho não forem favoraveis. É muito importante manter a equipe sempre motivada e, nos dias de hoje, isso também é um grande desafio.

    Abs,

    Eduardo Ramos

    ResponderExcluir
  2. Com certeza, é uma prática importante. A semana de 40 horas da XP. Mas eu não consideraria como crucial para que ela funcione.
    Mesmo com agilidade, algumas horas extras são necessárias, em alguns casos. Tenho acompanhado alguns casos no twitter, onde o analista está com dificuldades de deixar as "barras verdes", por n motivos.
    Não pode virar rotina, mas nossa área é complicada e mesmo dando prazos coerentes e praticando agilidade, pode ser que necessitemos de algumas horas extras.
    Esse foi o motivo que deixei esta prática da XP (semana de 40hs) de fora.
    Também deixei as user stories de fora, assim como os post-its, o quadro branco, pois achei que essas práticas estão mais relacionadas a como nos organizar para que possamos aplicar as práticas ágeis.
    A stand-up meeting também entraria nesse caso, mas pelo seu aspecto natural de controle diário, verificação da implementação das histórias, resolvi incluir no post.
    Mas sem dúvida, seguir corretamente todas as práticas ágeis, são fundamentais para buscar o sucesso na aplicação destas práticas.

    ResponderExcluir