Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Usuario. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Usuario. Mostrar todas las entradas

viernes, agosto 18, 2023

El poder de la experimentación: una travesía a través de Scrum e historias de usuarios

 

Luego de muchos desafíos he observado una constante: la transformación ágil es una travesía de descubrimiento. Es un camino cargado de preguntas, dudas y esa ansiedad que genera la experimentación. He recorrido este camino con personas, equipos y organizaciones, y una de esas revelaciones es que Scrum, combinado con Historias de Usuario y Desarrollo Conducido por Hipótesis (HDD), puede ser la brújula que nos guíe a través de los paisajes corporativos actuales.

La esencia de la experimentación

Hecho: la experimentación no se trata de fracaso o éxito. Se trata de aprender, adaptarse y mejorar, en el sentido de crecer. Se trata de desafiar las suposiciones y aceptar una realidad en constante cambio. En el corazón de Scrum, el proceso iterativo de inspección y adaptación es en sí mismo un experimento. Es una búsqueda de la verdad, pero también de la belleza y la excelencia.

La experimentación es un arte, pero, sobre todo, una ciencia. Es una filosofía que ha estado en el centro de mi trabajo durante más de una década. Pero ¿qué significa exactamente y por qué resuena tan profundamente en el mundo Ágil?

El proceso de descubrimiento. En el ámbito de Scrum, la experimentación no es simplemente una herramienta o un método; es una forma de pensar que impregna cada acción, decisión e interacción. Permite a los equipos navegar por esos horizontes complejos y en constante cambio de los negocios modernos.

Para experimentar, ten la voluntad de explorar. La experimentación comienza con la curiosidad. Se trata de preguntar, "¿Y si…?" ¿Y por qué no…?" Se trata de tener el valor de adentrarse en lo desconocido, desafiar el statu quo y sondear posibilidades sin un destino predeterminado.

Para experimentar, no le temas a la incertidumbre. Uno de los aspectos más viscerales y emocionales de la experimentación es su incertidumbre inherente. Hay un miedo y una sensación de asombro al no saber qué sucederá a continuación. Es esta incertidumbre la que alimenta la creatividad, la innovación y el crecimiento. Es por ello por lo que causa tanto temor hablar en voz alta de experimentos en los entornos organizacionales de hoy. Sigue siendo un tabú. Antes, era una herejía.

Experimentando, aprendes a través del fracaso. No voy a usar palabras bonitas. Que falla, que negación, que infortunio. No.  En mis años como coach, he visto equipos tropezar, flaquear y frustrarse. Pero también los he visto crecer, aprender y transformarse. La experimentación reconoce que el fracaso no es un callejón sin salida sino una encrucijada, un punto de reflexión, una lección que se debe acoger, que se debe dejar entrar en nuestra cultura organizacional. Es en estos momentos de fracaso cuando a menudo se produce el aprendizaje más profundo.

Experimentando continuamente, cimientas resiliencia. Es de esta manera que las personas y los equipos se vuelven más adaptables, más receptivos y más alineados con la naturaleza dinámica de su trabajo. Es un proceso que fomenta una cultura de confianza, colaboración y empoderamiento.

Frecuentemente me preguntan cómo fomento, cómo cultivo la experimentación. Aquí les dejo algunas notas:

  1. Colabora: involucra a todos. La diversidad de pensamiento es el caldo de cultivo de la innovación.
  2. Acepta el fracaso: este es una oportunidad de aprendizaje. Celébralo, analízalo, crece a partir de él.
  3. Haz preguntas: fomenta la curiosidad. Aviva una cultura en la que se celebre hacer preguntas.
  4. Itera: los experimentos pequeños y frecuentes permiten un aprendizaje y una adaptación rápidos.
  5. Reflexiona: Tómate el tiempo para reflexionar sobre los resultados. ¿Qué aprendiste? ¿Cómo lo aplicarás?
  6. Crea espacios seguros: permite errores. Crea un entorno en el que el fracaso se vea como una oportunidad, no como una amenaza.
  7. Celebra el aprendizaje: concéntrate en el viaje de aprendizaje, no solo en los resultados. Reconoce y recompensa el crecimiento y la comprensión.
  8. Comparte ideas: la transparencia fomenta la colaboración. Comparte hallazgos, ideas y reflexiones abiertamente dentro del equipo y la organización.

