agile – Cómo lidiar con historias que comparten funcionalidades

Pregunta:

Tengo dos historias (sé que les falta la parte beneficiosa)

  1. Como usuario de gestión de crédito, puedo ver las diferencias de nómina actuales y anteriores de las oficinas.
  2. Como Usuario de Gestión de Crédito, puedo recibir un correo electrónico que contiene un PDF de las diferencias de nómina actuales y anteriores de las Oficinas.

Los dos están relacionados en el sentido de que tendrían los mismos criterios de consulta / filtro. La única diferencia es que en la historia "Ver", los resultados se muestran al usuario y en la historia "Correo electrónico", los resultados se escriben en un PDF que se envía por correo electrónico al usuario.

Estoy luchando con la separación de los aspectos comunes de estas dos historias o si debería hacerlo.

Por ejemplo, ambos tendrán la misma consulta, lo que hacen con los resultados es diferente.

¿Debo separar la consulta en otra historia que sea puramente técnica?

La creación del PDF y el envío del correo electrónico deben realizarse sin conexión, ¿debería convertirse en una historia técnica?

Pude ver dividir esas dos historias en 2 historias funcionales y 2 historias técnicas.

  1. Como Sistema, puedo calcular las diferencias en la nómina actual y anterior de las Oficinas.

  2. Como usuario de gestión de crédito, puedo ver las diferencias en la nómina actual y anterior de las oficinas.

  3. Como Sistema, puedo crear un documento PDF de las diferencias en la nómina actual y anterior para Oficinas.

  4. Como Usuario de Gestión de Crédito, puedo solicitar recibir un correo electrónico que contenga un PDF de las diferencias en la nómina actual y anterior de las Oficinas.

El problema al que sigo volviendo es que los 4 pisos no son independientes y no "cortan el pastel".

Así que no estoy muy seguro de cómo lidiar con estos dos.

Respuesta:

Las historias de usuario no son especificaciones del sistema ni requisitos funcionales. Más bien, son el comienzo de una conversación que puede conducir a tales especificaciones o requisitos.

En consecuencia, esperaría que hubiera una superposición en la implementación del sistema. Las Historias de usuario no están destinadas a describir dicha superposición funcional ni a eliminarla. El propósito de User Stories es capturar las expectativas funcionales desde el punto de vista del usuario, no describir los detalles de implementación.

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım