 |
| Imagen de: La Oficina de Proyectos de Informática |
Una de las principales innovaciones que representa el desarrollo ágil frente a los enfoques tradicionales, es en la forma de levantar los requerimientos del usuario.
A diferencia del enfoque tradicional, en el cual el “Diseño de Sistema” contiene documentación detallada del comportamiento y representa el final de las conversaciones, en las metodologías ágiles se hace uso de las “Historias de usuario”, las cuales se enfocan en definir lo que el usuario necesita hacer, sin describir el cómo, por lo que representa el inicio y no el final de las conversaciones.
En este artículo, presentamos una plantilla para documentar las historias de usuario, puede utilizarse en un marco de trabajo de desarrollo ágil (por ejemplo Scrum), e incluye la documentación de los enunciados de las historias y los criterios de aceptación en una misma plantilla.
Está plantilla no pretende ser una Pila de Producto, por lo que no incluye su nivel de prioridad (La pila de producto es otro documento).
A diferencia del enfoque tradicional, en el cual el “Diseño de Sistema” contiene documentación detallada del comportamiento y representa el final de las conversaciones, en las metodologías ágiles se hace uso de las “Historias de usuario”, las cuales se enfocan en definir lo que el usuario necesita hacer, sin describir el cómo, por lo que representa el inicio y no el final de las conversaciones.
En este artículo, presentamos una plantilla para documentar las historias de usuario, puede utilizarse en un marco de trabajo de desarrollo ágil (por ejemplo Scrum), e incluye la documentación de los enunciados de las historias y los criterios de aceptación en una misma plantilla.
Está plantilla no pretende ser una Pila de Producto, por lo que no incluye su nivel de prioridad (La pila de producto es otro documento).
Pero antes:
> Plantilla de historias de usuario y criterios de aceptación en un marco de desarrollo ágil
La plantilla está libre de derechos de autor y puede ser usada libremente por nuestros lectores. ¿Buscas otras plantillas?, visita la Página de Plantillas, donde encontrarás plantillas de la Pila de Producto (Product Backlog), Reunión de retrospectiva y muchas más.
Si buscas ejemplos sobre como elaborar una historia de usuario, te recomendamos el siguiente artículo:
> 30 ejemplos de historias de usuario
La plantilla está libre de derechos de autor y puede ser usada libremente por nuestros lectores.
Las especificaciones de diseño en enfoques tradicionales, contienen documentación detallada de los pasos a seguir por el usuario y definiciones de interfaz gráfica (pantallas), es decir, describe que quiere hacer el usuario y como lo quiere hacer.
Por otra parte, en las historias de usuario, el enunciado representa el principio de las conversaciones y no el final. Se enfoca en definir lo que quiere el usuario.
Si buscas mas información sobre el concepto de historias de usuario, te recomendamos este articulo:
> ¿Qué son las historias de usuario?: 7 preguntas y respuestas
Los criterios de aceptación, definen los requerimientos del dueño de producto sobre cómo deben comportarse el sistema ante distintos eventos.
Las historias de alta complejidad deben subdividirse en historias de menor complejidad. Una medida aceptada generalmente es subdividir una historia en varias, si se observa que esta tiene más de 4 criterios de aceptación.
En el marco de trabajo Scrum, no esta prescrita una forma para documentar los elementos del Product Backlog, sin embargo, las historias de usuario son la forma más utilizadas.
En Scrum, el encargado de elaborar los elementos del Product Backlog es el Product Owner. Sin embargo, el Scrum Master tiene la tarea de ayudar al equipo Scrum (Product Owner y desarrolladores) a aplicar técnicas para que los elementos del Product Backlog sean claros y concisos. Una de esas formas, puede ser ayudándolos a escribir historias de usuario.
Te gustaría certificarte como Scrum Master, sigue el enlace:
> La Certificación Scrum Master Profesional (PSM)
El enunciado está compuesto por el Rol, Acción y Resultado. El enunciado no describe detalles de cómo se va a ejecutar la acción que necesita el usuario.
Están compuestos por la descripción del contexto, evento y consecuencia, definen los requerimientos del dueño de producto sobre cómo deben comportarse el sistema para ejecutar la acción. Representan el inicio de la definición del cómo. No están diseñados para ser tan detallados como una especificación de diseño tradicional.
Si una historia de usuario tiene más de 4 criterios de aceptación, debe evaluarse subdividir la historia.
Puede añadirse un número de escenario para identificar al criterio, asociado a la historia de usuario en cuestión.
Los elementos de los criterios de aceptación son:
De esta forma, el formato para documentar los criterios de aceptación es:
Escenario [Número de escenario] [Titulo del escenario]: En caso que [Contexto] y adicionalmente [Contexto], cuando [Evento], el sistema [Resultado / Comportamiento esperado]
Tomando el ejemplo anterior de las búsquedas de productos por categoría, un posible escenario podría ser:
Escenario 1: En caso que exista una categoría sin productos asociados, cuando el cliente despliegue el listado de categorías para realizar su búsqueda, el sistema mostrará el siguiente texto al lado de la categoría “Actualmente no poseemos productos para esta categoría”.
Una vez has escrito tus historias de usuario, debes utilizarlas para que los desarrolladores de software puedan definir el backlog de producto y la planificacion de iteraciones.
Te recomendamos el siguiente articulo sobre como usar las historias de usuario.
> ¿Qué son las historias de usuario?: Recomendaciones sobre su definición y uso
¿Buscas otras plantillas?
Visita la Página de Plantillas, donde encontrarás plantillas de la Pila de Producto (Product Backlog), Lista de tareas de la iteración (Sprint Backlog), Reunión de retrospectiva y muchas más.
¿Cuál ha sido su experiencia desarrollando las historias de usuario?, ¿Qué información agregaría a esta plantilla?, ¿Cuáles resultados ha tenido documentando historias de usuario?, ¿que lecciones aprendidas podría compartir?.
Te invitamos a dejarnos comentarios en la Web de La Oficina de Proyectos de Informática (pmoinformatica) (Si lo deseas, puedes firmar tu comentario con la dirección de tu web).
Proyectos Ágiles con Scrum: Flexibilidad, aprendizaje, innovación y colaboración en contextos complejos
Autor: Martin Alaimo; Martin Salas.
>> Latinoamérica (amazon.com)
>> España (amazon.es)
>> Ver reseña
En este libro encontrarás un excelente compendio de las metodologías ágiles, sus procedimientos y artefactos. Excelentes ejemplos prácticos.
> La Guía del PMBOK 6ta edición y las metodologías ágiles
> La Transición hacia la Agilidad
> ¿Qué son las historias de usuario?: Recomendaciones sobre su definición y uso
Impulsa tu carrera y certifícate profesionalmente como Scrum Master con el curso [2024] Scrum Master Certification en Español. 🎓. En Udemy. ¡Haz clic, aprende Scrum 🚀 y obtén tu certificación profesional! 👩🎓
Presentamos la plantilla en el siguiente enlace.
La plantilla está libre de derechos de autor y puede ser usada libremente por nuestros lectores. ¿Buscas otras plantillas?, visita la Página de Plantillas, donde encontrarás plantillas de la Pila de Producto (Product Backlog), Reunión de retrospectiva y muchas más.
Si buscas ejemplos sobre como elaborar una historia de usuario, te recomendamos el siguiente artículo:
> 30 ejemplos de historias de usuario
La plantilla está libre de derechos de autor y puede ser usada libremente por nuestros lectores.
Antes de usar la plantilla de historias de usuario
Las especificaciones de diseño en enfoques tradicionales, contienen documentación detallada de los pasos a seguir por el usuario y definiciones de interfaz gráfica (pantallas), es decir, describe que quiere hacer el usuario y como lo quiere hacer.
Por otra parte, en las historias de usuario, el enunciado representa el principio de las conversaciones y no el final. Se enfoca en definir lo que quiere el usuario.
Si buscas mas información sobre el concepto de historias de usuario, te recomendamos este articulo:
> ¿Qué son las historias de usuario?: 7 preguntas y respuestas
Los criterios de aceptación, definen los requerimientos del dueño de producto sobre cómo deben comportarse el sistema ante distintos eventos.
Las historias de alta complejidad deben subdividirse en historias de menor complejidad. Una medida aceptada generalmente es subdividir una historia en varias, si se observa que esta tiene más de 4 criterios de aceptación.
Las historias de usuario en Scrum
En el marco de trabajo Scrum, no esta prescrita una forma para documentar los elementos del Product Backlog, sin embargo, las historias de usuario son la forma más utilizadas.
En Scrum, el encargado de elaborar los elementos del Product Backlog es el Product Owner. Sin embargo, el Scrum Master tiene la tarea de ayudar al equipo Scrum (Product Owner y desarrolladores) a aplicar técnicas para que los elementos del Product Backlog sean claros y concisos. Una de esas formas, puede ser ayudándolos a escribir historias de usuario.
Te gustaría certificarte como Scrum Master, sigue el enlace:
> La Certificación Scrum Master Profesional (PSM)
El enunciado de la historia de usuario
El enunciado está compuesto por el Rol, Acción y Resultado. El enunciado no describe detalles de cómo se va a ejecutar la acción que necesita el usuario.
Para una mejor clasificación y organización puede añadirse un código a cada historia, para ayudar a su identificación unívoca dentro del proyecto.
A continuación a la descripción de cada uno de estos elementos:
Una vez se definen estos componentes, la frase de historia queda establecida de la siguiente forma:
Esto equivale al Titulo descriptivo de la historia, que Puede utilizarse para hacer referencia en la pila de producto, junto con su código.
Se pueden aplicar las siguientes variantes en la definición del rol:
O también variar entre obligatorio u opcional en la descripción de la funcionalidad:
También puede omitirse la descripción de la consecuencia:
Aquí te compartimos algunos ejemplos sobre como escribir historias de usuario:
> 30 ejemplos de historias de usuario
Al escribir las historias de usuario, te recomendamos tener en cuenta no cometer los errores que se describen en el siguiente articulo:
> ¿Qué son las historias de usuario?: 5 errores comunes al escribirlas
A continuación a la descripción de cada uno de estos elementos:
- Identificador (ID) de la historia: Código que identifica unívocamente a la historia en el Proyecto que se esté desarrollando. El formato debe ser elegido por el equipo.
- Rol: Es el rol que está desempeñando el usuario cuando utiliza la funcionalidad que se está describiendo. Debe ser lo más especifico posible, describiendo el rol o actor que se está desempeñando. El enunciado puede escribirse como se sigue: Yo como un [Rol], Desempeñando el rol de [Rol], Como un [Rol], entre otros. Por ejemplo:
- Yo como cliente registrado.
- Desempeñando el rol de cliente registrado.
- Como un cliente registrado.
- Característica / Funcionalidad (Feature): Representa la función que el rol quiere o necesita hacer en el sistema que se está desarrollando. Puede diferenciarse entre acciones obligatorias u opcionales, utilizando la palabra puede o necesita para describir la acción. Por ejemplo:
- Necesito realizar búsquedas de productos por categorías.
- Puedo seleccionar una categoría para ver el número de productos que tiene asociado.
- Razón / Resultados: Lo que el rol necesita lograr al ejecutar la acción. Este es el resultado de ejecutar la acción desde el punto de vista del rol. Este punto puede ser opcional, pues la historia puede documentarse sólo con la definición del rol y la acción (sin definir la consecuencia).
- Yo como un [Rol], necesito [Descripción de la funcionalidad], con la finalidad de [Descripción de la consecuencia].
Esto equivale al Titulo descriptivo de la historia, que Puede utilizarse para hacer referencia en la pila de producto, junto con su código.
Se pueden aplicar las siguientes variantes en la definición del rol:
- Como un [Rol], necesito [Descripción de la funcionalidad], con la finalidad de [Descripción de la consecuencia].
- Desempeñando el rol de [Rol], necesito [Descripción de la funcionalidad], con la finalidad de [Descripción de la consecuencia].
- Como un [Rol], puedo [Descripción de la funcionalidad], con la finalidad de [Descripción de la consecuencia].
- Como un [Rol], puedo [Descripción de la funcionalidad].
- Yo como un [Rol], puedo [Descripción de la funcionalidad].
Aquí te compartimos algunos ejemplos sobre como escribir historias de usuario:
> 30 ejemplos de historias de usuario
Al escribir las historias de usuario, te recomendamos tener en cuenta no cometer los errores que se describen en el siguiente articulo:
> ¿Qué son las historias de usuario?: 5 errores comunes al escribirlas
Certifícate como Scrum Master
Domina Scrum y lidera equipos con éxito. Prepárate para el examen de certificación mundial de CertiProf y transforma tu carrera.
Los criterios de aceptación
Están compuestos por la descripción del contexto, evento y consecuencia, definen los requerimientos del dueño de producto sobre cómo deben comportarse el sistema para ejecutar la acción. Representan el inicio de la definición del cómo. No están diseñados para ser tan detallados como una especificación de diseño tradicional.
Si una historia de usuario tiene más de 4 criterios de aceptación, debe evaluarse subdividir la historia.
Puede añadirse un número de escenario para identificar al criterio, asociado a la historia de usuario en cuestión.
Los elementos de los criterios de aceptación son:
- Número de escenario: Número (ejemplo 1, 2, 3 ó 4), que identifica al escenario asociado a la historia.
- Título del escenario: Describe el contexto del escenario que define un comportamiento. Por ejemplo, si se toma el ejemplo de búsquedas de productos por categoría, un posible ejemplo pudiera ser: Categoría sin productos asociados.
- Contexto: Proporciona mayor descripción sobre las condiciones que desencadenan el escenario.
- Evento: Representa la acción que el usuario ejecuta, en el contexto definido para el escenario.
- Resultado / Comportamiento esperado: Dado el contexto y la acción ejecutada por el usuario, la consecuencia es el comportamiento del sistema en esa situación.
De esta forma, el formato para documentar los criterios de aceptación es:
Escenario [Número de escenario] [Titulo del escenario]: En caso que [Contexto] y adicionalmente [Contexto], cuando [Evento], el sistema [Resultado / Comportamiento esperado]
Tomando el ejemplo anterior de las búsquedas de productos por categoría, un posible escenario podría ser:
Escenario 1: En caso que exista una categoría sin productos asociados, cuando el cliente despliegue el listado de categorías para realizar su búsqueda, el sistema mostrará el siguiente texto al lado de la categoría “Actualmente no poseemos productos para esta categoría”.
Definición y uso de las historias de usuario
Una vez has escrito tus historias de usuario, debes utilizarlas para que los desarrolladores de software puedan definir el backlog de producto y la planificacion de iteraciones.
Te recomendamos el siguiente articulo sobre como usar las historias de usuario.
> ¿Qué son las historias de usuario?: Recomendaciones sobre su definición y uso
¿Buscas otras plantillas?
Visita la Página de Plantillas, donde encontrarás plantillas de la Pila de Producto (Product Backlog), Lista de tareas de la iteración (Sprint Backlog), Reunión de retrospectiva y muchas más.
¿y qué opinas tú?
¿Cuál ha sido su experiencia desarrollando las historias de usuario?, ¿Qué información agregaría a esta plantilla?, ¿Cuáles resultados ha tenido documentando historias de usuario?, ¿que lecciones aprendidas podría compartir?.
Te invitamos a dejarnos comentarios en la Web de La Oficina de Proyectos de Informática (pmoinformatica) (Si lo deseas, puedes firmar tu comentario con la dirección de tu web).
Síguenos en: 
Lectura recomendada
Autor: Martin Alaimo; Martin Salas.
>> Latinoamérica (amazon.com)
>> España (amazon.es)
>> Ver reseña
En este libro encontrarás un excelente compendio de las metodologías ágiles, sus procedimientos y artefactos. Excelentes ejemplos prácticos.
Gestión práctica de proyectos con Scrum: Desarrollo de software ágil para el Scrum Master
Autor: Antonio Martel.
>> Latinoamérica (amazon.com)
>> España (amazon.es)
Una gran cantidad de casos reales y experiencia práctica para el Scrum Master en los proyectos con metodologías ágiles, como hacer estimaciones, presupuestos, lecciones aprendidas y más.
Autor: Antonio Martel.
>> Latinoamérica (amazon.com)
>> España (amazon.es)
Una gran cantidad de casos reales y experiencia práctica para el Scrum Master en los proyectos con metodologías ágiles, como hacer estimaciones, presupuestos, lecciones aprendidas y más.
¿Interesado en otros productos y últimas novedades?
>> Visita nuestra sección de productos amazon
>> Visita nuestra sección de productos amazon
Otros artículos
> La Guía del PMBOK 6ta edición y las metodologías ágiles
> La Transición hacia la Agilidad
> ¿Qué son las historias de usuario?: Recomendaciones sobre su definición y uso
He revisado su plantilla y es bastante útil pero hay cosas que se escapan, por ejemplo si quiero registrar un producto, en que parte de la plantilla pondría los atributos que va a tener ese artículo determinado. He visto en otras páginas que los ponen como criterios de aceptación pero no calza con la plantilla que ustedes presentan muchas gracias.
ResponderEliminar