1

2 Histórias de Usuário

HISTÓRIAS DE USUÁRIO E
PLANEJAMENTO
Karin Becker
Instituto de Informática - UFRGS

A premissa A premissa
3 4

Requisitos de software são um problema de
Se um dos lados dominar a comunicação, o

comunicação resultado fica comprometido

Quem vai usar

Quem vai construir

Os requisitos estão na cabeça de muitos

Trabalhar juntos para que a comunicação flua e

seja equilibrada
 História de Usuário O que são “Usuários”?
5 6

Uma funcionalidade útil da perspectiva de um
Escrever a história da perspectiva do usuário

usuário ou cliente
Diferentes usuários, diferentes objetivos
BigMoneyJobs website
Como um usuário,
Não refletir sobre os diferentes usuários pode levar
Como um usuário, desejo restringir
desejo acesso ao meu
à perda de histórias importantes e problemas de
Como um usuário,
disponibilizar meu currículo desejo ofertar compreensão Como empresa,
currículo empregos desejo divulgar
Como um usuário, Como profissional, Como profissional, ofertas de
Como um usuário, desejo encontrar desejo manter meu desejo restringir
Como um usuário, empregos
desejo manter meu vagas currículo atualizado acesso ao meu
desejo visualizar Como profissional, currículo
currículo atualizado
currículos desejo
Como um Como consultor de RH,
disponibilizar meu
profissional, desejo desejo visualizar
currículo
encontrar vagas currículos de candidatos
Todos exemplos do BigMoneyJobs usados nestes slides são extraídos (com adaptação ou não) do
livro User Stories Applied, Mike Cohn, Addision Wesley.

Papéis Histórias devem ser CCC

7 8

Ampliar a perspectiva sobre o que é o usuário

O que eles farão com o software

Como eles usam o software

Conhecimento pré-existente

Familiaridade com o software/computador

“Persona”

Mudança de paradigma

Usuárioé alguém/algo tangível

Software resolve um problema concreto de alguém
 CCC CCC
9 10

“Cartões representam requisitos, ao invés de
Conversa Como um

profissional, desejo
documentá-los” (R. Davies)
Obter detalhes da história procurar por vagas

Cartão
Pode resultar em mais histórias

Curto
Anotar detalhes se quiser, mas não é um contrato

Prioridade Quais critérios Tem que tem

podem ser usados que pagar?

Estimativa
em uma busca?

Anotações Como visualizar
o resultado?

Adaptável Quais
Tem que ser um
Como um profissional, desejo informações
membro do site?
procurar por vagas mostrar?
Deve-se salvar Acho que está
a busca? meio complexo:
é um episódio !!

CCC CCC
11 12

Confirmação
Confirmação

Decisões importantes não são escritas (para serem não

Capturar as expectativas (testes de aceitação)
lidas)

Lembretes sobre o que deve ser testado

Decisões importantes são testadas (automaticamente)

O suficiente para lembrar o que deve ser testado Verso
Testar se profissional está logado no site
Frente Testar se profissional não excedeu buscas de
acordo com sua categoria
Como um Testar busca por localização (pais/cidade),
profissional, desejo faixa salarial e função
procurar por vagas Testar que mostra lista de vagas (nome da
empresa, função, faixa salarial)
Testar que lista de vagas pode ser ordenada
por empresa, função ou faixa salarial
Testar que mostra detalhes de vaga (bla,
bla, bla)
 O “Cliente” Identificando histórias
13 14

Will Extreme Programming
“Eliciação e captura (de requisitos) deveriam ser

kill your customer?* ilícitos” (Mike Cohn)

Cliente = Time do Cliente
Requisitos estão prontos, basta fazermos as

“Comprometido” perguntas certas
representante do negócio
(gerente de produto, dono do
Metáfora do Arrastão (trawling)
produto, etc)

Malhas de diferentes tamanhos
 Usuários, especialistas,
representantes de partes
Tempo de vida
interessadas

Múltiplas passadas

Analistas, testadores e Q&A,
projetistas de interface
Pescadores experientes

* www.coldewey.com/publikationen/conferences/oopsla2001/agileWorkshop/hendrickson.html

Técnicas de Identificação Técnicas de Identificação

15 16

Entrevista
Workshops

Popular
Planejamento inicial (visão de produto, visão de

Escolha bem quem entrevistar
release)

Desejo vs necessidade

Combina brainstorming com prototipação básica

Perguntas abertas e livres que contexto
 Muitashistórias (priorização e detalhamento depois)

