2 Modelagemrequisitoshistorias Alem

Modelagem com historias
KLEITOR
br.linkedin.com/in/kfranklint
Bem além dos requisitos

1 1
Modelagem de requisitos
com histórias de usuário
Modelagem, Decompor
produtividade e requisitos de
produtos que os negócio
clientes amam
Historias e
planejamento
Prototipação e
caso de uso, histórias
bem me quer...
Métricas de
requisitos
Workshops de
requisito
Meu cliente,
minha historia
2 2
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
O problema do
problema
Não, Estamos
obrigado muito
ocupados
O problema mais comum não é que não

chegamos à causa raiz; O problema mais
comum é que nós nem tentamos.
3 3
Como estamos lidando com a incerteza:

faturamento e satisfação do cliente?
Fonte: https://clipzen.blog/2017/11/28/noestimates-my-way-to-do/
4 4
1. Como você modela a

necessidade do cliente?
2. Como você apresenta o
atendimento da necessidade
do cliente?
3. O que é um caso de uso,

o que você escreve nele?
4. Qual o custo da não
qualidade?
5 5
Por que precisamos documentar o

produto?
Qual a diferença entre muito

documentado em bem
documentado?
Dimensões: técnica e do cliente
6 6
Por que não, use cases?
1999: Use Case Pitfalls: Top 10 Problems from Real

Projects Using Use Case
https://pdfs.semanticscholar.org/5bd9/84c9851f2107382b4bb8d0adf557ce94dec9.pdf
Uma reformulação: Use case 2.0
7 7
Especificação de caso de uso
Rastreabilidade entre a necessidade do

cliente e evolução do produto: objetiva e
efetiva ou lenta e muitas vezes
impraticável?
Cadê o mapa: contratos, manutenção, satisfação?
8 8
Rastreabilidade... quão rápido é?
1. Como associar uma solicitação de mudança a um

trecho de código e uma regra de negócio?
2. Como rastrear o investimento na variabilidade do
requisito ao longo das entregas?
3. Como corrigir um bug em menos tempo?
4. Como analisar desperdícios na produção do produto?
Objetivo e efetivo ou lento e muitas vezes impraticável?
9 9
Especificação de
caso de uso
Problemas de foco: quão objetivo é...?
1. Descreve o sistema ou a necessidade do cliente?

2. Comportamento de software x necessidades de
negócio.
3. Negócio, interação com o sistema e UI juntos
4. Nível não padronizado de detalhes
5. Longo e confuso, nunca acabam: desperdício, pois a
visão inicial não é completa.
Confuso e com problemas de foco?

10 10
Problemas de foco: quão objetivo é...?
1. Longo e confuso, nunca acabam: desperdício, pois a

visão inicial não é completa.
http://www.ateomomento.com.br/o-problema-da-descoberta-do-escopo-o-cone-da-incerteza/
Confuso e com problemas de foco? 11 11

Problemas de foco: Quantas e quais perguntas eu preciso
fazer pro cliente?
Grande volume de
informações x significado
http://www.accera.com.br/blog/big-data/informacao-vs-confusao/
Respostas mais precisas para poucas perguntas críticas para o seu

negócio e que trarão resultados efetivos.
12 12
Especificação
de caso de uso
Problemas de desempenho coletivo do time.
Use cases estimulam baixa autoestima e baixo

desempenho
Como medir o desempenho do time pela entrega de use
case? Foco, custo de tipo de atividade
Impossibilita gestão coletiva e colaborativa do

conhecimento.
Como aprender coletivamente acelerando o tempo
produtivo e reduzindo incertezas?
Imagem: https://www.bfm.my/ryg-team-performance-michael-kossler-iclif.html 13 13
Especificação
de caso de uso
Problemas de desempenho coletivo do time.
Qual é a velocidade de qualquer equipe?
Melhoria continua: custo alto de experimentação

colaborando negativamente para entrega contínua
favorecendo algo grau de variabilidade no ciclo de
entrega.
Valor: pouco?
Generalidades escondem
necessidades específicas: atores x personas.
Descreve a interação com sistema, não como o produto pode ser

altamente consumível: agradabilidade e aderência.
Baixo (ou nenhum) grau de visibilidade da necessidade do cliente:

grau alto de incerteza: quem, quando, porque
Valor: pouco?
O cliente não entende use case:

gera incerteza, aumenta a probabilidade de
rejeição do produto e mudança de escopo.
Não atende nem o potencialmente entregável nem o

potencialmente consumível.
16 16
Valor: pouco?
Trabalha com atores. Atores são sobre sistema, personas são

