O documento discute técnicas de modelagem de requisitos, como casos de uso e histórias de usuário. Apresenta exemplos de como decompor requisitos de negócio em histórias menores e critérios de aceitação. Também discute problemas comuns em casos de uso, como falta de foco e rastreabilidade, e como histórias de usuário podem ser uma alternativa para documentar requisitos de forma mais objetiva.

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

2. 2 2
Modelagem de requisitos
com histórias de usuário
Modelagem,
produtividade e
produtos que os
clientes amam
caso de uso,
bem me quer...
Meu cliente,
minha historia
Historias e
planejamento
Métricas de
requisitos
Decompor
requisitos de
negócio
Prototipação e
histórias
Workshops de
requisito

3. 3 3
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
O problema mais comum não é que não
chegamos à causa raiz; O problema mais
comum é que nós nem tentamos.
Não,
obrigado
Estamos
muito
ocupados

4. 4 4
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Como estamos lidando com a incerteza:
faturamento e satisfação do cliente?
Fonte: https://clipzen.blog/2017/11/28/noestimates-my-way-to-do/

5. 5 5
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
3. O que é um caso de uso,
o que você escreve nele?
4. Qual o custo da não
qualidade?
1. Como você modela a
necessidade do cliente?
2. Como você apresenta o
atendimento da necessidade
do cliente?

6. 6 6
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Por que precisamos documentar o
produto?
Qual a diferença entre muito
documentado em bem
documentado?
Dimensões: técnica e do cliente

7. 7 7
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
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

8. 8 8
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Rastreabilidade entre a necessidade do
cliente e evolução do produto: objetiva e
efetiva ou lenta e muitas vezes
impraticável?
Especificação de caso de uso
Cadê o mapa: contratos, manutenção, satisfação?

9. 9 9
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
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?
Rastreabilidade... quão rápido é?
Especificação de caso de uso
Objetivo e efetivo ou lento e muitas vezes impraticável?

10. 10 10
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
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.
Problemas de foco: quão objetivo é...?
Especificação de
caso de uso
Confuso e com problemas de foco?

11. 11 11
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
1. Longo e confuso, nunca acabam: desperdício, pois a
visão inicial não é completa.
Problemas de foco: quão objetivo é...?
Especificação de caso de uso
Confuso e com problemas de foco?
http://www.ateomomento.com.br/o-problema-da-descoberta-do-escopo-o-cone-da-incerteza/

12. 12 12
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Problemas de foco: Quantas e quais perguntas eu preciso
fazer pro cliente?
Especificação de caso de uso
http://www.accera.com.br/blog/big-data/informacao-vs-confusao/
Grande volume de
informações x significado
Respostas mais precisas para poucas perguntas críticas para o seu
negócio e que trarão resultados efetivos.

13. 13 13
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
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?
Problemas de desempenho coletivo do time.
Especificação
de caso de uso
Imagem: https://www.bfm.my/ryg-team-performance-michael-kossler-iclif.html

14. 14 14
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Problemas de desempenho coletivo do time.
Especificação
de caso de uso
Imagem: https://www.bfm.my/ryg-team-performance-michael-kossler-iclif.html
Melhoria continua: custo alto de experimentação
colaborando negativamente para entrega contínua
favorecendo algo grau de variabilidade no ciclo de
entrega.
Qual é a velocidade de qualquer equipe?

15. 15 15
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Valor: pouco?
Especificação de caso de uso
Imagem: https://www.bfm.my/ryg-team-performance-michael-kossler-iclif.html
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

16. 16 16
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
O cliente não entende use case:
gera incerteza, aumenta a probabilidade de
rejeição do produto e mudança de escopo.
Valor: pouco?
Especificação de caso de uso
Não atende nem o potencialmente entregável nem o
potencialmente consumível.

17. 17 17
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Valor: pouco?
Especificação de caso de uso
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.

18. 18 18
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Qualidade: baixa?
Especificação de caso de uso
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?

19. 19 19
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Custo e prazo:
fora do controle?
Especificação de caso de uso
Estimulam a incerteza e impactam fortemente na mudança
de escopo.
Como medir impacto só tendo o genérico?

20. 20 20
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Custo e prazo:
fora do controle?
Especificação de caso de uso
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.

21. 21 21
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
User stories
http://www.agilebuddha.com/agile/scrum-backlog-epic-user-story-acceptance-criteria/
Histórias do usuário

22. 22 22
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Como vc vende seu produto?
Aqui está: 10 rosas pequenas, cada uma
com 20 pétalas e talo de 10 cm verde.
R$ 120,00 tudo.
Minha esposa vai gostar?
Desculpe senhor,
vendemos flores,
não satisfação.

23. 23 23
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Como vc vende seu produto?
Aqui estão as lindas rosas que pediu:
perfumadas, cores vibrantes, frescas
em um pacote encantador
Ótimo, quero que minha
esposa se sinta única
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

24. 24 24
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Venda benefícios, não produtos.
Onde os benefícios estão registrados?
http://www.wordstream.com/blog/ws/2016/11/10/customer-loyalty

25. 25 25
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
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.

26. 26 26
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
User stories - FORMATOS
Como, Enquanto <quem / uma persona>
Eu quero <o quê/ fazer algo>
Para ê / <porquê / para alcançar algo>

27. 27 27
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
User stories - Exemplos
Frente
Verso ( critérios de
qualidade)
Padrão. Quantas e
quais as perguntas?

28. 28 28
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
User stories – Teste de aceitação.
Verso ( critérios de
aceitação)Exemplo:
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?

29. 29 29
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
User stories – Teste de aceitação.
Dimensões de valor:
-Contratual
-Manutenção
-Criação de novos produtos
-Etc.

30. 30 30
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Decompondo requisitos