Questionário  Storyboards

Ótima para priorizar  Personas

Menos eficiente para identificar requisitos  Cenários de uso

Difícil investigar os detalhes  Walkthrough para identificação de histórias

Observação  Key players

Palavras tomam outro sentido  Ênfase é quantidade, e não qualidade
 Escrevendo Histórias Escrevendo Histórias
17 18

Proposta Mike Cohn
Como usuário, desejo poder fazer cálculos

matemáticos básicos

Com um papel claro

Como declarante de imposto de renda, desejo poder
fazer cálculos matemáticos básicos

Com razão clara (valor agregado)

Como declarante de imposto de renda, desejo poder
fazer cálculos matemáticos básicos para sumarizar
itens para os quais são declaradas apenas totalizações

Granularidade das Histórias Granularidade das Histórias

19 20
 Épico Propriedades das Histórias
21 22

Como headhunter,
Independente

desejo saber tempo

Negociável
médio de colocação
em empresas
Como headhunter,
desejo extrair relatórios
Como headhunter,
Valor
sobre preenchimento de
desejo saber as

Estimável
vagas
vagas preenchidas
por período de

Small (pequena)
tempo

Testável
Como um headhunter,
desejo análise das
receitas obtidas por
colocações

Bill Wake. Extreme programming explored.

Propriedades : Independente Propriedades: Negociável

23 24

Evitar sempre que possível introduzir dependências

entre histórias

Dificuldades com priorização e estimativas

Exemplo

Como comprador, desejo pode pagar com Visa

Como comprador, desejo pode pagar com Master
Como comprador, desejo poder pagar com um tipo de cartão de
crédito
Como comprador, desejo quero ter duas opções de pagamento por
cartão de crédito

Histórias não são contratos de requisitos
implementáveis

Detalhes são negociados durante a conversa

Desafio: quanto detalhe incluir?

Uma ou duas frases para lembrar sobre o que
conversar

Notas sobre questões a serem resolvidas durante a
conversa

Todo detalhe acertado torna-se teste de aceitação
 Propriedades: Negociável Propriedades: Negociável
25 26

Frente

Verso

Propriedades : Estimável Propriedades : Pequena

27 28

Tamanho da história
Dividir histórias muito grandes

Mais ou menos certeza

episódios

Quando não é possível estimar

Falta de conhecimento do domínio
história composta
 Conversar para ter um entendimento superficial
história complexa

Falta de conhecimento técnico
 Spike

Combinar histórias muito pequenas
 Aprender o suficiente para poder estimar
 A história do spike, e a história real

Muito grande
 Episódio
 Placeholder para um requisito tomando forma e que deve ser
discutido (quando o tempo certo chegar)
 Propriedades : Pequena Propriedades : Pequena
29 30

História composta
História complexa

Como profissional, desejo postar meu currículo Como cliente, desejo pagar minha anuidade com cartão de crédito

Abordagens comuns
Abordagem comum : Investigar

Decomposição CRUD Decomposição orientada a dados
Como desenvolvedor, desejo investigar o processsamento de
Como profissional desejo Como profissional desejo pagamento CC na web Spike
• adicionar curriculo (formação, experiência, • adicionar e editar formação
salario, etc) • adicionar e editar experiëncia
• modificar curriculo existente • adicionar e modificar salário Como cliente, desejo pagar minha anuidade com cartão de crédito
• ter múltiplos curriculos disponíveis • ter múltiplos curriculos disponíveis
• etc • etc

Propriedades : Testável
31

Passar em testes de aceitação prova que a história

foi implementada corretamente
32 Troca de paradigma e vantagens

Desenvolvimento incremental

Regressão

Poucos são os testes que não podem ser automatizados

 Histórias : Por quê? Histórias : Por quê?
33 34

Histórias mudam o foco de escrever para conversar
A dificuldade da escrita

Construir o que se pediu, mas não o que era necessário
Avisos paraquiais

Escritos de boa fé, mas ….

“Na sexta feira às sete, os meninos do Oratório farão
uma representação da obra “Hamlet” de Shakespeare,
no salão da igreja. Toda a comunidade está convidada
para tomar parte nesta tragédia.”

“Prezadas senhoras, não esqueçam a próxima venda
para beneficência. É uma boa ocasião para se livrar das
coisas inúteis que há na sua casa. Tragam os seus
maridos!”

Histórias : Por quê?

35

Histórias permitem balancear a comunicação entre