La esencia de la experimentación es algo rico y complejo que ha moldeado mi trabajo y la vida de aquellos a los que he acompañado. Es más que una técnica o un proceso; es una forma de ser, un camino que conduce a una comprensión más profunda de nosotros mismos, nuestro trabajo y nuestro mundo. Es el latido del corazón Ágil, y es lo que hace que nuestro trabajo no sea solo un trabajo, sino una pasión, una aventura y una celebración del potencial humano.

Puedes leer algo más sobre esto en:

http://www.gazafatonarioit.com/2022/01/no-cometas-los-mismos-errores.html

O en mi libro Cultura Ágil: ese oscuro objeto del deseo.

La técnica de desarrollo conducido por hipótesis (HDD)

Esta técnica es el núcleo de la experimentación. Con HDD, planteamos preguntas, diseñamos experimentos, analizamos resultados y tomamos decisiones.

Por ejemplo, considera un equipo que lucha con su compromiso de sprint. La hipótesis podría ser: "Al reducir la cantidad de Historias de Usuario en un 25 % en el próximo Sprint, mejoraremos la tasa de finalización en un 20 %". ¿El resultado? A veces funciona, y a veces no. Pero siempre, aprendemos. Incluso ya sabemos que, si aplicas patrones como El Clima de Ayer o Los Equipos que terminan más temprano aceleran más rápido, vas a aumentar tus probabilidades de tener éxito. Entonces dejará de ser un experimento y se convertirá en una práctica común a tu alrededor. Para saber más de estos patrones, puedes consultar el libro Scrum: epítome de experiencias o en mis blogs en:

http://www.gazafatonarioit.com/

O en:

https://luchosalazar.com/category/agilidad/

La técnica HDD no es simplemente un método, sino un enfoque filosófico para el desarrollo de productos y la resolución de problemas. He aquí un breve vistazo a sus elementos centrales y cómo ha llegado a influir en la forma en que trabajo con equipos y organizaciones.

Un enfoque científico. El corazón de HDD radica en tratar cada nueva idea, característica o cambio como un experimento. Adopta un enfoque científico en el que se formula una hipótesis y luego se diseña un experimento estructurado para probar esa hipótesis.

La hipótesis. Una hipótesis es una declaración bien elaborada que expresa una suposición que se va a probar. Por ejemplo, "Implementar la función Pagar Contra Entrega mejorará la participación del usuario en un 20 %". La belleza de este enfoque es su claridad y enfoque, que establece una meta y una métrica precisas para el éxito o el fracaso.

Diseña el Experimento. Dibujar el experimento implica planificar cómo se probará la hipótesis. Esto incluye definir las métricas, el público objetivo, las condiciones y los criterios de evaluación. Es una etapa crítica donde entran en juego la precisión, la previsión y la colaboración.

Ejecuta el experimento y aprende. Una vez que el experimento está diseñado, es hora de ejecutarlo. Esta etapa puede estar llena de anticipación, conmoción y, a veces, desasosiego. Los resultados pueden confirmar la hipótesis, refutarla o revelar ideas inesperadas. Independientemente del resultado, la atención se centra en el aprendizaje y la adaptación. Si no aprendes nada del experimento, quizás no era un experimento del todo.

Itera y adáptate. HDD no es un evento único sino un ciclo continuo. Cada experimento conduce a nuevos conocimientos, nuevas preguntas y nuevas hipótesis. Es un proceso dinámico y en evolución que se alinea perfectamente con la naturaleza iterativa y adaptativa de Ágil y Scrum.

Ahora bien, ¿por qué debería importarte HDD? Esta técnica ha sido transformadora en mi práctica. Aporta disciplina, claridad y un enfoque implacable en el aprendizaje. Alienta a las personas a pensar de manera crítica y sistémica, desafiar los supuestos y aceptar la naturaleza cambiante de su trabajo.

Historias de usuarios y la conexión humana

¡El poder de las historias de usuario!