31. 31 31
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
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/

32. 32 32
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
User stories - Granularização
http://www.romanpichler.com/blog/epics-and-ready-stories/

33. 33 33
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
User stories - Granularização
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

34. 34 34
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
User stories - Granularização
Decompondo e agrupando requisitos
de negócio.
Por regras de negócio
RN: Limite de valor pago, desconto por seção, quantidade mínima enviada.

35. 35 35
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
User stories - Granularização
Decompondo e agrupando requisitos
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).

36. 36 36
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
User stories - Granularização
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.

37. 37 37
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
User stories - Granularização
Decompondo e agrupando requisitos de negócio.
Por conjunções
E, ou, se, quando, então...
https://pt.wikihow.com/Decompor-N%C3%BAmeros

38. 38 38
“Não existe algo tão inútil
quanto fazer eficientemente
o que não precisa ser feito”
Peter Drucker

39. 39 39
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
Onde está o MVP em uma história?

40. 40 40
Analise de S...? Satisfação, ROI
O impacto econômico do requisito
Analise passiva
(Essencialmente
descrição do que ouve)
Validar aceitação
-Apresentar telas e
funcionalidades.
Histórias e fluxo de valor
Analise ativa
(Analise, mesmo!)
Capturar necessidade
Reduzir riscos
Mostrar ganho
Produzir mais e
melhor
Validar aceitação:
-Mostrar benefícios
-Mudança de escopo
-Priorização
-Testar agradabilidade
( programa de relacionamentos)

41. 41 41
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

42. 42 42
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
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.

43. 43 43
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
User Story 4: Como, um comprador quero pagar com um cartão de
crédito.
https://www.uxpin.com/studio/blog/forget-tedious-documentation-
prototype-requirements-instead/
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

44. 44 44
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
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

45. 45 45
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
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

46. 46 46
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Prototipação de largura x profundidade. Fluxo de 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
Como capturar feedback empírico?
Design suporta a historia: persona, necessidade, valor

47. 47 47
Explorando a necessidade
do cliente.
Padrões permitem identificar rapidamente
anomalias e entregar mais rápido

48. 48 48
Antes de tudo....
Modele as conversas

49. 49 49
Cuide do roubo de tempo usando histórias
https://clipzen.blog/2017/09/04/ahn-roubaram-meu-queijo-kanban-e-o-
superpoder-da-visibilidade/

50. 50 50
User Stories – Validação.
Card: para lembrar do teste, conversa
Conversation: detalhes
Confirmation: teste de aceitação
Cuide do roubo de tempo usando histórias

51. 51 51
User Stories facilitam a conversação
https://www.slideshare.net/petersaddington/agile-and-user-story-workshop-peter-saddington
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?

52. 52 52
Necessidades de quem?
-Do cliente
-Do time
Explorando história(necessidades)

53. 53 53
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

54. 54 54
Sessões exploratórias com o time
Qual o delay do time para descobrir surpresas?
Troque amplamente discutido por
objetivamente explorado.

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

56. 56 56
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
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)

57. 57
MoSCoW (M) Deve ter, (S) deveria ter, (C) poderia
ter, (W) não terá por enquanto
Deve ter Deveria Poderia Não terá
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?
Atividade de priorização:
-Eleja o facilitador
-Vote a prioridade e enquadre
-Priorize no quadro Kanban

58. 58 58
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Histórias e as dores
do cliente

59. 59 59
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
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

60. 60 60
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Benefícios x saída do sistema
-protótipo,
-Historia, etc.
E o resultado?
Documentação viva
Mapa do ROI do desenvolvimento

61. 61 61
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
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

62. 62 62
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Que tal um catálogo padrão
para login, crud, consulta, relat, etc?

63. 63 63
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
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/

64. 64 64
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
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?

65. 65 65
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
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

66. 66 66
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
MODELO DE KANO
Respostas emocionais
DEVE TERSE TIVER
INSATISFEITO
NEUTRO
DESAPONTADO
MUITO
SATISFEITO
SATISFEITO
RESPOSTA
EMOCIONAL

67. 67 67
Teste funcional
Negócio
-Histórias
-Teste exploratório
Bug zero
-Teste exploratório
-Heurísticas

68. 68 68
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

69. 69 69
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

70. 70 70
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

71. 71 71
Histórias facilitam
a conversação e
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.
Não,
obrigado
Estamos
muito
ocupados

72. 72 72
Histórias são:

73. 73 73
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Roadmaps do produto com histórias
Ver: http://www.agilemodeling.com/artifacts/userStory.htm

74. 74 74
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Escopo flexível
Mudança de escopo: problema ou
realidade?
Como histórias podem ajudar?
Foco, rastreabilidade, comunicação, contratos
Dimensões
-Cliente
-Time

75. 75 75
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Roadmaps do produto com histórias
Pequenos ciclos
Grandes pacotes
e contrato
Roadmap
do contrato

76. 76 76
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Roadmaps do produto com histórias
https://blog.easyagile.com/anatomy-of-an-agile-user-story-map-4ecb6a508d94

77. 77 77
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Métricas com histórias
Rejeitados, bloqueados, bugs ( quant e taxa), mais
usadas, mais mudadas, velocidade, no prazo, etc.

78. 78 78
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Gestão ágil de mudança no projeto
https://www.arraspeople.co.uk/camel-blog/change-management/5-golden-rules-of-effective-change-management/

79. 79 79
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Gestão ágil de
Mudança no projeto
-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
http://blog.readytomanage.com/change-management-cartoon/

80. 80 80
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
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
Gestão ágil de
Mudança no projeto

81. 81 81
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
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
Lembre

82. 82 82
Gratidão

83. 83 83
Parabéns!!!!!
Seu time conseguiu