Buscar en Gazafatonario IT

domingo, agosto 23, 2020

El extraño caso de las historias de usuario técnicas

 

Photo by fauxels from Pexels

Nota: la versión en inglés de este artículo en:

https://luchosalazar.com/2020/08/25/the-strange-case-of-technical-user-stories/

Advertencia

La atención continua a la excelencia técnica y al buen diseño mejora la agilidad”.

[Manifiesto por el desarrollo ágil de software]

Cuando Kent Beck llegó con la idea de las historias de usuario como parte del juego de planificación de eXtreme Programming (XP Planning Game), no imaginó el impacto que esa idea tendría en el desarrollo de software y, por extrapolación, en el desarrollo de productos, varios años después; fue como un “efecto mariposa”. De hecho, al principio solo las describió como algo con lo que los clientes definen el alcance del proyecto "con historias de usuarios, que son como casos de uso". Pueden encontrar más sobre esto en “La historia de las historias de usuario”.

Pero una de las prácticas que ha perdurado hasta nuestros días es esta de querer expresar todo como una historia de usuario. En la práctica, esto es posible. Ya que las historias de usuario se pueden representar de infinitas formas. En el libro Historias de usuario: una visión pragmática, que escribimos con Jorge Abad, quien también  me compartió algunas de sus ideas para este artículo, hablamos precisamente de algunos de los modos de representación de las historias de usuario, incluyendo el User Stories Conversation Canvas, un lienzo para mantener y registrar conversaciones sobre estos elementos del backlog de producto.

Sin embargo, hay algunas cosas que definitivamente no son historias de usuario. El “apellido”, ese “de usuario” está allí por una razón muy importante que ni siquiera el mismo Kent Beck imaginó al comienzo. Él hablaba de “stories”, simplemente historias: estas se ven, se perciben, se entienden, se describen desde el punto de vista de quien las va a usar una vez estén implementadas o de quienes las van a consumir una vez hagan parte de los productos o servicios que se desarrollen usando esta técnica.

Las cosas así, cuando se trata de software, las llamadas historias técnicas no son una buena idea. ¿Quién es el usuario de “quiero integrar la IA de Google para hacer la traducción del texto”? ¿O de “quiero optimizar la base de datos para acelerar las consultas”? Pero sí es posible saber quién es el usuario de “quiero traducir un texto para entenderlo mejor” y de “quiero consultar la información del cliente” con la condición de que el resultado de la consulta se presente en menos de dos segundos.

Es un hecho, representar algo en forma de historia de usuario cuando no se trata de usuarios-personas del sistema es un error. Hay mejores formas de documentar o registrar este otro tipo de actividades “internas” de un sistema. Una de ellas es precisamente poniéndolas en su lugar como tareas que el equipo debe realizar para lograr finalmente algo de valor para el usuario-persona a través de una o varias historias de usuario. Pensemos en historias de usuario como “historias de persona”. Quizás esto nos ayude a entender la diferencia.

Una de las formas de saber si algo es una “historia de usuario-persona” o no, es cuando al mantener conversaciones con los representantes del negocio, por ejemplo un Dueño de Producto, estas conversaciones fluyen naturalmente y la fuente de información casi siempre es ese representante del negocio. Pero si este empieza a preguntar por términos o expresiones técnicas que emergen en el diálogo y el equipo de desarrollo tiene que dar explicaciones intrincadas que no son del dominio de aquel, entonces quizás hemos traspasado el plano del valor o beneficio de la historia para los usuarios a uno del dominio del equipo técnico.

Photo by fauxels from Pexels

Tenemos que hacer un left outer join seguido de una eliminación de duplicados” es algo con lo que perdemos a los usuarios. “Diariamente hacemos refactoring del código y luego lo integramos con el del resto del equipo usando Bamboo o Jenkins”, mientras “automatizamos los escenarios de prueba usando behaviour-driven development” y “consumimos el web service de [INSERTA AQUÍ TU PROVEEDOR DE WS FAVORITO] para conocer el valor del dólar minuto a minuto”, son conversaciones clásicas que dejarán en ascuas a un Dueño de Producto o a cualquier otra persona de las áreas del negocio.

Y no, no es porque usamos los términos en inglés. Aun en español van a sonar muy extraños a los usuarios. Más, cuando muchas de esas expresiones no tienen un equivalente apropiado en nuestro idioma o, en la vida cotidiana, significan algo totalmente distinto para el común de las personas:

¿Una “combinación externa por la izquierda”? – ¿A qué estará jugando?

¿“Desarrollo conducido por comportamiento”? – ¿Estará hablando de que su comportamiento en la empresa lo tiene a prueba?

¿Y mi consulta de los datos del cliente?”, preguntan con los ojos bien abiertos y con esa expresión de desánimo que solo significa que no están recibiendo lo que quieren y que incluso los lleva a pensar que los miembros del equipo no han entendido del todo lo que los usuarios necesitan. Por lo general, es una combinación de ambos. El asunto se pone más grave si alguien del equipo intenta explicar con mayor detalle lo que significa todo ese galimatías* técnico o trata de justificar con ello los tiempos estimados de desarrollo. A estas alturas es a todas luces evidente que se requiere la presencia de un facilitador, coach, Scrum Master o similar, para abortar la conversación y llevarla por otro camino.

Finalmente, no entendamos las historias de usuario-persona o las historias de persona como aquellas que solo abordan el “front-end” o la experiencia del usuario, de la persona. No. Toda historia de usuario tiene componentes “verticales” que van desde la forma cómo se comunica una persona con el sistema, hasta cómo se almacena y se procesan los datos que intercambia esa persona con el sistema o el entorno: base de datos, servicios, lógica del negocio, presentación, etcétera.

Más sobre cómo conducir conversaciones con historias de usuario en nuestra serie de historias de usuario altamente efectivas:

http://www.gazafatonarioit.com/p/la-serie-historias-de-usuario-efectivas.html

Y todavía mucho más en el libro Historias de usuario: una visión pragmática.

Llamado a la acción

Separemos explícitamente las historias de usuario, las de valor para el negocio, usuarios o clientes, de las tareas del equipo y de los componentes “internos” del sistema (producto) con los que se logra obtener ese valor o beneficio. Como agentes de cambio, asegurémonos de que los miembros del equipo desarrollen habilidades y destrezas en el dominio del negocio, ayudándolos a ellos y a los Dueños de Producto e interesados a mejorar las interacciones entre unos y otros mediante la conversación continua, ojalá cara a cara (¡en 2020 encendamos la cámara!) y a que no todo tiene que ser una historia de usuario, al menos no representadas de la misma manera.

Conclusión

Si en la conversación sobre una historia de usuario es el Dueño de Producto quien termina interrogando al equipo para aclaraciones y no al contrario, quizás el diálogo no sea realmente sobre la historia de usuario.

Epílogo

*Usé intencionalmente la expresión “galimatías”, quizás poco conocida, pero que tiene un lugar en mi Gazafatonario, para dejar la sensación en el ambiente de lo que percibe o siente un usuario final cuando lo confundimos con tecnicismos propios del desarrollo de software.

galimatías

Del fr. galimatias 'discurso o escrito embrollado', y este del gr. κατὰ Ματθαῖον katà Matthaîon 'según Mateo', por la manera en que este evangelista describe la genealogía que figura al comienzo de su evangelio.

1. m. coloq. Lenguaje oscuro por la impropiedad de la frase o por la confusión de las ideas.

2. m. coloq. Confusión, desorden, lío.

Real Academia Española © Todos los derechos reservados