Ao longo do desenvolvimento de projetos de software, é comum que surjam necessidades técnicas, como a migração de um banco de dados para um novo servidor, mudanças nos testes automatizados, alterações no servidor de aplicação, criação de um serviço para integração contínua, etc. Em geral, a resolução destas necessidades não agrega valor ao produto diretamente. Porém indiretamente podem ter grande influência na qualidade do projeto em desenvolvimento.

 

Sabemos que os requisitos funcionais de um projeto desenvolvido segundo a metodologia Scrum devem estar mapeados em histórias, compondo o Product Backlog, onde cada história agrega algum valor ao produto em desenvolvimento. Mas e as necessidades técnicas? Elas agregam valor ao produto? Devemos criar histórias técnicas no Product Backlog? Como convencer o PO de que as demandas técnicas agregam valor ao produto?

 

É natural que ao longo do desenvolvimento de projetos a equipe de desenvolvimento se depare com necessidades não funcionais, como as descritas no inicio deste texto(ajuste nos teste automatizados, migração de um servidor para outro, criação de um serviço para integração contínua, etc). São requisitos geralmente percebidos pelos membros da equipe de desenvolvimento e cujo valor que agregam ao produto não é reconhecido pelo PO. A dúvida que surge em muitas equipes é: como tratar tais requisitos em um projeto Scrum? Destaco neste post duas maneiras de incluir as necessidades técnicas no backlog de tarefas da Sprint.

 

A primeira abordagem seria acomodar as necessidades técnicas dentro das histórias que já estão no Product Backlog. Por exemplo, suponhamos que uma equipe percebe a necessidade de de ajuste nos testes automatizados de uma tela X. Suponhamos também que já tenhamos no Product Backlog uma história que envolva algum ajuste na mesma tela X. Esta primeira estratégia trata de acomodar a necessidade de ajuste nos testes dentro da história de ajuste na tela. Assim, dentre as tarefas a serem realizadas para concluir a história de ajuste na tela, teremos a tarefa de ajustar o testes automatizados desta tela. Desta forma estamos assumindo que para que a história original esteja pronta é preciso que as necessidades técnicas associadas a ela também tenham sido concluídas. Esta abordagem funciona para os casos em que existe uma ligação forte entre um requisito funcional e um requisito funcional, de forma que os dois estejam relacionados em uma única história. No exemplo acima as duas demandas estão relacionadas pelo fato de se referirem à mesma tela X.

 

A segunda abordagem trata da criação de histórias técnicas no Product Backlog. Neste caso, a necessidade técnica não tem uma relação muito forte com alguma história do Product Backlog. Como exemplo podemos citar a necessidade de ajustes na infra-estrutura de testes automatizados(ao invés de um ajuste em algum teste específico). Esta é uma necessidade que não está fortemente ligada a um recurso funcional do produto, porém, pode agregar valor, uma vez que tendo uma boa infra-estrutura de testes, o sistema poderá ser testado de forma mais eficiente antes de ser entregue, conferindo maior qualidade ao produto. É importante lembrar que, para que o PO aprove estas histórias, a equipe precisa convencê-lo de que a conclusão destas histórias agregarão valor ao produto. Em geral, o PO pode não perceber o valor destas histórias de imediato, por isso é importante que a equipe de desenvolvimento tenha conhecimento e argumentos para fundamentar a criação das histórias técnicas. No exemplo dado acima(o da infra de testes), o argumento utilizado pode ser o de que a quantidade de bugs encontrados no produto poderia ser reduzida caso os testes estivessem sendo executados sobre uma infra-estrutura adequada, pois seriam notados antes mesmo de o incremento do produto ter sido entregue, evitando desperdício de tempo e retrabalho.

 

De maneira geral, o importante é deixar claro para o PO o porque a resolução das necessidades técnicas é importante, independente da abordagem escolhida para lidar com tais necessidades. É preciso mostrar o valor que tais requisitos agregam ao produto, mesmo que indiretamente.

 

E você, já teve dificuldade com demandas técnicas? O PO reconheceu estas demandas? Como foi essa experiência?

Até o próximo post!