¿Deberían repetirse las funcionalidades comunes como historias muy similares dentro de cada contexto en el que se necesitan?

Digamos que para un sistema, hay varias historias que se repetirían a lo largo pero en diferentes contextos.

Por ejemplo, Buscar

"Como [insertar función], quiero buscar en una lista de datos para poder encontrar fácilmente lo que estoy buscando".

Lo mismo ocurre con el inicio de sesión, el filtrado, la edición del perfil, etc. Todas estas son historias que cada rol necesitaría realizar para completar una determinada épica (o son épicas en sí mismas).

No estoy seguro de si debo repetir todas estas historias para cada función (y etiquetarlas como "Tema de inicio de sesión" o "Tema de búsqueda") o si creo UNA "Búsqueda épica" separada a la que me referiría cada vez que quisiera necesita (que, por supuesto, contiene historias de usuarios para buscar).

¿Pensamientos?

Creo que debe preguntarse por qué, en su entorno particular, cada una de estas cosas son actividades drásticamente diferentes. ¿Por qué un inicio de sesión no es solo un inicio de sesión? ¡Las historias de usuario no son documentos de especificación!

Respuestas (4)

Un usuario del sistema puede tener múltiples roles al mismo tiempo que forman una jerarquía desde un rol muy genérico hasta un rol específico.
Por ejemplo, si un usuario ha iniciado sesión como administrador, en ese momento también tendrá el rol de "Usuario registrado" y "Usuario".

Si tiene un conjunto de historias que es igual excepto por el rol mencionado en las historias, primero debe buscar un rol más general que pueda reducir todas esas historias a una sola.
No quieres tener una docena de historias "Como X-role, quiero editar mi perfil para mantenerlo actualizado", cuando puedes tener una sola "Como usuario conectado, quiero edite mi perfil para mantenerlo actualizado" por aproximadamente la misma complejidad de una sola historia fuera del conjunto.

Si las historias no son lo suficientemente similares para ser agrupadas bajo un solo usuario, por ejemplo porque los objetivos son diferentes, entonces depende de su relación con otras historias en el proyecto si ya qué tema o epopeya pertenecen.

Si la única diferencia en la historia es el rol, y si los roles no necesitan capacidades de búsqueda o interfaces de usuario diferentes, utilice un término genérico que signifique "todos los roles" y escriba una historia. ("Como una persona que interactúa con el sistema" tal vez)

Si algunos roles necesitan diferentes capacidades de búsqueda o interfaces de usuario, primero escriba e implemente la historia genérica, luego escriba una o más historias adicionales para cubrir las capacidades adicionales. ("Como administrador de sistemas, quiero buscar datos ocultos para poder..." o "Como usuario avanzado, quiero buscar en varios parámetros para poder encontrar lo que busco más rápidamente")

Estoy lidiando con algo similar en un proyecto en este momento.

No olvidemos que, en esencia, Agile es un proceso de iteración. Como tal, no debe sentirse obligado a comprometerse con algún enfoque con estas historias por adelantado.

Yo diría que la habilidad para buscar x es la historia correcta, y la habilidad para buscar y es otra. No es necesario tener una historia específica para cada usuario para realizar cada búsqueda. Esa es una historia que define esas reglas de búsqueda, según el tipo de usuario.

Luego, en el desempaquetado, alguien (¿usted?) podría necesitar profundizar en esto con sus desarrolladores para dividir la historia en tareas si es necesario.

¡Confía en tu instinto e intenta algo diferente si no obtienes cadencia después de un par de sprints!

Si solo el rol que realiza la acción es diferente, y las acciones (agregar, buscar, editar, etc.) así como el contexto (perfil de usuario, facturas, etc.) de las acciones son iguales, entonces está hablando de un solo usuario historia.

Puede usar un nombre más amplio para estos roles o simplemente escribirlos todos si no son demasiados; Por ejemplo, como usuario del personal , quiero buscar ABC para poder XYZ. O tal vez como personal de TI o personal de administración , queremos ABC para poder XYZ.

Los roles no necesitan representar roles reales en su sistema.

También ayuda si sus historias tienen las propiedades INVEST para cuando estén listas para la selección.