10 dicas para escrever boas estórias de usuários

5 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
5
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

10 dicas para escrever boas estórias de usuários

  1. 1. 10 dicas para escrever boas estórias de usuários 1. Usuários em primeiro lugar Como o próprio nome sugere, estórias de usuários descrevem como o usuário utiliza o produto, portanto, devem ser escritas pela perspectiva do usuário. Além disso, elas auxiliam a identificar uma funcionalidade específica que o usuário deseja, e que traga valor ao produto. Caso não se saiba quem é o usuário e o porquê ele gostaria de determinada funcionalidade/produto/usabilidade, então nenhuma estória deve ser escrita. Primeiro procure entender a real necessidade do usuário, seja observando usuários, seja conversando, caso contrário corre-se o risco de criar estórias especulativas baseadas em crenças e ideias, e não em evidências. 2. Use Personas para descobrir a estória certa Uma excelente técnica para ter insights sobre os usuários é trabalhar com personas. Personas são personagens fictícios baseados em um conhecimento prévio que se tenha a respeito do grupo alvo de determinada estória. Normalmente, possuem um nome, uma foto, características, comportamentos e atitudes relevantes e, obviamente, um objetivo. Este objetivo é o benefício que a persona deseja atingir, ou o problema ela deseja ver solucionado ao usar o produto. A persona auxilia também a descobrir as estórias certas para cada situação. Basta perguntar para você mesmo “Qual funcionalidade o produto deve conceder para que a
  2. 2. as personas atinjam seus objetivos?”, respondendo esta pergunta, chega-se a estória adequada a determinado grupo. 3. Crie estórias de forma colaborativa Estórias de usuários não são especificações, mas sim uma ferramenta de comunicação e colaboração, portanto, nunca devem ser escritas sem o time que as desenvolverá. Elas devem ser embasadas em uma conversação, o PO e o time devem discutir a estória juntos. É sempre interessante estender isso não somente à discussão, e realizar também a escrita da estória de forma colaborativa. Isto promove a imaginação e agrega conhecimento para o time, resultando em estórias escritas cada vez melhores. 4. Mantenha suas estórias simples e concisas As estórias devem ser escritas de forma que sejam facilmente entendidas pelo time de desenvolvimento, mantendo-as simples e concisas. Evite termos confusos e ambíguos e use voz ativa, lembre-se também de focar no que é importante e esqueça o resto. Uma boa estória deve ser entendida por qualquer um que faça parte do time, em qualquer situação e a qualquer momento. Em termos gerais uma estória deve responder a 3 questões simples:  Quem? – É aquele que demonstrou a necessidade, a quem esta estória representa. Use a frase “Eu,.......” ou “Eu, como ........”, substituindo o “........” por aquele que precisa que determinado problema seja resolvido.  O que? – É o que esta pessoa deseja, o que ela enxerga como solução dos problemas dela, como uma melhoria na rotina diária dela, ou como uma redução
  3. 3. dos desperdícios dela. Use verbos como “Precisar”, “Desejar”, “Querer” e “Ter necessidade”.  Por que? – É porquê está pessoa deseja o “O que”, ou seja, é o que esta pessoa entende como o resultado da solução, o benefício que enxerga como essencial. Usualmente está posterior a palavra “pois”. Exemplo: Eu, operador de caixa, preciso cancelar um item de uma compra, pois o cliente não pode ficar aguardando uma terceira pessoa autorizar o cancelamento. 5. Inicie com épicos Épicos são estórias grandes, não refinadas, genéricas, e que serão repartidas em várias estórias posteriormente. Ao iniciar com épicos, permite-se esboçar a funcionalidade do produto sem entrar a fundo em detalhes, auxiliando o time a entender o contexto de forma mais ampla e entregar de forma mais assertiva o desejo do usuário.
  4. 4. Além disso, reduz o tempo e esforço para se ter insights, já que a contextualização genérica permite que a criatividade e as ideias fluam de forma mais ampla. Caso inicie diretamente com estórias muito detalhadas em seu backlog, corre-se o risco de gerar informações inconsistentes, pois elas podem não estar correlacionadas. 6. Refina suas estórias até que elas estejam prontas para produção Quebre os épicos em pequenas estórias, quantas vezes forem necessárias, até que elas estejam claras, possíveis de serem produzidas em uma sprint e sejam passíveis de testes. Todos os membros do time de desenvolvimento devem compreender de forma fácil o significado da estória. Ainda, deve-se ter uma forma adequada de determinar que a estória está pronta, ou seja, que foi produzida. 7. Adicione critérios de aceite Conforme os épicos vão sendo quebrados em estórias menores, lembre-se de adicionar critérios de aceite, ou seja, complementos à narrativa que permitem que sejam descritas as condições para que a estória seja aceita como desenvolvida. Eles são importantes pois enriquecem a estória, tornam-na testáveis, e asseguram que seja possível demonstrar a capacidade do produto ao usuário. Não existe uma regra geral para o número de critérios de aceite, porém vale citar que, caso haja um número excessivo, cabe o questionamento quanto ao tamanho da estória. Excesso de critérios de aceite demonstram que a estória pode ser quebrada em outras estórias. 8. Use cartões de papel Na criação de softwares é até estranho citar cartões de papel, mas sua utilização traz dois benefícios:  Facilitam uma maior colaboração da equipe, pois qualquer um pode pegar um cartão, a qualquer momento e anotar uma ideia;  Podem ser facilmente agrupados em mesas, paredes ou janelas, para checar consistência, o quanto da necessidade foi atendida, e visualizar dependências.
  5. 5. Mesmo que as estórias estejam guardadas de forma eletrônica, vale a pena utilizar o papel como forma de promover melhor a discussão. 9. Mantenha suas estórias visíveis e acessíveis Estórias servem para comunicar informação, sendo assim, não as esconda em um HD, Cloud ou qualquer similar. Torne-as visíveis, por exemplo, colocando-as em uma parede. Esta atitude promove a colaboração, cria transparência e torna óbvio quando há uma demanda muito alta, já que o local onde você está colocando essas estórias ficará lotado rapidamente. 10. Não confie apenas em estórias de usuários Criar uma excelente experiência para seus usuários requer muito mais que estórias. Elas são ferramentas para capturar as funcionalidades do produto, mas não são boas para descrever a “jornada” do usuário na utilização do produto, e nem o visual do produto. Sendo assim, complemente as estórias com outras técnicas, como Fluxogramas (Exemplo no Anexo A), Mapa de estórias (Story Map, exemplo no Anexo B), rascunhos de layouts e mockups.
  6. 6. Além disso, estórias de usuários não são boas para capturar requerimentos técnicos. Caso seja preciso comunicar estas questões utilize estórias técnicas ou UML – Unified Modeling Language. BÔNUS Ao responder “Sim” às 6 perguntas abaixo, sua estória estará pronta para desenvolver:  A estória é independente, ou seja, se sustenta sozinha sem a dependência de outra estória?  A estória pode ser negociável, ou seja, mudada ordem de desenvolvimento ou até mesmo removida sem impactar outras estórias?  A estória entrega valor ao usuário final, ou seja, o usuário terá algum benefício financeiro, tempo, agilidade, comodidade, usabilidade ou assertividade perceptível?  A estória pode ser estimada, ou seja, é possível prever uma pontuação de dificuldade de desenvolvimento para ela?  A estória é pequena, ou seja, tem o tamanho suficiente para caber dentro de uma Sprint apenas?  A estória é possível ser testada, ou seja, é possível verificar se o que ela solicita pode ser verificada? Nota: No Anexo C deste documento encontram-se exemplos de épicos e estórias que surgiram a partir destes épicos.
  7. 7. ANEXO A - Fluxograma
  8. 8. ANEXO B – Mapa de Estórias
  9. 9. ANEXO C – Exemplo de Épico e Estórias Verde – Who? (Usuário/Persona) Vermelho – What? (Desejo, interesse) Azul – Por quê? (Motivo, valor) Épico 1 – Eu, como cliente, desejo visualizar os produtos mais vendido, pois gostaria de comprar um ou mais deles. Estória 1.1 – Eu, como cliente, desejo organizar os produtos mais vendidos por preço, pois assim consigo ver o mais barato por primeiro. Estória 1.2 – Eu, como cliente, desejo organizar os produtos mais vendidos por popularidade, pois assim consigo ver o mais popular por primeiro. Épico 2 – Eu, como administrador, preciso fazer a gestão dos usuários, pois assim consigo manter organizado o banco de dados. Estória 2.1 – Eu, como administrador, preciso criar um novo usuário, pois assim posso adicionar um novo empregado ao sistema. Critério de Aceite 2.1.1 – Quando criado cadastro, preciso adicionar um e-mail de contato a este usuário. Critério de Aceite 2.1.2 – Quando criado cadastro, preciso adicionar uma foto a este usuário. Critério de Aceite 2.1.3 – Quando criado cadastro, preciso adicionar um número de telefone/celular a este usuário. Estória 2.2 – Eu, como administrador, preciso visualizar o cadastro de um usuário, pois assim posso assegurar que as informações que ali contem são verdadeiras. Estória 2.3 – Eu, como administrador, preciso editar um cadastro de usuário, pois assim consigo corrigir erros. Critério de Aceite 2.3.1 – Quando feita alguma alteração, o sistema precisa me avisar caso eu tente sair da edição sem salvar. Estória 2.4 – Eu, como Administrador, preciso apagar o cadastro de um usuário, pois assim posso remover um empregado quando este for demitido.

×