Embed Size (px)
Citation preview
Aqui vai uma história: ou você me dá o que eu pedi, ou eu acabo com a sua vida
Era uma vez…
1. Histórias de usuário 101
2. Escrevendo histórias melhores
3. Quando não é uma história
Parte 1
História de Usuário 101
?.
O que é uma história de usuário?
?. Histórias de usuário 101.
Não é uma especificação funcionalNão é para relatar um bugNão é um documento de definições técnicas Não é uma enunciação detalhadaNão é um requisitoNão é um contratoNão é algo para funcionar sem o P.O.
O que não é uma história de usuário...
×
Uma história de usuário é...
É uma requisição de funcionalidade sobre o ponto de vista do usuário
É uma expressão negociável de uma necessidade
É uma expressão de um incremento usável de software
Por que escrevemos histórias,não especificações ou requisitos?
?. Histórias de usuário 101.
Indivíduos e interação entre eles mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Relembrando o manifesto ágil...
Facilitam o diálogo
Qualquer um pode escrever
Qualquer um pode entender a demanda
Focam na entrega de valor
Facilitam a mudança de comportamento
Descrevem uma possibilidade/demanda, não uma solução
Escrevemos histórias pois elas
Cascata: o objetivo aqui é gerenciar e garantir o escopo
Cascata: esse documento contém TUDO?!
3Cs
!. Histórias de usuário 101.
CartãoConversaçãoConfirmação
Componentes da histórias de Ron Jeffries
3Cs
CartãoConversaçãoConfirmação
A demanda deve ser sucinta e compreensível por todos. A história é descartável, não um requisito a ser rastreado.
3Cs
Componentes da histórias de Ron Jeffries
CartãoConversaçãoConfirmação
A demanda deve ser discutida e negociada. A história não é uma ordem, mas uma ferramenta para o diálogo e tomada de decisão.
3Cs
Componentes da histórias de Ron Jeffries
CartãoConversaçãoConfirmação
A demanda deve ser compreendida por todos. O valor a ser entregue deve estar claro para os envolvidos.
3Cs
Componentes da histórias de Ron Jeffries
Declaração de ValorCritérios de aceitação
Anatomia básica de um Cartão
Declaração de ValorCritérios de aceitação
Anatomia básica de um Cartão
Pausa aleatória
Modelos de Declaração de Valor
!. Histórias de usuário 101.
Como/Sendo um <papel/persona/perfil>quero/preciso/necessito de <meta/desejo>pois/de modo que <benefício>
Modelo Connextra (padrão mais conhecido)
Exemplo 1
Como um Vendedorquero adicionar novos itens em um pedido recorrentede modo que não precise reagendar tudo novamente
Modelo Connextra (padrão mais conhecido)
Exemplo 2
Sendo um Administrador de Redesquero filtrar os IPs por subredepois quero poder agrupá-los para melhorar a organização da minha infraestrutura
Modelo Connextra (padrão mais conhecido)
Mike Cohn
Como um <papel/persona/perfil>quero/preciso/necessito de <meta/desejo>
Variações do Modelo Connextra
Mike Cohn
Como um Vendedorquero listar todos os pedidos de um cliente
Variações do Modelo Connextra
Chris Matts
A fim de <benefício a ser recebido>como um <papel/persona/perfil>,eu quero <meta/desejo>
Variações do Modelo Connextra
Chris Matts
A fim de visualizar toda minha infraestruturacomo um Administrador de rede,eu quero uma visão centralizada dos meus elementos monitorados
Variações do Modelo Connextra
Variações do Modelo Connextra
5Ws (Who, When, Where, What, Why)
Como <quem>,<quando> <onde>,eu <o que>,porque <por que>
Variações do Modelo Connextra
5Ws (Who, When, Where, What, Why)
Como Vendedor,ao acessar as últimas vendas efetuadas,eu preciso ordená-las por data de entrega,porque preciso avisar os clientes do prazo dado pela fábrica
Variações do Modelo Connextra
Para demonstrar diferenciação
Diferente do(a) <situação atual ou indesejada>,Como <papel>,Eu quero/preciso que <situação desejada>
Variações do Modelo Connextra
Para demonstrar diferenciação
Diferente do relatório de compras atual,Como administrador,Eu quero/preciso que seja informado quem efetuou a compra
Parte 2
Escrevendo histórias melhores
INVEST
!. Escrevendo histórias melhores.
Independente (Independent)
Negociável (Negotiable)
Possui valor para os usuários/clientes (Valuable to users)
Estimável (Estimatable)
Pequena (Small)
Testável (Testable)
Seis atributos para uma boa história, de Bill Wake
Não seja genérico
!. Escrevendo histórias melhores.
Não use declarações vagas: "Como usuário..."
Uma das grandes vantagens das histórias dos usuários é fazer com que os desenvolvedores entendam mais das motivações dos usuários e tenham maior empatia por eles.
Identifique quem é o usuário
A identificação do usuário deve servir como ponto para discussão:
O que ele faria?
Como ele faria?
Qual abordagem se adapta melhor a esse usuário?
Identifique quem é o usuário
Defina quando e onde:
"[...] a listagem de contatos [...]"
"[...] quando adiciono um novo pedido de frete [...]"
"[...] ao finalizar a inclusão de um novo host na monitoração [...]"
Identifique o contexto
Defina um contexto maior: um objetivo de negócio que sustente mais de uma história
Um contexto genérico não irá prover nada de interessante para discussão e melhoria do produto. Somente será uma desculpa para o aumento descontrolado do escopo, baseado em vontades individuais ou opiniões de Hippos
Identifique o contexto
HIPPOS: highest paid person opinion
Avalie a zona de controlee a esfera de influência
!. Escrevendo histórias melhores.
Todo sistema tem 3 áreas:
A zona de controle que inclui aquelas coisas no sistema que nós podemos mudar nós mesmos
Um pouco de teoria de sistemas...
Todo sistema tem 3 áreas:
A zona de controle que inclui aquelas coisas no sistema que nós podemos mudar nós mesmos
A esfera de influência que inclui atividades que nós podemos impactar, mas não exercemos controle sobre
Um pouco de teoria de sistemas...
Todo sistema tem 3 áreas:
A zona de controle que inclui aquelas coisas no sistema que nós podemos mudar nós mesmos
A esfera de influência que inclui atividades que nós podemos impactar, mas não exercemos controle sobre
E o ambiente externo que inclui os elementos que não temos nenhuma influência
Um pouco de teoria de sistemas...
O motivo da necessidade do usuáriodeve estar na esfera de influência do time
O entregável (o que o usuário quer)deve estar na zona de controle do time
Em uma boa história...
Como gerente de vendas, eu preciso saber o número total de vendas por vendedor, pois assim posso calcular e submeter
as comissões mensais para o RH da empresa
Como gerente de vendas, eu preciso saber o número total de vendas por vendedor, pois assim posso calcular e submeter
as comissões mensais para o RH da empresa
Zona de controle do time
Esfera de influência do time
Uma boa história implicaem ter algum risco
!. Escrevendo histórias melhores.
Micro-histórias
Histórias enganadoras
Histórias falsas
Situações nas quais não há riscos...
Micro-histórias
Difícil identificar os riscos
Não são problemáticas por si só
Devem ser eliminadas em planejamentos de médio e longo prazo
Situações nas quais não há riscos...
Devemos evitar quebrar os itens em tamanhos menores até o momento que seja necessário adicionar mais informações específicas, antes de precisarmos começar a trabalhar nesses itens.
Um backlog eficiente está estruturado de forma hierárquica. Nele há vários tamanhos de histórias…
O quão MICRO?!?
Um backlog linear, somente com elementos do mesmo tamanho, ou não permite um planejamento preciso (pois os itens são muito grandes) ou não permite uma visão e entrega completa do valor (pois os itens são muito pequenos).
O backlog deve ser hierárquico para garantir uma visão completa do que está sendo entregue.
O quão MICRO?!?
Jeff Patton nos diz para pensar em Asteroids…
Jeff Patton nos diz para pensar em Asteroids…
1. Você precisa quebrar os asteróides grandes até deixá-los tão pequenos que um raio laser certeiro seja capaz de destruí-lo.
Jeff Patton nos diz para pensar em Asteroids…
1. Você precisa quebrar os asteróides grandes até deixá-los tão pequenos que um raio laser certeiro seja capaz de destruí-lo.
2. Mas não pode sair fragmentando todos, senão fica impossível de navegar e manobrar.
Jeff Patton nos diz para pensar em Asteroids…
1. Você precisa quebrar os asteróides grandes até deixá-los tão pequenos que um raio laser certeiro seja capaz de destruí-lo.
2. Mas não pode sair fragmentando todos, senão fica impossível de navegar e manobrar.
3. Tem que manter um bom número de asteróides medianos para saber o que vai vir e fragmentar aqueles que dá conta de eliminar de verdade.
Outra pausa aleatória
Histórias enganadoras
Descrevem uma solução, e não uma necessidade do usuário
Situações nas quais não há riscos...
Histórias enganadoras
Como administrador do sistema, quero poder acessar mais rapidamente a interface principal, por isso preciso que a carga de requisições da interface seja reduzida/saneada
Situações nas quais não há riscos...
Parte 3
Quando não é uma história
Não escreva histórias falsas
!. Quando não é uma história.
Como desenvolvedor, eu preciso eliminar as tabelas duplicadas da base
de dados
?. Quando não é uma história.
Como P.O., eu quero que na listagem de endereços a coluna de nomes fique mais
destacada que a coluna de valores
?. Quando não é uma história.
Como testador, eu preciso preparar o plano de testes da versão 3.5
?. Quando não é uma história.
Por que esses enunciados não são histórias de usuário?
?. Quando não é uma história.
Histórias falsas são aquelas queenunciam necessidades do time:
Como desenvolvedor, eu preciso…
Como P.O., eu quero…
Como testador, eu preciso...
Não são usuários... tanto a necessidade quanto a entrega estão na zona de controle do time
Por que não é uma história?
Não se trata de um usuário
Não é uma requisição de uso para a persona
Não traz valor para o negócio
Por que não é uma história?
Se não traz valor para o usuário,por que fazemos?
?. Quando não é uma história.
Bem mais fácil gerar funcionalidades desnecessárias quando fazemos o que queremos
Eliminar os desperdícios
Devemos eliminar da cadeia de valor tudo que não gera valor
Mas precisamos manter o que evita a perda de valor
Um pouco de pensamento Lean
Quando é algo que precisamos fazer
!. Quando não é uma história.
Preparação/Manutenção de ambiente
Correções de defeitos
Ajustes pontuais e melhoria de performance
Não entrega valor, mas precisa ser feito
Saber expressar o que precisamos discutir e fazer
Faça para não precisar fazer mais
Descreva a ação a ser tomada
Discuta e escreva
Foque no que pode ser automatizado
Para preparar/ajustar o ambiente
Decreva o que está errado
Descreva o comportamento aberrante
Descreva o comportamento esperado
Demonstre ação ou condição
Ao executar [...]
Quando [...]
Para correções de defeitos
Elicite a necessidade
O que precisa ser feito, não como faremos
Tenha ciência de que você (geralmente) já está em dívida
Escreva de forma a manter a conversação
Demonstre o valor de fazer aquilo
Para ajustes pontuais e melhoria de performance
Elicite a necessidade
Precisamos <necessidade>,pois <motivo>
Para ajustes pontuais e melhoria de performance
Elicite a necessidade
Precisamos ajustar o tamanho das colunas,pois algumas estão com o texto do cabeçalho cortado
Para ajustes pontuais e melhoria de performance
Mais uma pausa aleatória
Quando é uma pergunta
!. Quando não é uma história.
Quando é uma perguntaHá algo a ser feito, mas não sabemos como
!. Quando não é uma história.
Se quem fez a requisição não sabe o que quer, vamos descobrir juntos
Há algo a ser feito, mas não sabemos como:
Testar uma tecnologia
Há alto grau de incerteza na aplicação
Não é possível estimar
Falta conhecimento no time
Temos dúvidas sobre isso...
Determine qual a pergunta a ser respondida
Determine qual a entrega esperada
Determine um tempo razoável a ser consumido para ter a resposta
Negocie quais aspectos serão levados em conta e quais não
A sua requisição é uma pergunta
Antes de ir embora...
Escreva cedo a declaração de valor e deixe para detalhar depois
Evite escrever soluções
Pense em mais de um stakeholder que pode tirar proveito da solução para a situação elencada. Isso abre oportunidade para quebrar a história depois
Dicas finais
Use figuras para explicar a história
Escreva as dúvidas
Foque na declaração do problema/necessidade do usuário ao invés do problema técnico
Discuta a história
Dicas finais
Obrigado pela atenção!
Alguma pergunta?
to be continued...