Las historias de usuarios dan vida a nuestro trabajo. Son la voz de nuestros usuarios, el latido de nuestro producto. Pero también pueden ser un campo de juego para la experimentación. Recuerdo a un equipo que una vez tuvo el desafío de comprender las necesidades de sus clientes. Decidimos experimentar involucrando a los clientes directamente en la creación de Historias de Usuario. El compromiso, la empatía, los conocimientos que obtuvimos fueron transformadores. El producto prosperó, al igual que el equipo. De hecho, usamos Historias de Usuario Conducidas por Hipótesis para que cada nueva característica del producto, y el producto mismo, fueran considerados una hipótesis, un experimento en sí. Es de esta manera que empiezas a promover, aún sin mencionarlo, una cultura de experimentación en tu ámbito empresarial.

La belleza de las historias de usuario radica en su sencillez y humanidad. Sirven como puente entre los requisitos técnicos y las necesidades humanas reales, creando una conexión que impulsa el desarrollo significativo de productos.

El elemento humano. Las historias de usuario ponen al usuario en el foco del proceso de desarrollo de productos. No se trata de código, algoritmos o bases de datos; se trata de personas, emociones, experiencias. Infunden empatía en el desarrollo del producto, convirtiéndolo en un esfuerzo colaborativo y compasivo. Son una parte viva y palpitante del desarrollo ágil. Les ponen cara a las funciones, voz al código y corazón al producto. Al utilizar Historias de Usuario como base para los experimentos, no solo humanizamos el proceso, sino que también aportamos claridad, enfoque y empatía a nuestra búsqueda de innovación y excelencia.

En mi trabajo con diversos equipos y empresas, estas historias simples pero profundas a menudo han sido el catalizador de la creatividad, la colaboración y la conexión. Nos recuerdan que, en el centro de toda nuestra tecnología, procesos y métodos, siempre hay una persona, con necesidades, deseos y sueños. Conectar con ese elemento humano es lo que hace que nuestro trabajo no solo sea efectivo sino también significativo y satisfactorio.

No quiero extenderme más en este sentido. En mi blog puedes encontrar docenas de publicaciones sobre ello, incluyendo presentaciones, artículos y, por supuesto, el libro de la portada negra y naranja.

Pensamientos finales

Mi periplo ha sido uno de continua experimentación. Con cada fracaso, éxito y sorpresa, he aprendido, evolucionado y prosperado. Al menos, lo he intentado. Es una experiencia profundamente personal, llena de pasión, temor, alegría y resiliencia. Lo que he compartido no es solo un método o una técnica, sino una forma de vivir y trabajar. Se trata de ser humano y humanizante en un mundo de complejidad. Se trata de coraje, curiosidad y compasión. Y, sobre todo, se trata de la voluntad de experimentar, cuestionar y crecer.

Aquí tienes el próximo experimento y el siguiente paso en tu propio viaje. Auguro que será tan emocionante, esclarecedor y gratificante como todo lo anterior.

viernes, agosto 04, 2023

El poder de las historias de usuario: sembrando narrativas para cosechar productos disruptivos

 

Esta es algo así como la transcripción de mi charla relámpago en Ágiles Colombia 2023 en Barranquilla. Y al final, está la charla para su descarga.

El poder de las historias de usuario:
sembrando narrativas para cosechar productos disruptivos

Las historias de usuario son un instrumento muy muy poderoso. Escuchen esto, queremos hacer las cosas “the Agile way”, y muchas veces nos preguntamos “¿eso cómo se hace?” “¿Eso con qué se come?”. Pues bien, las historias de usuario son ese utensilio que necesitamos para ello.

Veamos cómo en esta sesión relámpago…

Ninguna charla, mucho menos relámpago, sobre historias de usuario estaría completa si no comenzamos por aquí.

“Con historias y contando historias es como las culturas se hacen más fuertes y sobreviven”.

Con historias es como hemos llegado a este momento del tiempo, algunos científicos ya dicen que estamos en la era del Antropoceno, la nuestra. Imagen así el poder que tienen las historias si son ellas las que nos han permitido evolucionar durante los últimos 2 millones de años.

¡Y las historias de usuario son eso: historias!

Las historias de usuario son un protocolo de comunicación social, y la comunicación es condición requerida, indispensable, sine qua non dicen los intelectuales, para que haya verdadero trabajo colaborativo que, a su vez, es esencial para que la hagamos las cosas de la manera ágil.

Así es que lo más, con énfasis en “más”, importante de las historias de usuario son las conversaciones que se gestan alrededor de ellas. En su entorno.

