Pra mim, essa é uma frase muito arrebatadora. Acho que
essa idéia sempre foi óbvia pra mim, mas nunca tinha parado pra pensar que
acreditar nessa tese pode fazer você drasticamente entender como funciona um
projeto ágil. O artigo do Ralph Johnson me fez chegar a uma definição
simplória, mas no mínimo intrigante, sobre o que realmente podemos chamar de desenvolvimento
ágil de software: A arte de minimizar
tempo e esforço para a conversão de um software da versão corrente para uma
próxima versão, de forma a se aproximar cada vez mais dos desejos de seus usuários.
Pense bem... todas as práticas do XP e de vários
outros métodos convergem de certa forma para essa definição. Vamos examinar as
práticas da primeira edição do XP por exemplo:
Jogo do
Planejamento, Cliente Presente:
Qual é o conjunto mínimo de funcionalidades que eu posso entregar, de modo que
o cliente possa avaliar e se beneficiar de forma efetiva e imediata do trabalho
realizado com a maior freqüência possível? Se descobrirmos algo no meio do
processo, de que forma podemos nos adaptar para que o foco na satisfação do
cliente seja mantido? Essas duas práticas nada mais são do que modos eficientes
de se chegar a uma versão n+1 tendo como meta agregar o máximo de valor para o
software sob o ponto de vista do cliente em um dado momento.
Entregas
Freqüentes, Integração Contínua:
Quantos mais entregas eu fizer, mais próximo estarei de satisfazer as
necessidades de meus usuários. Quanto mais eles começarem a usar o produto,
maior será a nossa sintonia. Se o código não for integrado continuamente, o
momento da entrega será muito penoso e sujeito a erros. Portanto, uma boa
Integração Contínua facilita o processo de entrega freqüente e, portanto,
diminui o trabalho de se fazer a versão n virar n+1.
Metáforas,
Design Simples, Refactoring e Test Driven: Essas práticas te direcionam a uma aplicação fácil de ser manipulada.
Melhor do que isso, te levam a uma aplicação cuja manipulação é muito mais
segura. Te levam a um bom design. Mas o que é um bom design? Não é aquele que
permite melhorar, estender ou alterar a aplicação de forma mais fácil e segura?
Quanto mais fácil é alterar a aplicação, mais fácil será incrementar suas
versões e mais ágil será o projeto, pois a capacidade de se entregar
funcionalidades é muito aprimorada.
Programação
em Pares, Propriedade Coletiva, Padrões de Codificação, Ritmo Sustentável: Essas práticas atuam diretamente sobre a capacidade
de produção dos desenvolvedores. Elas os levam a entender melhor o que estão
fazendo, aumentando a velocidade e a qualidade com que implementam as funcionalidades
da versão n+1.
Em termos gerais, cada ação de uma equipe de
desenvolvimento que atue diretamente no sentido de facilitar, agilizar ou
assegurar a qualidade da transformação do seu software de uma versão n para uma
versão n+1 é um poderoso elemento catalisador para a agilidade de seu projeto. Algumas
práticas de Arquitetura e Gerência de Configuração, apesar de não muito
formalizadas na semântica dos processos, são extremamente importantes no
sentido de complementar o projeto com recursos que ajudam-no consideravelmente
no seu dia-a-dia. Na área de Gerência de Configuração eu citaria: Branching,
automação de deployment, de montagem de ambiente, de execução e construção de
cenários de testes. Também citaria a formalização de arquitetura (incluindo aí
uma arquitetura que facilite algumas práticas como o TDD), padrões de
codificação e regras para análise estática de código.
Compreender o processo de incrementar software, é, no
meu entender, a chave para o amadurecimento e para o sucesso daqueles que querem
conduzir projetos de software vencedores. Cada vez mais técnicas e ferramentas
nos ajudam nessas atividades, cabe a nós saber como balanceá-las de modo a
contribuir para a agilidade dos nossos projetos.