user stories

Post on 29-Jun-2015

227 Views

Category:

Technology

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

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

TRANSCRIPT

USER STORIES

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

UMA BOA HISTÓRIA É:

Independente Negociável Valiosa Estimável Small (pequena) Testável

I N V E S T

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

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

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

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

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

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

A ORDEM ESTÁ CORRETA?

Independente Negociável Valiosa Estimável Small (pequena) Testável

Valiosa Testável Small (pequena) Independente Negociável Estimável

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]

REFERÊNCIAS

BDD in the largehttp://lizkeogh.com/2012/06/01/bdd-in-the-large/

Your stories are too bighttp://goodrequirements.com/2012/too-big/

What’s in a Story?http://dannorth.net/whats-in-a-story/

INVEST in Good Stories, and SMART Taskshttp://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

Bruna Gomesbrugome@gmail.com

Skype: brugome

top related