Proposta para especificação de histórias de usuários alinhadas a IEEE 830

Proposta para especificação de histórias de
usuários utilizando a engenharia centrada no
uso alinhada à prática IEEE 830
André Rocha Agostinho
andre@magnadev.com.br

Índice
1. Elicitando e Especificando Requisitos
2. Desmistificando User Stories
3. Como aplicar User Stories
4. User Stories no SCRUM
5. Boas práticas e sugestões
Tempo previsto:
Total: 50 minutos

Elicitando e Especificando
Requisitos

User centered design
• Atenção detalhada as necessidades, vontades e limitações do usuário final
do produto durante o processo de design.
• Elicitação de requisitos do usuário através de métodos investigativos como
estudo da etinografia, investigação contextual, personas, testes de
usabilidade e outros métodos como generativo que pode incluir card
sorting e sessões de design participativo ou cooperativo.
Elicitando e Especificando Requisitos
Abordagens

User centered designer não é a bala de prata
Pontos fracos
• Estudos de usuários: Fácil confusão entre o que os usuários querem
com o que eles realmente precisam
• Protótipo rápido: muitas vezes um substituto desleixado para design.
• Testes de usabilidade: Ineficiente ao encontrar problemas que muitas
vezes poderiam ter sido evitados através de um projeto adequado
Abordagens

Usage centered design
• Processo sistemático que utiliza modelos abstratos para
desenhar com simplicidade as atividades do usuário no
sistema.
Abordagens

Destrinchando Usage Centered Design
User Role Model Task Model Content Model Bussiness Rule Model
Profiles
Actors User stories
Task case Abstract prototype
Prototype
Goals model
Critério de aceitação
Abordagens

Comparativo
Abordagens

Não apenas um, não apenas o outro....
User Centered Design
Coleção de técnicas de fatores humanos unidos sobre uma
filosofia de entendimento de usuários envolvendo-os no design.
Usage Centered Design
Uma alternativa de engenharia de software para
o user-centered design.
Questionários
Conversas com o
usuário
Brainstorms Cardsorting ....
Modelos
mentais
Modelos de
interfaces
Modelos de
especificações
Modelos de
usuários
....
Abordagens

• Nasceu na metodologia XP (Extreme Programming) mencionado pela primeira
vez por Kent Beck - 1998
• Em 2001 Ron Jeffries propos um modelo (3Cs)
• Anos seguintes Mike Cohn deu continuidade e é hoje o principal
especialista na área.
Desmistificando User Stories
Uma breve história

Por qual motivo foi criado?

1º Convite
Um convite para uma conversa, com uma linguagem simples e objetiva.
2º Convesa
Uma conversa onde os envolvidos clarificam ideias e todo o entendimento é
compartilhado e anotado.
3º Confirmação
Verificação e confirmação se a estória atinge ou não os
objetivos especificados.
Anote o meu celular
Poxa legal que você
também gosta de The
Smiths.
3Cs
• Card
• Conversation
• Confirmation
Afinal o que é uma user story?

Descreve uma funcionalidade que terá valor para um usuário de um sistema.
Xaveco de Bar
Como galanteador, quero enviar um
guardanapo para a mocinha bonita,
para conseguir sexo esta noite.
Critérios de aceitação:
• Ter um garçom camarada
• Xaveco do guardanapo funcionar
• Conquistar a mocinha
• Convencer a ir pro motel
Composto por 3 aspectos:
• Descrição escrita da estória a ser usada para o planejamento como um lembrete
• Conversas sobre a estoria que servirão para destrinchar detalhes do
funcionamento
• Testes que transmitem e documentam informações para determinar quando uma
estória esta completa
Frente Verso
Afinal o que é uma user story?

Pré-requisitos
- Ter um documento de visão bem definido
- Ter elicitado o mínimo necessário de requisitos do usuário
- Montar um customer team
Visão do produto Requisitos do usuário Customer Team
O que eu preciso para escrever?

No mundo perfeito seria uma unica pessoa que pudesse priorizar trabalho para os
desenvolvedores e responder a todas as questões que envolve o funcionamento do
software, escrevendo assim todas as estórias.
Escrever estórias é um trabalho que deve envolver mais pessoas e então sugere-se
um time do cliente (customer team) composto por:
• Testers
• Product manager
• Usuarios reais
• Designers de interação
Customer team

