¿Cómo formateo las historias de usuario negativas?

9

Siguiendo el estilo formal de la historia del usuario:

Como <user>, quiero <goal>que eso <benefit>.

Nuestro equipo ha encontrado dificultades para expresar cosas donde los propietarios del sistema desean hacer algo que afecte negativamente al usuario.

Como ejemplo arbitrario, supongamos que el propietario quiere que el sistema cobre a los clientes cada vez que revisen su correo electrónico.

Siguiendo el estilo formal de las historias de usuarios, puede escribir esto de la siguiente manera:

Como cliente, quiero que me cobren cada vez que reviso mi correo electrónico para que el propietario del sistema pueda aumentar sus ingresos.

Obviamente, el cliente no desea ser acusado; la historia se vuelve desagradable de leer y el lenguaje se interpone en el camino de los hechos.

¿Cómo podría escribirse el requisito de manera diferente?

user-story Paul Turner
fuente
1
¿Tiene problemas para escribir la historia o crear algo que no cree que sea ético?
JeffO

Respuestas:

24

Si pagar dinero afectara negativamente a los clientes, no estarían usando ese servicio. No te preocupes por esto. Además, los usuarios (generalmente) no pagan dinero porque quieren ayudar a los propietarios del sistema, sino porque quieren algún servicio a cambio, por lo que su ejemplo debería ser así:

Como cliente, quiero que me cobren cada vez que reviso mi correo electrónico para poder obtener el servicio X a cambio.

Además, las historias de los usuarios se escriben desde la perspectiva de todos los roles de los usuarios, no solo de los clientes finales. Considere escribir esto desde la perspectiva del propietario del sistema como otra función de usuario:

Como propietario del sistema, quiero que se cobre a los clientes cada vez que revisen su correo electrónico para aumentar mis ingresos.

Un consejo general: concéntrese en la parte positiva de la historia del usuario y no piense demasiado. Deberían ser simples. Si la historia del usuario es muy negativa, sin una forma de evitarla, entonces el problema está en la concepción del sistema, y ​​en ese caso realmente no importa lo que escriba en sus tarjetas.

Goran Jovic
fuente
El peligro de escribir desde la perspectiva del propietario del sistema es que todas las historias provienen esencialmente de los propietarios y el valor de la userparte de la historia disminuye.
Paul Turner
@ProgrammingHero: Esa es solo una alternativa que sugerí. :)
Goran Jovic
55
@ProgrammingHero Creo que puedes estar obsesionado con la semántica. El propietario del sistema puede ser el propietario del sistema (por ejemplo, propietario del producto). Este propietario del sistema también puede ser un rol de usuario único en el software mismo. La historia del usuario debe escribirse contra el rol o tipo de usuario que resulta ser Propietario del sistema, donde como Propietario del sistema la persona es una persona en el rol de Propietario del producto de un equipo de desarrollo de software, que en realidad es completamente diferente.
maple_shaft
44
Aquí @Programming: recordar que existe la historia de servir a usted - a decir que por qué se necesita la función y quién se beneficia. Si beneficia a la empresa, dígalo en la historia para que el equipo tenga claro por qué existe la función. La tarjeta existe para la transparencia, entre otras cosas. Saber que está haciendo algo que no beneficia al usuario es algo bueno .
Bryan Oakley
11

El <user>no tiene que ser el usuario final - que puede fácilmente ser el dueño del propietario / sistema de negocio:

As a system owner
I want to charge customers
So that the business can pay my programmers
Oded
fuente
No creo que tener el propietario del sistema como usuario sea correcto; cada historia podría escribirse desde su perspectiva si este enfoque es válido.
Paul Turner
Además, entendí que la historia es una reacción a algo que el usuario hace (revisar su correo electrónico) en lugar de algo que hace el propietario del sistema, por lo que tenerlo desde la perspectiva del usuario parece más correcto.
JohnL 01 de
44
@JohnL: la historia no es una reacción a nada. Es una explicación de por qué está implementando la función. Sin embargo, aunque parezca que el usuario puede no beneficiarse, generalmente lo hacen. Incluso en este caso específico, se benefician porque cuando los cambie, la compañía será rentable, lo que le permite a la compañía continuar brindando el servicio al usuario.
Bryan Oakley
4

Las historias de usuarios no existen para cumplir algún tipo de requisito metodológico. Existen únicamente para aclarar qué está haciendo un equipo, por qué lo están haciendo y quién se beneficia de eso. Si tuerce las palabras para oscurecer el significado o se ajusta a algún requisito estricto de cómo se supone que debe ser una historia, no sirve a nadie.

