“Yo no sé muchas
cosas, en verdad,
Digo tan solo lo
que he visto.
Y he visto que la
cuna del hombre
la mecen con
cuentos,
que los gritos de
angustia del hombre
los ahogan con
cuentos,
que el llanto del
hombre
lo taponan con
cuentos.
Y que el miedo
del hombre
ha inventado
todos los cuentos…
Yo sé muy pocas
cosas, es verdad,
pero me han
dormido con todos los cuentos
y
sé todos los cuentos ...”
[León Felipe,
Aguaviva.]
La vida es una alegoría,
los seres humanos no solo estamos configurados como cuerpos biológicos
abastecidos de estímulos y pulsiones, pues nacemos en un entorno social y por
tanto nos relacionamos, desde lo más esencial –lo familiar, hasta lo más
universal, con nuestros semejantes. Pero además poseemos una visión personal
para interpretar nuestra cotidianidad, tenemos ideales y pensamientos,
emociones y aversiones que nos hacen actuar
de formas particulares al interpretar nuestra realidad.
En todo esto, la
narración de historias juega un papel muy importante en la construcción de conocimiento. La
narrativa es una forma de caracterizar los fenómenos de la experiencia humana. Dice
Ivar Jacobson en su libro Casos de Uso 2.0 que “la narración de historias
permite a las culturas sobrevivir y progresar; es el camino más simple y más
efectivo para pasar el conocimiento de una persona a otra. Es la mejor manera
de comunicar lo que un sistema debe hacer y hacer que todo el mundo trabaje en
el sistema sobre los mismos objetivos.” [1]
Las historias (de
usuario) establecen una manera de organizar y comunicar experiencias. Las personas
usan instintivamente la narración de historias para organizar un cúmulo de
ideas que consideran disperso; además, gracias a ellas pueden organizar lo que
saben acerca de su trabajo y de cómo lo hacen. Al narrar historias, las
personas nos invitan de una forma u otra
a investigar sus pensamientos, sus sentimientos y sus intenciones.
Finalmente, como oyentes y más tarde como lectores de las historias de usuario,
adherimos a los acontecimientos, como una exploración de la experiencia de los
usuarios, entendiéndolas mejor y de la forma más completa posible, pero sobre
todo, comprendiendo su valor real.
Quienes transitamos a
diario por el vasto universo del diseño y construcción de productos de software
sabemos que es importante enfocarnos en el valor que estos prestarán a sus
dueños, los usuarios, y a otros interesados. El mismo Jacobson dice que “solo
se genera valor si el sistema se usa realmente; así, es mejor enfocarse en cómo
se usará el sistema que en las largas listas de funciones o características que
ofrecerá.” [2] Y agrega más adelante: “es fácil capturar y validar la
completitud de las historias y estas, a su vez, facilitan filtrar las formas
potenciales de usar el sistema que ofrezcan poco o ningún valor real a los
usuarios. Este foco constante en el valor permite asegurar que cada entrega del
sistema sea tan pequeña como sea posible, a la vez que tenga valor real para
los usuarios del sistema y para los interesados que financian el desarrollo.”
[3]
Cuenta
las historias, no las escribas
En su libro “Fifty Quick Ideas to Improve your User
Stories”, Gojko Adzic & David Evans [4], compilan una serie de conceptos
sobre cómo mejorar nuestras historias de usuario o, mejor aun, sobre cómo
mejorar el desempeño del equipo ágil usando la técnica de las historias de
usuario. Me interesó mucho la primera de esas ideas, muy acorde a mi interés
actual sobre las historias y la supervivencia de las culturas. Esta idea es
precisamente la del título de esta sección: cuenta historias, no las escribas.
Uno de los errores más
comunes de las personas que empiezan a usar prácticas ágiles es creer que las
historias de usuario son requisitos livianos. Las historias de usuario no son
requisitos, son más bien una carta de intención de lo que queremos que haga el
sistema, son recordatorios para conversaciones que tendremos más adelante, el Equipo
de Desarrollo y el Dueño de Producto, pero definitivamente no son requisitos.
Este malentendido conduce a situaciones en que las historias sean recolectadas
en herramientas de gestión de actividades, con muchos detalles escritos o
proporcionados por representantes del negocio.
Nada más alejado de una
buena práctica. Las historias de usuario implican un modelo totalmente
diferente, Gojko y David lo llaman “requisitos por colaboración”, un modelo donde
la transferencia de conocimiento vía documentos “pesados” se reemplaza por
involucramiento y colaboración, al mejor estilo del Manifiesto Ágil. Ya sabemos
que la conversación cara a cara es la forma más efectiva de comunicar
información y que una buena discusión entre los interesados y el equipo ágil lleva
a mejores preguntas/respuestas, opciones e ideas del producto. Cuando los
requisitos se escriben, aun si los llamamos historias de usuario, estas
discusiones nunca suceden y las mejores ideas se pierden para siempre. Tengo algo
de experiencia en esto, pasé dos décadas escribiendo requisitos de software,
todo tipo de requisitos, todo tipo de productos de software.
La recomendación es
simple, avanzan Adzic y Evans en su libro: intenta contar historias o que te
cuenten historias, en vez de escribirlas. Usa tarjetas físicas o un sistema de
tiquetes electrónicos, pero solo como recordatorios de esa conversación que
tendrás más adelante. No gastes mucho tiempo tratando de descifrar los detalles
de las historias con anticipación. Compromete a los interesados del negocio e
involucra a los miembros del equipo en una discusión, busca distintas
perspectivas de la historia y explora opciones. Esta es la forma de acceder a
los beneficios reales de trabajar con historias de usuario.
Beneficios
clave de contar historias
Las discusiones permiten
a los representantes del negocio, no solo explicar lo que quieren, sino también
asegurarse de que los miembros del equipo entiendan esto correctamente. Uno de
los mayores problemas en los modelos tradicionales son los malos entendidos
entre los distintos roles en el equipo y entre los interesados, entre quienes
existen niveles heterogéneos de conocimiento acerca de las necesidades de cada
uno, complemento además del ya típico fenómeno del “teléfono roto” [5]. Es un
hecho, explicar una historia cara a cara evita caer en vacíos de conocimiento
sobre la historia.
El segundo beneficio,
apuntan Adzic & Evans, es el análisis más rápido. Cuando el equipo completo
se involucra en una discusión, los vacíos funcionales, las inconsistencias y
los requisitos no claros se descubren más rápidamente que cuando una sola
persona (léase Analista del Negocio o similar), escribe los detalles.
Pero el beneficio más
importante de la comunicación cara a cara, comparada con el paso de información
vía documentos, es que la primera produce mejores soluciones, mejores
productos. Para ser capaz de construir buenas soluciones, las personas
necesitan conocer los planes y las oportunidades del negocio, entender el
dominio del problema, tener un conocimiento profundo de las restricciones
técnicas estar al tanto de las nuevas tecnologías que potencialmente les puedan
servir. Involucrar a un grupo de personas en el análisis desde diferentes
perspectivas ayuda al equipo a beneficiarse del conocimiento compartido.
Como
lograrlo
La excusa más común para
llenarnos de documentación es la insistencia del negocio en la aprobación
formal, las regulaciones legales o gubernamentales o las dependencias con
terceros. Si es necesario “firmar” las historias hazlo a medida que las
discutes. Es más, si el alcance final debe ser aprobado por varios interesados
en el negocio, involúcralos en las reuniones de Refinamiento, días antes de la
reunión de planificación del Sprint donde se van a construir las historias. En
cualquier caso, el Dueño de Producto juega un papel muy importante en la
consecución de tales aprobaciones. Es una de sus responsabilidades directas.
Como siempre, ensaya
distintos acercamientos y en cada retrospectiva analiza como le fue a tu
equipo. Como dice el refrán, la experiencia no se improvisa. Hasta allí el
tema, recomiendo amplísimamente los libros que usé como referencia
Referencias
[1] [2] [3] Ivar
Jacobson et all. Use Case 2.0. Ivar Jacobson
International. 2011. Traducción
de Luis
Antonio Salazar y Carlos Mario Zapata.
[4] Gojko Adzic & David Evans, Fifty Quick Ideas
to Improve your User Stories, ©
2013 – 2014 Nueri Consulting LLP
[5] Conocido también en algunas culturas o regiones como
el fenómeno o el juego del “teléfono descompuesto”
Para saber más de historias de usuario
puedes leer mi serie de artículos en este mismo Gazafatonario:
http://goo.gl/iJvj7
http://goo.gl/NZv4vj
http://goo.gl/e1DSVh
http://goo.gl/eGHQQU