O papel do analista
- A estória deve ser escrita na visão de negócio e sem nenhum termo técnico.
- A facilidade na escrita e leitura, possibilita uma grande redução do gap entre a
equipe técnica, analistas e cliente.
- Os visionários do produto conhecem a melhor forma de descrever as estórias.
- Um analista na equipe pode agregar na especificação dos requisitos de forma
geral, mas é a simplicidade de uma especificação em uma linguagem clara que
possibilitará a escrita de estórias.

Requisitos muitos bem detalhados e com documentação extensa podem facilmente
cair em um dos principais problema: documentos viram a meta de negócio.
User stories tendem a ser simples o suficiente para
transparecer o que o usuário necessita,
sendo assim esta a real meta do negocio
Cliente, usuário, stakeholders e equipes técnicas, quando uma dessas partes
domina a comunição, o projeto pode se perder. O engajamento entre eles é melhor
forma de garantir o compartilhamento das informações dos requisitos.
1º Comunicação
2º Foco no produto
Por que devo escrever?

Aplicando User Stories
Baby Steps com cenário hipotético
Marcelo
- 45 anos
- Empreendedor no ramo literário
- Acordou um certo dia com uma ideia:
Joana
Profissional UX
Através de uma indicação
conversa com uma
profissional de UX
Quero construir um site de reputação de
livros

• Website para avaliações de livros: Ratazana.com.br
• Público alvo: Leitores diversos
• Visão: Fornecer resenhas e avaliações de livros não por especialistas mas sim
por outros leitores
• Perfil do usuário: homens e mulheres acima de 13 anos residindo no Brasil
VISÃO:
REQUISITOS:
• Atores: Leitor
• Lista de perfis: 3 tipos
• Lista de atividades: 5 atividades principais
• Conteúdo: Modelo mental e categorização (Taxonomia )
• Regras de negócios: Sistema de avaliações 5stars (....)

REQUISITOS:
• Lista de atividades
• Personas
Persona:
Carlos Eduardo
25 anos
Leitor assíduo de ficção científica
Lê em média 2 livros por mês
Em mesa de bar, adora compartilhar com os amigos seus
últimos livros lidos.
Atividades
Buscar livros
Visualizar livro
Fazer avaliação
Visualizar avaliações

DOR (Definitation of Ready) para escrever estórias
 Visão do produto
 Definição do usuário
 Perfil do usuário
 Personificação do usuário
 Lista de atividades principais
 Esboço de conteúdo: modelo mental e categorização
 Esboço de regras de negócios: sistema de avaliações 5stars
Próximos passos Montar o customer team

“The Three Amigos” proposta de Dan North (criador do BDD)
BA PO Tester
Product Manager
ou PO
Designer de interação Engenheiro de SW
Proposta
inicial
Proposta
Modificada

Montagem do Customer Team
 Product Manager ou PO
 Designers de interação
 Testers (recomendado) ou pessoas no time com skills de tester
(prática recomenda no desenvolvimento Lean)
 Analistas (opcional)
 Usuários reais (recomendado no livro User Stories Applied)
 Engenheiro de SW (recomendação própria)
João
PO
Ricardo
Designer de interação
Fábio
Engenheiro de SW

Por que um Product Manager?
 PO é uma recomendação da metodologia SCRUM.
 Necessidade de treinamento e entendimento da metodologia SCRUM
 Product Manager tem skills e disciplinas alinhadas a produto.
 A role PO do Scrum é mais voltado ao negócio do que o produto
João
PO

Por que um Designer de interação?
 Alinhado a abordagem Usage Centered Design e User Centered Design
 Assim como o engenheiro de SW, deve ter diversas skills:
 Protipação rápida ou detalhada
 Discutir e fornecer soluções de interfaces
 Incorporar personas para testes
 Escrever cenários de testes
 Ponte entre User Centered Design e Usage Centered Design
 Ponte entre a comunicação do Customer Team e do Develloper Team (Fronts)
Ricardo
Designer de interação

