28. May 2020
Nuestro enfoque de las historias de usuario

En la situación actual, estamos poniendo a prueba las herramientas con las que trabajamos a diario y evaluando su idoneidad para el uso diario en la oficina doméstica. Uno de los elementos fundamentales en Scrum son las historias de usuario. A continuación, mostraremos lo que hace que una historia de usuario sea una buena historia de usuario para nosotros en XITASO, así como lo que resulta particularmente importante en la situación actual.

¿Qué son las historias de usuario y cómo se estructuran?

Lo que en inglés se denomina «user stories» son lo que nosotros llamamos historias de usuario. El propietario del producto describe los requisitos desde el punto de vista del usuario en una historia de usuario. Es decir, explica qué buscan los usuarios en el software, o los clientes en un producto, para alcanzar sus objetivos empresariales.

Las historias de usuario constan de unas pocas frases fácilmente comprensibles. Son cortas, pero concisas, específicas y detalladas desde el punto de vista del cliente. Las historias de usuario no solo transmiten las expectativas de los futuros sistemas informáticos, sino también los requisitos de los productos entregados que hacen realidad los proyectos ágiles. Las historias de usuario se mueven en el espacio de los requisitos sin cambiar al espacio de la solución. No proporcionan soluciones técnicas que obliguen a los desarrolladores a aplicarlas de forma estricta y, por lo tanto, son diferentes de una especificación. ^{1 2}

Una historia de usuario debe ser sencilla y fácil de entender.

«Como [usuario], me gustaría añadir la [función] a [valor]».

Es decir, una historia de usuario responde a las preguntas QUIÉN quiere QUÉ y POR QUÉ:

[Usuario] – ¿Quién?
El marcador de posición [Usuario] se rellena con roles o personas. Una persona es un representante típico de un grupo destinatario. El rol del usuario también puede definirse en función del contexto de cada momento. Así, por ejemplo, es posible asignar el mismo rol a diferentes personas y describir la relación existente con el producto.

[Valor] – ¿Por qué?
El marcador de posición [Valor] responde a la pregunta de POR QUÉ. Aunque la estructura de la frase le tiente a omitir esta cláusula subordinada, una historia de usuario no está completa sin este añadido.

[Función] – ¿Qué?
El marcador de posición [Función] se rellena con la expectativa, los objetivos y los deseos del [usuario]. La función responde así a la pregunta de QUÉ necesita y espera el cliente. Si el producto ya se encuentra disponible en el mercado, muchas de las funciones deseadas vendrán sin duda directamente del usuario. En las primeras fases de un proyecto, se pueden formular suposiciones sobre qué [función] espera el [usuario] basándose en la experiencia del cliente o del propietario del producto y del equipo.

Esto significa que, hasta que no se indica el [valor], no se explica por qué el logro de la [función] es importante en absoluto para el [usuario] y qué valor añadido crea el cumplimiento de la historia de usuario. Como muy tarde en este punto, la historia de usuario ofrece una reflexión veraz sobre el grado en el que ha logrado satisfacer los requisitos de los clientes. Incluir los requisitos es fácil (por ejemplo, porque el cliente pide a gritos una función). Pero entender por qué es importante para él es lo que da al equipo el contexto necesario. ³

Así escribimos las historias de usuario en XITASO

Como resultan fáciles de comprender y se centran en el usuario, las historias de usuario son una técnica popular y ampliamente utilizada para describir las entradas en la pila de producto de un equipo de Scrum. En consecuencia, en XITASO también utilizamos historias de usuario en todos nuestros equipos de Scrum. Sin embargo, la forma en la que estas se crean, el modo en el que se estructuran y la manera en la que se ejecuta la «solución ideal» esbozada difieren en el día a día de los diferentes equipos individuales y también dentro de un mismo equipo en función del caso de que se trate.

Así pues, apartándonos del enfoque clásico, preferimos poner un énfasis especial en el «porqué» del requisito en la historia de usuario, explicando primero ese «porqué» en la estructura de dicha historia. Como el equipo debe desarrollar una solución para satisfacer las necesidades del cliente, es crucial conocer exactamente los motivos o el problema de dicho cliente para poder ofrecer soluciones alternativas que sean más eficaces, o incluso más baratas, si es que esto último es también necesario. Además, al anteponer el «porqué» a la historia del usuario, desde el comienzo de dicha historia, uno se pone en el lugar del cliente y, por tanto, también ve las cosas con la perspectiva del usuario.

En XITASO, no solo trabajamos en nuevos productos de software, sino también en la mejora de los productos existentes. En este caso, las historias de usuario suelen referirse a funciones ya disponibles. Por ejemplo, una historia de usuario para una tienda en línea existente podría ser así: «Para poder procesar el pago de mi pedido de forma rápida y cómoda, como cliente me gustaría vincular los datos de mi tarjeta de crédito con mi cuenta». Esta formulación responde a las preguntas de quién quiere qué y por qué. No obstante, queda abierto cuál es el procedimiento actual. ¿Aún no es posible que el cliente pague con tarjeta de crédito o ya es posible, pero el cliente tiene que volver a introducir los datos de la tarjeta de crédito cada vez que realiza un pedido? Dependiendo de la situación de partida, las expectativas y la urgencia de los cambios también son distintas para el cliente en cuestión. Así, para lograr un mejor entendimiento común de lo que se debe conseguir con esta historia de usuario, nos ha resultado útil ampliar dichas historias con una cláusula subordinada del tipo «puesto que, en la actualidad», que describe el procedimiento actual que debe mejorarse: «Para poder procesar el pago de mi pedido de forma rápida y cómoda, como cliente me gustaría vincular los datos de mi tarjeta de crédito con mi cuenta, puesto que, en la actualidad, tengo que volver a introducir los datos de mi tarjeta de crédito cada vez que hago una compra».

