Cómo lidiar con historias que comparten funcionalidad

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

1. Como usuario de Credit Management, puedo ver las diferencias de nómina actuales y anteriores para las oficinas.
2. Como usuario de Credit Management, puedo recibir un correo electrónico que contiene un PDF con las diferencias de nómina actuales y anteriores para las oficinas.

Los dos están relacionados porque 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 incluso 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 fuera de línea, ¿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 para las oficinas.

2. Como usuario de Credit Management, 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 Credit Management, puedo solicitar recibir un correo electrónico que contenga un PDF con las diferencias en la nómina actual y anterior de las oficinas.

El problema al que vuelvo es que las 4 historias no son independientes y no "cortan el pastel".

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

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 se solape la implementación del sistema. Las Historias de usuarios no están destinadas a describir dicha superposición funcional o eliminarla. El propósito de User Stories es capturar expectativas funcionales desde el punto de vista del usuario, no describir detalles de implementación.

No: intente dividir las historias, haga una historia y luego la otra.

Hacer: Asegúrate de que el equipo de desarrollo conozca la segunda historia.

El problema al tratar de planificar las tareas detalladas y crear un modelo genérico que pueda manejar ambos de una manera elegante es que es difícil.

El propósito de las historias de usuarios es hacer cosas. Elegante es un objetivo secundario y debe dejarse a refactorizar.

Obviamente es muy molesto si lleva esto al máximo y no le cuenta a nadie sobre las otras diez tareas similares que deben realizarse, pero también es totalmente concebible que la segunda o tercera tarea no se piense hasta que se complete la primera. Si quieres planearlo todo ve con cascada.

En un acuerdo violento con Robert Harvey, el propósito de una historia de usuario es comprender lo que el usuario debe poder hacer. A medida que se prepara, el cliente comprende y se preocupa por la historia del usuario, pero a los desarrolladores les importa un poco más. Una vez que haga suficientes preguntas para comprender y estimar el trabajo, puede crear tareas para apoyarlos.

En este caso particular, podría crear tareas que permitan el núcleo de ambas historias de usuario que se realizarían junto con lo que aborde primero.

Las cosas importantes para agregar a la historia del usuario son:

• Criterios de aceptación
• Supuestos

Hablando estrictamente, las Historias de usuarios son la promesa de una conversación para comprender el resultado requerido.

Por ejemplo, tomar tu segunda historia de usuario

Como usuario de Credit Management, puedo recibir un correo electrónico que contiene un PDF con las diferencias de nómina actuales y anteriores para las oficinas.

Piensa en lo siguiente:

• ¿Cuál es la "necesidad" del usuario que impulsa este requisito? (¿El PDF en un correo electrónico como solución proviene de ellos? Esto podría no abordar la necesidad y su equipo podría encontrar una mejor solución)
• ¿Cuál es el segmento mínimo que puede abordar la "necesidad" de este usuario y validar su solución? Los circuitos de retroalimentación cortos son valiosos.

Cuando se acerque a la división de la historia, recuerde sus criterios de INVERSIÓN cuando sea posible.

1. Yo independiente
2. N egotiable
3. V valioso
4. E stimatable
5. Centro comercial
6. T estable

Está bien tener historias que tengan un orden natural. Tenga esto en cuenta: por lo general, la primera historia es más grande ya que brinda la funcionalidad requerida y la segunda historia se basa en ella.

Desafiaría las historias "técnicas", ya que generalmente es más probable que sean tareas para ayudar a apoyar la implementación de las historias centradas en los resultados del usuario.

TL; DR

Suponiendo que ambas historias de usuario se encuentren dentro del alcance dentro de la misma iteración, el trabajo del equipo es descomponer las historias en un plan de implementación y sus tareas correspondientes. Las historias de usuarios proporcionan contexto y alcance; no son implementaciones, especificaciones o elementos de la lista de perforación.

Las historias deben descomponerse en tareas de iteración

Ya sea que esté siguiendo Scrum o alguna otra metodología ágil, es un error común omitir la fase de planificación de una iteración. En Scrum, cuando un elemento del Backlog del producto (no tiene que ser una historia de usuario, estrictamente hablando) se incorpora al Sprint actual, se supone que el equipo debe usar parte de Sprint Planning para factorizar los puntos en común entre los elementos de trabajo, identificar dependencias y luego desarrolle un Backlog de Sprint para capturar el trabajo a nivel de tarea.

Como señaló en su publicación, no es raro (y de hecho es deseable) que una iteración ágil contenga historias de usuarios estrechamente relacionadas. En Scrum, esto aparece a través del uso del Objetivo Sprint. Fuera del marco de Scrum, a menudo todavía tiene sentido extraer historias relacionadas debido a sus objetivos compartidos o dependencias compartidas. Al extraer y luego trabajar en las dependencias compartidas dentro de una única iteración, los equipos a menudo pueden evitar la necesidad de refactorizar o iterar sobre el código para características similares pero no idénticas en el futuro.

Tareas Implementar historias

Aquí hay otra forma de pensar sobre la planificación de dependencia para las historias de usuarios. En general:

1. Una epopeya / tema se utiliza para la planificación a largo plazo o la agrupación en una cartera.
2. Una historia de usuario se utiliza para comunicar objetivos, contexto y alcance.
3. La planificación justo a tiempo se utiliza para desarrollar una implementación que se ajuste a una sola iteración.
4. Las tareas implementan el plan justo a tiempo que cumple con la definición de Hecho para una o más historias de usuario.

La mayoría de los profesionales consideran que tratar las historias de los usuarios como un plan de implementación o una lista de tareas es un antipatrón ágil. Independientemente de cómo elija llamarlo, no omita la fase de planificación justo a tiempo de su marco ágil y asegúrese de rastrear las dependencias y los detalles de implementación compartidos en algún lugar dentro del proceso de su equipo.