Por que um Engenheiro de SW?
 Alinhado a abordagem Usage Centered Design
 Skills de engenharia de SW que deve cobrir diversas disciplinas do SWEBOK, ex:
 Qualidade na especificação dos requisitos
 Levantamentos de requisitos não funcionais
 Testabilidade e qualidade
 Codificação e automatização dos testes
 Ponte entre a comunicação do Customer Team e do Develloper Team (Backs)
Fábio
Engenheiro de SW

Usage Centered Design Especificação em User Stories
User Model Usuário da estória
Tasks Model Descrição da estória
Content Model Protótipos
Bussiness Model Critérios de aceitação
Mãos na massa com PO
Atividades
Buscar livros
Visualizar livro
Fazer avaliação
Visualizar avaliações
Visualizar Livro
Como leitor, quero visualizar um livro,
para ter conhecimento sobre suas
informações.
• Deve apresentar informações
quando publicado
• Livro deve conter imagem de capa
• Livro deve estar categorizado
Frente Verso
João
PO

Mãos na massa com PO
Refatoração
Visualizar Livro
Como leitor, quero visualizar um livro,
para ter conhecimento sobre suas
informações.
Notas: conversar com o Ricardo como
podemos fazer uma interface simples
Vamos usar o Google Books! Cadastramos
na mão!
quando publicado
• Livro deve ter informações ISBN
João
PO

User Stories Workshop
Visualizar Livro
Como leitor, quero visualizar um
livro, para ter conhecimento sobre
suas informações.
Notas: conversar com o Ricardo como
podemos fazer uma interface simples
Vamos usar o Google Books! Cadastramos
na mão!

User Stories Workshop Critérios de aceitação:
quando publicado
• Livro deve estar disponível
Given que o livro está publicado
When eu acessar
Then mostrar informações do livro
Especificação de cenário simples
Especificação de cenário personificado
When eu acessar
And eu tiver um perfil de “leitor Ratão”
And priorizar informações da sinopse
• Deve priorizar informações de
sinopse para o perfil “Ratão”

User Stories Workshop
Compilando informações
• Deve priorizar informações de sinopse para
o perfil “Ratão”
Deve apresentar informações
When eu acessar
Visualizar Livro
Como leitor, quero visualizar um
livro, para ter conhecimento sobre
suas informações.
Protótipo:
Notas: Interface simples. Usar o Google
Books!
Deve priorizar informações de sinopse para o perfil “Ratão”
When eu acessar e tiver perfil “Ratão”
And priorizar informações de sinopse

Revisão do processo para criação de user stories
Não precisa ser dificil
1. PO esboça algumas estórias de acordo com a prioridade do backlog
2. As estórias precisam ser simples mas alinhadas ao 3Cs
3. PO não precisa se preocupar em estourar todas estórias. Estórias não descritas
podem ser mantidas como Épicos e serem trabalhadas mais pra frente.
4. PO prioriza estórias que irão ser trabalhas no workshop
5. PO convoca workshop com o Customer Team
6. Customer Team trabalha revisando estórias. Cada um faz o seu papel e o objetivo é
sair com estória compilada com informações para desenvolvimento (Scrum, Kanban...)
7. Workshops para escrita de estórias NÃO FAZEM parte do planning.
8. No planning as estórias já devem estar bem contadas o suficiente para:
- Develloper Team poder estimar o esforço necessário
- Customer Team poder objetivar as entregas
- Ambos os times chegarem a um acordo do que realmente precisa ser entregue.
Ex: Objetivo da Sprint

User Stories no SCRUM
Organizando iterações
Para o planejamento de realeases, o Customer Team ordena as estorias em varias pilhas
cada pilha representando uma iteracao.
Sprint 1 Sprint 3Sprint 2
User story 1
User story 4
User story 3
User story 8
User story 5
User story 7
User story 6
User story 2
User story 5
Backlog
User story 9
User story 10
Epic 1 Epic 2

Customer Team: Vai priorizar estórias com
maior valor de negócio aos usuários do
sistema.
Developer Team: pode sugerir mudanças na
priorização das estórias por motivos
técnicos (Ex: dependências), mas no geral
deve-se ter o consentimento em entender
que as entregas devem gerar valor aos
usuários.
Priorizando