sobre negócio. Ator não tem necessidade, personas sim.
Na apresentação do produto não favorecem a demonstração de

ganhos do cliente, mas a interação com o sistema.
17 17
Qualidade: baixa?
1. Estimula a entrega de trabalho incompleto: fluxos de

exceções não explicitam critérios de qualidade. Dão
talvez indícios.
2. Como medir a rejeição do cliente: a validação do
genérico e a impossibilidade de avaliar aderência.
3. Como mostrar pro cliente seus ganhos?
18 18

Custo e prazo:
fora do controle?
Estimulam a incerteza e impactam fortemente na mudança

de escopo.
Como medir impacto só tendo o genérico?
19 19

Custo e prazo:
fora do controle?
Manutenção:
1. Custo muito alto: setup, etc;
2. Curva de aprendizagem longa
3. Não apoia rapidamente a realidade da mudança do
escopo e requisito.
4. Dificulta decomposição funcional.
5. Não define claramente fronteiras entre use cases.
6. Forte acoplamento estrutural torna lento a mudança do
requisito e a nova entrega do produto.
7. Não tem regras para decomposição da entrega de valor.
20 20
Histórias do usuário
User stories
http://www.agilebuddha.com/agile/scrum-backlog-epic-user-story-acceptance-criteria/
21 21
Como vc vende seu produto?
Aqui está: 10 rosas pequenas, cada uma Minha esposa vai gostar?
com 20 pétalas e talo de 10 cm verde.
R$ 120,00 tudo.
Desculpe senhor,
vendemos flores,
não satisfação.
22 22
Como vc vende seu produto?
Aqui estão as lindas rosas que pediu: Ótimo, quero que minha
perfumadas, cores vibrantes, frescas esposa se sinta única
em um pacote encantador
Com certeza, seu

bom gosto pra
flores diz tudo.
Que tal um lindo

cartão para
acompanhar?
https://pt.depositphotos.com/20381689/stock-photo-man-customer-ordering-flowers-bouquet.html 23 23
Venda benefícios, não produtos.

Onde os benefícios estão registrados?
http://www.wordstream.com/blog/ws/2016/11/10/customer-loyalty
24 24
User stories
1. Descrição escrita de cenário de negócio

2. Contém testes que transmitem a qualidade
e o valor (benefício) da entrega.
3. UMA PARTE DO TODO

Não exclui qualquer outra
forma ou artefato de
modelagem.
25 25
User stories - FORMATOS
Como, Enquanto <quem / uma persona>

Eu quero <o quê/ fazer algo>
Para ê / <porquê / para alcançar algo>
26 26
User stories - Exemplos

Verso ( critérios de
Frente qualidade)
Padrão. Quantas e
quais as perguntas?
27 27
User stories – Teste de aceitação.
Verso ( critérios de
Exemplo: aceitação)
Bug zero: campo obrigatórios,

teclas enter, etc.
Negócio:
Ver tarefas em atraso
Ver tarefas concorrentes (
multitarefas)
Ver entregas em atraso
Ver tendências de atraso
Quais os critérios
de qualidade?
28 28
User stories – Teste de aceitação.
Dimensões de valor:
-Contratual
-Manutenção
-Criação de novos produtos
-Etc.
29 29
Decompondo requisitos
30 30
User stories - Granularização
1. Temas são coleções de histórias relacionadas.

2. Épicos são histórias grandes
https://blog.craft.io/2017/04/23/writing-epic-user-stories/
31 31
http://www.romanpichler.com/blog/epics-and-ready-stories/
32 32
Decompondo e agrupando requisitos

de negócio.
Por passos do fluxo
Como, cliente eu quero comprar os produtos no meu carrinho de

compras para que eu possa receber meus produtos em casa.
Passos: logar, por no carrinho, pagar, receber
33 33

de negócio.
Por regras de negócio
RN: Limite de valor pago, desconto por seção, quantidade mínima enviada.
34 34

de negócio.
Por operações
Como, um diretor eu quero gerir o estoque para conhecer produtos com data de
validade de 30 dias para planejar promoções.
Operações: listar ( recuperar), reclassificar ( atualizar), atualizar lista de

promoção ( excluir, adicionar).
35 35

Decompondo e agrupando requisitos de negócio.
Por papeis
Como, organização de notícias quero publicar novos artigos em nossa página

inicial, para que os clientes tenham um motivo para retornar periodicamente.
Papeis: cliente, jornalista, admin, editor.
36 36

Decompondo e agrupando requisitos de negócio.
Por conjunções
https://pt.wikihow.com/Decompor-N%C3%BAmeros
E, ou, se, quando, então...
37 37
“Não existe algo tão inútil
quanto fazer eficientemente
o que não precisa ser feito”
Peter Drucker
38 38
Onde está o MVP em uma história?
Como, Enquanto <quem / uma persona>

