Métodos Ágeis - Mais Mitos /ou: Doce utopia?

Posted: 17 de jan de 2008 | . David Lojudice Sobrinho | tags: ,

Estava lendo Some value statements beyond Agile Manifesto. O post traz algumas declarações dos métodos ágeis com um rápido aprofundamento.

Vou reproduzir cada declaração (ver definição no próprio post) e colocar meu ponto de vista sobre o assunto. No final, coloco minha opinião sobre o movimento.

Self Organizing Team over Control & Command Team.
A metodologia ágil, como movimento que nega os movimentos anteriores, tem a tendência de querer quebrar antigos valores. O que é historicamente normal.

Infelizmente, querer ter uma equipe descentralizada, sem "chefe" tem algumas falhas.

Primeiro que aquele "chefe" que tem a palavra final, que não é aberto a idéias dos subordinados, não ouve e só manda, não existe mais. Se seu chefe é aquele que te atrapalha ao invés de viabilizar seu trabalho, mude de emprego.

Depois, dificilmente uma equipe descentralizada vai ser aceita dentro da organização. Simplesmente porque o chefe do chefe quer ouvir uma só pessoa e essa pessoa é o canal de comunicação e decisão. Ou seja, um responsável ainda é necessário. Alguém tem que falar "sim" ou "não" e ser responsável por isso.

No extremo, acho que equipes descentralizadas devem funcionar em poucas empresas, provavelmente pequenas, mas não vai funcionar na maioria.

Cuidado. Utopia faz parte dos movimentos revolucionários. Todos tem um pouco dessa doce ingenuidade. Mas não arrisque seu emprego por eles.

Agile done over just done.
É isso. Feature pronta é feature pronta. Crie sua definição do que é "feature pronta" e seja feliz. Do post do Michael Nygard, criei meu checklist:

1. All unit tests are green.
2. The code is as simple as it can be.
3. It communicates clearly.
4. It compiles in the automated build from a clean checkout.
5. The customer has accepted the feature.

Enough Design over big up-front design.
Finalmente, como movimento que nega o movimento anterior, a metodologia ágil acerta aqui. Com seus curtos ciclos de desenvolvimento e ferramentas para garantir a qualidade nesses ciclos(Continuous Integration, xUnit, etc.), é possível ter pequenas alterações em produção em tempos nunca imaginados nos tempos do modelo em cascata ou mesmo nos mais recentes, como no RUP.

Mas aqui cuidado novamente. Alguns mais radicais irão dizer que qualquer tipo de especificação documentada, seja do cliente ou de um arquiteto, nem que seja um Use Case, já é BDUF (Big Up-Front Design). Como radicalismo esta longe da minha pessoa, eu acredito no seguinte: se seu código sozinho não conseguir expressar a sua funcionalidade de modo intuitivo, não tenha vergonha em produzir documentos ou diagramas. O importante é a "comunicação" da intenção do código.

Code Reuse over cut and paste.
Eu gosto da idéia de reutilização e tento sempre que possível não duplicar código. Mas para quem já tem alguns anos de estrada, sabe que nem sempre isso é possivel. Tentar levar essa regra ao limite pode quebrar sua aplicação.

Pair programming over code review
Esse é um ponto complicado. Eu, hoje, acho que o code review seja suficiente. Dependendo do contexto (código com baixa complexidade, por exemplo), acho que duas pessoas no mesmo computador seja um desperdício. Mas estou aberto a tentar um dia e descobrir que estava errado.

Stand up Meetings over status meetings
Concordo com o princípio. Porém acho que deva ocorrer usando ou não metodologia ágil.

Tenha membros seniors
Tem uma declaração implícita que é pouco "divulgada": Tenha membros seniors.
Como você pode ter equipe descentralizada, membros negociando e tomando decisões diretamente com os clientes, codificação descentralizada, refatoração a qualquer momento do desenvolvimento, etc., sem que todos eles sejam ótimos programadores-arquitetos? Qualquer outro tipo de programador iria ficar mais perdido que peixe fora d'agua.

Minha opinião sobre tudo isso é: Métodos Ágeis trás a luz verdadeiras preciosidades, princípios que condiz com a natureza do software. Mas também trás outros princípios que não se encaixa a todos ou são simplesmente utópicos.

No caso de não se encaixar, adapte-se. Não é necessário levar ao pé da letra o que lemos nos livros. Use sua inteligência, experiência e intuição e pegue o que for necessário para você. Continuous Integration, não foi criada no XP e já trazia resultados. Test Case não foi criado no XP e já trazia resultados. Ou seja, partes isoladas podem trazer resultados sem ter que aplicar tudo "by the book".

0 comentários: