Buscar en Gazafatonario IT

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

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.

miércoles, abril 22, 2020

La historia de las historias de usuario


Ejemplo de una historia de usuario de Kent Beck. Fuente: Extreme Programming Explained, de Kent Beck
Brevísima historia detrás de la historia de las historias de usuario

Durante un entrenamiento a entrenadores de historias de usuario, hace poco nos preguntaban a Jorge y a mí sobre el origen de las historias de usuario. Por alguna razón olvidada para mí, en el libro omitimos ese pequeño detalle, aunque mencionamos a Connextra cuando hablamos de la forma más usual que suelen tomar las historias de usuario:

Como rol deseo característica Para beneficio

Bueno, aquí les escribo lo que les contamos a los entrenadores:

La historia de las historias de usuario

No es la primera vez que nos preguntan y durante todos estos años, he visto a mucha gente en las redes sociales hacer lo mismo. Por ejemplo, me encontré con este tuit de Seb Rose en octubre de 2019:


Hola, historiadores de Scrum, tengo algunas preguntas:
- Las historias de usuarios comenzaron con XP, documentadas por primera vez en el '98. ¿Es eso cierto?
- Sutherland ejecutó el primer proyecto Scrum en el '93. ¿Usaron historias (o similares)?
- Las historias de usuario ahora están integradas en la práctica de Scrum. ¿Cuándo sucedió eso?
Hay todo un hilo de respuestas. Entre estas, una de Mike Cohn, quien fue convocado por algunos otros tuiteros:

Rachel Davies escribió sobre esto en un artículo. Luego escribí sobre eso en mi libro.
Se refería a ese formato que él mismo popularizó en su libro sobre historias de usuario.
Por supuesto, la intervención de la misma Rachel Davies no se hizo esperar:

Tuve conversaciones con @mikewcohn en la XP2001 donde presenté un póster que incluía la plantilla de la historia de Connextra y fui revisora de su libro sobre Historias de usuario. Él fue influenciado por XP en ese momento ya que el libro de Scrum acababa de salir.
Ya en 2014 había tenido la oportunidad de conocer sobre Rachel Davies vía una versión cruda y sin editar del libro User Story Mapping de Jeff Patton.

En el libro, Patton muestra una fotografía de su amiga:

Rachel Davies mostrando una tarjeta de historia.
Fuente: User Story Mapping by Jeff Patton, Peter Economy

Sobre el origen de las historias de usuario y de sus formas

Es bien conocido que las Historias de usuarios se originaron con eXtreme Programming (XP). Lo que es poco conocido es que su primera descripción escrita en 1998 solo afirma que los clientes definen el alcance del proyecto "con historias de usuarios, que son como casos de uso".

En lugar de ofrecerse como una práctica distinta a XP, se describen como una de las "piezas del juego" utilizadas en el "Juego de Planificación” (Planning Game) del mismo XP.

Recordemos que eXtreme Programming (XP) fue desarrollada por Kent Beck en 1996 y a partir de allí la refinó hasta publicarla en su libro Extreme Programming Explained en 1999.

De hecho, Jeff Patton indagó con el mismísimo Kent sobre el origen específico de las historias de usuario:
Lo que estaba pensando era en la forma en que los usuarios a veces cuentan historias sobre las cosas nuevas y geniales que hace el software que usan. [Por ejemplo,] Si escribo el código postal y se completa automáticamente la ciudad y el estado sin tener que tocar un botón.
Creo que ese fue el ejemplo que desencadenó la idea. Si puedes contar historias sobre lo que hace el software y generar interés y visión en la mente del oyente, ¿por qué no contar historias antes de que lo haga el software?
- Kent Beck a Jeff Patton, por correo electrónico personal, agosto de 2010

Figura 7. Ejemplo de Tarjeta de Historia

Fuente: Extreme Programming Explained, by Kent Beck

