Como rastreamos os detalhes de uma história de usuário?[fechado]

Question

Portanto, se uma história de usuário for algo nebuloso como:

Como representante de vendas, gostaria de capturar as informações de contato para poder acompanhar mais tarde.

Nem tenho certeza se essa é uma história de usuário válida, mas tenho certeza de que está próxima o suficiente.

Depois, há detalhes/tarefas para implementar essa história de usuário.E tenho certeza de que "O representante de vendas deve ser capaz de ir de uma caixa de texto para outra." é um dos requisitos.Como capturamos/rastreamos isso?Isso faz parte da história do usuário ou é algo que deve ser considerado separadamente?

Answer 1

Uma história do usuário captura a essência de um recurso, não os detalhes, uma história é um suporte para a discussão.

Então, para responder à sua pergunta, os detalhes são transmitidos por via oral durante uma discussão, porque a discussão cara a cara é a mídia de comunicação mais eficaz. Se você sentir a necessidade, os detalhes podem ser capturados como notas na parte traseira do cartão (se você estiver usando cartões) ou ... em um "notas"Campo se você estiver usando uma ferramenta eletrônica. Na verdade, eu costumo usar um"como demonstrar"Campo também para capturar uma descrição de alto nível de como essa história será demonstrada na demonstração da Sprint e usará" Notas "muito breves para qualquer outra informação, esclarecimentos, referências a outras fontes de informação, etc. (Créditos ao famoso de Henrik Kniberg. Gerador de cartão de índice). Se encontrar isso muito útil, especialmente ao usar especificações executáveis.

PS: sua história é perfeitamente válida e é uma boa prática incluir os benefícios em seu modelo ("como um Função, Eu quero ação de modo a benefícios").

Answer 2

As histórias de usuário devem ser declarações curtas em 1 a 3 frases.

http://en.wikipedia.org/wiki/user_story

Quero poder guiar de uma caixa de texto para outra é outra história do usuário.

Você pode rastrear essas coisas em uma ferramenta como www.rallydev.com ou qualquer tipo de ferramenta de rastreamento de tarefas (SharePoint, Excel mesmo ... etc.).

A próxima coisa que você faz é priorizar.

Answer 3

Apenas dando uma facada violenta...

Como representante de vendas,
Quero que toda entrada de dados e navegação sejam realizadas usando o teclado
para que eu não precise tirar as mãos do teclado
(e para que cumpramos as diretrizes de acessibilidade).

Ou

Como um negócio,
Queremos que todos os nossos produtos sejam totalmente utilizáveis ​​usando apenas a entrada do teclado
Para que possamos vender para clientes que necessitam de software acessível.

Answer 4

A primeira parte pertence a um documento "requisitos de negócios" (geralmente escrito por um analista de negócios). As primeiras gerações deste documento são de alto nível, mas as versões finais (várias iterações depois) são bastante detalhadas.

http://www.tdan.com/view-articles/6089

A segunda parte (sobre tabbing) faz parte de outro documento - "UX Spec" (mostra todas as telas e descreve a interação do usuário). Este é geralmente escrito por uma pessoa/equipe diferente (produto ou equipe UX).

http://uxdesign.com/ux-defined-2

http://www.uxmatters.com/mt/archives/2007/05/sharing-ownership-ox-ux.php

Answer 5

Sim, esse é um problema que também temos muito. Por um lado, as histórias de usuários precisam ser conscientes, por outro lado, todos os detalhes da questão devem ser colocados em algum lugar.

Usamos o XPlanner e resolvemos isso colocando a descrição curta no corpo de texto da história do usuário. Em seguida, usamos o recurso XPlanners "Notes" (texto ou arquivos arbitrários que podem ser anexados a uma história do usuário) para obter detalhes.

Dessa forma, podemos adicionar o máximo de informações necessárias à história do usuário, sem atravessar a história da história do usuário. Você também pode consultar a documentação externa, se não quiser ter tudo no XPlanner.

Essa abordagem funciona muito bem para nós.

Answer 6

Concorde com os outros, que essa é uma história viável, mas capture os requisitos (derivados) podem ser melhor capturados em outros lugares.

Desenvolvedores de software e tipos de negócios estão familiarizados com a terminologia diferente, algumas do que pode ser simples de entender por uma (estruturas de dados) pode não significar nada para outro. As histórias de usuários são uma ferramenta ou um meio pelo qual o usuário comercial pode transmitir uma mensagem como ponto de partida que é expandido (com testes, detalhes, etc.).

A comunicação oral pode ser eficaz, mas a eficácia depende da capacidade dos receptores de ouvir e compreender o significado da mensagem. É aqui que a comunicação oral pode falhar. Diferentes tipos de comunicação Ocorrendo formas mais ou menos formais de comunicação. A comunicação vocal é uma "forma informal de comunicação" que arrisca a mensagem sendo maluca, mal interpretada e mal -entendida. Assim como o jogo jogou quando criança, onde uma criança sussurra uma mensagem para outra criança, que diz a outra, até que tudo o ouça ... quando a última criança diz a mensagem ao grupo, ela geralmente foi mal interpretada e mal interpretada novamente, causando uma mensagem degradada.