Quando foi redigido, em 2001, o Manifesto para Desenvolvimento Ágil de Software concentrou-se em projetos. Podemos perceber essa tendência nos princípios IV e V do Manifesto: “Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.”
A abordagem é correta, uma vez que aplicativos são desenvolvidos através de projetos. Após seu desenvolvimento, entretanto, eles passam para fases de manutenções continuadas, nas quais os desafios de gestão e a forma de trabalho costumam ser bem diferentes.
Em especial, nota-se uma diferença substancial na etapa de pré-game. Quando é um projeto (um novo software ou módulo), pouco se sabe sobre o produto que será desenvolvido.
Costuma-se, então, realizar uma inception, que é um conjunto de atividades que se realiza no início de um projeto com as finalidades de:
a) descobrir e estabelecer uma visão comum do produto a ser desenvolvido;
b) realizar uma primeira validação de negócio e de tecnologia;
c) entrosar os principais stakeholders envolvidos no projeto.
Salvo o desenvolvimento de um novo módulo ou um esforço semelhante que justifique uma nova inception, durante os ciclos de manutenção espera-se que os desafios de compreender o escopo do produto, validar negócio/tecnologia e entrosar stakeholders já estejam vencidos.
Outra diferença ao se passar de projeto para operação continuada é que, durante seu desenvolvimento, naturalmente ocorre um aumento sobre o conhecimento do produto, reduzindo incertezas e riscos. Consequentemente, alguns processos e controles podem ser simplificados.
Algumas semelhanças, entretanto, se mantêm. Tendo como referências ágeis o Scrum e o Kanban, nas operações continua sendo interessante manter:
- Um backlog do produto com as manutenções evolutivas solicitadas;
- O papel do Product Owner (PO) como gestor do backlog do produto;
- O papel de facilitador do Scrum Master (SM);
- As características de autogestão, de espírito elevado de colaboração e de trocas de conhecimento do Time de Desenvolvimento;
- A posse coletiva de todos itens do Backlog da Sprint, mesmo que tarefas sejam realizadas por membros específicos do Time;
- O quadro kanban para atualização de tarefas, com o devido cuidado de não empurrar, controlando os trabalhos em andamento (WIP);
- O desenvolvimento de incrementos através de ciclos curtos, de uma semana a um mês;
- As reuniões diárias para manter uma boa comunicação e integração do Time;
- As reuniões de retrospectiva ao final de cada ciclo para evolução do aprendizado e da qualidade.
Concluindo, respeitadas semelhanças e diferenças entre projetos (desenvolvimento de produtos) e operações (manutenções corretivas e evolutivas), durante as fases de manutenção podemos simplificar o processo de trabalho.
Preservamos, entretanto, as características importantes de comunicação, colaboração, flexibilidade, integração e qualidade presentes nas características originais dos métodos ágeis.
* Roges Horacio Grandi e Alexandre Horn são professores da Estácio do RS.