Story points e a unidade utilizada para cada estória. Esta unidade representa o quanto de
esforço necessário o Dev Team necessita para completar a estória. É comum o uso de Ideal
Days ao invés de Story Points.
Estimando

Cada pilha ira conter algumas estorias e a soma das estimativas deve representar a
velocidade do time de desenvolvimento. A velocidade do time de desenvolvido e
criado após rodar algumas iterações e falhar nas estimativas iniciais.
Velocidade do Dev. Team
Sprint 1
User story 1 – 5pts
TOTAL: 22 story points
Velocidade do Time
20 story points
/ sprint
Negociação na priorização e particionamento das estórias devem ocorrer em
situações onde o total de pontos é maior que a velocidade do time.

Fraquezas de uma user story
• Linguagem informal
• Especificação incompleta
• Não contempla requisitos
não funcionais
Boas práticas e sugestões
Nem tudo é tão bonito

• Linguagem informal
• Aplicar a técnica 5Ws para escrita estória
5ws Especificação
Who Leitor
What Avaliar um livro
Why Expressar sua opinião
Where Na interface de visualização do livro
When Quando estiver autenticado
Sugestões

• Especificação incompleta
• Contemplar especificações quando achar necessário
• Criar rastreabilidade com a estória
5ws Especificação
Who Leitor
What Avaliar um livro
Why Expressar sua opinião
Where Na interface de visualização do livro
When Quando estiver autenticado
Use case “Avaliar livro”
1. O sistema deve...
2. O sistema deve...
Nem tudo é tão bonito

• Requisitos Não Funcionais
• Especificar critérios de aceitação não funcionais
Não funcionais
• Sistema deve carregar informações em até
2 segundos
Funcionais
Sistema deve carregar informações em até 2 segundos
Given que o sistema está efetuando uma requisição
When eu acessar
Then apresentar informações em até 2 segundos
Scenario: Sistema deve carregar informações em até 2
segundos
Given que o sistema está efetuando uma <requisição>
When <leitor> acessar
Then apresentar <informações> em até 2 segundos
Examples:
requisição | leitor | informações | saida
http get | Carlos | titulo,sinopse,ISBN | 0.80s
http rest | João | titulo,sinopse,ISBN | 1.80s
Sugestões

Sugestões
• O que é um requisito bem especificado?
IEEE 830
Caractéristicas User Stories
Correto Sempre ser direcionado ao uso do software
Não ambíguo Não devem existir estórias que descrevem as mesmas coisas
Completo Completar com informações até onde a equipe achar válido
Consistente Deve ser consistentes a documentos de alto nível (Ex: requisitos produzios no User
Centered Design)
Classificável Capacidade de priorizar por importância
Verificável Critérios de aceitações e testes
Modificável Totalmente leve e passível de refatoração
Rastreável Permite rastreabilidade com épicos e demais especificações complementares

Referências
1. User Stories Applied – Mike Cohn
2. Usage centered engineering for Web Application – Constantine Lockwood
3. http://www.urisan.tche.br/~pbetencourt/engsoftI/IEEE830/caracteristicas.html
4. http://pt.slideshare.net/wakaleo/bdd-the-unit-test-of-the-product-owner
5. http://pt.slideshare.net/skillsmatter/bdd-introduction
6. http://dannorth.net/introducing-bdd/
7. http://www.agileforall.com/2010/05/new-to-agile-remember-a-user-story-is-more-than-a-
card/
8. http://gojko.net/category/presentations/BDD
9. http://www.urisan.tche.br/~pbetencourt/engsoftI/IEEE830/
10. A proposal to combine requirements elicitation techniques to build a Vision and Use Cases
in Scrum Methodology. Agostinho A., Kattan H. , Sigonirini N.
http://pt.slideshare.net/AndreRocha1/2013-0520-artigo-prof-muniz-neryandrherez-v18-
revhmk

Proposta para especificação de histórias de usuários alinhadas a IEEE 830

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (19)

Ähnlich wie Proposta para especificação de histórias de usuários alinhadas a IEEE 830

Ähnlich wie Proposta para especificação de histórias de usuários alinhadas a IEEE 830 (20)

Mehr von André Agostinho

Mehr von André Agostinho (17)

Proposta para especificação de histórias de usuários alinhadas a IEEE 830