Como estudiante de sistemas ágiles/scrum, encuentro muy difícil la situación en la que tienes que escribir una historia de usuario en la forma clásica y, al mismo tiempo, describir el comportamiento del flujo de trabajo paralelo. Como un ejemplo muy simple y general que puede describir la situación, podemos escribir esta historia de usuario:
Como usuario que quiere comprar un artículo, quiero poder pagar con MasterCard, para que el pedido comprado pueda establecerse en estado 'para entregar'.
En esta historia de usuario, hay toneladas de diferentes "flujos de trabajo alternativos de tareas de usuario" o situaciones que pueden definir diferentes procesos (no necesariamente errores), como:
Mientras un cliente realiza un pedido, su tarjeta de crédito falló
Mientras un cliente realiza un pedido, su sesión de usuario se agota
Mientras un cliente usa un cajero automático, la máquina se queda sin recibos y necesita advertir al cliente
Mientras un cliente realiza un pedido, su número de tarjeta de crédito no existe
Mientras un cliente realiza un pedido, el PIN falló
(quizás no son los mejores ejemplos, pero solo para describir los efectos secundarios).
En el sistema Agile/Scrum, solo puede describir el comportamiento deseado, pero no los efectos secundarios/flujos de trabajo paralelos.
Mis preguntas:
¿Cómo me aconsejas que incluya las historias pendientes que cubran estas situaciones?
¿Cómo me aconsejan que cree historias que sigan un "Diagrama de flujo de trabajo del proceso de tareas"? (esta segunda pregunta es diferente pero relacionada)
Una de las buenas técnicas que usan los equipos es escribir los criterios de verificación de la historia del usuario en el reverso de una nota adhesiva o en información adicional de la historia del usuario (si usa una herramienta electrónica). Todos estos escenarios detallados que menciona funcionan bien como criterios de verificación y usarlos como tales significa que no perderá esta información adicional.
Personalmente, no recomendaría crear historias de usuario separadas, ya que entraría en tantos detalles que tendría que enfrentarse a muchos problemas para hacer malabarismos con todas las historias, aunque también se podría considerar una alternativa viable.
Y, sobre todo, no se apegue demasiado a un formato específico de historias de usuario . Si necesita y desea información adicional, simplemente escríbala y adjúntela de alguna manera. Su objetivo debe ser la comprensión común del trabajo que se debe realizar y no seguir la definición del libro de la historia del usuario. La historia del usuario es solo un medio para lograr un objetivo de comprensión común, por lo que siempre que el equipo comprenda la influencia de la historia en el flujo de trabajo alternativo, lo hará bien.
Tiene una buena pregunta, y creo que mirar la historia del usuario puede ayudar a desglosar algunas partes del problema. Mi reacción inicial es que, como usuario, no le importa el estado de la orden de compra, eso no es importante para usted.
La historia de usuario puede ser mucho más simple y ser As a user you want to be able to use Mastercard to purchase an article. Esto implica:
Historias de usuarios adicionales:
De su ejemplo, hay estos siguientes, que deben investigarse:
While a customer places an order, their user session times out
As a user when I place my order, I expect not be charged twice nor get multiple orders without paying, y del mismo modo, `Debería poder buscar mi pedido y comprender el estado.While a customer uses an ATM machine, the machine runs out of receipts and needs to warn the customer
As a user when I ask for a receipt but there are none, I expect to emailed the receiptAs a user I expect a transaction to be declined if there are no receipts available but I want one.While a customer places an order, their credit card number doesn't exist
As a user, when I enter an invalid credit card (for whatever reason) I should be notified before the order is placed, so I can correct itAs the finance department when a invalid credit card is entered send an automated email to the user to indicate their order will be cancelled unless they fix the credit card number. Finance también puede ser su usuario, no solo su cliente.While a customer places an order, the PIN failed
As a user when I enter an invalid PIN, I should be alerted to enter a valid oneif this happens more than 3 times, I want my card to be destroyed in case of theft.Para el consejo específico:
¿Cómo me aconsejas que incluya las historias pendientes que cubran estas situaciones?
and also all other user stories, eso es cierto de facto.¿Cómo me aconsejan que cree historias que sigan un "Diagrama de flujo de trabajo del proceso de tareas"? (esta segunda pregunta es diferente pero relacionada)
ben k