Organizar e priorizar requisitos para Desenvolvimento de Software

Em um ambiente complexo, cheio de contradições, nasce uma excelente oportunidade para adoção de metodologias que possam apoiar ao time de TI na criação de soluções que agreguem valor ao negócio.

No entanto, o maior desafio para os gestores de TI é saber a melhor forma de organizar o desenvolvimento das soluções e priorizar os requisitos que serão entregues nas soluções desenvolvidas e/ou configuradas.

Organizar e priorizar requisitos requer uma boa dose de determinação e paciência. Sem falar no trabalho de lidar com diferentes interesses das áreas de negócio e das equipes de desenvolvimento.

Eis que surge o grande desafio para quem está à frente da área de delivery, é nesta hora que dá vontade de largar a posição de gestor e correr para integrar o corpo técnico..... lamento informar, mas isso não será mais possível, pelo menos na empresa atual!!

Há um tempo, durante uma de minhas pesquisas, deparei-me com uma técnica criada por Jeff Patton que ajuda e muito a vencer esse dilema. Essa técnica é chamada de "User Story Mapping" ou "Mapa de Estórias de Usuários".

Vamos à metodologia:

Antes de prosseguirmos, vale a pena relembrar a definição básica de uma Estória de Usuário:

• Breve descrição da necessidade do cliente;
• Descrição do produto;
• Descrição do comportamento da solução;
• Requisito de alto nível.

Exemplo usando uma estrutura simplificada:

"Como vendedor quero incluir pedidos de venda"

 Exemplos mais elaborados:

"Como [Tipo de usuário, ator] eu quero [ação, tarefa, etc.] para que eu possa [objetivo a ser alcançado]."

"Como vendedor, eu quero incluir pedido para que eu possa aumentar o faturamento."

Outros formatos de estórias de usuários podem ser criados, no entanto, os princípios básicos não podem ser esquecidos:

• Uma ou duas sentenças, no máximo;
• São estimáveis;
• Podem mudar.

Depois de revisarmos o básico sobre estória de usuário, vamos à técnica.

Em primeiro lugar, é necessário trabalhar com a visão do plano cartesiano, ou seja, dois eixos, um para indicar a criticidade e outro para a sequência de uso, características determinantes para organizar as estórias de usuário de modo que facilite a priorização.

Exemplo:

Ufa! como foi difícil desenhar no MS-Word.....

O passo seguinte é escrever as estórias de usuário. Nesta etapa, é fundamental que todos os envolvidos participem pois esta é uma sessão colaborativa. O ideal é usar blocos de postit's e cada um com seu bloco, descrevendo suas estórias e fixando-as no local definido. Vale salientar que o diagrama (x,y) mostrado na figura acima deve estar pregado na parede para que todos possam colocar seus postit's sobre ele.

Um ponto tão importante quanto a entrega da solução é que esta etapa deve ser executada por todos. É importante evitar que apenas um ou outro colaborador seja o responsável por escrever as estórias de usuário, todos devem ser responsável pois essa é uma atividade no formato brainstorming.

Como sugestão, faça uma opção por um formato mais simples para escrever as "user story". Utilize verbos no infinitivo para facilitar: Incluir pedido. O foco é pensar no que as pessoas fazem e não no que o sistema deve fazer!

A próxima etapa é determinar, para cada estória de usuário, quem será o ator responsável por sua execução. No exemplo acima, o responsável por incluir pedidos é o Vendedor. Logo, o postit alterado passa a ficar assim:

Na sequência, é necessário determinar a frequência em que a estória de usuário irá ocorrer. Agora é o momento de visualizar as estórias de usuário como uma funcionalidade do sistema (requisito funcional). O objetivo é determinar de quanto em quanto tempo aquela funcionalidade será executada. 

Esse tempo é fundamental para atribuir um peso à estória de usuário. Quanto maior a frequência de uso, maior será o peso atribuído. Exemplo e sugestão de uma tabela de peso conforme frequência de uso da estória de usuário:

• a cada hora: peso 5;
• diariamente: peso 4;
• semanalmente: peso 3;
• mensalmente: peso 2;
• trimestralmente: peso 1.

Avalie as frequência e estabeleça a faixa de valor que melhor convier com o que está sendo desenvolvido.

