Cómo lidiar con historias que comparten funcionalidad

27

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.

agile requirements user-story Joe Young
fuente
44
si va a utilizar "historias técnicas de usuarios", tenga en cuenta que aquí hay 3 cosas, no 4. Las diferencias que calcula a partir de su modelo y dos tipos de vistas, una vista PDF y una vista GUI. Simplemente presenta el informe de manera diferente.
candied_orange
1
Aborda uno de ellos. Luego aborda al otro. Es así de simple.
Ant P
¿Por qué son dos historias?
JeffO

Respuestas:

55

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.

Robert Harvey
fuente
3
Estaba empezando a escribir algo muy similar, pero esta respuesta ya cubre todos los aspectos míos, por lo que +1
Doc Brown
Lo mismo aquí, mantenga la implementación fuera de ella.
candied_orange
1
@JoeYoung: los detalles de implementación van a la implementación, ¿dónde más? Y cómo le dices esto a otro desarrollador depende de la estructura de comunicación de tu equipo. Por supuesto, puede haber un requisito funcional involucrado aquí, como "cuando se visualizan las diferencias de nómina en línea o cuando se recuperan como PDF, es importante obtener exactamente el mismo contenido en ambos casos" . Si ese es el caso, agregue esto como una nota a al menos una (mejor ambas) historias de usuarios. Sin embargo, no ponga ninguna descripción de cómo se implementará este requisito en la historia.
Doc Brown
3
El diseño no se trata de decirle a un desarrollador cómo resolver problemas. Le está diciendo a un desarrollador qué problemas resolver.
candied_orange
1
Cuando califica el costo de tiempo de estas historias, ¿cómo las califica? Supongamos que la parte de consulta común tarda 5 horas, la parte de vista web tarda 6 horas y la parte de vista PDF tarda 7 horas. ¿Estima el tiempo, dice arbitrariamente que uno cuesta 11 horas (5 + 6) y el otro 7 (o viceversa: 12 y 6), o los estima en 6 y 7, pero tenga en cuenta en algún otro lugar? ¿Cómo se combinaron las 5 horas de gastos generales para ambos? 11 y 12 (los 5 añadidos a ambos)? Si dice "Este modelo no está destinado a manejar tales casos. Solo háblelo". aún podría estar grabado en un guión gráfico, pero ¿cómo?
Aaron
15

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.

Ewan
fuente
4

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
Berin Loritsch
fuente
Vale la pena señalar que no necesariamente necesita documentar más que la historia. La historia te da el contexto de nivel empresarial. El seguimiento más detallado que necesita depende de usted (y depende en gran medida de las restricciones de la organización). Sin embargo, debe intentar minimizarlo (personas que superan el proceso y todo eso).
Ant P
@AntP, estuvo de acuerdo, pero esto va hacia la Definición de Hecho (DoD) y debe caber en la parte posterior de su tarjeta 3x5 que tiene la historia del usuario.
Berin Loritsch
2

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.

Ilessa
fuente
2

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.

CodeGnome
fuente