Y una forma más de delimitar y hacer pequeñas
las historias de usuario
El problema actual
Dividir historias de usuario se ha convertido en un dolor
de cabeza para los practicantes ágiles, principalmente para quienes usan esa
técnica como motor para describir las necesidades de los usuarios y las
características finales de los productos.
Lo voy a decir de otra forma: en mi trasegar diario con
equipos y empresas que acompaño en el uso del enfoque y prácticas y marcos de
trabajo ágil, he visto que dividir historias de usuario es algo de lo que todos
hablan y tratan de practicar, pero les está costando.
Una de las causas de fondo de todo esto es la
subvaloración que se le ha dado a la práctica de historias de usuario. Por ser
algo tan sencillo, tan liviano, se estudia con poco detalle, de manera
superficial y muy rápido. Los practicantes ágiles apenas si le están dedicando
algunos minutos con la creencia de que ya conocen todo lo que deben conocer al
respecto. Pero no es así. De ser algo tan simple, pasó a ser algo tan poco
entendido y muy mal practicado. Quizás pasa lo mismo que con Scrum, liviano y
fácil de entender, pero difícil de llegar a dominar.
Voy a ir más a fondo: el problema no es dividir historias
de usuario en sí. Es tener historias de usuario lo suficientemente pequeñas,
pero de Valor para el negocio y para el usuario, que se puedan elaborar en muy
poco tiempo, desde unas pocas horas, hasta dos o tres días máximo, teniendo en
cuenta iteraciones cortas de 10 días. Y cuando digo 2 o 3 días como máximo, me
refiero a que la historia queda Terminada, cumple con todos los criterios de
aceptación y con todas las condiciones de la Definición de Terminado para las
historias de usuario individuales.
Entran las historias de persona
Soy
Nancy. Ama de casa. Jubilada hace muchos años. Quiero hacer una
transferencia de dinero a mi nieta sin tener que ir al banco. No quiero
exponerme a un contagio y ya no tengo fuerzas para esperar de pie haciendo
largas colas. Y quiero dedicar mi tiempo a otras labores de la casa.
Quiero hacer
la transacción desde mi celular o en el PC de la casa.
Debe ser fácil
de realizar porque no soy experta en el uso de estos dispositivos.
Quiero hacerlo
de manera segura y rápida. Que no me roben mi platica.
Miguel
es periodista. Viaja continuamente. Quiere saber cuándo le han consignado sus
honorarios y sus gastos de viaje para llevar un control estricto de sus
ingresos y gastos.
Miguel quiere
recibir información de las consignaciones en su celular, quizás a través de
mensajes de texto.
El mensaje
debe incluir información sobre el valor de la consignación, el concepto por el
cual se hizo y la fecha y hora de esta.
Miguel quiere
que nadie más pueda tener acceso a esa información en caso de que se le
extravíe el celular.
Aquí hay dos historias de
usuario, dos historias, 2 relatos desde el punto de vista muy particular y
hasta íntimo de dos personas. Tienen nombre propio, atraviesan vicisitudes
específicas, necesidades singulares. Requieren que se cumplan algunas condiciones
que consideran valiosas. Estas representan el éxito de su experiencia de
cliente usando productos de alguna corporación o empresa. Son historias de
persona.
Las historias de persona son concretas, en contraposición
a las abstracciones naturales de una historia de usuario que señalan o lidian
con, por ejemplo, Amas de Casa, Empleados, Clientes, Jubilados, trabajador
autónomo o free lance, entre muchos otros. La misma historia permite
conocer qué hace la persona, cómo lo hace, con quien lo hace, qué información
intercambia y con quién la intercambia o quién es el receptor de esta. De alguna manera también deja ver sus
principales problemas o inconvenientes al hacer lo que hacen. Es como si el
equipo de trabajo, incluso los interesados y el mismo Product Owner o Product
Manager, lo estuvieran viendo en acción, algo que se ha perdido en
las últimas décadas en pro de prácticas que, de distintas manera, impiden el
contacto o el acercamiento de quienes hacen productos con los consumidores o
usuarios de estos.
Las historias de persona comienzan con la “persona” que
originó la necesidad, con nombre y características demográficas únicas. Viene
de la práctica User Persona. Esta persona tiene una identidad única y
esto delimita el ámbito o el alcance de la historia y, por consiguiente, de la
característica del producto que un equipo está forjando. He usado esta técnica
en los últimos años y he comprobado que, en general, las historias resultantes
son pequeñas, siguen siendo de valor y, efectivamente, se pueden labrar en muy
pocas horas o, a lo sumo, en muy pocos días, junto a otras historias en una
iteración breve.
Esta es una regla general, por supuesto. Es posible que
algunas de estas historias todavía tengan que dividirse aún más para que se
puedan trabajar en un sprint corto sin el riesgo visible de que no se puedan
terminar junto a las demás.
No es la primera vez que uso el concepto de persona
relacionado con las historias de usuario. El primer bloque o nodo de mi User
Story Conversation Canvas es sobre las personas.
Sobre esto explico que “el equipo debe conocer muy bien el perfil de estas
personas, los aspectos personales y profesionales que los identifican, la
educación, datos demográficos, sus hábitos e incluso sus motivaciones y
comportamientos, lo que les gusta y lo que no. Después de todo desarrollamos
productos y servicios para seres humanos. El equipo debe sentir que conoce
al usuario”.
El enigma del “usuario” en la
historia de “usuario” y cómo resolverlo
 |
