Desenvolvimento Ágil Funciona

Esse é o título da entrevista feita pela InfoExame com o Akita.

Pra quem não sabe, Akita é um cara muito influente no cenário do Desenvolvimento de Software Nacional. Na comunidade Ruby, ele é mundialmente conhecido e muito atuante.

Eu gostei muito da entrevista onde ele defende a adoção das Metodologias Ágeis. Achei que ele foi direto ao ponto desmistificando algumas questões que surgem principalmente de Gerentes, PMO´s e afins com relação às “limitações” das Práticas Ágeis.

Mas se tivesse que criticar algum ponto da entrevista seria o trecho onde ele diz o seguinte:

Aqui tem muitas empresas que desenvolvem para outras empresas, portanto têm pouca liberdade. Lá, elas desenvolvem produtos próprios e é aí que está a diferença.

Na minha opinião essas palavras podem servir como desculpas para os Gerentes não abraçarem a Agilidade, justificando que tais metodologias servem apenas para empresas que produzem produtos próprios e que em ambientes de licitações, terceirizações e “off-shore” seja impossível a adoção de tais metodologias. Algo que eu não considero uma verdade.

Mas eu quero destacar a resposta do Akita aos comentários/dúvidas deixadas pelos internautas, que pra mim, fechou com chave de ouro a entrevista, que pode ser lida aqui.

Espero que cada vez mais empresas e equipes acordem para as Metodologias e principalmente para as Práticas e Valores Ágeis!

Respostas do Akita aos Comentários:

Complementando as dúvidas: - não há nenhuma distinção em termos de projetos "grandes" ou "pequenos". Lembrando que projetos grandes simplesmente são um portfolio de projetos menores que podem ser feitos sequencialmente ou em paralelo por uma ou mais sub-equipes.

Cada uma delas seguindo normalmente me preceitos ágeis. É um mito que ágil só serve para projetos pequenos. - o problema de sistemas grandes que ficaram ruins de dar manutenção não é por falta de documentação e sim por falta de disciplina dos desenvolvedores.

Apenas Scrum não é suficiente, você precisa de técnicas de Extreme Programming e, claro, de desenvolvedores sênior. Uma equipe de desenvolvedores júniors sempre vai fazer sistemas ruins. Você precisa, no mínimo, de uma mistura igual de sêniors e júniors, pareando entre si.

Pair programming é importante, Test Driven Development é essencial, Integração Contínua é vital, etc.

O código precisa ser refatorado constantemente, os testes precisam rodar sempre.

Em se desenvolvendo da forma correta, o código mantém muita da sua flexibilidade em manutenção e inclusive na coesão do seu design sem que se precise fazer Big Design Up Front (BDUF), que é sempre ruim.

Detalhe: é sempre uma má idéia começar fazendo o diagrama de todas as centenas de tabelas que se "acha" que vai precisar. Design incremental, acompanhado de testes, com constante refatoração sempre funciona melhor, independente do tamanho do projeto.

Documentação por burocracia é totalmente desnecessário. Não quer dizer que "qualquer" documentação seja ruim. Veja qualquer projeto open source, no mínimo existe um README que dá uma visão geral do sistema. Em muitos casos só isso já é suficiente. Em outros casos temos Wikis que detalham um pouco mais alguns aspectos mais importantes do projeto.

Agora, documentação de tudo é irrelevante porque, por definição, toda documentação ficará obsoleta e dessincronizada com o código. Isso não é um "talvez", é um axioma.

A única "documentação" realmente efetiva é "Código Limpo", ou seja, código bem testado, bem refatorado.

O próximo programador deve conseguir ver o mínimo de documentação (o README), rodar os testes e saber começar a se inteirar com o código diretamente pelo código.

Manutenção sem testes é suicídio, e isso também é um axioma.