Son conversaciones que se dan entre las personas involucradas, pero sobre todo comprometidas con el desarrollo de productos o la ejecución de actividades con enfoque Ágil y Lean.

Vamos a ver más en detalle esto porque es el mensaje principal de esta sesión.

Miren. Muchos todavía ven las historias de usuario, en el mejor de los casos, en este ámbito. Alguien tipo Product Manager/Product Owner “escribe” las historias de usuario y se las entrega a un equipo. En ocasiones hay una charla breve, muchas veces más relámpago que esta y ¡zas, ya está! Ahí les dejo sus historias.

Pero no, así no es. Es más bien de esta otra forma.

Esas conversaciones poderosas se dan, de un lado, entre esta persona tipo PM/PO y su entorno, incluyendo no solo a los usuarios o clientes finales, sino también a los interesados y más allá, gente del Mercado, de la Competencia, del Gobierno, de la Sociedad y del Medio Ambiente. Importantísimo estos dos últimos, volveremos a ello sobre el final de la charla.

Y de otro lado, entre esta PM/PO y el equipo de desarrollo de productos. Conversaciones abiertas, francas, en confianza, con transparencia.

Este es el ámbito donde las historias de usuario tienen mucho poder.

Pero eso no es todo… Las historias de usuario son poderosas si su práctica y el comportamiento que exhibimos quienes las usamos tiene como soporte la esencia de la agilidad. HU para colaborar, ya lo dijimos, pero también, HU para entregar en pequeño y frecuentemente, y una vez entregadas, para reflexionar con datos, no con supuestos. Y en el proceso, siempre siempre, mejora implacable.

Esto es absolutamente necesario, si no, son cualquier otra cosa menos historias de usuario a la usanza ágil.

Así que es definitivo. Si por lo menos ya las estamos usando, cambiemos nuestra forma de pensar acerca de las HU. Vamos de un mindset “especificacional” a uno conversacional. Las HU no son para escribir documentos repletos con características del producto. Para nada.

Dicho esto, empecemos también a pensar en las HU como experimentos. Como hipótesis que son realmente. Una HU siempre será una hipótesis hasta tanto el producto o el incremento de producto del que hace parte no está en manos del usuario final, del consumidor.

Así que empecemos a tratarlas como tal desde el principio.

Esto además ayuda a cambiar el mindset que necesitamos para tener éxito con ellas.

Y miren esto: ese apellido “de usuario” no está allí gratuitamente, por su linda cara como decimos. Las HU, o la práctica de estas, deben permitirnos conocer al usuario más que cualquier otra persona en nuestro entorno. ¿Quién es el usuario? ¿Qué hace?

¿Con quién lo hace? ¿Qué información intercambia? ¿Como lo hace? ¿Cuáles son sus dolencias y quejas? ¿Qué lo hará exitoso?

Responder a todas estas cuestiones solo se logra si el enfoque que usamos con HU está centrado en el usuario final y nadie más. En la persona.

De la misma manera, las historias de usuario deben permitirnos conocer más el producto, sus características esenciales, las que hacen feliz al consumidor, las importantes, las que lo dejan satisfecho, y las buenas bonitas, pero no baratas, las que lo dejan presuntuoso, más que cualquier otra persona a nuestro alrededor.

Ahora bien, Las HU poderosas, las que nos permiten crear productos disruptivos que nuestros clientes amen y que causen en ellos impactos a tal grado de modificar su modus vivendi, son pequeñas y aun así proporcionan valor a esos usuarios.

Pequeña es un término relativo, pero en general significa que se pueda construir en una iteración corta junto a otras HU.

También, las HU poderosas tienen unos criterios de aceptación bien definidos: tamaños, colores, matices, sabores, ángulos, vistas. Gozan de precisión, son colaborativos también. Quizás en una sesión hoy hablemos de mi modelo de las 7 C de los criterios de aceptación.

Y en el fondo, las HU poderosas se enfocan en el objetivo del usuario final. Son pequeños peldaños hacia el logro de una meta aún mayor: el objetivo del producto.

Aquí tenemos un ejemplo de una HU que no está basada en el objetivo, sino en la solución, un botón para exportar datos a un plano, ni más faltaba, se le tiene, pero esto no es del contexto de las HU, es algo de la solución.

