User stories

839 visualizações

Publicada em

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

Publicada em: Tecnologia
  • Seja o primeiro a comentar

User stories

  1. 1. USER STORIES
  2. 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. 3. UMA BOA HISTÓRIA É:  Independente  Negociável  Valiosa  Estimável  Small (pequena)  Testável  I  N  V  E  S  T
  4. 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. 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. 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. 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. 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. 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. 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. 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. 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. 13. Bruna Gomes brugome@gmail.com Skype: brugome

×