Depois disso, o product owner deve atribuir um valor para cada estória de usuário. Esse valor deve ser condizente com a importância daquela estória de usuário para o negócio, o quão ela é importante, o quanto ela agrega valor ao negócio. Em outras palavras, ele estará dizendo o quanto cada estória de usuário é importante para ele.

Semelhante modo à frequência, devemos atribuir um peso para cada classificação de valor atribuída pelo product owner. Sugiro que uma tabela simples e objetiva seja adotada. Exemplo:

• Alto: peso 3;
• Médio: peso 2;
• Baixo: peso 1.

Após essas classificações, calcule a pontuação de cada estória de usuário conforme pesos estabelecidos pela frequência e pelo valor, somando os pesos e definindo a pontuação: pontuação = frequência + ocorrência. 

A priorização será realizada com base nessa pontuação.

Nessa próxima etapa, é necessário ordenar as estórias de usuário em ordem cronológica de execução. Lembre-se que estamos imaginando o processo de negócio sendo executado e portanto, a ordem aqui deve ser coerente com a ordem de execução do processo de negócio, como se fosse uma história sendo contada. Exemplo:

Primeiro o usuário faz o cadastro, depois ele inclui pedidos, na sequência emite a fatura, depois a expedição separa, ..... 

Organize na horizontal (lado a lado) as estórias de usuário nessa sequência ordenada conforme acima. Pode ser que neste momento novas estórias de usuário sejam descobertas, normal isso, e este é um dos pontos fortes dessa ferramenta de trabalho, onde gaps são identificados e resolvidos antes mesmo de iniciar os trabalhos de desenvolvimento.

De posse da ordenação e da pontuação estabelecida nas etapas anteriores, priorize as estórias de usuário de forma objetiva (aqui saímos da subjetividade). Agora as estórias de usuário são organizadas de cima para baixo (vertical) conforme prioridade determinada pela pontuação. Organize as de maior criticidade (maior pontuação) de cima para baixo, porém, procure sempre manter a ordem cronológica definida na horizontal.

Agora, é necessário determinar as quebras de fluxo na execução dos processos que fora mapeado em estórias de usuários em segmentos de negócio ou grupos lógicos estabelecidos. Essas quebras estão diretamente ligadas às unidades de negócio que são responsável pela execução de cada estória de usuário e são elas que serão afetadas na medida em que as funcionalidades vão sendo entregues.

Uma visão interessante é que essas quebras ajudam ao time de desenvolvimento a determinar o momento certo de liberar uma release para ser testada. Para tanto, identifique as quebras de fluxo traçando linhas verticais, identificando cada etapa ao topo:

Por último, a técnica orienta que agora é a hora de determinar as releases, traçando linhas horizontais que agrupem blocos de estórias de usuários. A figura abaixo demonstra como fica a distribuição das estórias de usuários em releases, sendo como base para o planejamento do trabalho e entrega do time de desenvolvimento.

 Note que ao empregar essa técnica, temos alguns entregáveis determinantes para a realização do projeto de desenvolvimento de uma solução: visão geral da solução, funcionalidades, tipos de atores, prioridade dos itens a serem entregues, definição das releases e a participação e cooperação de todos os envolvidos no processo, tanto do time de negócios quanto do time de desenvolvimento.

O mais importante é que o negócio determina o que deve ser feito primeiro, o que deve ser deixado para depois, evitando problemas de alinhamento da TI com o negócio.

O mapa elaborado, quando concluído, trará a todos uma visão da cadeia de valor, possibilitando ainda que sejam estabelecidos relacionamentos entre as estórias de usuário. Possibilita também a identificação e o tratamento de gaps, fornecendo mecanismos para priorização objetiva do que será entregue.

Esta técnica é simples mas se aplicada, trará um grande ganho para o time de desenvolvimento e principalmente para o cliente. O fato de eliminar a subjetividade em todas as etapas do levantamento e priorização dos requisitos, já traz um ganho intangível para o product owner e o time de desenvolvimento.

Enfim, a intenção é que esta ferramenta possa ajudar e apoiar times de desenvolvimento e entrega de soluções e que seus benefícios sejam perceptíveis para quem a adotar.

Vale lembrar que a visão do diagrama montado aqui não é definir as fases do desenvolvimento em que um estória de usuário se encontra mas sim o relacionamento delas com o negócio. Portanto, não é observado neste diagrama etapas do tipo "a fazer", "em teste", "impedimento", etc,.

Obrigado pela atenção e bom trabalho!