En cambio, en este otro ejemplo, vemos con claridad una HU enfocada en el objetivo de un usuario final: elegir un método de envío, sin ninguna preferencia en particular ni ningún detalle que restrinja la solución final. Esta será un asunto del equipo de desarrollo del producto.

Y no podemos cerrar tampoco sin hablar de priorización por valor. Las HU poderosas se priorizan por algún aspecto de valor.

Técnicas como MoSCoW, WSJF, modelo de Kano, El costo de la demora y la Matriz de Impacto Motivado, conocida también como el modelo de Lucho.

Entre otras que se pueden usar para ordenar y reordenar un backlog constantemente.

¿Y todo esto para qué? Para hacer que germinen productos asombrosos. Aquí les dejamos un modelo simple pero efectivo para ello.

Ojo al paso 5: No es posible que construyamos productos asombrosos, que impacten a nuestros clientes, es una sociedad y en un planeta enfermos. Perentorio. Así que siempre pensemos en estos 2 factores además del financiero que es absolutamente necesario.

Esto era todo, mis amigos. Aquí 5 ideas claves de esta sesión relampagueante:

1.    Mindset conversacional para las HU,

2.    Colabora,

3.    Enfoque centrado en el usuario,

4.    Priorización eficaz con diferentes métodos, y

5.    desarrollo iterativo e incremental. ¡Lo nuestro!

Muchas gracias. Les dejo información de donde pueden conseguir muchísima más información, por si apenas llegan a nuestra sintonía. En bit.ly/lashistoriasdelucho y, por supuesto, el libro que se originó en esa página precisamente.

Puedes descargar la presentación aquí: 👇


domingo, enero 29, 2023

Historias de usuario basadas en hipótesis

Foto de Kaleidico en Unsplash

En general, las historias de usuario son hipótesis hasta tanto el producto resultante de aquellas se encuentre en manos de los usuarios quienes finalmente “emitirán” un veredicto al respecto. Es por ello por lo que hacemos entregas iterativas e incrementales, para poder adaptarnos a medida que esas sentencias emergen. Es posible que unas veces acertemos, pero es posible que otras veces no.

Ahora bien, el desarrollo basado en hipótesis (HDD por sus siglas de inglés de Hypothesis-Driven Development) es un método de prototipo que permite a los diseñadores de productos desarrollar, probar y elaborar un producto hasta que sea aceptable para los usuarios. Es una medida iterativa que explora los supuestos definidos durante la iniciativa e intenta validarlos con la retroalimentación de los usuarios. Y este es el principal beneficio de HDD.

También posibilita que se reduzca el tiempo y los recursos asociados con los procesos de desarrollo tradicionales. Además, la naturaleza iterativa del proceso permite una mejor comprensión de las necesidades y preferencias del usuario, lo que puede ayudar a garantizar que el producto satisfaga las necesidades del cliente.

El proceso de desarrollo basado en hipótesis incluye cinco pasos principales:

1.    Definir el problema: identificar el problema que necesita ser resuelto antes de comenzar el proceso de desarrollo.

2.    Formular la hipótesis: enunciar suposiciones e hipótesis que puedan ayudar a resolver el problema.

3.    Desarrollar un prototipo: elaborar un prototipo basado en las hipótesis formuladas.

4.    Probar el prototipo: validar el prototipo con usuarios reales y recopilar su retroalimentación.

5.    Iterar: iterar el prototipo en función de la retroalimentación y volver a probar hasta que satisfaga las necesidades del usuario.

No voy a entrar en detalles de cada uno de estos pasos del método. Lo que sí haré es ilustrarlos con un par de ejemplos antes de ir directamente al tema principal que nos convoca: las historias de usuario basadas en hipótesis.

Ejemplo 1 de HDD:

Problema: un motor de búsqueda no proporciona los resultados más precisos.

Hipótesis: Al mejorar los algoritmos utilizados para buscar, se proporcionarán resultados más precisos.

Prototipo: desarrollar un nuevo algoritmo que pueda buscar mejor a través del texto.

Prueba: hacer pruebas del nuevo algoritmo con usuarios que hayan buscado en el pasado y recopilar la retroalimentación de estos sobre la precisión de los resultados.

Iterar: tener en cuenta la retroalimentación dada para refinar el algoritmo y volver a probar hasta que los resultados sean lo suficientemente precisos para las necesidades de los usuarios.

Ejemplo 2 de HDD:

Problema: una tienda de ropa no tiene artículos para clientes de tallas grandes.

Hipótesis: al ofrecer ropa elegante y de moda para clientes de tallas grandes, la tienda atraerá a una base más grande de clientes.

Prototipo: desarrollar una línea de ropa elegante y de moda para clientes de tallas grandes.

Prueba: probar la línea de ropa con clientes de tallas grandes para obtener retroalimentación sobre el ajuste, el estilo, la calidad y el precio.

Iterar: usar la retroalimentación dada para refinar la línea de ropa y volver a probar hasta que los productos satisfagan las necesidades de los clientes.

Entran las historias de usuarios con el enfoque HDD

Historia # 1

Veamos un par de historias de usuario en la forma clásica:

Como cliente de tallas grandes,

Quiero poder encontrar ropa elegante y a la moda que me quede bien,

Para sentirme tan seguro y elegante como cualquier otra persona.

Hipótesis: al ofrecer ropa elegante y de moda para clientes de tallas grandes, la tienda de ropa atraerá a una base más grande de clientes.

Historia # 2

Como estudiante,

Quiero poder encontrar fácilmente fuentes confiables de información para fines de investigación,

De modo que pueda encontrar rápidamente respuestas precisas a mis preguntas.

Hipótesis: al mejorar los algoritmos utilizados para la búsqueda, se suministrarán resultados más confiables y precisos.

Vamos a darle un giro a estas historias de usuario con el enfoque HDD, es decir, representar la historia como una hipótesis. Para ello, usaré la forma:

Creemos que <esta capacidad>

Dará como resultado <este resultado>

Tendremos confianza para proceder cuando <veamos esta señal medible>

Historia # 1

Creemos que ofrecer ropa elegante y de moda para clientes de tallas grandes dará como resultado una base más grande de clientes para la tienda de ropa. Tendremos confianza para proceder cuando observemos un aumento de clientes en un 15 % y de ventas en un 25 %.

Criterios de aceptación:

·       La tienda debe ofrecer una gama de ropa elegante y de moda para clientes de talla grande.

·       La ropa debe quedarles bien a las clientes de talla grande.

·       La ropa debe ser de calidad superior.

·       El precio de la ropa debe ser razonable.

Historia # 2

Creemos que mejorar los algoritmos utilizados para buscar

Dará como resultado resultados más confiables y precisos.

Tendremos confianza para proceder cuando observemos una mejora en los resultados de búsqueda.

Ahora, escribe algunos Criterios de Aceptación de estas historias de usuario

Criterios de aceptación:

·       El motor de búsqueda debe ser capaz de buscar con precisión a través del texto.

·       Los resultados deben ser lo más precisos posible.

·       La búsqueda debe ser rápida y eficaz.

·       La búsqueda debe proporcionar una gama de resultados que sean relevantes para la consulta.

Ahora, veamos algunas historias de usuario con este enfoque HDD de una aplicación tipo “Netflix”:

Creemos que ofrecer recomendaciones de contenido personalizado

Dará como resultado usuarios más comprometidos.

Tendremos confianza para proceder cuando veamos un aumento del 17 % en la participación de los usuarios.

Criterios de aceptación:

·       La aplicación debe proporcionar recomendaciones de contenido personalizadas basadas en los hábitos de visualización del usuario.

·       Las recomendaciones deben ser pertinentes y precisas.

·       El usuario debe poder ver fácilmente el contenido recomendado.

 

Creemos que brindar una experiencia de visualización optimizada

Resultará en una mejor experiencia para el usuario.

Tendremos confianza para proceder cuando observemos un aumento en la satisfacción del usuario.

Criterios de aceptación:

·       La aplicación debe proporcionar una experiencia de visualización optimizada.

·       El usuario debe poder encontrar y ver contenido fácilmente.

·       El tiempo de carga debe ser rápido.

·       La interfaz de usuario debe ser intuitiva y fácil de usar.

Una breve explicación de este enfoque

HDD es una forma específica de describir historias de usuario que incluye tres elementos clave:

1.    Creemos en <esta capacidad>: este elemento describe la capacidad o función en la que se centra la historia de usuario. Define lo que la historia de usuario está tratando de lograr desde un punto de vista funcional o técnico.

