Histórias de usuários - Declaração de valor

Histórias de Usuário

Augusto Rü[email protected]

The Best, The Rare, The Rest

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