Entonces responda la pregunta "quién se beneficia" y "por qué estamos implementando esto" honestamente. Su equipo de desarrollo necesita esta información para hacer su trabajo. Incluso si la historia es negativa desde el punto de vista del usuario, es información valiosa.

Dicho esto, lo que describe suena más como un escenario de caso de uso en lugar de una historia. Quizás si reduce esto a piezas más pequeñas, podría ser más claro quiénes son los propietarios y beneficiarios. Por ejemplo, la función de cobrar por consultar el correo electrónico tiene varios componentes. Como mínimo, hay un componente de interfaz de usuario y un componente de back-end, y quizás una regla de negocio.

Puede dividir su función en estas historias:

Como proveedor de un servicio de correo electrónico, quiero cobrar una tarifa por cada correo electrónico leído para poder ganar dinero y continuar brindando y mejorando el servicio.

Como usuario, quiero que el cobro de la tarifa por correo electrónico se realice automáticamente para que pueda leer mi correo electrónico sin tener que reconocer cada tarifa a medida que se cobra para que mi experiencia sea más agradable.

Como usuario, quiero poder revisar fácilmente los términos del servicio y los montos de las tarifas para comprender las tarifas que se cobran y poder confiar en que estoy obteniendo el valor de mi dinero.

Como usuario, quiero que la tarifa de cobro por leer el correo electrónico sea pequeña para poder usar este servicio

Bryan Oakley
fuente
2
Me gusta esta respuesta: existen metodologías para construir algo. Cuando se convierten en dogmas para ser seguidos a ciegas, ya no están cumpliendo su propósito.
Jay Elston
-1

Estoy de acuerdo en que escribirlo en términos del propietario del sistema parece incorrecto, porque el propietario del sistema no inicia esta historia; el usuario sí, cuando revisa su correo electrónico. Pero no creo que deba hablar en términos de lo que el usuario quiere, sino más bien de lo que espera que suceda.

As a customer
When I check my email
I should be charged
So I continue to recieve Service X

El usuario esperaría que le cobren porque le ha indicado su plan de pago.

JohnL
fuente
3
No importa quién "inicie" la historia. El objetivo de la historia es que el equipo comprenda el valor comercial de la historia. Algunas veces el valor comercial es mejorar la experiencia del cliente, otras no. Se honesto. No es que el cliente vea la tarjeta. El objetivo es asegurarse de que el equipo tenga claro por qué está haciendo algo. Si la realidad es que lo estás haciendo para extraer dinero del usuario, dilo. Sin embargo, si el objetivo real es permanecer en el negocio para poder servir al usuario, dígalo.
Bryan Oakley
1
Si así es como le enseñaron a escribir historias de usuarios, lamento informarle que se equivocó. Una historia de usuario define lo que un usuario necesita o no quiere lo que espera que suceda. El hecho de que se cobre por correo electrónico es simplemente un hecho. Como usuario, NECESITO que me cobren para poder revisar mi correo electrónico. Esta respuesta es objetiva e inequívocamente incorrecta y sugiero eliminarla.
maple_shaft
Supongo que no entendí bien, aunque sugeriría simplemente agregar eso como respuesta. Agradezco que me corrijan, el voto negativo no tanto . Y creo que importa quién inicia la historia porque así es como sé con qué historias estoy lidiando en este momento. No hay forma de que pueda tenerlos todos en mi cabeza a la vez, así que para saber qué sucede cuando un usuario revisa su correo electrónico, voy a la historia que comienza con As a user, when I check my email...Si no puedo hacerlo de manera confiable, las historias de los usuarios están fundamentalmente rotas. Lo siento.
JohnL
2
@JohnL: lo que estás describiendo suena más a escenarios de casos de uso que a historias de usuarios. Ambos formatos están bien para describir los requisitos de software, use el que mejor funcione para usted y se ajuste mejor a su flujo de trabajo de desarrollo.
Goran Jovic
2
Goran y Bryan hacen excelentes puntos. Parece que está lidiando con casos de uso porque las historias de usuario no lo benefician. Se supone que estas cosas ayudarán a que su proyecto tenga éxito, si cree que en general son un obstáculo general, entonces los casos de uso y las historias de usuarios probablemente le resulten poco o ningún beneficio y no debe obligarse a usarlas. Este es un escenario perfectamente legítimo cuando la lógica comercial real, la complejidad y el valor percibido por el usuario de su software son tan bajos que las historias de los usuarios son escasas o de conocimiento común.
maple_shaft