| Imagen de OpenClipart-Vectors en Pixabay |
No me malentiendan. He escrito lo suficiente sobre
historias de usuario, incluso he publicado un libro con
mi gran amigo Jorge
Abad
sobre estos menesteres
cuya edición en inglés recientemente fue referenciada por la Agile
Alliance. No hay un problema de fondo con el usuario en la
historia de usuario. Pero conocer más al usuario sí ayuda.En general, un “usuario” es un concepto abstracto con cierto
nivel de vaguedad que se puede automatizar o categorizar para trabajar con él,
pero su uso ha mostrado ser de mucha valía en los negocios y en la industria.
Un “usuario” describe actividades y responsabilidades de un grupo de
individuos. Escribí ampliamente sobre eso en mi libro Asuntos
de la Ingeniería de Software, cuando hacía referencia a
los Casos de Uso de Ivar Jacobson y a un elemento fundamental de los casos de
uso: el Actor. Y un usuario es precisamente eso, un actor. De hecho, decía en
una de mis Lecturas
Fundamentales, en noviembre
de 2006 que “Debemos indagar por las costumbres del actor, su
perfil, su experiencia, su conocimiento, el entorno donde se mueve”, nada
diferente de lo que estoy diciendo hoy nuevamente, 16 años después.
Un usuario es un rol que se define a través de una tarea o
acción concreta o un grupo de funciones con mucha afinidad, que son ejecutadas por
personas durante el consumo de un producto o el uso de un sistema. Sin embargo,
los usuarios no son algo tan simple como pueden parecer para el practicante
ágil inexperto y aún para muchos expertos. Los usuarios pueden llegar a gozar
de una ambigüedad tal que vuelven problemática la obtención de historias de
usuario pequeñas y de valor. He revisado conjuntos de historias de usuario donde
los usuarios exhiben incompatibilidades entre ellos o donde unos tienen
sobrecarga de responsabilidades o donde se presenta cierta tensión entre unos
usuarios y otros, además de algunas otras tramas inesperadas.
En particular, la ambigüedad es un aspecto destacado para
el diseño de productos porque nos muestra una fotografía de la ausencia de
precisión que una persona, sus colegas e incluso todos en la empresa pueden
llegar a tener sobre los roles y sus responsabilidades. He dedicado más de dos
décadas a estudiar este fenómeno y he tenido experiencia de primera mano cuando
de usuarios o consumidores y sus responsabilidades o acciones se trata. Por
ejemplo, he leído, debatido y ayudado a mejorar decenas de historias de usuario
con usuarios como “cliente”, “visitante”, “abonado”, “cliente potencial”,
“interesado” o “solicitante” que dicen muy poco o nada sobre el contexto de uso
de la historia de usuario y que obstaculizan de distintas formas la división de
una épica en historias más pequeñas y trabajables.
Una de las pocas formas que me ha funcionado para
resolver todo esto es que todos los interesados en el producto, es decir, el
equipo de producto y el equipo de trabajo en pleno vean al usuario en acción.
Hay disponer de la logística necesaria, a lo Ojo del Gran Hermano, para que
todas estas personas tengan la oportunidad de ver a sus potenciales usuarios o
consumidores trabajando. ¿Qué hacen? ¿Cómo lo hacen? ¿Cuándo? ¿Con quién lo
hacen? ¿Qué información intercambian unos con otros y quienes de estos también
son usuarios y quienes no? ¿Cuáles son sus principales problemas o las
dificultades más frecuentes que impactan su desempeño? ¿Cuáles son los
criterios de éxito que tienen en cuenta en su accionar habitual?
Resolver estas cuestiones es de suma importancia antes de
pensar en la solución que necesitan estos clientes o consumidores.
De vuelta a las historias de
persona
 |
