Ser agil é negar analise e design ?
Recentemente li um artigo do Martin Fowler (já tinha lido, mas praticamente o reli com outros olhos) onde ele discute a questão do design e da análise dentro do mundo ágil, mais precisamente o XP (Extreme Programming). No artigo, cujo título é “Is Design Dead?”, Fowler discorre sobre vários tópicos e tenta ver se é realmente um fato que com a adoção de metodologias ágeis, o uso de padrões, análise prévias e design se tornaram práticas mortas
Dentro do times ágeis, existem diversas premissas que devem ser adotadas para que se possa colher todas as vantagens que ele oferece. Algumas das mais famosas são:
- Faça o justo necessário: não faça aquém nem além do que deve ser feito na iteração
- Refatoração : sempre que puder melhore o código
- Foco nas tarefas que agregam valor na visão do cliente
- Fazer o simples e depois evoluir o código de acordo com a necessidade.
Fazer o justo necessário é de focar em gerar valor para o cliente. Aqui a principal mensagem está em evitar tarefas que no final não geram retorno. Exemplo: o tme que gasta horas para criar um modelo de dados; times que gastam considerável soma de tempo para escrever bibliotecas para fazer algo que não esteja ligada a funcionalidade que o cliente deseja naquela iteração (api de log, api de para ler o xml de configuração, api para tratar string, etc). Nesta ideia também se encaixa a questão de evitar tarefas que não agregam valor para o produto.
A Refatoração constante do código significa mais que simplesmente rescrever trechos de código e sim, uma busca constante por simplicidade, qualidade e por programas legíveis. Uma coisa que os mais novos sempre erram é de ter uma visão simplória do que venha ser Refatorar : não é simplesmente acerto de escopo de variável, comentar, etc. Refatorar, em XP principalmente é “alma do negócio”.
Quando se diz – ” Fazer o simples e evoluir“, você está comunicando ao seu time que é desejável que façam coisas simples. A medida da necessidade do projeto, os modelos, arquiteturas, etc., vão evoluindo e ganhando os recursos necessários para resolver os problemas. Dentro da refatoração existirá, também, o espaço necessário para a melhora.
Fazer ou não fazer análise em projetos ágeis ?
Diante do que disse antes, principalmente de evitar atividades que não agreguem valor, os mais puristas, diriam que fazer analise ( estudo, diagramas, etc para entender a arquitetura e quais seriam os requisitos técnicos) é algo que não deve ser feito. Iriam além estes mesmo: afirmaria que tal prática é ultrapassada e que de nada server.
Bom, eu discordo. E se me perguntassem isso, responderia: - “Depende ! “
Se estamos falando de um sistema simples, cujos os requisitos são extremamente claros, fazer analise pode ser um passo a mais que poderia ser retirado. Ou então, considerado como um história de documentação que deve ser tratado no backlog ( mas com baixa prioridade de acordo com a visão do cliente). Porém se estamos falando de sistemas cujo o processo a ser gerido é complicado e/ou com regras de negócios complexas, uma fase, por menos que seja, de análise ajudaria até melhor entender os requisitos. O problema está que muitas equipes de desenvolvimento tornam o resultado de uma analise uma verdade absoluta e imutável. Bem, isso não pode ser verdade pois o cliente vária vezes nem ter certeza do que quer e ao longo das entregas que começa a desenhar melhor sua necessidade e desejo.
Analisar previamente ajuda a diminuir riscos e a nortear, de certo modo, a visão do time na hora de implementar.
Entretanto, ao realizar uma analise, podemos pensar como um rascunho do Niemeyer de um prédio novo. Serve apenas para ter um impressão inicial não muito clara do que iremos realizar.
Quem usa XP não adota padrões? Não define arquitetura?
Esta aí outra coisa que não gosto e nem concordo em ouvir. Bem, os padrões não são ruins, são as pessoas que abusam do direito de usá-los. Já vi gente fazendo um site para 10 pessoas (coisa interna de uma empresa) cujo o escopo é limitado e quase nunca evolui, colocando milhões de camadas, milhares de DAOs, VOs, etc.
Muitos poderiam dizer, principalmente os defensores mais ferrenhos, que devem sempre fazer as coisas simples. Minha resposta : no final, caso faça algo descendente, é bem possível que “esbarre” num padrão.
Outra coisa que não concordo é a questão de não se discutir arquitetura… Para um projeto pequeno, você pode se dar ao luxo de não pensar nisso, pelo menos, num primeiro momento, mas para projetos grandes, tem que pensar nos componentes pois isso influirá diretamente na forma que time irá implementar as coisas. Novamente reforço que, quando sugiro usar padrões, não é pegar o livro e fazer tudo que está dizendo ali. Nada nos impede de adaptar a sugestão para nossa realidade.
Rebeldia e revolução a parte, sempre vou dizer que o melhor caminha continua sendo o do meio. Ficar com o melhor de todos os mundos é o paraíso a ser desejado.