Lidando com o fim de um projeto
É inevitável que um projeto chegue ao fim, na verdade, se pensarmos na teoria, todo projeto deve começar com o seu escopo bem definido e isso inclui uma data de entrega. O pessoal que trabalha com ágil pode dizer “mas nós trabalhamos com ciclos interativos e é o cliente quem define as prioridades”, sim, é verdade, mas todo cliente quer uma data de quando o projeto será entregue. Até mesmo, porque o cliente tem seu planejamento e seu orçamento e tudo isso gira em torno do tempo de execução do projeto.
No final do projeto, é normal que a equipe começe a ter ciclos de ociosidade, justamente porque novas features não serão adicionadas, bugs críticos já foram corrigidos e o projeto já está estável o suficiente para ir para produção. Só que essa ociosidade da equipe, pode trazer danos irreverssíveis, como: insatisfação, desinteresse, frear o ritmo da equipe, esquecimento de pontos específicos do projeto, etc.
Imagino que nenhuma equipe queira passar pelos problemas expostos acima, por isso o final do projeto deve ser enxergado como uma oportunidade de melhorar o que já existe, de mudar alguma tecnologia que esteja “desatualizada”, de documentar o que for necessário e de refletir sobre erros e acertos. Uma estratégia que tenho usado e que tem me ajudado muito nesses momentos, é de criar uma espécie backlog de tudo que pode ser melhorado no projeto, mas que não é crítico em determinado momento, depois, conforme for sobrando tempo, vou priorizando esse backlog e executando com a equipe as melhorias pontualmente.
Atualmente estou em um projeto, que devido ao escopo ser muito apertado, eu e minha equipe tivemos que abrir mão de qualidade para podermos entregar o projeto no tempo estimado. Isso, como pode-se imaginar, gerou alguns códigos difíceis de manter. Minha equipe também era um pouco imatura no início do projeto e isso também impactou diretamente na qualidade do código. Para piorar, muitas regras de negócio foram sendo definidas em runtime pelo cliente e é claro que isso também impactou na qualidade do projeto. Como o projeto está de certa forma estabilizado, o momento para pensar em melhorias e algumas mudanças é agora e isso passa a ser a arma do líder de projeto para manter sua equipe motivada, ocupada e no seu ritmo. Sem contar o fato de que as melhorias, tirarão das costas própria equipe o trabalho árduo de manutenção no futuro (o que poderia também desmotivar a equipe).
Vale ressaltar, que nesse momento do projeto, o líder deve ter todo cuidado para que essas melhorias feitas através de técnicas de refatoração não impactem o funcionamento do projeto, afinal a definição mais simplista de refatoração é: melhorar algo que já existe, mas mantendo o seu comportamento original.
Além disso, o líder sempre deve contar com a possibilidade do cliente solicitar alguma mudança ou resolução de algum bug durante esse processo de melhoria, e para não ser pego de surpresa, o que eu indico é que o processo de melhoria seja feito paralelamente a última versão de código do projeto entregue ao cliente. Como fazer isso? Usando o famoso trunk (última versão entregue ao cliente) e branch (versão gerada a partir do trunk e onde será feita o processo de melhoria). Depois, todo cuidado é pouco durante o merge dessas alterações e é nesse momento, onde os testes, que inicialmente foram esquecidos, irão ajudar muito!
O principal objetivo do desenvolvimento orientado a testes (TDD) é direcionar o design do código para que o mesmo fique claro e legível o suficiente para suportar manutenções e ser escalável, mas outro ponto do TDD, é que os testes sejam uma maneira de fornecer segurança aos programadores para realização de melhorias (refatorações), por isso, se você teve que abrir mão de testes no começo do projeto, não deixe de pensar neles no final, mesmo que isso não seja o mais indicado e que o ciclo do TDD não indique isso, mas como já sabemos, na teoria as coisas são de um jeito, na prática elas são de outra.
Seguem algumas dicas de tarefas que podem ser executadas/pensadas na fase de término do projeto:
- Testes unitários
- Testes de interface/aceitação
- Testes integrados
- Programação em par (o uso em processos de refatoração é muito válido e tem um resultado muito positivo)
- Padronização do código
- Documentação do código
- Estudo de novas tecnologias/frameworks/linguagens (para os próximos projetos ou até mesmo projeto atual)
- Melhoria de performance de algum ponto da aplicação que possivelmente possa ser um gargalo no futuro
- Troca de opiniões entre a equipe para melhoria do processo de desenvolvimento
- Reuniões para discussão de erros e acertos do projeto
Para finalizar, gostaria de ressaltar que essas são observações baseadas na minha própria experiência como líder de projeto e que não tem relação direta com nenhuma metodologia, na verdade são pontos relevantes e que certamente muitos tem como referência pontos específicos de diversas metodologias.
Se você gostou desse tópico, por favor considere deixar um comentário ou se inscreva no feed e tenha no futuro todos os tópicos entregues diretamente no seu agregador.
Perfeito! Sem os testes na hora da refatoração provavelmente os programadores seriam mais resistentes com medo de quebrar o que está funcionando. Muito bom post! Sempre aprendo por aqui!
Realmente, o que normalmente acontece é que o tempo ocioso nessa faze do projeto é desperdiçado na internet, ou com outras tarefas menos importantes.
Entender o que foi feito e propor uma melhoria além de manter a equipe ocupada, da uma sensação de dever cumprido.
Ótimo post.