Definição Ágil de User Stories – Toda história deve ter um início feliz

Toda história deseja um final feliz e no caso do processo de criação de um software não é diferente.

por Daniel Semedo

Era uma vez a história de uma equipe de desenvolvimento de softwares que sempre entregava projetos conforme a solicitação do cliente. Todas as funcionalidades requisitadas encontravam-se disponíveis, não ocorriam mudanças no backlog e muito menos barreiras ou dificuldades ao longo de cada sprint. Todos os projetos eram planejados e executados primorosamente. E assim continuou para todo o sempre.

Toda história deseja um final feliz e no caso do processo de criação de um software não é diferente. Desenvolvemos sistemas exclusivamente para resolver problemas de nossos clientes e deixá-los satisfeitos: esse é o final feliz que todo projeto de software almeja. Entretanto, para obtermos o final feliz, devemos perseguir esse objetivo desde o início, criando user stories consistentes e cada vez mais tangíveis ao olhar do nosso cliente, aumentando a qualidade e a confiabilidade de cada user story que compreende o backlog (repositório de user stories) que garantem a entrega de funcionalidades corretas ao final de cada sprint.

Na criação do backlog - que consiste basicamente em inserir requisitos de diferentes tipos que o sistema deverá ter para cumprir um objetivo específico - devemos extrair de nosso cliente informações importantes para a concretização do projeto. Podemos trabalhar com a criação de cenários de uso da aplicação, detalhando passo a passo cada funcionalidade que estará presente no sistema e, assim, relacionar o detalhamento de um cenário a user stories que estejam dentro do contexto especificado nesse cenário.

Realizado o desenho do "esqueleto" do sistema no momento da criação do backlog será mais fácil priorizar quais user stories serão trabalhadas em cada sprint e ajudar a criação do protótipo. É importante que a prototipação das telas seja realizada logo no início do sprint, para que a validação funcional da aplicação seja feita pelo o Product Owner e as respectivas mudanças encontradas sejam repassadas o quanto antes para a equipe de desenvolvimento, evitando que se entregue funcionalidades que não atendam às necessidades do cliente ou que as próprias user stories tenham que voltar para o backlog, para serem retrabalhadas em um próximo sprint.

Vale lembrar que 82% do custo envolvido em retrabalho surge devido a má definição de requisitos e 56% dos projetos entregues e considerados falhos são ocasionados por problemas nesta etapa do desenvolvimento, segundo pesquisa de James Martin. Por isso, devemos nos preocupar constantemente com a forma como os sistemas são requisitados, uma vez que quanto mais detalhada e tangível a requisição for, melhor será o entendimento pelas outras partes do projeto.

Utilizando estas práticas de engenharia de requisitos, mantemos as user stories bastante simples e alinhadas ao negócio, melhorando a especificação do que deve ser feito e, consequentemente, aumentando a velocidade e a confiança da equipe sobre o que está sendo desenvolvido. Outro ponto a ressaltar é que o Scrum não prega como obrigação seguir a User Story: ela é bastante utilizada devido à facilidade neurolinguística de capturar necessidades e comprovar a sua real utilidade. Devemos observar que ao melhorar a execução com técnicas de engenharia de software e ferramentas não transformamos o método SCRUM em SCRUMBUT.

O início feliz da user story está dado. O restante da história caberá a você decidir. Pense em prosseguir traçando os passos seguintes com cautela, verificando se o que você faz hoje consegue ser lean e deste modo a entrega de seus projetos de software estará mais perto de um final feliz.