En el libro, Beck no dice mucho sobre las historias, hacen parte de las prácticas primarias, junto con otras que conocemos ampliamente como Pair Programming, Continuous Integration y Test-First Programming, sí, esa que a la postre se convertiría en la Test-Driven Development de hoy, entre algunas otras. Sobre las historias (que aún no eran “de usuario”), Kent enfatiza:
“Escribe las historias en fichas y colócalas en una pared por la que pases con frecuencia. La Figura 7 es una tarjeta de muestra de una historia que deseo que implemente mi programa de escáner. Cada intento que he visto de informatizar historias ha fallado en proporcionar una fracción del valor de tener cartas reales en una pared real. Si necesitas informar el progreso a otras partes de la organización en un formato familiar, traduce las tarjetas a ese formato periódicamente”.
Fuente: Extreme Programming Explained, by Kent Beck
La advertencia de registrar las historias en herramientas ya venía desde entonces. Recordemos que XP, junto a Scrum, eran los dos marcos de trabajo dominantes cuyos autores estuvieron presentes en la declaración del Manifiesto Ágil.

Más adelante, en 2001, Ron Jeffries propone el modelo de Tarjeta, Conversación, Confirmación, para distinguir historias de usuarios "sociales" de prácticas de requisitos "documentales", como los casos de uso. Pueden leer su artículo en:


Como nota tangencial, este modelo lo llamamos aliteración Carta, Conversación, Confirmación en nuestro libro de historias de usuario.

Ese mismo año, 2001, Rachel Davies presentó su charla "Tuning XP" en el XPDay con Tim Mackinnon, donde presentaron el formato de historia que usaban en Connextra:

"As a role I want feature so that benefit"


Años más tarde, en 2006, Davies reflexionaba sobre esta “plantilla” antes de dar a conocer sobre un ejercicio que usó en uno de sus entrenamientos. Ella decía que:
“Este formato puede llevar a las personas a centrarse más en los intereses de los usuarios finales que en la perspectiva de la persona que presenta el caso de negocio. Además, cuando se les da una plantilla, las personas pueden comenzar a tratar las tarjetas de historias escritas de esta manera como especificaciones de requisitos mínimos que se centran en las palabras escritas en lugar de usar historias como herramientas para conducir una conversación. Peor aún, las historias que no se ajustan a esta forma serán maltratadas hasta que lo hagan”.

Rachel tiene razón. Esta es una de las grandes anomalías o antipatrones que hoy por hoy siguen presentándose con el uso de las historias de usuario y por ello insistimos tanto a lo largo y ancho de nuestro libro que las historias de usuario son un instrumento de conversación y de colaboración.
Pero no nos desviemos de nuestra historia.

En 2003, Bill Wake creó el mnemotécnico INVEST para iniciativas ágiles de desarrollo de software, como un recordatorio de las características de un elemento de Product Backlog de buena calidad.

Según el mismo Wake este elemento, PBI para abreviar,  puede escribirse comúnmente en forma de historia de usuario, pero no es obligatorio. Como sabemos estos PBI se pueden usar en un Product Backlog tipo Scrum, en un tablero Kanban o un proyecto XP.

En 2004, Mike Cohn publica su libro: User Stories Applied: For Agile Software Development, donde ayuda a popularizar el formato de Davies y su equipo en Connextra. En el hilo de Seb Rose alguien le dice a Mike que fue él (Cohn) quien popularizó el formato, además de los puntos de historia y de la velocidad, ampliamente usados con Scrum. Mike lo corrige:

He contribuido a la popularidad de ellos pero no originé ninguno.
Y todo ello nos trajo hasta aquí.

Epílogo

En lo personal, me parece una historia fantástica. Una a la que hemos asistido en nuestro tiempo. Tardé en empezar a usar historias de usuario pero cuando llegué a ellas hará unos ocho o nueve años, me ayudaron a derrumbar los antiguos paradigmas con los que venía trabajando hasta entonces.

Y en el futuro me gustaría que alguien hablara de mi Lienzo para Conversar sobre Historias de Usuario como parte de la historia de las historias de usuario. Por eso quise terminar la historia a nuestros entrenadores con esta parte:

En 2018, Jorge Abad y Lucho Salazar publican finalmente su libro: Historias de usuario: una visión pragmática, que incluye el User StoriesConversation Canvas, un lienzo para que los usuarios, Dueños de Producto, Gerentes de producto y otros interesados mantengan conversaciones efectivas con los miembros de los equipos de desarrollo de productos y se construyan productos o servicios extraordinarios.
Fuente: ¡conversaciones con Jorge y Lucho!

Fin de la Historia de las Historias de Usuario

Referencias

Además de las fuentes explícitas, pueden consultar algunas otras para saber más sobre esta genial historia: