Roges Horacio Grandi e Alexandre Horn, professores da Estácio do RS. Foto: Divulgação.

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.