negócio e desenvolvimento
36 Histórias vs. Casos de Uso

Histórias são a base do desenvolvimento iterativo
(incremental, e ágil)

Histórias facilitam o planejamento

Histórias encorajam a concepção compartilhada de
um produto
 Histórias vs. Casos de Uso Histórias vs. Casos de Uso
37 38

Ivar Jacobson

Tornou-se popular com UML e o Processo Unificado

Identificar e representar o comportamento pretendido
do sistema em desenvolvimento, sem a preocupação de
especificar como este comportamento é implementado

Quais são as necessidades do usuário?

Como o usuário e o sistema interagem para atender estas
Como empresa,
necessidades?
desejo divulgar

Quem/quais são as partes envolvidas nesta interação? Como profissional,
Como profissional, ofertas de
desejo manter meu

Descreve o que o sistema faz, não como faz currículo atualizado desejo candidatar- empregos
me a vagas

Requisitos funcionais Como profissional,
Como um Como consultor de RH,

Deriva a busca e definição de requisitos não funcionais desejo
profissional, desejo visualizar
disponibilizar meu
desejo encontrar currículos de candidatos
currículo
vagas

Casos de Uso Casos de Uso

39 40

descreve uma interação típica entre usuário(s) e sistema As a recruiter, I’d

uma função perceptível do ponto de vista externo

um objetivo a ser atingido com o sistema

uma seqüência de ações - incluindo suas variantes - que o sistema/ator
devem executar com o objetivo de produzir como resultado algo que
atenda as necessidades de um ou mais atores (usuário)

“Um CASO DE USO é um documento TEXTUAL. O mais importante
neste trabalho é ESCREVER TEXTO que detalha cada caso de uso”
(Craig Larmann)

Preliminar

Essencial

Concreto

Informal vs Templates
like to pay for a
Use Case Title: Pay for a job posting job posting with
Primary Actor: Recruiter
Precondition: The job information has been entered but is not viewable. credit card
Success Guarantees: Job is posted; recruiter's credit card is changed.
Main Success Scenario
1. Recruiter submits credit card number, date, and authentication information.
2. System validates credit card.
3. System charges credit card full amount.
4. Job posting is made viewable to job seekers.
5. Recruiter is given a unique confirmation number.
Extensions
2a: The card is not a type accepted by the system.
2a1: The system notifies the user to use a different card.
2b: The card is expired.
2b1: The system notifies the user to use a different card.
2c: The card is invalid.
2c1: The system notifies the user to use a different card.
3a: The card has insufficient credit available to post the ad.
3a1: The system charges as much as it can to the current card.
3a2: The user is told about the problem and asked to enter a second credit card for the remaining charge.
The use case continues at Step 2.

http://www.mountaingoatsoftware.com/articles/advantages-of-user-stories-for-requirements
 Histórias vs. Casos de Uso Histórias vs Casos de Uso
41 42

Ambas

São instrumentos de identificação e “expressão” (ainda que temporária) de requisitos

Guiam o desenvolvimento

Principais diferenças

Escopo
 Ambas são focadas em valor ao negócio
 Caso de Uso: Uma função completa da perspectiva do usuário
 História: Uma breve descrição de funcionalidade, tal como percebida por um usuário, priorizada e estimada
 Um caso de uso pode compreender muitas histórias

Nível de completude
 Requisitos
 Critérios de aceitação

Propósito
 Histórias são usadas para planejar, e são usadas como lembretes de conversas nas quais detalhes
devem ser obtidos
 Casos de uso documentam um acordo contre cliente e tiome de desenvolvimento

Longevidade
 Casos de uso permanecem ao longo da vida de um produto
 Histórias só existem em backlogs de coisas a fazer ou em desenvolvimento

http://tynerblain.com/blog/2009/02/02/user-stories-and-use-cases/

Conclusões
44

Mudanças de paradigma na identificação, expressão e

43 Conclusões verificação de requisitos

Abordagem arrastão

Se a premissa é problema de comunicação, então vamos
conversar

Histórias

Histórias balançam a comunicação entre negócio e
desenvolvimento

Histórias são a base do desenvolvimento iterativo
(incremental, e ágil)

Histórias facilitam o planejamento
 Para saber mais …
45

Mike Cohn

Blog
 blog.mountaingoatsoftware.com/

Tutoriais
 Effective
user for agile requirements
www.mountaingoatsoftware.com/presentations

Livros
 Cohn,M. User Stories Applied: For Agile Software
Development. Pearson.