André Faria apresenta 10 padrões para Quebrar (Dividir) Estórias de Usuários com base no Livro Agile Software Requirements. http://www.amazon.com/Agile-Software-Requirements-Enterprise-Development/dp/0321635841 Mais informações: http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/

1. padrões
para
quebrar
estórias
de usuário
@andrefaria
André Faria Gomes

2. http://www.amazon.com/Agile-Software-Requirements-Enterprise-Development/dp/0321635841

3. 1Passos do Workflow
Identifique os passos do fluxo de
trabalho e implemente o workflow em
estágios incrementais
Como um gerente eu quero alterar
o preço de venda
- Posso publicar o preço de venda
através da vitrine do produto
- Posso enviar uma mensagem
para o portal do cliente
- Posso publicar a tabela de preços
para uma categoria de clientes

4. 2Regra de Negócio
Algumas estórias parecem muito simples, mas regras de negócio
podem ser mais complexas do que parecem. É importante quebrar as
estórias para diminuir a complexidade da regra de negócio.
Como um gerente, eu posso organizar clientes por região
. . . organizar por CEP
. . . organizar por bairro
. . . organizar por consumo de energia elétrica

5. 3Maior Esforço
Uma estória pode ser quebrada em diferentes partes
onde o maior esforço estará em implementar a primeira
parte. As vezes, uma estrutura precisa ser construída
para implementar a primeira estória, isso feito,
adicionar mais funcionalidade depois se torna trivial.
Como um usuário, eu gostaria de selecionar ou alterar meu plano através do portal
. . . Quero pagar por tempo de uso
. . . Quero pagar antecipadamente
. . . Quero fazer parte do clube tudo-incluso

6. 4 Simples e Complexo
Quando o time está discutindo sobre uma estória
e a estória parece ficar maior e maior (e
enquanto a x? Você considerou y?), pare e
pergunte: “Qual a versão mais simples que
funcionária?” Capture a versão mais simples em
uma estória específica, e então quebre as
variações e complexidades em outras estórias.

7. 5 Variações nos Dados
Variações nos dados e fontes de dados são outra fonte de
escopo e complexidade. Considere incluir estórias depois
de construir a versão mais importante.
Como um gerente eu quero enviar mensagens aos clientes:
. . . que optam por receber mensagens
. . . em Inglês
. . . em Espanhol
. . . em Árabe

8. 6 Exibição de Dados
A complexidade pode estar na interface com o usuário ao invés de na
funcionalidade em si. Quebre as estórias para para construir a versão
mais simples possível da UI e então torne-a rica mais tarde.
Como um usuário, eu posso ver meu consumo de energia em diversos gráficos
... em gráficos de barra para comparar o consumo semanal
... em um gráfico comparativo, para comparar meu consumo com outros
usuários que moram minha região

9. 7 Diferir Qualidades
Muitas vezes, a implementação inicial não
é tão difícil, mas fazer a coisa ficar segura,
rápida ou escalar é.
O time pode aprender muito com a
implementação inicial que talvez, possa
algum valor para o cliente, então quebre a
estória pelos requisitos não-funcionais.

10. 8 Operações
Palavras como gerenciar ou
controlar cobrem muitas
operações, que podem se tornar
uma maneira natural de quebrar
estórias.
Como um usuário, posso gerenciar minha conta:
. . . Eu posso criar uma conta nova.
. . . Eu posso editar as configurações da minha conta.
. . . Eu posso cancelar minha conta.
. . . Eu posso acresecentar mais dispositivos a minha conta.

11. 9 Use-Case Scenarios
Se casos de uso forem desenvolvidos para representar uma
iteração complexa entre duas ou mais partes (usuários e
sistemas), então a estória pode ser quebrada por cenário
(Caminho Feliz, Caminho Alternativo, etc).

12. 10Spike
Se a estória for complexa ou
grande demais, ou se a
implementação não
pobremente conhecida, faça
um spike técnico ou funcional
para descobrir e aprender,
então quebre as estórias com
base no resultado do Spike
http://www.extremeprogramming.org/rules/spike.html

13. Obrigado
@andrefaria
http://blog.andrefaria.com
http://blog.bluesoft.com.br