Eu quero <o quê/ fazer algo>
Para ê / <porquê / para alcançar algo>
http://www.userdrivendev.com/p/keep-it-simple.html
39 39
O impacto econômico do requisito
Analise passiva Validar aceitação

(Essencialmente -Apresentar telas e
descrição do que ouve) funcionalidades.
Analise de S...? Satisfação, ROI

Histórias e fluxo de valor
Analise ativa
(Analise, mesmo!) Validar aceitação:
Capturar necessidade -Mostrar benefícios
Reduzir riscos -Mudança de escopo
Mostrar ganho -Priorização
Produzir mais e -Testar agradabilidade
melhor ( programa de relacionamentos)
40 40
Um proposta para um fluxo de valor
Capturar / modelar
necessidade Funcionalidade ( pacote lógico )
Registrar usuário
Histórias
- Como, atendente preciso registrar

novo cliente para que ele tenha
visualize a loja.
- Como, atendente quero me
registrar no sistema para
cadastrar clientes
Validar aceitação:
Benefícios x
mudança de escopo
41 41
User stories e prototipação.
http://digitaldeepak.com/heat-maps/
Protótipos por sua própria natureza, são uma versão incompleta e

esboçada do produto final. Eles não são perfeitos. Eles não precisam
ser. Não devem ser. Na verdade, um protótipo ligeiramente esboçado
é muitas vezes melhor para obter feedback.
Warfel, T. Z. (2009). Prototyping: a practitioner’s guide. Rosenfeld Media.
42 42
User Story 4: Como, um comprador quero pagar com um cartão de
crédito.
Como mostrar os benefícios usando protótipo?

Como explorar as generalidades verticais, horizontais e
transversais?
Como descobrir o fluxo de valor do cliente?
Como mapear contrato x necessidade usando
protótipo?
Como simular a experiência em detalhes?
Como mapear a fidelidade visual x fidelidade da
interação
https://www.uxpin.com/studio/blog/forget-tedious-documentation-
prototype-requirements-instead/
43 43
Por que usamos protótipos?
Queremos aprender rápido. Mas,

nessa jornada queremos...
-que o usuário participe da

experiência da prototipação: há
detalhes suficientes?
-Mapa do protótipo para o contrato:

horizontal, vertical, transversal
44 44
Por que usamos protótipos?
Queremos aprender rápido. Mas,

nessa jornada queremos...
-Meios baratos e rápidos de modelar a

necessidade
-Reduzir incertezas e riscos
-Descobrir o que importa em um
determinado contexto
45 45
Prototipação de largura x profundidade. Fluxo de valor
Como capturar feedback empírico?
Design suporta a historia: persona, necessidade, valor
História (design) promove detalhes para a prototipação

História promove detalhes para simular a experiência
Histórias permitem-nos compreender as implicações de nossas escolhas de
design
46 46
Explorando a necessidade
do cliente.
Padrões permitem identificar rapidamente

anomalias e entregar mais rápido
47 47
Antes de tudo....
Modele as conversas
48 48
Cuide do roubo de tempo usando histórias
https://clipzen.blog/2017/09/04/ahn-roubaram-meu-queijo-kanban-e-o-
superpoder-da-visibilidade/ 49 49
Cuide do roubo de tempo usando histórias
User Stories – Validação.
Card: para lembrar do teste, conversa

Conversation: detalhes
Confirmation: teste de aceitação
50 50
User Stories facilitam a conversação
1. Cliente- como descrevo o que quero?

2. Stakeholders- o que preciso no meu produto para ser
bem sucedido?
3. GP -como faço para acompanhar e planejar este
trabalho?
4. Analista de negócio-quais são os detalhes desta entrega?
5. UX-como eu entendo que os usuários precisam?
6. Dev- quais são os detalhes das tarefas que eu preciso
para trabalhar hoje?
7. QA- como faço para validar este trabalho concluído?
https://www.slideshare.net/petersaddington/agile-and-user-story-workshop-peter-saddington
51 51
Explorando história(necessidades)
Necessidades de quem?
-Do cliente
-Do time
52 52
Sessões exploratórias
-Com o time: focadas, rápidas

Foco: Visão de negócio e técnica
15 minutos em sessões diárias
Com o cliente:
-Foco: priorização, análise da dor,
jornada das personas (transversalidade);
-Tempo e frequência: para cada cliente um estratégia
53 53
Sessões exploratórias com o time
Qual o delay do time para descobrir surpresas?
Troque amplamente discutido por

