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