Soy desarrollador en un equipo scrum y me resulta difícil entender y empatizar con el objetivo final cuando las historias comienzan con "Como el sistema". Estas historias deberían ser sencillas porque, como desarrollador, debería poder construir para cumplir con los criterios de aceptación, pero me parece que con frecuencia me las devuelven después de la revisión porque había algunas necesidades de las partes interesadas que no se estaban satisfaciendo.
Como ejemplo, había una historia que involucraba un montón de casos extremos y parecía estar creciendo en complejidad día a día. Cuando investigué más a fondo para comprender por qué estamos cubriendo estos casos extremos, resultó que se estaban creando características para una parte interesada y características que se estaban creando para una parte interesada completamente diferente. Lo que probablemente podría haber ahorrado muchos viajes de comunicación entre el primer ministro y yo si se hubieran definido como dos historias.
En resumen, ¿debemos evitar usar historias que comiencen con "Como el sistema"?
Sí. Usar 'el sistema' como usuario en stories es malo.
El objetivo del formato "como... quiero... Para que..." es dar al desarrollador una idea del motivo de la función solicitada. Esto debería permitirles llenar los vacíos en las especificaciones.
En lugar de "hacer que el botón sea rojo", tendría "como cliente, quiero que el botón de compra sea rojo para poder identificarlo fácilmente y hacer clic en él fácilmente".
Entonces, cuando recibe la solicitud y ve que el fondo también es rojo bajo la condición X. No sigue adelante ciegamente y hace que el botón sea invisible.
Debe insistir en que el BA/PM/SM o quien sea, elabore una lista de usuarios del sistema y que cada historia use uno de los usuarios de esa lista.
Las historias de usuarios son un enfoque ágil de los requisitos que enfatizan el valor del usuario final.
Todas las historias de usuarios están escritas en el idioma del usuario final de modo que puedan ser entendidas por una persona no técnica que instantáneamente "obtendrá" el valor que ofrece la historia.
La razón por la que se hace esto es que ayuda a los usuarios finales no técnicos a comprender qué progreso está logrando el equipo y a priorizar el trabajo.
Algo que comienza con "Como el sistema..." no es una historia de usuario. Es una tarea técnica envuelta en el formato de historia de usuario.
Entonces, ¿dónde encajan las tareas técnicas?
Por lo general, el propietario del producto creará historias de usuarios que signifiquen valor para el usuario final. Los priorizarán y luego los presentarán al equipo como parte del refinamiento de la cartera de pedidos o la planificación del sprint .
El equipo técnico a menudo no puede mirar una historia de usuario y comprender exactamente qué es lo que necesita entregar. Esto se debe a que una historia de usuario es una invitación a una conversación . El propietario del producto habla con el equipo técnico a través de la historia del usuario. Mientras hacen eso, el equipo técnico a menudo divide la historia en una o más tareas técnicas . Estas tareas técnicas no necesitan ser entendidas por los usuarios finales, se pueden escribir en un formato que no sea una historia y pueden ser de naturaleza muy técnica.
Un ejemplo, digamos que tengo la siguiente historia de usuario:
Como usuario del sitio web por primera vez, quiero registrarme para poder acceder al sitio web.
El equipo técnico podría analizar esa historia y dividirla en una serie de tareas técnicas:
Crear tabla de usuario en la base de datos
Diseñar las páginas de registro
Agregar validación a los campos de entrada
...etcétera.
Debe haber pocas o ninguna tarea técnica que no se relacione con una historia. Incluso algo como:
Configurar el entorno de desarrollo
se puede envolver en la primera historia de usuario que ofrece valor para el usuario final.
El objetivo con este enfoque es tener:
Las historias de usuario deben ser secciones verticales que brinden valor a un usuario final. El sistema es una máquina sin sentido a la que no le importa el valor, por lo que las historias de usuarios que comienzan con "como el sistema" generalmente no lo ayudarán a comprender por qué estamos haciendo algo desde la perspectiva del negocio o del cliente.
Por lo tanto, habrá historias en las que escribirá "como el sistema" que al principio pueden parecer muy complejas técnicamente o 100% backend que no tienen ningún valor tangible para el usuario final. Eche un vistazo más de cerca e intente comprender realmente por qué queremos que el sistema haga algo o se comporte de cierta manera porque el sistema siempre está diseñado para interactuar con un ser humano en algún momento y ayudarlo a tomar algún tipo de decisión.
Sí, como propietario de un producto que escribe historias de usuarios todo el tiempo para un proyecto MUY grande que se considera un pionero ágil en nuestra industria, puedo decir que nunca escribiríamos "Como sistema..."
Una historia de usuario es una historia sobre un usuario . Si profundizas en la lógica de por qué se necesita algo, siempre hay un ser humano en alguna parte y esa persona es de quien trata la historia. Incluso en los casos en los que está escribiendo una historia sobre un servicio externo que tiene que compartir datos con nosotros en el back-end, inevitablemente hay un usuario de ese servicio en alguna parte.
Estoy bastante seguro de esto porque nuestro proyecto en su conjunto ha puesto mucho esfuerzo en la práctica de crear historias de usuario útiles, y nosotros, los propietarios de productos, revisamos nuestras historias con regularidad. Si uno de nosotros escribiera "Como sistema...", le garantizo que lo despedazarían en la sesión de revisión por pares. Peor aún, si la historia realmente brindara funcionalidad a dos clientes diferentes, se dividirían en pedazos aún peor. Una buena práctica es reducir la historia a la porción vertical útil más pequeña, y siempre debe centrarse en las necesidades de un usuario (o clase de usuarios) que esté claramente definida.
Además, el hecho de que su historia "creciera en complejidad día a día" indica que hay algo disfuncional en el proceso de preparación de su historia. Una historia de usuario debe mantenerse pequeña para permitir un mejor seguimiento de la velocidad del equipo, una planificación más sencilla y (en un mundo ideal) permitir algo entregable (aunque pequeño) en cada sprint. Una historia de usuario debe centrarse en un usuario, tan pequeña como sea práctico, y el creador de la historia debe dejarla ir una vez que comienza el desarrollo. He tenido que cambiar los criterios de aceptación sobre la marcha (mientras se desarrolla una historia), pero soy extremadamente reacio a hacerlo y le dejaré muy claro al desarrollador exactamente por qué se debe hacer. El 99% de las veces, si surge algo nuevo que cambia las cosas después de que la historia está en marcha, simplemente se convertirá en un nuevo elemento en la lista de espera.
En general, realmente creo que probablemente deberían revisar cómo abordan la creación de historias, la preparación de historias y la planificación.
En definitiva, no necesariamente pero sí tiene “mal olor”.
Parece que el problema principal es que pueden estar mal escritos y, lo que es más importante, no se entienden bien. Parece que es necesario mejorar la comunicación con respecto al propósito y la meta de estos elementos.
El punto de decir "Como..., quiero" es mostrar a quién ayuda la historia y dar información al desarrollador sobre a quién pedirle que la complete. Decir "Como sistema" implica que el sistema se preocupa (¿en serio?) y en realidad está solucionando como parte de los requisitos (supone que se trata de algún tipo de pieza no interactiva).
Debe pensar en a quién necesita ayudar y escribir la historia desde su punto de vista, luego pensar en cómo puede resolverlo.
Yo diría que todo depende de cuál sea el objetivo de este requisito en particular. Hay algunos casos o tipos de requisitos que podríamos considerar aquí, por ejemplo:
Como nota al margen, diría que su pregunta toca un tema muy amplio. Utilice cualquier enfoque para documentar los requisitos que brinde claridad a su proceso de desarrollo, reduzca la confusión entre las partes involucradas y no implique gastos generales innecesarios. Intencionalmente, no he mencionado explícitamente centrarme en documentar el valor aquí, no porque no sea importante, sino porque centrarse en el valor del usuario se puede lograr de varias maneras y documentar la parte "para que" de la historia del usuario y evitar "como un sistema". historias, es solo una de ellas.
Sí, eso está mal, lo rechazaría como un defecto de la fase de requisitos.
Considere el problema que las historias de usuario intentan abordar: personas sin experiencia que intentan escribir casos de uso que solo enumeran funciones y no consideran el propósito comercial detrás del requisito.
Luego, considere el problema que intentan resolver los casos de uso: personas sin experiencia que intentan escribir requisitos funcionales simplemente enumerando funciones y sin considerar el propósito comercial detrás de los requisitos...
No es que un actor no pueda ser un sistema informático, es que el etiquetado no se vincula con un propósito comercial del mundo real.
mike robinson