É inegável que a adoção das metodologias ágeis traz grandes benefícios para times de desenvolvimento. Esta abordagem de gerenciamento de produtos é focada na comunicação entre o time de desenvolvimento e o cliente, além de facilitar a identificação e a mitigação dos riscos do projeto.

É através desta interação entre o time de desenvolvimento e o cliente que os requisitos do produto a ser desenvolvido é concebido, unindo a visão de negócios do cliente e o conhecimento técnico da equipe.

Este conjunto de requisitos, nas metodologias ágeis, recebe o nome de backlog do produto e representa a visão geral das funcionalidades que determinado sistema deve conter. Cada item do backlog é representado através de uma estória de usuário, que é a visão de um ator (usuário) sobre alguma necessidade que o produto em desenvolvimento irá resolver.

Muito embora uma estória de usuário tenha uma estrutura definida e enxuta, às vezes os times de desenvolvimento têm dificuldade em entender ou estimar o esforço necessário.

Frequentemente estórias de usuário representam uma porção muito grande do produto (um tema) e, por consequência, sua finalização não cabe dentro de uma Sprint. Por conta deste problema, é comum que estórias sejam decompostas em outras a fim de que sejam desenvolvidas em um dado Sprint.

Neste artigo vamos abordar os seguintes pontos:

• Vantagens da decomposição
• Decompondo estórias de usuário S.P.I.D.R
  • Spike
  • Paths (Caminhos)
  • Interfaces
  • Data (Dados)
  • Rules (Regras)
• Empenho e prática são importantes

Vantagens da decomposição

Além do benefício citado acima, de quebrar estórias para que sejam mais facilmente estimadas e que caibam no período de uma Sprint, a decomposição permite que a quantidade adequada de requisitos sejam selecionados para o desenvolvimento.

Ao quebrar um estória, fica mais fácil para o time estimar o seu desenvolvimento. Lembre-se de que os desenvolvedores se comprometem com o escopo selecionado para a Sprint. Sendo assim, o risco de alguma característica de negócio ser esquecida é reduzida.

Quebrar estórias também permite que seu entendimento seja facilitado. Ao lidar com um requisito menor, a compreensão de uma funcionalidade por parte do time é maior e como consequência, o time não precisa parar no meio do processo de desenvolvimento para sanar dúvidas com o cliente.

Outro aspecto importante é que estórias de usuário menores tem um impacto positivo na moral do time, pois são finalizadas mais rapidamente, aumentando o senso de realização, bem como aumentando a motivação através do atingimento dos objetivos.

Decompondo Estórias de Usuário usando S.P.I.D.R

S.P.I.D.R é um acrônimo, do inglês, para Spike, Paths, Interfaces, Data e Rules. Estas cinco técnicas podem ser utilizadas em conjunto, independente da sua ordem, ou então apenas uma delas, dependendo da necessidade.

Spike

Uma atividade de pesquisa com o objetivo de construir conhecimento. Este tipo de atividade é colocada em sprint, normalmente, para avaliar a viabilidade técnica de uma regra de negócio ou então o entendimento de uma API para integração. Essa técnica deve ser utilizada com parcimônia pois pode interferir no desenvolvimento geral de uma sprint.

Paths (Caminhos)

Definir os caminhos (paths) possíveis de uma estória e dividir cada caminho em sua própria estória. Às vezes uma estória torna-se complexa pois ela compreende diversos caminhos aos quais o usuário pode tomar para concluir seu objetivo.

Uma dica bacana é desenhar os caminhos possíveis em um flowchart para que as ramificações fiquem mais evidentes. O objetivo não é quebrar em todos os caminhos possíveis, mas sim decompor a estória ao ponto que ela seja executável em uma iteração.

Exemplo: Dada a estória a seguir, com os critérios de aceite:

Sendo um cliente do e-commerce, eu quero finalizar meu pagamento para que eu receba meu produto.

• Possibilitar o pagamento via cartão de crédito
• Integrar o pagamento com PayPal

A estória acima poderia ser decomposta em duas, da seguinte forma:

• Sendo um cliente do e-commerce, eu quero finalizar meu pagamento via cartão de crédito para que eu receba meu produto; e
• Sendo um cliente do e-commerce, eu quero finalizar meu pagamento via PayPal para que eu receba meu produto.

Do ponto de vista de negócios, certamente uma das duas pode gerar o maior valor e entrar em desenvolvimento o mais cedo o possível.

Interfaces

Decomposição de uma estória através de suas interfaces com o usuário ou interfaces de dados. Um requisito pode definir que a funcionalidade deve ser executada num dispositivo móvel e no desktop.

Como são visões bem diferentes, podem ser divididas em mais de uma estória. Um exemplo de interface de dados pode ser um requisito para exportar um relatório em .csv, .xlsx ou XML. Pode-se criar uma estória para cada tipo de dado exportado.

Data (Dados)

É a decomposição de estórias considerando somente um subconjunto dos dados necessários para sua conclusão. Eventualmente um requisito tem dependência de muitas fontes distintas de dados e considerar todas as opções pode fazer com que uma estória de usuário seja complexa demais para o desenvolvimento.

Neste caso, faz sentido segmentar o desenvolvimento por tipo de dado. Considere a estória a seguir:

• Sendo um estúdio de cinema, eu preciso saber da melhor data de lançamento para o meu filme para que eu tenha a maior receita o possível.

À primeira vista, não parece ser muito complexo, mas considere as entradas para este requisito:

• Tipo de filme – Romance? Talvez seja melhor lançar perto do dia dos namorados. Comédia familiar? Considere lançar perto das férias escolares. Blockbuster? Normalmente lançados no verão (Norte Americano)
• Feriados – O lançamento deve coincidir com algum feriado? Será benéfico ou não?
• Outros filmes – O estúdio certamente não quer competir com um lançamento de filme da Marvel.
• Deve-se esperar? Quanto?
• Deve-se antecipar? Quanto?

Considerando todos os tipos de entrada, o algoritmo certamente será muito complexo para desenvolver, manter e testar. Neste caso, a decomposição por dados seria a abordagem ideal. Talvez a funcionalidade possa não ser tão útil considerando apenas algumas das entradas, mas certamente será mais fácil de medir o progresso, realização de testes e o senso de objetivo alcançado.

Para o caso acima, escreva estórias desta maneira:

Como vimos no exemplo, aplicar a decomposição por dados permite ao time entender melhor cada regra de entrada e desenvolver uma porção do produto que atende a um requisito específico.

Rules (Regras)

Flexibilizar as regras de negócio ou requisitos de tecnologia em uma versão inicial do produto. É comum na indústria que times de produtos desenvolvam protótipos, ou produtos mínimos viáveis (MVPs, do inglês), com o intuito de testar uma nova funcionalidade com seus clientes ou validar a viabilidade de um determinado produto. Como agilidade é um fator importante, alguns aspectos técnicos, ou regra de negócios, podem ser ajustados para que o time cumpra o prazo.

Considere o caso a seguir:

• Uma financeira quer um sistema que exibe gráficos do valor de uma ação de mercado atualizados a cada segundo.

Digamos que, por razões técnicas, o time conclua que atender ao requisito da taxa de atualização do gráfico seja muito complexo, o que deixa a estória de usuário grande demais para uma Sprint. Como para a gerência da financeira o mais importante é a exibição do gráfico, se opta por flexibilizar este requisito. Certamente ele será desenvolvido, mas num momento oportuno.

Empenho e prática são importantes

São muitos os benefícios que a decomposição de estórias de usuário traz para um projeto. Contudo, apesar de simples de entender, quebrar as estórias utilizado as técnicas acima pode ser difícil e vai exigir do time bastante empenho e prática. Mas esse esforço é recompensado pois os benefícios são claros – até aumentando a moral do time.

As técnicas do S.P.I.D.R não são mutuamente exclusivas, ou seja, não é necessário considerar os cinco pontos na mesma estória. Se ao aplicar uma das técnicas, a estória estiver satisfatoriamente decomposta, não é mais necessário continuar. Pule para a próxima estória.

Texto adaptadohttps://www.betteruserstories.com