Barra Superior

PMOinformatica.com
La oficina de proyectos de informática
La web sobre gerencia de proyectos de informática, software y tecnología.
Síguenos en:     

lunes, 6 de mayo de 2013

¿Qué son las historias de usuario?: 5 errores comunes al escribirlas

Imagen de: The DIY Musician
Pmoinformatica.com, “La Oficina de Proyectos de Informática”, presenta una nueva entrega de su serie “¿Qué son las historias de usuario?, en esta ocasión comentaremos acerca de “5 errores comunes al escribir historias de usuario”.

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 metodologías ágiles de Management Plaza



¿Buscas formarte en la aproximación Agile y el marco de trabajo Scrum? la metodología ágil más utilizada en el mundo.

Con el curso online en directo (Onlive) de gestión ágil de proyectos con Scrum de Management Plaza, conocerás los principios ágiles, la metodología Scrum, sus roles, instrumentos y prácticas.




Como adicional, el curso te ayuda a prepararte para las certificaciones de Professional Scrum Master I (PSM I), Professional Scrum Product Owner (PSPO I) de scrum.org o la certificación Fundamentos Agile / Scrum de EXIN.

Más cursos >>

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.

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)




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?

¿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.

Suscríbete a la lista de correo electrónico:


Vía FeedBurner, se abrirá una nueva ventana

También puedes seguirnos vía Twitter, Facebook o Linkedin:

   

¿Interesado en otros productos y últimas novedades sobre desarrollo ágil? 
>> 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 en la entrada

Pmoinformatica.com," La Oficina de Proyectos de Informática ", es un participante en el Programa de Servicios de Amazon Associates LLC, un programa de publicidad de afiliación diseñado para proporcionar un medio para que sitios web puedan ganar honorarios por la publicidad y enlaces a amazon.com y amazon.es.