¿Cómo hacemos un seguimiento de los detalles de una historia de usuario? [cerrado]

Question

Así que si una historia de usuario es una nebulosa algo como:

Como representante de ventas, me gustaría capturar la información de contacto para que pueda seguir adelante.

Ni siquiera estoy seguro de si eso es una historia de usuario válido, pero estoy seguro de que es lo suficientemente cerca.

A continuación hay detalles / tareas de aplicación de esta historia de usuario. Y estoy seguro de "El representante de ventas debe ser capaz de pestaña de un cuadro de texto a otro." es uno de los requisitos. ¿Cómo captura / seguimiento de esto? Es esta parte de la historia de usuario o se trata de algo que es para ser considerado por separado?

Answer 1

Una historia de usuario captura la esencia de una característica, no los detalles, una historia es un apoyo para la discusión.

Así que, para responder a su pregunta, los detalles se transmiten oralmente durante una discusión, porque discusión cara a cara es la medios de comunicación más eficaz. Si usted siente la necesidad, los detalles pueden ser capturados como notas en la parte posterior de la tarjeta (si está utilizando tarjetas) o ... en un " Notas " campo si está utilizando una herramienta electrónica. En realidad, por lo general uso un " ¿Cómo hacer una demostración " campo demasiado para capturar una descripción de alto nivel de cómo se demostrará esta historia en la demo del sprint y un uso muy breves "notas" para cualquier otra información, aclaraciones, las referencias a otras fuentes de información, etc (créditos a la famosa tarjeta de índice generador ). Si encuentra este muy útil, especialmente cuando se utilizan las especificaciones ejecutables.

PD: su historia es perfectamente válido y es una buena práctica incluir los beneficios en su plantilla ( "Como función , quiero acción para que beneficios ").

Answer 2

Historias de usuarios deben ser breves declaraciones en 1 a 3 frases.

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

Quiero ser capaz de pestaña de un cuadro de texto a otro es otra historia de usuario.

Puede realizar un seguimiento de estas cosas en una herramienta como www.rallydev.com, o simplemente cualquier tipo de herramienta de seguimiento de tareas (SharePoint, Excel, incluso ... etc.).

La siguiente cosa que se hace es priorizar.

Answer 3

Sólo tomando una puñalada en bruto ...

  

Como representante de ventas,
  Quiero toda la entrada de datos y la navegación a llevarse a cabo utilizando el teclado
  de modo que yo no tengo que tomar mis manos del teclado
   (y por lo que cumplimos con las directrices de accesibilidad) .

o

  

Como negocio,
  Queremos que todos nuestros productos sean plenamente utilizable sólo con la entrada de teclado
  Por lo que podemos vender a los clientes que requieren software accesible.

Answer 4

La primera parte pertenece a un documento "requisitos de negocio" (normalmente escrito por un analista de negocios). Las primeras generaciones de este documento son bastante alto nivel, pero las versiones finales (después de varias iteraciones) son bastante detallada.

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

La segunda parte (aproximadamente tabbing) es parte de otro documento - "UX spec" (muestra todas las pantallas y describe la interacción del usuario). Éste se escribe generalmente por una persona / equipo diferente (producto o equipo UX).

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

http: //www.uxmatters .com / tm / archives / 2007/05 / compartir la propiedad de ux.php-

Answer 5

Sí, esto es un problema también tenemos un montón. Por un lado, las historias de usuario deben ser Conscise, por el contrario todos los detalles Nitty Gritty se deben poner alguna parte .

Utilizamos xplanner, y resolvemos esto poniendo la breve descripción en el cuerpo de texto de la historia de usuario. Luego usamos XPlanners "notas" característica (o archivos de texto arbitraria que se pueden conectar a una historia de usuario) para los detalles.

De esta manera podemos añadir mayor cantidad de información necesaria para una historia de usuario, sin estorbar encima del propio texto de la historia de usuario. También puede hacer referencia a la documentación externa, si no quieren tener todo en xplanner.

Este método funciona bastante bien para nosotros.

Answer 6

De acuerdo con los demás, que esta es la historia viable, pero la captura de los requisitos (derivados) pueden ser mejor capturados en otro lugar.

desarrolladores de software y Business tipos están familiarizados con la terminología diferente cierta lo que puede sencillo de entender por (estructuras de datos) uno puede significar nada a otro. Los casos de uso es una herramienta o un medio por el cual el usuario de negocio puede transmitir un mensaje como punto de partida que se expande en (con pruebas, detalles, etc.).

Comunicación oral puede ser eficaz, pero la eficacia depende de la capacidad de los receptores para escuchar y comprender el significado del mensaje. Aquí es donde la comunicación oral puede fallar. Diferentes tipos de comunicación offerring más o menos formales formas de comunicación. La comunicación vocal es una "forma informal de la comunicación", que corre el riesgo de que el mensaje sea escuchado mal, misinterpretted, y la incomprensión. Al igual que el juego que se juega como un niño, donde un niño susurra un mensaje a otro niño, que le dice a otro, hasta que todos hayan oído ... Cuando el último hijo dice que el mensaje para el grupo por lo general ha sido mal interpretado entonces misinterpretted de nuevo, causando un mensaje degradado.