2.    Dará como resultado <este resultado>: este elemento describe el resultado esperado o el beneficio de la capacidad o característica descrita en el primer elemento. Define qué problema está tratando de resolver la historia de usuario y qué valor aportará al usuario.

3.    Tendremos confianza para proceder cuando <veamos esta señal medible>: este elemento define una señal medible que indicará que se ha logrado el resultado esperado. Este es un aspecto clave de la forma HDD de representar historias de usuario, ya que garantiza que el éxito de esta se pueda medir y rastrear.

El formato HDD es una forma efectiva de escribir historias de usuario porque garantiza que cada historia de usuario está claramente definida y tiene un propósito específico. Este modelo ayuda a garantizar que todos los interesados comprendan claramente el problema que la historia de usuario intenta resolver, el resultado esperado de la solución y la señal medible que indicará el éxito. Esto puede ayudar a garantizar que el producto se entregue a tiempo, dentro del presupuesto y a satisfacción de todos los interesados y consumidores.

Algunos beneficios que he comprobado al usar este modelo incluyen:

1.    Claridad: este modelo ayuda a definir claramente el problema que la historia de usuario está tratando de resolver y el resultado esperado de la solución. Esto puede facilitar que todos los interesados y comprometidos entiendan el propósito de la historia de usuario y cómo encaja en el producto general.

2.    Alineación: al establecer claramente el problema y el resultado esperado, esta forma puede ayudar a garantizar que todos estén alineados con el objetivo de la historia de usuario. Esto puede ayudar a reducir la confusión y garantizar que todos trabajen hacia el mismo objetivo final.

3.    Medición: el modelo permite definir una señal medible que indique el éxito de la historia de usuario. Esto puede ayudar a determinar si la solución final es exitosa, es decir, la hipótesis era cierta y si se ha logrado el resultado esperado.

4.    Priorización: el modelo facilita la priorización de historias de usuarios al tener una comprensión precisa del problema y del resultado que todos quieren. Esto puede ayudar a garantizar que las historias de usuarios más importantes e impactantes se aborden primero.

5.    Comunicación: esta forma de historia de usuario proporciona una forma clara y concisa de comunicar la historia del usuario a todos los interesados, los miembros del equipo y otras personas involucradas en el desarrollo del producto. Después de todo, lo más importante siguen siendo las conversaciones que se tengan alrededor de la historia de usuario. Esta es una manera más de iniciar y mantener esas conversaciones.

Algunos ejemplos adicionales

En la forma clásica:

Como cliente,

Quiero poder pagar mis compras con mi tarjeta de crédito

Para poder tener más flexibilidad en mis pagos.

En forma de hipótesis:

Creemos que proporcionar a los clientes la capacidad de pagar sus compras con su tarjeta de crédito

Dará como resultado que los clientes tengan más flexibilidad en sus pagos.

Tendremos confianza para proceder cuando al menos el 70 % de los clientes opten por pagar con su tarjeta de crédito.

 

En la forma clásica:

Como empleado de una empresa de logística,

Quiero poder rastrear la ubicación de nuestra flota en tiempo real

Para poder tomar decisiones más informadas.

En forma de hipótesis:

Creemos que proporcionar a los empleados de la empresa de logística la capacidad de rastrear la ubicación de la flota en tiempo real

Dará como resultado que los empleados puedan tomar decisiones más informadas.

Tendremos confianza para proceder cuando al menos el 75 % de la ubicación de la flota se actualiza en tiempo real.

 

En la forma clásica:

Como empleado de recursos humanos,

Quiero gestionar las solicitudes de vacaciones de los empleados de forma automatizada

Para poder ahorrar tiempo y reducir los errores.

En forma de hipótesis:

Creemos que proporcionar la capacidad para que los empleados de RR. HH. gestionen las solicitudes de vacaciones de los empleados de manera automatizada

Dará como resultado que los empleados de RR. HH. brinden un mejor servicio a los empleados de la compañía.

Tendremos confianza para proceder cuando las solicitudes de vacaciones se gestionen en menos de 24 horas.

 

Como puedes ver, el formato clásico proporciona una descripción general de la historia del usuario. Sin embargo, en forma de hipótesis, se proporciona una vista más detallada y estructurada de la historia, con un claro énfasis en el problema, la solución y la medida de éxito.

 

domingo, octubre 09, 2022

De historias de usuario a historias de persona

 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.