User stories
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

User stories

on

  • 183 views

Dicas para escrever boas histórias no contexto do desenvolvimento ágil de software.

Dicas para escrever boas histórias no contexto do desenvolvimento ágil de software.

Statistics

Views

Total Views
183
Views on SlideShare
183
Embed Views
0

Actions

Likes
1
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

User stories Presentation Transcript

  • 1. USER STORIES
  • 2. USER STORIES  Histórias precisam ser escritas de uma forma que todo o time entenda (negócio, analistas, desenvolvedores, testers)  A escrita de uma história deve envolver diferentes papeis  Colocar em produção deve ser uma decisão de negócio
  • 3. UMA BOA HISTÓRIA É:  Independente  Negociável  Valiosa  Estimável  Small (pequena)  Testável  I  N  V  E  S  T
  • 4. INDEPENDENTE  É muito mais fácil trabalhar com histórias quando elas são independentes  A ideia é sermos capazes de programar e implementar em qualquer ordem  Colocar em produção deve ser uma decisão de negócio
  • 5. NEGOCIÁVEL  Uma boa história é negociável  Não é um contrato explícito de features. Os detalhes são criados pelo cliente e programadores durante o desenvolvimento  Uma boa história captura a essência, não os detalhes  O card pode conter notas, ideias de teste, tudo o que puder ajudar na comunicação
  • 6. VALIOSA  Uma história precisa ter valor para o cliente  O valor deve ser levado em conta na hora de quebrar uma história  As histórias devem ser tratadas como pedaços de bolo
  • 7. ESTIMÁVEL  Uma boa história pode ser estimada  Não precisa ser algo preciso, mas apenas o suficiente para o cliente ordenar e programar a implementação das histórias  Histórias muito grandes são confusas e difíceis de estimar
  • 8. PEQUENA  Boas histórias tendem a ser pequenas  Histórias pequenas são fáceis de entender, de estimar e executar  É mais fácil controlar e alterar o escopo com valor se você tem histórias pequenas  Mas histórias muito pequenas podem gerar dependência e/ou bloqueio. Cuidado com a ordenação na priorização  O maior propósito de dividir coisas em histórias pequenas é conseguir feedback rápido
  • 9. TESTÁVEL  Uma boa história é testável  Testar as features antes da implementação deixa o time mais produtivo  Os testes ajudam a descobrir se o objetivo foi atingido  O time pode tratar requisitos não-funcionais (performance e usabilidade) como coisas que também precisam ser testadas. Descobrir como operacionalizar esses testes pode ajudar o time a aprender sobre necessidades verdadeiras
  • 10. A ORDEM ESTÁ CORRETA?  Independente  Negociável  Valiosa  Estimável  Small (pequena)  Testável  Valiosa  Testável  Small (pequena)  Independente  Negociável  Estimável
  • 11. ELEMENTOS DE UMA HISTÓRIA  O título da história nos ajuda a determinar o “done”  Narrativa: a função é mostrar o benefício da feature  Os títulos dos cenários devem dizer o que é diferente  Dado que [algum contexto] Quando [eu faço alguma coisa] Então [Essa nova coisa acontece]
  • 12. REFERÊNCIAS  BDD in the large http://lizkeogh.com/2012/06/01/bdd-in-the-large/  Your stories are too big http://goodrequirements.com/2012/too-big/  What’s in a Story? http://dannorth.net/whats-in-a-story/  INVEST in Good Stories, and SMART Tasks http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
  • 13. Bruna Gomes brugome@gmail.com Skype: brugome