¿Cómo se organiza una historia de usuario?En un desarrollador ágil, ¿cómo organizas historias de usuarios?
Lo que hice fue esto para una aplicación web:
Hecho el título de una página web como 'índice', a continuación, una lista de los almacenes, el usuario puede hacer en esta página.
continué para todas las páginas.
Es esta la forma más eficaz?
La segregación de historias de usuario por "página web" no me parece óptima; debe elegir el conjunto de páginas basado en historias de usuarios, y no al revés. Clasificaría por "papel" del usuario, de hecho, en diseño centrado en el usuario, en el "persona" en juego.
En nuestra tienda, escribimos Use Cases. Ejemplos de Casos de uso:
Create New Customer Account
Assign User Rights
Receive Order
Accept Payment
Tenemos un formulario con dos columnas. La primera columna es el usuario, y la segunda columna es el sistema informático. En las dos columnas, comenzamos a enumerar las acciones. El usuario hace esto, el sistema responde así, etc. Dejamos huecos entre las entradas para que los pasos fluyan naturalmente de izquierda a derecha y de nuevo. Hay un lugar en el formulario que indica a qué roles se aplica el caso de uso (por ejemplo, Administrador de proyectos, Administrador).
A partir de los casos de uso, comenzamos a crear páginas web.
También puede hacer diagramas de casos de uso:
que empezar con la identificación de lo que es escenario de los usuarios van a realizar con la aplicación. Normalmente, estos son bastante predicables. Un usuario inicia sesión en un sitio web con una determinada tarea en su cabeza y desea cumplir esa tarea.
Me limitaría a un escenario como una lista de pasos secuenciales. Por ejemplo, el usuario inicia sesión, el usuario selecciona el producto, el usuario elige la cantidad, el usuario se retira, finaliza.
Tener el escenario anotado también puede ayudarlo a determinar qué partes de la aplicación son más importantes que otras, y qué situaciones se pueden implementar fácilmente "en el medio". Y finalmente, qué escenario podría ser un tope de show para el lanzamiento de la aplicación.
personalmente me gusta las historias de usuario de estilo de TDC y tareas. En general, en virtud de BDD/Agile va a crear historias de usuario en una reunión de planificación en los siguientes términos:
As a [role] I need [capability] so that [desired outcome].
Una historia de usuario en realidad no debería ser más complejo que eso, ya que en realidad sólo son marcadores de posición para futuras conversaciones (un aspecto clave de Agile que la mayoría de las empresas malinterpreta.) Una vez que llegue al punto en una iteración en que está dispuesto a poner en práctica una historia de usuario, se generará una o más tareas para que la historia lo general en forma de preocupación/Contexto/Observaciones:
preocupación: algunos Actividad
Contexto: al hacer tal y tal
Observación: Esta cosa debe ser añadido a la base de datos
Observación: lo debe recibir un nuevo identificador único
Observación: La cosa debe estar relacionada con esa cosa
Cada tarea ahora está escrita de tal manera que se puede traducir directamente a una prueba de "especificación" de estilo BDD que configura el contexto, realiza la acción de preocupación y verifica las observaciones. (Para obtener un excelente ejemplo de cómo funciona esto con xUnit.NET, see this site.)
Al crear historias de usuario, no es importante pensar demasiado técnicamente. En realidad, no desea dividir sus historias en elementos altamente técnicos y de bajo nivel como "Crear una página web con el título 'xyz'. Mostrar las tiendas a, byc en esta página". Eso es súper técnico y no retrata ningún requisito comercial útil. Una historia debe ser más fluida y dinámica y representar el requisito comercial real: "Como cliente, necesito ver todas las tiendas que contienen los productos que estoy buscando para poder comprar lo que necesito a un gran precio". A partir de esa historia de usuario, terminaría con tareas que definen los aspectos más técnicos de la creación de esta página (estoy extrapolando mucho de lo que leí en su pregunta ... perdóneme por cualquier licencia artística que tenga al expandir el concepto).):
Preocupación: Encontrar Tiendas
Contexto: Cuando se busca un producto con el mejor precio
Observación: la página web debe mostrar una cuadrícula de miniaturas almacenar las imágenes que contienen buscan los usuarios de productos
Observación: Las tiendas deben e ordenadas de tal manera que los que tienen el precio más bajo aparece en la parte superior de la página
Observación: Al hacer clic en la miniatura de una tienda me debería llevar a una página en la que se almacena el sitio web que contiene el producto, el usuario busca
La historia anterior es bastante alto y cubre el comportamiento esperado de toda la página. La especificación anterior se puede usar para verificar el comportamiento correcto de la página resultante, utilizada como referencia para crear pruebas de UI automáticas, etc. Sin embargo, también habrá código que maneja esta página, y se deben crear tareas adicionales para las cosas de nivel inferior como bien.
Preocupación: Recuperando Tiendas
Contexto: Durante la búsqueda de entidades memoria que contiene un producto específico
Observación: Una colección de StoreResultDetail debe ser devuelto
Observación: La colección de tiendas puede ser vacío
Observación: Cada StoreResultDetail debe contener el nombre de la tienda
Observación: Cada StoreResultDetail debe contener el precio del producto
Observación: Cada StoreResultDetail debe contener la dirección URL de la página web de la tienda
Observación: Cada StoreResultDetail puede contener la dirección URL del producto en el sitio web de esa tienda
La tarea anterior podría implementarse mediante un método de servicio en algún servicio, junto con cualquier otro comportamiento requerido para implementar la especificación para toda la página.
Una vez que tenga sus tareas, puede crear diseños visuales para unir, implementar códigos y pruebas unitarias (o especificaciones BDD) y QA probar su aplicación con documentación adecuada, clara y concisa para verificar sus pruebas.
Los agrupamos por características, o mejor, características mínimas comercializables (MMF) para que añadan valor al producto. De hecho, por ejemplo, no hay forma de mostrar algo que no se puede crear o de crear algo que aún no se puede ver. Entonces, agrupamos la creación/visualización para que se entreguen juntas. Las actualizaciones y eliminaciones pueden venir más tarde, YMMV.
Me gusta mucho esto. Entonces, ¿la observación se vuelve tan técnica como puede obtenerse? ¿Contendría cosas como "el usuario debería poder tabular el siguiente cuadro de texto"? –