objetivamente explorado.
54 54
Sessões exploratórias com o time
Mapa de Histórias
Atividade em duplas:
-Escreva duas histórias (escolha o sistema)
-Use 3c e explore horizontal
-Escreva novas histórias ou critérios: vertical
55 55
O que é valor?
-Necessidade gera valor

-Algo pelo qual o cliente está disposto a pagar.
-A etapa do processo ou prática que está
contribuindo para o valor global
Todo o resto será atividade sem valor acrescentado

(NVA)
56 56
MoSCoW (M) Deve ter, (S) deveria ter, (C) poderia
ter, (W) não terá por enquanto
Nós conseguiremos? O que é mais importante?

É isso que o cliente quer? Do que o cliente pode
abrir mão agora? Qual o impacto econômico?
Deve ter Deveria Poderia Não terá
Atividade de priorização:
-Eleja o facilitador
-Vote a prioridade e enquadre
-Priorize no quadro Kanban
57
Histórias e as dores
do cliente
58 58
Por que testar

a agradabilidade?
Os usuários quase sempre preferem um produto simples, com

menos recursos executados extremamente bem sobre um
produto com inchaço de recursos com um monte de recursos que
são executados apenas marginalmente bem.
file:///C:/Users/p001161/Documents/Agil-Teste/Agil/metodologias/lean/Kano/Book Excerpt The User Experience Team of One

_ UX Magazine.htm
59 59
Benefícios x saída do sistema
E o resultado?
-protótipo,
-Historia, etc.
Documentação viva
Mapa do ROI do desenvolvimento
60 60
Atividade: usando prototipação e histórias,

simule a experiência do usuário
Apresente 3 histórias
Deixe o cliente (outro grupo) contar a história
(transversalidade)
Conte a historia com o protótipo
Remodele histórias ou protótipos
61 61
Que tal um catálogo padrão

para login, crud, consulta, relat, etc?
62 62
User stories e design da jornada do

usuário
https://yzoedesign.wordpress.com/2013/05/06/user-journey-map-based-on-experience-prototyping-may-6/
63 63
Imersão na realidade
do cliente
Consolidação das dores.

-Como fazer as dores dos clientes emergirem?
Teste de aderência
-Como desenhar requisitos orientados a “Uau!”?
-Como tornar a agradabilidade visível?
64 64
Testando a aderência
pela agradabilidade
Quando usar?
Quando a equipe está tendo problemas de priorização.
Quando se deseja que o senso de satisfação do cliente se
torne visível.
Quando você não sabe o que diferencia seu produto dos
seus concorrentes.
Quando você precisar desenvolver uma visão
compartilhada com a equipe na direção do produto e
futuro
65 65
MODELO DE KANO
Respostas emocionais
MUITO
SATISFEITO
RESPOSTA
SATISFEITO
EMOCIONAL
NEUTRO
DESAPONTADO
INSATISFEITO
SE TIVER DEVE TER
66 66
Teste funcional
Negócio
-Histórias
-Teste exploratório
Bug zero
-Teste exploratório
-Heurísticas
67 67
Sessões exploratórias Benefícios
-Ajuda a reduzir incertezas e riscos

-Colabora para definir trabalho completo
-Ajuda a encontrar informação na confusão
-Melhoram o desempenho coletivo
-Exploram generalidades
-Adequam escopo e prazo
68 68
Sessões exploratórias Benefícios
-Propagação e estabilização do conhecimento

-Redução do setup
-Ajuda a estabilizar a velocidade do time
-Colabora para o bem documentado e Documentação
viva
-Ajuda a priorizar
-Ajuda a identificar
cenários de teste.
-Ajuda a encontrar 20% dos principais benefícios
que reduzem 80% problemas
69 69
Quero abandonar as historias.
Tem tecnologia melhor?
Qual é a sua dor? Que problema você quer resolver?

Qual o impacto econômico da escolha?
Desenvolver e entregar produto não é uma atividade isolada
70 70
Histórias facilitam Não, Estamos
a conversação e
obrigado muito
ocupados
aumentam o valor
Quero abandonar as historias.

O que pode está ocorrendo:
-Estou no meio do furacão e não sei como usar histórias
-Tenho dificuldade, nunca modelei valor
-Não sei como utiliza-las com o cliente
-Acredito que só o protótipo e RNs resolvem
-etc.
71 71
Histórias são:
72 72
Roadmaps do produto com histórias
Ver: http://www.agilemodeling.com/artifacts/userStory.htm
73 73
Escopo flexível
Mudança de escopo: problema ou

