Estoy muy acostumbrado a las historias de usuarios para funciones impulsadas por el usuario final. Pero si comienza un proyecto desde cero, ¿tiene sentido tratar a los dueños de negocios como usuarios y definir sus necesidades de esa manera también? Algunos ejemplos
As a Business Owner
I want regular database backups
So that we can maintain business continuity
As a Business Owner
I want end-user analytics
So that we can know how our platform is being used
As a Business Owner
I want end-user authentication
So that only registered users have access
Cosas como estas son obviamente características que un equipo de desarrollo/devops tiene que construir, pero no están realmente impulsadas por el usuario final en el sentido tradicional en el que pienso para las historias de los usuarios. ¿Pensamientos?
El término "usuario" en las historias de usuario a menudo se entiende mejor como un actor o rol en un caso de uso, o incluso simplemente como un consumidor de valor . El objetivo principal de tener un rol claramente definido en una historia de usuario es enmarcar la historia para restringir el alcance. El objetivo secundario es garantizar que la historia de usuario se vea como un marcador de posición de colaboración, en lugar de una especificación sucedánea. Con un consumidor identificado de la historia, es mucho más fácil para el equipo saber con quién hablar sobre los detalles de implementación o los criterios de aceptación.
Para resumir una larga historia, no hay nada malo con sus historias desde un punto de vista puramente pragmático. Sin embargo, pueden ser mejores si aprovecha el "usuario" en el formato de la historia para mejorar el contexto y la colaboración.
Si bien es probable que sus historias sean procesables tal como están, puede mejorarlas con un mejor encuadre y creando oportunidades de colaboración. Veamos un ejemplo.
Usando los objetivos descritos anteriormente, puede reescribir su primera historia de la siguiente manera:
Como administrador de la base de datos
, quiero asegurarme de que la base de datos se pueda recuperar en 4 horas
para que podamos cumplir con nuestros objetivos de continuidad comercial.
Es probable que esta historia sea superior a la original porque:
Sus otras historias también se beneficiarían de un tratamiento similar. Definitivamente vale la pena dedicar un poco más de tiempo a asegurarse de haber capturado a los colaboradores correctos para una historia central, así como el contexto suficiente para garantizar que el equipo esté construyendo lo correcto .
Si hay varios roles o funciones mejoradas, y una sola historia no los captura (o posiblemente no pueda) todos, a menudo es mejor elegir un caso de uso básico y luego iterarlo. ¡De eso se trata el desarrollo iterativo! Si está utilizando historias de usuarios, debería mejorar sus funciones de forma iterativa , incremental y empírica de todos modos. Al adoptar un enfoque interactivo, puede concentrarse en obtener funciones justo a tiempo y con un nivel de calidad "suficientemente bueno", en lugar de tratar de especificar una solución compleja con grandes esfuerzos de planificación iniciales que generalmente limitarán en exceso. el espacio de la solución sin ningún propósito útil.
Cuando se hace correctamente, las historias de usuario no son solo una forma diferente de describir las especificaciones antiguas. Representan un paradigma diferente basado en la colaboración y el control empírico, y requieren una forma fundamentalmente diferente de pensar sobre el dominio de un problema.
Aproveche las historias de los usuarios como iniciadores de conversación y notas abreviadas para alimentar su colaboración. No escriba historias detalladas para cosas que no están actualmente en el alcance (YAGNI), pero dedique tiempo a descomponer e identificar las cosas realmente importantes durante el refinamiento de la cartera de pedidos y la planificación de Sprint. Cuando una característica determinada finalmente entre en el alcance como parte de un Sprint Goal cohesivo, será mucho más obvio si tiene el quién y el qué correcto en sus historias, y eso a su vez será una mejor guía para el Equipo de Desarrollo cuando trabaje. sobre cómo implementarlo durante el Sprint actual!
Bienvenido a PM.
Una de las personas más influyentes en este mundo (de la gestión de proyectos), Mike Cohn, escribió un artículo al respecto en 2015 que definitivamente deberías leer con el nombre No todo necesita ser una historia de usuario : uso de las características de FDD . Algunos de sus artículos se utilizaron para proporcionar buenas respuestas a preguntas dentro de esta comunidad y también se adaptan a los suyos.
El nombre del artículo menciona la solución del autor para los casos en los que el usuario está demasiado lejos: desarrollo basado en características (FDD) .
Como escribe el autor
Una función FDD se escribe en este formato:
[action] the [result] [by|for|of|to] a(n) [object]Como ejemplos, considere estos:
- Estimar el precio de cierre de las acciones
- Generar un identificador único para una transacción
- Cambiar el texto que se muestra en un quiosco
- Combinar los datos para transacciones duplicadas
Ya tienes algunas respuestas excelentes, pero solo quiero agregar algo. Dices que tus historias:
no están realmente orientados al usuario final en el sentido tradicional
No estoy seguro de que ese sea el caso de todas las historias que enumeras.
Por ejemplo:
Como propietario de una empresa, quiero copias de seguridad periódicas de la base de datos para que podamos mantener la continuidad del negocio.
Sí, esto es importante para el dueño del negocio, pero eso se debe al impacto que tendrá en los usuarios finales.
Podrías reescribirlo como algo como:
Como usuario final, quiero estar seguro de que mis datos están protegidos para no perder el acceso al producto o tener que volver a ingresar mis datos.
Del mismo modo para:
Como propietario de una empresa, quiero la autenticación del usuario final para que solo los usuarios registrados tengan acceso
Sus usuarios finales también quieren un servicio seguro. Esto podría reescribirse como:
Como usuario final, quiero estar seguro de que mi cuenta es segura para que nadie más pueda acceder a mi información o realizar cambios no autorizados.
Las historias de usuario son una herramienta para comprender y satisfacer las necesidades de los usuarios. Podría cambiar el último para decir "Como usuario que paga, quiero que mis inicios de sesión estén seguros para que no me cobren por el uso no autorizado de mi cuenta".
Existen otros mecanismos como la Definición de Listo para problemas de calidad como disponibilidad, pruebas, etc.
Además, Scrum no requiere el uso de historias de usuario, por lo que si desea agregar capacidad de recuperación (que es en lo que me centraría sobre la copia de seguridad en sí), no tiene que usar una historia de usuario para agregar eso a la acumulación.
usuario253751