 |
| Imagen de: The DIY Musician |
Las historias son el principal instrumento de levantamiento de requerimientos en el marco del desarrollo ágil de software, que ha tomado gran auge junto con Scrum, las técnicas de Extreme Programming (XP) y otros marcos de trabajo ágiles.
En el artículo presentamos 5 errores comunes que pueden cometerse al escribir historias de usuario, tales como: Definir el rol en la historia como “Usuario”, “Dueño de Producto” o “Desarrollador”, estos son roles inespecíficos no asociados a algún proceso de negocio en particular. Asimismo, otros errores comunes son, el no describir el valor de la historia para el área de negocio y no describir los criterios de aceptación de la historia.
Presentamos a continuación el artículo:
Referencia
Este escrito está basado en un artículo original de Kristian Kaczor, 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.
5 errores comunes al escribir historias de usuario
1.- Definir el rol a quien va dirigida la historia como el “Usuario”
Ejemplo: “Como un Usuario, deseo poder gestionar cuentas de cliente, con el fin de eliminar cuentas no utilizadas o cuentas erróneas”.
A primera vista, todos los elementos que requiere una historia están presentes. Sin embargo, ¿Qué sucedería si necesitamos entender el rol del usuario para poder construir la funcionalidad del sistema?, ¿Quien es la persona para la cual se desarrollará esta funcionalidad?, ¿es un Representante de Atención al cliente que necesita verificar los datos de clientes individuales mientras atiende llamadas telefónicas en un Call Center? o ¿es un administrador de un canal virtual de atención al cliente que necesita una lista de clientes ordenadas por antigüedad?.
Las expectativas del sistema pueden ser muy diferentes según se defina el rol para quien se desarrolla la historia, por lo que es muy importante definirlos específicamente, evitando roles genéricos en las historia, como por ejemplo "El Usuario".
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.
2.- Definir el rol a quien va dirigida la historia como el “Product Owner”
Ejemplo: ¿Cómo Product Owner, quiero que el sistema tenga la posibilidad de eliminar cuentas del cliente, con la finalidad que los usuarios puedan eliminar las cuentas de cliente?
De nuevo, todos los elementos están presentes, pero algo está mal, primero se dice que el “Product Owner Quiere”, pareciera ser una historia que se escribió porque alguien la quería y no porque realmente la necesitaba. Luego, una historia no puede ser dirigida al Product Owner (este es un representante de las necesidades de los usuarios de las áreas de negocio), hacerlo de esta manera evidencia problemas conceptuales en la implementación del desarrollo ágil, además, al igual que en el punto 1, no se le asigna un rol claro a la persona que permita establecer sus expectativas.
3.- Definir el rol a quien va dirigida la historia como el “Desarrollador”
Ejemplo: “Como desarrollador, yo quiero reemplazar el Widget de Barra para seleccionar productos, con la finalidad de dar mantenimieno al widget de barra para seleccionar productos”.
Este es un ejemplo típico de una historia para un Backlog técnico o la representación de un requerimiento técnico. Estas historias con frecuencia formar parte de la deuda técnica que puede ir creciendo a lo largo del proyecto. Por lo general, la deuda técnica incluye actividades de mantenimiento necesarios para realizar actualizaciones de software, refactorización, cambiar frameworks, entre otros.
Ejemplo: ¿Cómo Product Owner, quiero que el sistema tenga la posibilidad de eliminar cuentas del cliente, con la finalidad que los usuarios puedan eliminar las cuentas de cliente?
De nuevo, todos los elementos están presentes, pero algo está mal, primero se dice que el “Product Owner Quiere”, pareciera ser una historia que se escribió porque alguien la quería y no porque realmente la necesitaba. Luego, una historia no puede ser dirigida al Product Owner (este es un representante de las necesidades de los usuarios de las áreas de negocio), hacerlo de esta manera evidencia problemas conceptuales en la implementación del desarrollo ágil, además, al igual que en el punto 1, no se le asigna un rol claro a la persona que permita establecer sus expectativas.
3.- Definir el rol a quien va dirigida la historia como el “Desarrollador”
Ejemplo: “Como desarrollador, yo quiero reemplazar el Widget de Barra para seleccionar productos, con la finalidad de dar mantenimieno al widget de barra para seleccionar productos”.
Este es un ejemplo típico de una historia para un Backlog técnico o la representación de un requerimiento técnico. Estas historias con frecuencia formar parte de la deuda técnica que puede ir creciendo a lo largo del proyecto. Por lo general, la deuda técnica incluye actividades de mantenimiento necesarios para realizar actualizaciones de software, refactorización, cambiar frameworks, entre otros.
Si describimos estás historias técnicas de la forma en que se presenta en el ejemplo, no estamos agregando ningún valor al cliente, por lo que no obtendremos el apoyo del Product Owner y muchos menos de los usuarios del área de negocio.
¿Cómo escribir esta historia de forma correcta?, por ejemplo podría hacerse de la siguiente forma: “Como un usuario comercial, yo necesito poder ver múltiples productos en una misma barra y poder seleccionarlos, para poder hacer mi selección de forma más rápida”. Luego de describir la historia, describiríamos tareas como "Hacer Refactorización del mecanismo para incluir los productos en el widget de barra de productos" y luego "actualizar la versión de Java", entre otras.
Los criterios de aceptación deben ser medibles y verificables mediante pruebas, por ejemplo, “el usuario puede ver en la barra 5 productos en una misma vez” y “al presionar el botón para mover la barra, el usuario puede recorrer cinco productos en menos de 5 segundos”. Otro criterio pudiera ser, “al hacer click sobre el producto, la página de detalle del producto se muestra en menos de 4 segundos”.
Lectura Recomendada sobre Desarrollo Ágil de Software
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
Kanban: Cambio Evolutivo Exitoso Para su Negocio de Tecnología
Anderson, D; Reinertsen, D; Maeda, M (Traductor).
España (Amazon.es)
Latinoámerica (Amazon.com)
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
Anderson, D; Reinertsen, D; Maeda, M (Traductor).
España (Amazon.es)
Latinoámerica (Amazon.com)
4- No describir el valor para el negocio o beneficio
Ejemplo: “Como vendedor de libros, quiero una opción de filtrado”.
En este ejemplo, tenemos el rol, tenemos la necesidad, pero falta la razón y el valor de negocio. ¿Por qué un vendedor quiere una opción de filtrado?, ¿Qué objetivo necesita alcanzar con eso?, ¿Es por ejemplo para poder responder a solicitudes especificas de clientes?. Necesitamos describir este valor o funcionalidad en las historias de usuario para que los desarrolladores cuenten con más información sobre las expectativas de los usuarios.
5- No establecer los criterios de aceptación o condiciones de satisfacción
Cada historia de usuario, debe ser documentada con sus criterios de aceptación o condiciones de satisfacción, no hacerlo, puede ocasionar una definición inadecuada de las tareas o estimación errónea (subestimación o sobrestimación del esfuerzo requerido). Como resultado, los casos de prueba no cubrirán los criterios adecuados debido a un entendimiento erróneo.
Los criterios de aceptación juegan un papel importante en la confirmación del entendimiento del requerimiento. Estas condiciones sirven como iniciadoras de conversaciones entre el equipo y el Product Owner.
En la medida en que se descubren estos criterios de aceptación, es posible que las historias necesiten ser refinada, replanificadas o divididas en varias historias.
¿y qué opina usted?
¿Qué opinas tu de las historias de usuario como instrumento de levantamiento de requerimientos?, ¿Cuáles ventajas y desventajas encuentras?, ¿Consideras que falta algún error común en esta lista?.
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).
<< Artículo anterior: ¿Qué son las historias de usuario?: 7 preguntas y respuestas
¿Buscas más información de metodologías ágiles?Ejemplo: “Como vendedor de libros, quiero una opción de filtrado”.
En este ejemplo, tenemos el rol, tenemos la necesidad, pero falta la razón y el valor de negocio. ¿Por qué un vendedor quiere una opción de filtrado?, ¿Qué objetivo necesita alcanzar con eso?, ¿Es por ejemplo para poder responder a solicitudes especificas de clientes?. Necesitamos describir este valor o funcionalidad en las historias de usuario para que los desarrolladores cuenten con más información sobre las expectativas de los usuarios.
5- No establecer los criterios de aceptación o condiciones de satisfacción
Cada historia de usuario, debe ser documentada con sus criterios de aceptación o condiciones de satisfacción, no hacerlo, puede ocasionar una definición inadecuada de las tareas o estimación errónea (subestimación o sobrestimación del esfuerzo requerido). Como resultado, los casos de prueba no cubrirán los criterios adecuados debido a un entendimiento erróneo.
Los criterios de aceptación juegan un papel importante en la confirmación del entendimiento del requerimiento. Estas condiciones sirven como iniciadoras de conversaciones entre el equipo y el Product Owner.
En la medida en que se descubren estos criterios de aceptación, es posible que las historias necesiten ser refinada, replanificadas o divididas en varias historias.
¿y qué opina usted?
¿Qué opinas tu de las historias de usuario como instrumento de levantamiento de requerimientos?, ¿Cuáles ventajas y desventajas encuentras?, ¿Consideras que falta algún error común en esta lista?.
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).
<< Artículo anterior: ¿Qué son las historias de usuario?: 7 preguntas y respuestas
¿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:
>> Visita nuestra sección de productos amazon
Referencia
5 Common Mistakes We Make Writing User Stories
Otros artículos sobre Desarrollo ágil, Scrum y Test Driven Development
No hay comentarios :
Publicar un comentario