user stories -

User StoriesUser Stories

Por: Ricardo MouraPor: Ricardo Moura


Clássico Product Backlog

No SCRUM, de acordo com Schwaber e Beedle (2002), os requisitos conhecidos até o momento são listados, dando origem ao Product Backlog.

Estes requisitos são agrupados de acordo com suas prioridades, apresentando as seguintes informações: descrição do requisito; tempo estimado para o desenvolvimento; responsável pelo desenvolvimento.

No XP, a definição preliminar dos requisitos é feita a partir das escritas das User Stories pelos clientes. As User Stories são descrições textuais sucintas a respeito das funcionalidades do sistema (BECK, 2000).

Story

• Funcionalidade no mundo do software, estória no mundo XP/SCRUM;

• O termo em inglês é story (estória – conto) e não history (história – relato de fatos);

• Estórias são equivalentes a requisitos;

• Um produto de software é um conjunto de estórias;

É basicamente uma lista de requisitos, funções que o dono É basicamente uma lista de requisitos, funções que o dono do negócio solicita e que espera que elas sejam entregues, do negócio solicita e que espera que elas sejam entregues, descrita em linguagem coloquial. descrita em linguagem coloquial.


Aspectos Críticos: 3C

As estórias possuem três aspectos críticos, os quais devem ser "obrigatoriamente" lembrados ao serem criadas:

Cards - Estórias devem ser escritas em cartões ou post-its para obrigá-las a serem pequenas;

Conversation - Lembrete para identificar uma funcionalidade que foi conversada e discutida com os stakholders;

Confirmation - O cliente define (implícita ou explicitamente) uma maneira de validar esse pedido.


Exemplos da utilização do 3C

Cards

"Um administrador pode cadastrar um jogo para que os apostadores possam fazer seus palpites de resultado"

ConversationO administrador pode cadastrar o jogo quando quiser? E se ele cadastrar muito em cima? - Ah, eu acho que ele tem que cadastrar com no mínimo 48h de antecedência- Legal... concordo

Confirmation• Um administrador não poderá cadastrar um jogo com menos de 48h de antecedência • O jogo deve pertencer ao campeonato corrente • Um administrador não poderá cadastrar dois jogos envolvendo os mesmos times no mesmo horário


INVEST

Independent : Estórias devem ser independentes uma das outras;

Negotiable : Estórias não são contratos, mas lembretes para discussões;

Valuable : Estórias devem agregar valor para o cliente;

Estimatable : Os desenvolvedores devem ser capazes de estimar o

tamanhos das estórias;

Small : estórias grandes dificultam as estimativas. Bem como estórias

muito pequenas. Quebre ou agrupe dependendo do caso.

Testable : Estórias devem ser possíveis de serem testadas.


Exercício 1

Imagine que você é um construtor de móveis e alguém lhe apresenta o problema exposto na figura abaixo como necessidade para criação de um novo produto.

Escrevas estórias baseadas no que foi apresentado até o momento.


Escrevas estórias baseadas no que foi apresentado até o momento.

http://visaoagil.files.wordpress.com/2009/02/clip-image002.gif

http://visaoagil.files.wordpress.com/2009/02/clip-image002.gif

Como um <PERFIL> eu posso/gostaria/devo <FUNÇÃO> para <VALOR AO NEGÓCIO>

Modelo de descrição


Como um <TOMADOR DE SERVIÇO> eu gostaria de <IMPRIMIR A NOTA FISCAL > para <COMPROVAR O SERVIÇO PRESTADO>

A resposta à esta pergunta é representada pelo <PERFIL>. Analisando de uma outra forma, podemos dizer que representa o “papel” exercido pelo usuário no fluxo do negócio.

Pergunta: Quem deseja imprimir a nota fiscal?Resposta: Tomador de Serviço

Modelo de descrição : Quem?


Respondendo a esta pergunta encontraremos uma das partes mais importantes da estória, que representa o real desejo do dono do negócio: a <FUNÇÃO>. Também para os desenvolvedores, essa é a informação mais valiosa, pois vai determinar o que deve ser feito.

Pergunta: Após a nota fiscal ter sido emitida, o que deseja realizar?Resposta: Imprimir a nota fiscal.

Modelo de descrição : O QUE?


SCRUMSCRUM

Pode não parecer, mas esta é uma das perguntas mais difíceis de ser respondida. Isso porque na maioria das vezes o motivo não é visto como algo muito importante tornando-se uma tarefa árdua mensurar o <VALOR AO NEGÓCIO>.

Pergunta: Por que precisa imprimr a nota fiscal?Resposta: Para comprovar o serviço prestado.

Modelo de descrição : POR QUE?

•Como um <Cliente> eu posso <pesquisar produtos> para <agilizar as minhas compras>;

•Como um <gerente comercial> eu devo <dar opções de pagamento> para <facilitar a compra dos meus clientes>;

•como um <gerente de contas> eu devo <oferecer planos de vendas> para <fidelizar meus clientes>;

•Como um <Cliente de Negócios> eu posso <pesquisar recurso de divulgação de produto> para <aumentar as minhas vendas>;

Exemplos com o modelo de descrição


Exercício 2

Reescreva as estórias que criou no Exercicío 1, aplicando o modelo proposto.


Index Card Informal


Index Card Formal: Frente


Index Card Formal: Verso


Modelo de User Storie proposto pela MCP

Index Card no Centro de Conhecimento


http://conhecimento.mcptecnologia.com/pages/viewpage.action?pageId=4259867






“A história deve ser compreensível para clientes e desenvolvedores, testável, valiosa para o cliente, e suficientemente pequena para que os programadores possam criar meia dúzia em uma iteração.”

Retirado do livro Planning Extreme Programming de Kent Beck e Martin Fowler

Resumindo ...


Perguntas ???


Obrigado!


user stories -

Technology