sábado, 13 de março de 2010

Pensando em ágil

150px-Rodin_The_Thinker_Laeken_cemetery O quanto às metodologias ágeis são eficases? Essa é uma pergunta que todos com certeza já se fizeram a partir do momento que tiveram contato com elas.

Mas realmente é muito complicado garantir que tais metodologias funcionam ou não. Mas eu ando bem desencanado com isso, Por quê?

Por que já vi projetos ágeis falharem e terem sucesso, assim como já vi projetos cascata falharem e terem sucesso também.

Ayende Rahien, o cara por trás do Rhino Mock, escreveu um post  falando sobre metologias e sabe o que é engraçado? Nenhuma delas fala sobre engenharia de software.

Uma vez fui questionado por um colega se eu gostava de XP e quando eu perguntei o porquê ele me falou: O projeto “xyz” foi feito com XP. O detalhe desse projeto em questão é que ele funciona, o cliente esta satisfeito de uma forma geral, mas tem um código horrível de dar manutenção. Por isso eu respondi: “Que culpa a qualidade do código tem de você utilizar XP?”.

Não interessa que tipo de metodologia você utiliza, sem aplicar boas práticas de engenharia de software, boa arquitetura, bom profissionais, adivinha o que vai acontecer?

Bom, mas o que tem realmente chamado a minha atenção e que me tem trazido bons resultados são algumas práticas contidas nas metodologias ágeis. Aqui vão algumas que tenho me atentado:

1) Comece a desenvolver pelo que agrega maior valor ao negócio.

Eu não sei com vocês, mas geralmente as funcionalidades que você tem que desenvolver que agregam maior valor ao negócio, ou seja, o que seu cliente mais precisa, também são as mais difíceis.

Mas isso é bom, pois afeta diretamente o desenho do projeto, arquitetura, forma de comunicação entre outras coisas.

Exemplo, no ramo de manufatura se a funcionalidade que agrega maior valor é a de ordem de produção, por que começar com cadastro de produtos? Ai você vai me questionar o seguinte: Mas você não precisa de produto para criar a ordem de produção? Sim, realmente vou precisar de produtos. Porém, nesse nosso cenário a tela de produto pode ser afetada por várias funcionalidades do nosso sistema (compras, por exemplo).

Bom se eu sei que a tela de ordem de produção vai precisar de informações de produto, não é melhor eu colocar no produto somente as informações necessárias para gerar a ordem de produção?

Perceba o seguinte, se você já desenvolveu tudo que as outras funcionalidades precisam de produto, a tela de produto só terá o necessário, nada a mais e nada a menos. Isso ajuda muito para evitar que você fique tendo retrabalho em funcionalidades que já estavam prontas por que precisa atender necessidades de outras funcionalidades.

2) Revisão entre pares

Eu ainda não tive a oportunidade de trabalhar em lugar que adota programação em pares, mas é uma realidade, se você tem uma pessoa te ajudando a desenvolver ou revisando algo que você já tenha feito as chances disso sair com sucesso aumentam, principalmente se a outra pessoa for mais experiente que você.

3) Validação contínua com o cliente

Tem pessoas que simplesmente tem pavor de validar uma funcionalidade com o cliente antes da entrega formal do projeto, por quê? E o se o cliente pedir alguma alteração?

Ivar Jacobson diz o seguinte:

"Todos os sistemas mudam durante o ciclo de vida. Isto deve estar na cabeça quando se desenvolve sistemas que se espera durar mais do que a primeira versão."

Obs.: Estou à procura da fonte onde ele disse essa frase, assim que eu encontrar eu atualizo o post.

Ou seja, a mudança é uma constante em nosso cotidiano podemos estar desenvolvendo novos produtos ou dando manutenção, o negócio é algo que vive evoluindo, a isso é devido a importância de construirmos softwares flexíveis o bastante para acompanhar essas mudanças.

O que eu coloquei acima não é nenhuma novidade, se você conhecer o manifesto agile vai encontrar tudo isso e muito mais lá. Vale apena conhecer as práticas independente se você irá utilizá-las ou não.