realidade?
Dimensões
-Cliente
-Time
Como histórias podem ajudar?

Foco, rastreabilidade, comunicação, contratos
74 74
Pequenos ciclos
Grandes pacotes
e contrato
Roadmap
do contrato
75 75
https://blog.easyagile.com/anatomy-of-an-agile-user-story-map-4ecb6a508d94
76 76
Métricas com histórias
Rejeitados, bloqueados, bugs ( quant e taxa), mais

usadas, mais mudadas, velocidade, no prazo, etc.
77 77
Gestão ágil de mudança no projeto
https://www.arraspeople.co.uk/camel-blog/change-management/5-golden-rules-of-effective-change-management/
78 78
Gestão ágil de
Mudança no projeto
http://blog.readytomanage.com/change-management-cartoon/
-JIT- planejamento e repriorização ( model storming)

-Estabeleça cadencia com o cliente e com o time
-Reuniões frequentes e objetivas: por que estamos aqui?
-Torne as mudanças visíveis: quadro de sinalização,
métricas, etc.
-Avalie e meça continuamente
79 79
Gestão ágil de
Mudança no projeto
Quando a mudança é solicitada:

-Histórias: foco nas pessoas afetadas e não na mudança que
parece ser melhor
-Que problema queremos resolver? 1 ano por 10 minutos
-Que mudança resolve o problema?
- Que resultados comerciais mostram as mudanças adotadas?
Curva de Roger
https://www.youtube.com/watch?v=hL-nO498FPY
80 80
Lembre
Foco mais na comunicação que em engenharia de

software
Relaxe não se pressione
Siga em frente até sentir confiança
Pense em que problema quer resolver
A maioria da interações são práticas
Preste atenção no que o outro quer lhe dizer
Lembre: muitas situações são parecidas
Entenda o contexto: ele tem muita informação
81 81
Gratidão
82 82
Parabéns!!!!!
Seu time conseguiu
83 83

2 Modelagemrequisitoshistorias Alem

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

2 Modelagemrequisitoshistorias Alem

Enviado por

Direitos autorais:

Formatos disponíveis

Modelagem com historias

Bem além dos requisitos

O problema mais comum não é que não

Como estamos lidando com a incerteza:

1. Como você modela a

3. O que é um caso de uso,

Por que precisamos documentar o

Qual a diferença entre muito

Dimensões: técnica e do cliente

Por que não, use cases?

1999: Use Case Pitfalls: Top 10 Problems from Real

Uma reformulação: Use case 2.0

Especificação de caso de uso

Rastreabilidade entre a necessidade do

Cadê o mapa: contratos, manutenção, satisfação?

Especificação de caso de uso

Rastreabilidade... quão rápido é?

1. Como associar uma solicitação de mudança a um

Objetivo e efetivo ou lento e muitas vezes impraticável?

Problemas de foco: quão objetivo é...?

1. Descreve o sistema ou a necessidade do cliente?

Confuso e com problemas de foco?

1. Longo e confuso, nunca acabam: desperdício, pois a

Confuso e com problemas de foco? 11 11

Respostas mais precisas para poucas perguntas críticas para o seu

Problemas de desempenho coletivo do time.

Use cases estimulam baixa autoestima e baixo

Impossibilita gestão coletiva e colaborativa do

Problemas de desempenho coletivo do time.

Qual é a velocidade de qualquer equipe?

Melhoria continua: custo alto de experimentação

Descreve a interação com sistema, não como o produto pode ser

Baixo (ou nenhum) grau de visibilidade da necessidade do cliente:

Especificação de caso de uso

O cliente não entende use case:

Não atende nem o potencialmente entregável nem o

Trabalha com atores. Atores são sobre sistema, personas são

Na apresentação do produto não favorecem a demonstração de

Especificação de caso de uso

1. Estimula a entrega de trabalho incompleto: fluxos de

Especificação de caso de uso

Estimulam a incerteza e impactam fortemente na mudança

Especificação de caso de uso

Com certeza, seu

Que tal um lindo

Venda benefícios, não produtos.

1. Descrição escrita de cenário de negócio

3. UMA PARTE DO TODO

User stories - FORMATOS

Como, Enquanto <quem / uma persona>

User stories - Exemplos

User stories – Teste de aceitação.

Bug zero: campo obrigatórios,

User stories – Teste de aceitação.

1. Temas são coleções de histórias relacionadas.

User stories - Granularização

Decompondo e agrupando requisitos

Por passos do fluxo

Como, cliente eu quero comprar os produtos no meu carrinho de

Passos: logar, por no carrinho, pagar, receber

User stories - Granularização

Decompondo e agrupando requisitos