| Imagen de Gerd Altmann en Pixabay |
Hola, soy
Mabel, Gerente de Crédito Hipotecario. Quiero un informe de solicitudes de
crédito para realizar proyección de aprovisionamiento y trabajar en las
próximas campañas con el área de Marketing.
El informe
debe ser diario y debo poder clasificarlo por tipo de crédito, pero también
quiero tener un resumen por tipo de crédito y la tendencia respecto a los
últimos 5 días.
También quiero
clasificarlo por tipo de solicitante y tener un subtotal de lo solicitado por
tipo de solicitante.
De manera
predeterminada quiero ver el informe del día inmediatamente anterior, pero
también quiero tener la posibilidad de ver el informe de una fecha anterior.
He estado usando una ligera variación de la forma
Davies-Cohn para representar las historias de persona:
Como [usuario]
Quiero [esta característica] Para [lograr este beneficio u objetivo]
que puede llegar a ser innecesariamente prolija y repetitiva,
aunque muy fácil de entender y de usar en muchos entornos dada la gran difusión
y documentación que ha tenido en las últimas dos décadas.
Pero bien podría usar muchas otras grafías para
representar historias de usuario. Por ejemplo, puedo usar las historias de
usuario estilo BDD, como en:
Registrar
datos personales.
Dado
que Ibeth, asesora de prensa de la alcaldía, solicitante de crédito de
libre inversión, se mantiene muy ocupada en su día a día y tiene poco tiempo
para hacer gestiones de manera presencial, ingresó los datos solicitados
y existe al menos un dato sin diligenciar. Cuando ella intente
enviar los datos, entonces recibirá un mensaje informándole de
los datos sin diligenciar y estos datos aparecerán marcados en rojo y no se
podrán almacenar los datos, aunque se le permitirá almacenar los datos de
manera temporal si ella así lo prefiere.
En conclusión, hay tantas o
más formas para representar historias de persona que para representar historias
de usuario. Y una vez más, noten amigos lectores que uso el término
“representar” como lo he hecho desde hace años, para alejarme y alejarlos de la
limitante y problemática expresión “escribir historias de usuario”. Aquel es
más abierto, indica que se pueden usar no solo palabras sino también figuras y
simbología de distinto tipo que la mente y la imaginación sean capaces de
retener. No sobra decir aquí que lo más importante de las historias de persona
también es la conversación que se mantenga alrededor de cada una de ellas.
Las personas son instancias de los usuarios. Son
ejemplos. Y los ejemplos te ayudan a encontrar inconsistencias en las historias
y porque te delimitan un contexto. Pero sobre todo, los ejemplos son buenos
porque te ayudan a iniciar conversaciones.
Y bueno, además del innegable beneficio del tamaño
(sucinto, en el sentido de pequeño) de las historias de persona, de su contexto
concreto e individualizado, otras ventajas de este instrumento derivado son los
siguientes:
·
Ayudan a definir un mejor y más aproximado
Producto Mínimo Viable, ya que, por naturaleza, estas historias de persona son
mínimas y minimalistas, en el sentido de que son esenciales y eliminan o ayudan
a eliminar lo que puede llegar a ser superfluo en el producto, es decir, nos
ayudan a eliminar desperdicio, a elaborar el producto correcto desde el
comienzo.
·
Las personas son, por naturaleza,
colaborativas. Cada una usa o consume un producto de una manera diferente, pero
entre todas colaboran para que el consumo o utilización del producto se
maximice.
·
Ayudan a que quienes se encargan de exponer
los productos a sus usuarios, es decir, aquellos que tienen la difícil pero
fascinante labor de brindar la mejor experiencia de usuario y de cliente
posible, tengan éxito, dado que las personas se conocen mejor, son más
concretas, generan más empatía y puedes imaginarlas con una sonrisa cuando el
producto las esté ayudando a lograr sus propios objetivos. Las personas nos
permiten conectarnos emocionalmente con ellas, los usuarios abstractos quizás
no.
·
Las historias de persona ayudan a iniciar y a
mantener conversaciones más fluidas y verosímiles que las historias de usuario.
Incluso nos permiten crear otras personas (personajes de la historia) para los
eventos alternativos de la historia o para los procesos de manejo de
excepciones en esta.
·
Las personas son más imaginables o
creíbles o comprensibles que los usuarios porque tienen un rostro y un nombre y
una identidad.
Llamado a la acción
Finalmente, te invito a que uses este modelo de historia,
de historia de persona. Eso sí, cuéntame y cuéntanos cómo lo podemos extender y
practicar mejor. Y no dejes de contactarme con cualquier inquietud que tengas
respecto a este o a cualquiera otra inquietud sobre las historias, sean de
usuario o de persona.
