Se bem se recordam, nos dois posts anteriores abordei o modo como ataquei o problema de ter de realizar um projecto de forma ágil, como eu acredito que é mais produtivo e motivador, num enquadramento mais tradicional, de quatro fases: Concepção, Elaboração, Construção e Transição. Nos outros dois posts abordei as duas primeiras fases, vou agora falar da terceira.

A Construção

A fase de Construção foi aquela em que se tornou mais simples conciliar a agilidade com a formalidade.

Iniciei esta fase com a definição do planeamento detalhado de toda a fase de Construção (+/- 2 meses), o que não é muito ágil... No entanto dividi o planeamento em iterações semanais, tendo por base duas linhas orientadoras:

• As user stories. As tarefas foram definidas em termos de implementar user stories, utilizando sempre a Linguagem Ubíqua e evitando termos técnicos. Por exemplo, não dividimos as tarefas em termos de camadas (UI, Negócio, BD), mas em termos de "Implementar Repositório de Templates", ou "Gerar documentos Word Mono-Conteúdo".
• Obter um aplicação funcional em permanência. No fim de cada iteração, a aplicação teria de ter qualidade para passar a produção se necessário.... e fazer algo de útil.

Estas duas linhas orientadoras permitiram que a aplicação estivesse num estado "controlado", quase em permanência, e permitiu também que a aplicação estivesse "usável" quase desde a primeira iteração. Reparem que estas duas características, pelo menos na minha experiência, são difíceis de conseguir numa aplicação desenvolvida através do modelo tradicional, simplesmente porque estas duas características não fazem parte dos objectivos definidos ao longo do projecto, mas apenas no fim do projecto.

Para além disso, no início de cada iteração, ou seja, semanalmente, tinha uma reunião com o meu chefe, onde analisávamos a iteração anterior e, em função dessa iteração e das anteriores a essa, ajustávamos o planeamento. Neste caso em concreto, a diferença em relação ao normal não é muita. A diferença é que ajustávamos sempre o planeamento tendo como regra dividir as tarefas em iterações de uma semana. Tarefas que não estivessem terminadas numa dada iteração eram partidas em duas, sempre que possível.

Do ponto de vista de gestão do projecto, estas eram as grandes linhas. Por exemplo, no que diz respeito ao relacionamento com o cliente não havia grandes questões porque os clientes eramos nós... Posso afirmar que as duas linhas orientadoras que definimos tiveram uma importância fundamental no controlo (e sucesso) do projecto. É algo que recomendo vivamente, seja qual for (bom, já sabemos que hão-de existir algumas excepções...) o tipo de metodologia utilizada.

No próximo post abordarei a parte mais técnica do projecto, ou seja, a construção propriamente dita.