 |
| Imagen de: Blog AEGXXI - Desarrollo |
Las historias de usuario son un instrumento para el levantamiento de requerimientos para el desarrollo de un software, que ha emergido con la aparición de los nuevos marcos de trabajo de desarrollo ágil, como por ejemplo Scrum o las diferentes técnicas que comprenden el Extreme Programming (XP).
En el artículo, presentamos conceptos de lo que es una historia de usuario, contestando 7 preguntas y respuestas, como: Forma en que se redactan, características que debe tener, para que se utilizan, en que se diferencian de otros instrumentos de levantamiento de información, como se valida que han sido implementadas y que problemas puede ocasionar una mala definición de las historias de usuario.
pmoinformatica.com, “La Oficina de Proyectos de Informática” presenta ¿Qué son las historias de usuario?, 7 preguntas y respuestas.
Referencia
Basado en un artículo original de Kristian Kaczor, escribiendo para Scrum Alliance, titulado, “5 Common Mistakes We Make Writing User Stories”. Invitamos a su lectura.
Plantilla de historias de usuario
Pmoinformatica.com coloca a su disposición una “Plantilla para documentar historias de usuario y criterios de aceptación”, completamente gratis. Nos gustaría recibir sus comentarios sobre la plantilla y sobre el contenido del blog.
Las 7 preguntas y respuestas sobre ¿Qué son las historias de usuario?
1.- ¿Qué son las historias de usuario?
Las historias de usuario, son descripciones cortas de una necesidad de un cliente del software que estemos desarrollando. Su utilización es común cuando se aplican marcos de trabajo ágiles, tales como Scrum o el Extreme Programming (XP).
2.- ¿Cómo se redactan las historias de usuario?
Al redactar una historia de usuario deben tenerse en cuenta describir el Rol, la funcionalidad y el resultado esperado de la aplicación en una frase corta. Adicionalmente, debe venir acompañada de los criterios de aceptación, no más de 4 por historia, redactado también en una frase que incluya el contexto, el evento y el comportamiento esperado ante ese evento.
¿Interesado en una plantilla para redactar historias de usuario?, revise el siguiente artículo “Plantilla de Historias de Usuario”, en pmoinformatica.com.
Formación en Scrum
En Scrum, el responsable de gestionar el Product Backlog es el Product Owner.
Cómo desempeñar el rol para maximizar el valor del software desarrollado para la organización.
3.- ¿Qué características deben tener las historias de usuario?
Algunas características deseables de las historias de usuario son:
- Que sean escritas por el usuario o por un analista de negocio que le represente.
- Frase corta que encaje en una tarjeta de 3 por 5 pulgadas.
- Debe describir el rol desempeñado por el usuario en el sistema, descrito de forma explícita.
- Debe describir el beneficio para el área de negocio que representa esta funcionalidad.
4.- ¿En qué se diferencian de otros instrumentos de levantamiento de requerimientos?
No debemos confundirlas con Casos de uso o Escenarios de uso, la gran diferencia, es que son más cortas y no deben describir la interfaz con el usuario, los pasos de navegación o flujo de procesos de la aplicación.
Su propósito principal de esta herramienta es la estimación del esfuerzo necesario para implementar una nueva funcionalidad (Feature), en un software, siguiendo la definición de “Hecho” (DONE) que defina el equipo.
Adicionalmente, se utilizan como iniciadoras de conversaciones entre desarrolladores de software y usuarios del área de negocio, las cuales servirán para identificar los requerimientos del negocio, requerimientos técnicos y para encontrar los supuestos (premisas) no visibles en una primera aproximación.
Su propósito, no es describir en detalle la funcionalidad.
Para estas estimaciones, se le asignan unidades de medida a las historias que representen magnitud y no días reales de duración, tales como: puntos de historia, días ideales u otra unidad de medida.
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 ayudandolos a escribir historias de usuario.
Te gustaría certificarte como Scrum Master, sigue el enlace:
> La Certificación Scrum Master Profesional (PSM)
5.- ¿Para qué se utilizan?
Su propósito principal de esta herramienta es la estimación del esfuerzo necesario para implementar una nueva funcionalidad (Feature), en un software, siguiendo la definición de “Hecho” (DONE) que defina el equipo.
Adicionalmente, se utilizan como iniciadoras de conversaciones entre desarrolladores de software y usuarios del área de negocio, las cuales servirán para identificar los requerimientos del negocio, requerimientos técnicos y para encontrar los supuestos (premisas) no visibles en una primera aproximación.
Su propósito, no es describir en detalle la funcionalidad.
Para estas estimaciones, se le asignan unidades de medida a las historias que representen magnitud y no días reales de duración, tales como: puntos de historia, días ideales u otra unidad de medida.
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 ayudandolos a escribir historias de usuario.
Te gustaría certificarte como Scrum Master, sigue el enlace:
> La Certificación Scrum Master Profesional (PSM)
¿Buscas más información de metodologías ágiles?
¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de metodologías ágiles?, entonces presiona "suscríbete" a continuación.
También puedes seguirnos vía Twitter, Facebook o Linkedin:
6.- ¿Cómo se confirma que una historia ha sido implementada adecuadamente y por lo tanto está “Hecho” (DONE)?
Se confirma por medio de la Prueba de Aceptación, la cual a su vez deriva de los criterios de aceptación (también denominados condiciones de satisfacción) asociados a la historia.
7.- ¿Qué problemas puede ocasionar el cometer errores al escribir las historias de usuario?
El levantamiento de requerimientos y las pruebas en el desarrollo ágil de software dependen en gran medida de las historias de usuario, por lo que si cometemos errores al definir las mismas podemos tener problemas a lo largo del desarrollo.
Podría pensarse, como cometer errores al expresar requerimientos de una forma tan simple, sin embargo, esta simplicidad puede ocasionar problemas. Por supuesto que el escribir buenas historias de usuario será más difíciles para equipos novatos en metodologías ágiles.
Los errores cometidos al escribir las historias pueden ocasionar un mal entendimiento de los requerimientos, mala formulación de casos de pruebas, y lo que es peor, una mala implementación, ocasionando el rechazo de los entregables de una iteración.
¿y qué opina tu?
¿Qué opinas de las historias de usuario como instrumento de levantamiento de requerimientos?, ¿Cuáles ventajas y desventajas encuentras?, ¿Qué lecciones aprendidas o recomendaciones compartirías con la audiencia?. 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).
Referencia
5 Common Mistakes We Make Writing User Stories
¿Interesado en libros sobre Desarrollo ágil de Software?
 |  |  |  | ||
| Kanban Autor: David J Anderson >> España (amazon.es)  >> Latinoámerica (amazon.com)  >> Ver reseña |
| Gestión Ágil de Proyectos Autor: Pablo Lledó >> España(amazon.es)  >> Latinoámerica (amazon.com)  | Diseño ágil con TDD Autor: Carlos Ble Jurado >> España(amazon.es)  >> Latinoámerica (amazon.com)  |
¿Quieres conocer otros productos y últimas novedades sobre desarrollo ágil y gestión de proyectos en amazon.es y amazon.com?.
>> Visita nuestra sección de productos amazon
Otros artículos sobre Desarrollo ágil, Scrum y Test Driven Development
No hay comentarios :
Publicar un comentario