A beleza das melhorias imperfeitas

Estava lendo o blog do James Shore (para quem não conhece, co-autor do recomendadíssimo The Art of Agile Development) quando li a seguinte pérola de sabedoria:

Greatness emerges from a relentless march of imperfect improvements. A tiny improvement today enables a better improvement tomorrow, which enables even more improvement the next day and the day after that. Before you know it, you have more fun working in your “legacy” codebase than on brand-new code. It’s possible! I’ve seen it.

Isso me fez parar para pensar em diversas atividades que andei fazendo no meu trabalho em um projeto de software livre (será assunto para outro post). Basicamente estou adotando algumas práticas de XP para a minha rotina de desenvolvimento. Tem sido uma experiência bastante agradável, principalmente porque os resultados apareceram rapidamente.

Existem dificuldades também, algumas por falta de experiência anterior com a metodologia mas a principal é comportamental: XP requer disciplina, principalmente ao seguir o máximo possível o timebox definido nas estimativas das histórias. Todas as vezes que lancei mão dessa disciplina porque queria terminar algo de uma vez só resultaram em fracasso retumbante. Atraso é igual a desperdício, pior ainda atraso que não resulte em software que funcione e/ou software que funcione mas não testado!

Voltando a Shore, nos últimos dois meses, estive bastante concentrado na busca por melhorias nos meus ciclos desenvolvimento. O projeto em que estou trabalhando tem uma base de código legada (legado é algo que não fiz, o que imediatamente se traduz a: poutz! – um sentimento profundo e dualista, onde não sabemos onde estamos nem para onde vamos). Qual foi a primeira coisa que fiz? Logo na primeira semana, me lancei a corrigir alguns bugs.

Em duas semanas, já tinha alguma documentação sobre coding standards, ao qual sigo toda vez que altero algum código. Em três semanas, já tinha os primeiros testes unitários (PHPUnit) e funcionais (Selenium) para checar se as correções foram bem sucedidas. Anteontem, atualizei a documentação para contemplar detalhes sugeridos pela FSF ao lançar um software sob GPL e, ontem, comecei a usar um script de build (Phing) para criar pacotes ZIPs e GZips para distribuição do software. Em quase todas as semanas consegui corrigir algum bug (mesmo que muitíssimo pequeno ou simples).

Claro que teve dedicação extra, apoio da gerencia (fundamental) e várias horas de estudo fora do trabalho para estudar soluções em PHP para a execução dessas atividades mas, o grande lab, foi o trabalho diário. Anteontem, fizemos nossa primeira release pública com a correção de um pouco mais de uma dúzia de bugs.

Há ainda um monte de coisa (integração contínua, versionamento do banco de dados, etc, etc) a fazer mas espero que tenha conseguido capturar a mensagem: é melhor ir melhorando aos poucos, de forma imperfeita, do que esperar meses até entregar a perfeição. Do que vale ficar perdendo tempo prevendo coisas (e criando um book de diagramas UMLs que ninguém irá atualizar ou consultar) que o seu cliente não precisa e que não terão utilidade? Adicione valor sempre, em pequenos ciclos de desenvolvimento, entregue valor!