También tratamos de forma intensa la cuestión de si los criterios de aceptación deben (pre)formularse al crear la historia de usuario y en qué medida debe hacerse esto. Está claro que los criterios de aceptación deben definirse en un diálogo entre el desarrollador y el propietario del producto. ¿Pero se formulan realmente los criterios de aceptación de todas las historias pendientes durante el refinamiento de la pila? ¿O puede resultar útil que el propietario del producto defina ciertos criterios de aceptación al crear la historia, que luego puedan debatirse y cambiarse durante el refinamiento de la pila? Por un lado, nuestra experiencia ha demostrado que puede resultar ventajoso formular los criterios de aceptación por adelantado para comunicar los cambios deseados a un equipo más amplio, pues esto proporciona un marco para el debate y la definición de los criterios y ahorra tiempo durante el refinamiento de la pila. Sin embargo, un argumento en contra de este enfoque es que los criterios de aceptación formulados por escrito ya prescriben una línea de pensamiento y, por lo tanto, pueden llegar a impedir la introducción soluciones creativas. Así que es cuestión de ponderar en cada caso el tiempo que se ahorra con lo que supone la búsqueda de soluciones creativas. Un compromiso podría ser que el propietario del producto ya haya pensado en los criterios de aceptación por adelantado, pero que aún no los haya fijado en la historia de usuario. De este modo, puede cotejar sus notas durante las reuniones o las charlas y añadir sus criterios de aceptación si es necesario.

Dependiendo de la estructura de roles que exista entre el cliente/contratante y el equipo del propietario del producto, la creación de la visión del producto y, en consecuencia, la parte creativa en la elaboración de las historias de usuario se deja completamente en manos del propietario del producto. En el caso de un fuerte visionario en el lado del cliente o del contratante, el propietario del producto asume más bien el papel de un ingeniero de requisitos, que moldea los requisitos de una forma que se ajuste al desarrollo ágil de software y represente la visión del cliente y su visión del producto ante su equipo de desarrollo. En este último caso, el propietario del producto suele carecer en la práctica de la capacidad de decisión para responder a todas las consultas o incluso para aceptar propuestas de solución alternativas por parte de su equipo en casos concretos. Así pues, es aconsejable crear las historias de usuario en una fase temprana y presentarlas en la reunión del equipo, pues así hay tiempo suficiente antes de iniciar la puesta en marcha para aclarar cualquier cuestión necesaria con el cliente o el contratante.

¿Qué requisitos especiales surgen para las historias de usuario cuando se trabaja a distancia?

En la actualidad, la crisis provocada por la pandemia de COVID-19 también ha dado lugar a nuevas situaciones y a desafíos especiales en nuestro trabajo diario. Desde este punto de vista, también hemos de comprobar si la historia de usuario sigue siendo adecuada o debe adaptarse en un equipo en el que los miembros trabajan ahora a distancia entre sí. Y, para conseguirlo, damos un paso atrás y nos preguntamos de nuevo qué propósito debe cumplir la historia de usuario. La historia de usuario debe transmitir al equipo de desarrollo los requisitos de un sistema, desde la perspectiva del usuario y utilizando solo unas cuantas frases. Por supuesto, la historia de usuario también cumple estas condiciones en los casos en los que se trabaja a distancia, pues el propietario del producto utiliza la historia de usuario al principio de la planificación y al principio del refinamiento para explicar el problema al equipo. Además, las historias de usuario se consultan durante el proceso de desarrollo en curso para recordar las relaciones entre las tareas individuales, o bien al finalizar la puesta en marcha, para volver a comprobar si los requisitos se han cumplido en todos los aspectos desde el punto de vista del usuario. En este punto en particular, es preferible que la historia de usuario se haya descrito con cierto detalle, puesto que, trabajando a distancia, no es posible preguntar a la persona que tenemos al lado o al propietario del producto que está sentado junto a nosotros si se ha entendido todo correctamente.

Por supuesto, la comprensión correcta y completa de la historia de usuario también se necesita en las planificaciones y los refinamientos que se llevan a cabo periódicamente. Asimismo, además de prestar más atención a los detalles, existen otros consejos que pueden ayudar a conseguir resultados óptimos en estas reuniones, incluso trabajando a distancia. Esto significa que el propietario del producto debe estar más pendiente de las expresiones faciales de su público. Por ejemplo, un ceño fruncido o una mirada errante suelen ser indicios de que el oyente está absorto en sus pensamientos o se ha desconectado del hilo del discurso. Planteando preguntas específicas, el propietario del producto puede comprobar si hay cuestiones que aún no se han entendido, así como registrar las respuestas por escrito en la historia de usuario.

De la experiencia que hemos adquirido en los equipos que trabajan a distancia y, sobre todo, de las últimas semanas, hemos extraído más indicaciones y consejos, que hemos reunido en nuestro podcast de vídeo, en los artículos del blog y en la serie de seminarios web denominada «Agile Wednesday». Nos gustaría haber despertado su interés y estaremos encantados de que vuelva a visitarnos.

Estos son algunos consejos para realizar buenas historias de usuario

Autores y personas de contacto

¿Tienes preguntas, ideas o comentarios sobre este tema? Ponte en contacto con nosotros.

Jennifer Saumweber
jennifer.saumweber@xitaso.com

Bernd Schächterle
bernd.schaechterle@xitaso.com