quinta-feira, maio 24, 2007

Boas práticas das metodologias ágeis

Muito se tem discutido a respeito das metodologias ágeis de desenvolvimento. A idéia é dar mais ênfase à prática que à teoria, ao sistema que à documentação. Porém em tempos onde a busca de certificações como CMM e MPSBR é grande, metodologias como XP, por exemplo, ainda têm que se adequar para poder competir com os métodos tradicionais nas grandes organizações. Porém, apesar de não integralmente, essas empresas podem adequar algumas das melhores práticas das metodologias ágeis em suas equipes.

  • Programação em Pares (Pair Programming): Nesse tipo de desenvolvimento há dois programadores por micro. Alguns podem dizer que essa é uma solução custosa do ponto de vista econômico, mas o fato é o contrário. Dois desenvolvedores juntos significa um código melhor escrito, algoritmos mais eficientes, menor possibilidade de bugs, programa mais manutenível. Além disso, evita-se um problema que ainda ocorre muito: um desenvolvedor responsável por um determinado módulo do sistema sai da equipe. É o suficiente para parar o projeto, já que só ele sabia sobre aquela parte. Com pair programming isso muda, ainda mais com sistemas de revezamento entre duplas, que também ocorre em XP.

  • Cliente faz parte da equipe: Geralmente o desenvolvedor tende a ver o cliente como inimigo. Para ele o usuário é aquele que nunca sabe o que quer, que sempre pede coisas diferentes e que provoca mudanças em algo que já estava pronto e funcional. Por isso há a tendência de a equipe de desenvolvimento acabar se isolando do seu cliente, que por sinal é o maior interessado no projeto. Para os métodos ágeis, o cliente é um membro da equipe. Ele participa das reuniões, escreve estórias (requisitos) e faz os testes de validação. Quanto mais próximo o cliente estiver, maiores são as chances de se entregar um produto de qualidade e útil para as necessidades do usuário final.

  • O desenvolvedor estima seus próprios prazos: Na divisão de tarefas é o desenvolvedor quem estima os prazos para a conclusão de determinada tarefa. O gerente apenas administra o processo de delegaçaõ das atividades. Caso o prazo estimado seja muito folgado, ou seja, o desenvolvedor terminou antes do prazo, então na próxima divisão de atividades são distribuídas um número maior de tarefas. Caso o tempo estimado seja muito curto, então o número de tarefas será diminuído. É o conceito de Yesterday's weather (tempo de ontem). O tempo hoje provavelmente será parecido com o de ontem. Se ontem choveu, hoje também choverá. Se sobrou tempo antes, então agora também sobrará, e por isso o número de tarefas aumentará para compensar isso.

As metodologias ágeis têm propostas bastante interessantes, apesar de necessitarem ainda de ajustes para serem totalmente aceitas pelo mercado. Como tudo na vida, cabe-nos avaliar prós e contras de cada lado e tentarmos criar uma proposta ótima.

Fico por aqui. Até a próxima!

Nenhum comentário: