Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta User Story Mapping. Mostrar todas las entradas
Mostrando las entradas con la etiqueta User Story Mapping. Mostrar todas las entradas

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:


jueves, febrero 01, 2018

Diferencias en el tratamiento de los requisitos entre los enfoques Cascada y Ágil


¡Una pregunta de un viejo amigo me llevó una vez más por este sendero!
Es un hecho. Muchos profesionales trabajan actualmente en circunstancias desafortunadas y, sin embargo, no toman la iniciativa de cambiar su situación porque están condicionados a un formato de seguridad, conformidad y conservación, donde todo puede parecer tranquilo pero, en realidad, nada es más perjudicial para el espíritu innovador y de transformación que requerimos hoy quienes vivimos en los tiempos del VUCA*.
En particular, durante la transición de un enfoque en cascada a uno Ágil tenemos que lidiar con la búsqueda de medios y maneras para acortar el tiempo de salida al mercado y entregar productos de alta calidad y de más valor, más temprano y más frecuente y, si es posible, a un costo menor. Sin embargo, el camino hacia la Agilidad puede ser escabroso, con baches riesgosos y con personas deambulando por allí erráticamente y hasta en dirección opuesta, incluso con temor a o sin saber cómo avanzar.
Y uno de los aspectos que empiezan a diferenciar en profundidad el uso de uno u otro enfoque es este de los requisitos. Abordamos este asunto con Carlos Gil, Johnny Ordoñez, Carlos Quiroga, Luis Mulato y el grandioso equipo de coaches del Scrum Coaching Retreat Cartagena y, como siempre, llegamos a algunas conclusiones que se mueven en el terreno de los principios y, más en el fondo, de los valores Ágiles, la cultura ágil, el Ágil es algo que eres:

  • En Ágil no hablamos de requisitos, más bien de respuestas a necesidades y, en otros casos, de hipótesis de cosas que queremos aprender. Cambiar el enfoque de “requisito” a “necesidad” o respuesta a necesidad, genera un sentido profundo de empatía entre todos los interesados, es decir, equipo de desarrollo de producto y usuarios o clientes finales.
  • A propósito de clientes finales, en Ágil, el cliente siempre es el centro de atención. Esto habilita a los equipos a buscar las mejores formas de suplir esa necesidad o de comprobar las hipótesis. Estas en últimas son necesidades de aprendizaje.
  • Creemos que esta es la distinción más grande entre las dos propuestas: el requisito te lleva a algo preestablecido, definitivo o definible claramente. Hablar de necesidades o de hipótesis abre la puerta al cambio.
  • En el enfoque Cascada se definen experiencias orientadas al proceso, con momentos de interacción preconcebidos por los formularios y procesos definidos en los requisitos, y aun hablamos de interacciones y no de conversaciones con las soluciones tecnológicas. En Ágil, aspectos como la experiencia de usuario, momentos de verdad, conversaciones, son esenciales para la definición de la historia de usuario que guía el desarrollo de producto.
Vamos con las disparidades entre uno y otro enfoque cuando de requisitos se trata
Son muchas las diferencias que existen en la forma de abordar los requisitos de un producto cuando usamos (o usábamos) la forma Cascada y lo que hacemos ahora, motivados por el pensamiento Ágil. Estas que describo a continuación son apenas algunas de ellas, algunas más relevantes que otras pero significativas todas al fin y al cabo.
Al principio del proyecto o del esfuerzo de desarrollo

En Cascada se toman o "levantan" (casi) la totalidad de los requisitos al principio del proyecto, y de muchos de ellos se hace con gran detalle. En Ágil no. Se establece un alcance, sí, una visión, pero de muy alto nivel, muy horizontal, es decir, no se llega a ningún detalle excepto quizás para esas necesidades de los dos primeros Sprints (a lo sumo), la porción de producto que se va a construir durante las primeras de cambio. El llamado Mínimo (o Minimísimo) Producto Viable.
En Cascada nos tardamos semanas y hasta meses haciendo esta primera actividad. En Ágil nos tardamos unas pocas horas, a lo sumo unos pocos días, se establece un bloque de tiempo (time-box) y cuando este se acaba, se acaba.
En Cascada participa una persona del lado del equipo de desarrollo o un "subequipo", el o los analistas funcionales o de requisitos. Quizás en algún momento entra uno que otro rol, como el Arquitecto de Software. En cualquier caso, no participa todo el equipo. En Ágil participa todo el equipo de desarrollo desde el inicio, escuchando a los usuarios e interesados en el producto.
Más adelante, cuando el proyecto está en marcha
En Cascada se refinan los requisitos, hay ajustes, controles de cambios. El sobrevaluado CCC (léase Comité de Control de Cambios) que se reúne el último jueves de cada mes, mientras el cliente ve impaciente cómo su competencia se adelanta y le quita parte del mercado. Mientras tanto, en Ágil se van refinando los requisitos iteración tras iteración. Siempre nos concentramos en lo que se va a construir en los siguientes 2 sprints o iteraciones, a lo sumo. Más tiempo no, porque las cosas pueden cambiar. Los equipos Ágiles aprovechamos los cambios para brindar ventaja competitiva a nuestros clientes.
En Cascada los requisitos siempre los "administra" una persona o un subequipo (analistas), con los usuarios. En Ágil hay un Dueño de Producto (representante de los usuarios), pero la responsabilidad es de todo el equipo.
En Cascada los requisitos se construyen, como sabemos, siguiendo un proceso secuencial donde ellos se tratan aparte y son una entrada al resto de ese proceso; además, el producto se entrega como un todo. En Ágil se construye un incremento del producto en cada iteración (de muy pocos días), esto es, producto probado y funcionando con valor, potencialmente desplegable y que genera retorno de la inversión (ROI) o, al menos, permite recibir retroalimentación, con lo que podemos aprender muchísimo del comportamiento y de la reacción de los usuarios al uso del producto.
En Cascada normalmente el orden de construcción lo decide el equipo de desarrollo (quizás en cabeza de un arquitecto o un subequipo). En Ágil el orden de construcción lo decide el usuario (dueño de producto), es él quien tiene la última palabra sobre esto.
En Cascada, el énfasis en cuanto a requisitos está en la especificación (documentación) de los mismos, en otras palabras, en escribir y escribir requisitos. En Ágil, el énfasis está en la conversación que tienen los usuarios o su representante (dueño de producto) con el equipo de desarrollo. Esta conversación es cara a cara y continua, durante todo el proyecto o esfuerzo de desarrollo.
Esta última característica es lo que nos empieza a volver ágiles, cuando lo logramos nos damos cuenta que estamos usando el pensamiento Ágil y estamos dejando atrás la cascada y otras formas tradicionales de trabajo.
En Cascada se espera que prácticas de aseguramiento de calidad permitan que se entregue un producto que cumpla con casos de prueba previamente definidos y aprobados con el área de negocio. En Ágil damos espacios a prácticas como TDD y BDD para guiar la definición de los criterios de aceptación, identificando de manera temprana la respuesta real que espera el usuario final, la prueba es guiada por la retroalimentación continua, lo cual mejora el uso y por lo tanto la aceptación del usuario.
Y sobre medios o herramientas para “recolectar” y administrar requisitos
Una diferencia en cuanto a los medios o mecanismos para "recolectar" requisitos:
En Cascada se usan medios como los documentos escritos tradicionales llenos de expresiones tipo "el sistema debe hacer esto" o "el sistema debe hacer aquello", o se usan mecanismos como casos de uso, entre otros. En cualquier caso, como mencioné antes, la fuerza está en elaborar grandes cantidades de documentación de requisitos. Escribí mucho sobre esto aquí en el Gazafatonario durante la década pasada y publiqué un libro al respecto. Lo pueden encontrar en Amazon.
En Ágil, por su parte, usamos medios o mecanismos que promuevan la conversación entre los interesados (usuarios y equipo de desarrollo). Las Historias de Usuario se han constituido en el medio esencial para esto. Pueden encontrar una especie de índice de mis artículos y propuestas y las de mi gran amigo Jorge Abad sobre este tema en bit.ly/lashistoriasdelucho.
Ahora sí, cuéntame en el foro de otras diferencias a la hora de recolectar y administrar requisitos o necesidades que consideres importantes.



*VUCA: siglas en inglés de Vulnerabilidad, Incertidumbre, Complejidad, Ambigüedad

sábado, noviembre 26, 2016

User Story Mapping - Una introducción


El User Story Map es una herramienta que permite generar una representación visual del producto completo. Ofrece una vista general de todas las funcionalidades que lo componen (the big picture) de punta a punta. 

Permite identificar Historias de Usuario faltantes en el Backlog, planificar Releases (entregas) dividiéndolo en porciones (Slicing) y visualizar cómo se distribuyen las funcionalidades de acuerdo a las diferentes áreas del sistema.

Son diferentes a los backlogs típicos de historias de usuario en cuanto: 

  • Hacen visible el flujo de trabajo o la cadena de valor
  • Muestran las relaciones entre historias más grandes y sus historias hijas
  • Ayudan a confirmar la completitud del backlog
  • Proporcionan un contexto útil para la priorización
  • Permiten planear entregas (releases) en porciones valuadas y completas de funcionalidad

En esta presentación, basada en el trabajo de Jeff patton, hago una breve introducción al tema de User Story Mapping. La pueden descargar de:


martes, agosto 23, 2016

Inceptions, con Jorge Abad



¿Cómo nacen los productos grandiosos? De esos cuyos componentes hacen resonancia entre sí e impactan el 'modus vivendi' de quienes los usan o consumen.

¿Cómo defines su alcance?

¿Cómo estableces el Producto Mínimo Viable - MVP?

¿Cuáles son las distintas técnicas y prácticas ágiles para hacer Inceptions de gran calidad y que motiven al equipo a empezar un trabajo fabuloso?

¿Qué es eso del Elevator Pitch?

¿Y el Product Box?

Además:

El User Story Mapping

+ El plan de entregas

+ El plan de iteraciones

+ Otras técnicas y herramientas que nos ayudan no solo a entender lo que queremos construir (lo que quieren nuestros usuarios o clientes), sino también a lograr consenso entre los miembros del equipo y los interesados en el proyecto y producto o servicio que queremos diseñar y construir.

Estas y algunas otras cuestiones son las que compartí con mi gran amigo Jorge Abad, con ejemplos concretos y prácticos, durante el Webinar del mismo nombre. El video lo pueden encontrar en:



Pueden descargar la presentación de:



Nota:
Este post lo podrás encontrar también en el blog de mi estimado amigo Jorge Abad @Jorge_Abad (Inceptions, con Lucho Salazar)