Padrões para Quebrar Estórias de Usuário

4,196 views
4,000 views

Published on

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/

Published in: Business
2 Comments
26 Likes
Statistics
Notes
No Downloads
Views
Total views
4,196
On SlideShare
0
From Embeds
0
Number of Embeds
1,165
Actions
Shares
0
Downloads
0
Comments
2
Likes
26
Embeds 0
No embeds

No notes for slide

Padrões para Quebrar Estórias de Usuário

  1. 1. padrões para quebrar estóriasde usuário @andrefaria André Faria Gomes
  2. 2. http://www.amazon.com/Agile-Software-Requirements-Enterprise-Development/dp/0321635841
  3. 3. 1Passos do Workflow Identifique os passos do fluxo de trabalho e implemente o workflow em estágios incrementaisComo um gerente eu quero alterar o preço de venda- Posso publicar o preço de vendaatravés da vitrine do produto- Posso enviar uma mensagempara o portal do cliente- Posso publicar a tabela de preçospara uma categoria de clientes
  4. 4. 2Regra de NegócioAlgumas estórias parecem muito simples, mas regras de negóciopodem ser mais complexas do que parecem. É importante quebrar asestó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. 5. 3Maior EsforçoUma estória pode ser quebrada em diferentes partesonde o maior esforço estará em implementar a primeiraparte. As vezes, uma estrutura precisa ser construídapara 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. 6. 4 Simples e ComplexoQuando o time está discutindo sobre uma estóriae a estória parece ficar maior e maior (eenquanto a x? Você considerou y?), pare epergunte: “Qual a versão mais simples quefuncionária?” Capture a versão mais simples emuma estória específica, e então quebre asvariações e complexidades em outras estórias.
  7. 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. 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 outrosusuários que moram minha região
  9. 9. 7 Diferir QualidadesMuitas 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 aimplementação inicial que talvez, possaalgum valor para o cliente, então quebre aestória pelos requisitos não-funcionais.
  10. 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. 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. 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 Spikehttp://www.extremeprogramming.org/rules/spike.html
  13. 13. Obrigado @andrefaria http://blog.andrefaria.com http://blog.bluesoft.com.br

×