Buscar en Gazafatonario IT

jueves, septiembre 10, 2020

Planificar historias de usuario en tareas


El trabajo a realizar durante el Sprint se planifica en la Planificación de Sprint. Este plan se crea mediante el trabajo colaborativo del Equipo Scrum completo.

En particular, en esta presentación  muestro algunos ejemplos de cómo descomponer historias de usuario de un backlog de producto en tareas de un backlog de sprint. También explico algunas prácticas y guías a tener en cuenta a la hora de la planificación.

Estas y otras ideas, en la presentación que puedes ver y descargar aquí.



domingo, agosto 23, 2020

El extraño caso de las historias de usuario técnicas

 

Photo by fauxels from Pexels

Nota: la versión en inglés de este artículo en:

https://luchosalazar.com/2020/08/25/the-strange-case-of-technical-user-stories/

Advertencia

La atención continua a la excelencia técnica y al buen diseño mejora la agilidad”.

[Manifiesto por el desarrollo ágil de software]

Cuando Kent Beck llegó con la idea de las historias de usuario como parte del juego de planificación de eXtreme Programming (XP Planning Game), no imaginó el impacto que esa idea tendría en el desarrollo de software y, por extrapolación, en el desarrollo de productos, varios años después; fue como un “efecto mariposa”. De hecho, al principio solo las describió como algo con lo que los clientes definen el alcance del proyecto "con historias de usuarios, que son como casos de uso". Pueden encontrar más sobre esto en “La historia de las historias de usuario”.

Pero una de las prácticas que ha perdurado hasta nuestros días es esta de querer expresar todo como una historia de usuario. En la práctica, esto es posible. Ya que las historias de usuario se pueden representar de infinitas formas. En el libro Historias de usuario: una visión pragmática, que escribimos con Jorge Abad, quien también  me compartió algunas de sus ideas para este artículo, hablamos precisamente de algunos de los modos de representación de las historias de usuario, incluyendo el User Stories Conversation Canvas, un lienzo para mantener y registrar conversaciones sobre estos elementos del backlog de producto.

Sin embargo, hay algunas cosas que definitivamente no son historias de usuario. El “apellido”, ese “de usuario” está allí por una razón muy importante que ni siquiera el mismo Kent Beck imaginó al comienzo. Él hablaba de “stories”, simplemente historias: estas se ven, se perciben, se entienden, se describen desde el punto de vista de quien las va a usar una vez estén implementadas o de quienes las van a consumir una vez hagan parte de los productos o servicios que se desarrollen usando esta técnica.

Las cosas así, cuando se trata de software, las llamadas historias técnicas no son una buena idea. ¿Quién es el usuario de “quiero integrar la IA de Google para hacer la traducción del texto”? ¿O de “quiero optimizar la base de datos para acelerar las consultas”? Pero sí es posible saber quién es el usuario de “quiero traducir un texto para entenderlo mejor” y de “quiero consultar la información del cliente” con la condición de que el resultado de la consulta se presente en menos de dos segundos.

Es un hecho, representar algo en forma de historia de usuario cuando no se trata de usuarios-personas del sistema es un error. Hay mejores formas de documentar o registrar este otro tipo de actividades “internas” de un sistema. Una de ellas es precisamente poniéndolas en su lugar como tareas que el equipo debe realizar para lograr finalmente algo de valor para el usuario-persona a través de una o varias historias de usuario. Pensemos en historias de usuario como “historias de persona”. Quizás esto nos ayude a entender la diferencia.

Una de las formas de saber si algo es una “historia de usuario-persona” o no, es cuando al mantener conversaciones con los representantes del negocio, por ejemplo un Dueño de Producto, estas conversaciones fluyen naturalmente y la fuente de información casi siempre es ese representante del negocio. Pero si este empieza a preguntar por términos o expresiones técnicas que emergen en el diálogo y el equipo de desarrollo tiene que dar explicaciones intrincadas que no son del dominio de aquel, entonces quizás hemos traspasado el plano del valor o beneficio de la historia para los usuarios a uno del dominio del equipo técnico.

Photo by fauxels from Pexels

Tenemos que hacer un left outer join seguido de una eliminación de duplicados” es algo con lo que perdemos a los usuarios. “Diariamente hacemos refactoring del código y luego lo integramos con el del resto del equipo usando Bamboo o Jenkins”, mientras “automatizamos los escenarios de prueba usando behaviour-driven development” y “consumimos el web service de [INSERTA AQUÍ TU PROVEEDOR DE WS FAVORITO] para conocer el valor del dólar minuto a minuto”, son conversaciones clásicas que dejarán en ascuas a un Dueño de Producto o a cualquier otra persona de las áreas del negocio.

Y no, no es porque usamos los términos en inglés. Aun en español van a sonar muy extraños a los usuarios. Más, cuando muchas de esas expresiones no tienen un equivalente apropiado en nuestro idioma o, en la vida cotidiana, significan algo totalmente distinto para el común de las personas:

¿Una “combinación externa por la izquierda”? – ¿A qué estará jugando?

¿“Desarrollo conducido por comportamiento”? – ¿Estará hablando de que su comportamiento en la empresa lo tiene a prueba?

¿Y mi consulta de los datos del cliente?”, preguntan con los ojos bien abiertos y con esa expresión de desánimo que solo significa que no están recibiendo lo que quieren y que incluso los lleva a pensar que los miembros del equipo no han entendido del todo lo que los usuarios necesitan. Por lo general, es una combinación de ambos. El asunto se pone más grave si alguien del equipo intenta explicar con mayor detalle lo que significa todo ese galimatías* técnico o trata de justificar con ello los tiempos estimados de desarrollo. A estas alturas es a todas luces evidente que se requiere la presencia de un facilitador, coach, Scrum Master o similar, para abortar la conversación y llevarla por otro camino.

Finalmente, no entendamos las historias de usuario-persona o las historias de persona como aquellas que solo abordan el “front-end” o la experiencia del usuario, de la persona. No. Toda historia de usuario tiene componentes “verticales” que van desde la forma cómo se comunica una persona con el sistema, hasta cómo se almacena y se procesan los datos que intercambia esa persona con el sistema o el entorno: base de datos, servicios, lógica del negocio, presentación, etcétera.

Más sobre cómo conducir conversaciones con historias de usuario en nuestra serie de historias de usuario altamente efectivas:

http://www.gazafatonarioit.com/p/la-serie-historias-de-usuario-efectivas.html

Y todavía mucho más en el libro Historias de usuario: una visión pragmática.

Llamado a la acción

Separemos explícitamente las historias de usuario, las de valor para el negocio, usuarios o clientes, de las tareas del equipo y de los componentes “internos” del sistema (producto) con los que se logra obtener ese valor o beneficio. Como agentes de cambio, asegurémonos de que los miembros del equipo desarrollen habilidades y destrezas en el dominio del negocio, ayudándolos a ellos y a los Dueños de Producto e interesados a mejorar las interacciones entre unos y otros mediante la conversación continua, ojalá cara a cara (¡en 2020 encendamos la cámara!) y a que no todo tiene que ser una historia de usuario, al menos no representadas de la misma manera.

Conclusión

Si en la conversación sobre una historia de usuario es el Dueño de Producto quien termina interrogando al equipo para aclaraciones y no al contrario, quizás el diálogo no sea realmente sobre la historia de usuario.

Epílogo

*Usé intencionalmente la expresión “galimatías”, quizás poco conocida, pero que tiene un lugar en mi Gazafatonario, para dejar la sensación en el ambiente de lo que percibe o siente un usuario final cuando lo confundimos con tecnicismos propios del desarrollo de software.

galimatías

Del fr. galimatias 'discurso o escrito embrollado', y este del gr. κατὰ Ματθαῖον katà Matthaîon 'según Mateo', por la manera en que este evangelista describe la genealogía que figura al comienzo de su evangelio.

1. m. coloq. Lenguaje oscuro por la impropiedad de la frase o por la confusión de las ideas.

2. m. coloq. Confusión, desorden, lío.

Real Academia Española © Todos los derechos reservados

viernes, julio 31, 2020

El Planning Poker me arruinó por completo

Si llegaste hasta aquí pensando que voy a estigmatizar esta práctica de estimación ágil, aún estás a tiempo de hacer clic en algún otro lugar de tu navegador. Quizás aquí, mi artículo sobre “Estimaciones en los tiempos de la agilidad”, en cuya sección final decía que si sigues estimando como hace algún tiempo seguramente no estás en el camino ágil o te alejaste de este, es más, quizás ni estés haciendo estimaciones propiamente dichas. A lo que seguí con una serie de recomendaciones que terminaban con una enfática pero respetuosa propuesta de simplemente no estimes del todo, enfócate en entregar Valor, en reducir el Time to Market, en eliminar desperdicios y en mejorar continuamente.

Se trata precisamente de evolucionar, de seguir experimentando y aprendiendo de los resultados de nuestros experimentos. Ya dimos el primer paso y fue dejar de usar técnicas tradicionales que requerían de tener mucha información y de hacer mucho trabajo que, a la postre, se convertía en desperdicio para la organización o que, en general, no era de valor para nadie. El nivel de predictibilidad era muy bajo, tuve la oportunidad de comprobarlo una y otra vez hasta la desesperación durante dos décadas. Luego empezamos a usar técnicas de estimación relativa y juegos como Planning Poker nos enseñaron a hacer mejores predicciones acerca del trabajo sin generar tanto desperdicio de tiempo.

A veces es posible hacer algo sin hacerlo. Una de las formas de estimar es no estimar. Sé que para llegar a eso el camino es cuesta arriba, pero eso muchas veces es bueno, porque cuando lo logras, ves que valió la pena porque la vista es fantástica.*

Así que avancemos un poco por ese camino…

Enfócate en generar Valor, no estimes

Imagen de Nattanan Kanchanaprat en Pixabay

Motiva al Dueño de Producto o a quien sea tu “cliente” a Ordenar por Valor todo lo que quiere. Acompáñalo en el proceso. Haz que se enamore profundamente de esta forma de pensar y de hacer basada en el valor, pero sin que llegue a odiar las formas anteriores. Hay muchas técnicas para ordenar el backlog:

  • En función de lo que quieran tus clientes o consumidores
  • Lo que los interesados internos quieren
  • Lo que creas que impactará más
  • La antiquísima MoSCoW
  • Por Costo-Beneficio
  • RoI (Retorno de la Inversión)
  • VIP (el método del servicio preferencial)
  • El costo de la demora
  • Puedes elaborar una matriz Valor – Complejidad  

Puedes usar una combinación de estos, por ejemplo, entre dos elementos Requeridos (MoSCoW), implementa primero el que menor costo de implementación tenga y mayor beneficio te genere (Costo-Beneficio) o el que mayor retorno de la inversión te genere (RoI); entre dos elementos que te generen el mismo RoI, construye primero el de mayor costo de la demora (CoD) o el que te haya solicitado la persona más importante para tu organización de entre tus interesados. Aunque, ojo, esta persona no siempre es la de mayor rango jerárquico.

Hazlo gradualmente, de manera orgánica. Experimenta.

Imagen tomada de https://pixabay.com/images/id-512503/

Pasa de puntos de historias a tallas de camiseta. Pero no hagas un equivalente entre una talla y un número de puntos. Sería como tratar de saltar en paracaídas con una soga atada al avión, ¡no lo vas a lograr! Si lo que quieres es “medir” la velocidad del equipo, entonces cambia la escala también: ya no serán 30 o 47 puntos, sino seis elementos Talla M u ocho talla S, por ejemplo. Más adelante, busca una forma cada vez menos cuantitativa y más cualitativa de realizar la estimación, que tienda o evolucione siempre hacia el valor del incremento de producto a entregar y se aleje de una vez por todas y para siempre del esfuerzo necesario para hacer el trabajo o de la complejidad inherente a cada elemento del producto.

Evidentemente necesitarás kilometraje ágil. Tú, tu equipo y muy probablemente tu organización ya habrán llegado, al menos, a la cima de la curva de la innovación, en este caso, de cambio de forma de pensar y de hacer las cosas “a lo ágil”. Es decir, una gran mayoría temprana y un sector de la mayoría tardía, ya han entendido de qué se trata, ya han interiorizado, practican y promueven el pensamiento ágil, los valores y principios del Manifiesto Ágil, los pilares de Colabora, Entrega, Reflexiona y Mejora del Corazón de la Agilidad; y ya hay un sistema de valores de poca o ninguna variabilidad y consistente con las prácticas empresariales como base que guía el accionar de todos o de casi todos en la empresa y en su entorno.

Algunos patrones Scrum para estimar

Imagen de Achim Scholty en Pixabay

Usa patrones Scrum como el Gradiente de granularidad. (II)

Hemos experimentado y sabemos que los elementos pequeños son más fáciles de estimar, pero desglosar los elementos de trabajo es mucho trabajo en sí mismo. Las estimaciones de trabajo para pequeños incrementos de producto y tareas tienen menos errores que para los más grandes por tres razones:

·    La magnitud del trabajo (y, por lo tanto, del posible error) es menor que para un incremento o tarea más grande.

·    El equipo puede comprender mejor las entregas y tareas más pequeñas que las más grandes.

·    El porcentaje de error en las entregas y tareas más pequeñas es menor que en las grandes porque hay menos elementos de adivinanzas (y el tamaño máximo de cualquier error se mitiga implícitamente).

Por lo tanto:

Divide los primeros PBI en elementos pequeños de medio Sprint o menos de trabajo para una persona (aproximadamente el 10 % del trabajo total del Sprint) cada uno. El equipo debe desglosar los PBI posteriores para que su tamaño sea proporcional a su profundidad en el backlog Producto.

Otro patrón es el del Trabajo fijo. (III)

Scrum divide el tiempo en dos. Hay un cronograma continuo para el análisis y el negocio, y un cronograma cíclico de Sprint para la producción. El tiempo para el análisis y la innovación es imposible de estimar y puede desarrollarse durante largos intervalos, porque surge de manera impredecible en un proceso que Steve Johnson llama "la corazonada lenta" en su libro “Where Good Ideas Come From: The Natural History of Innovation”, Capítulo III, “The Slow Hunch”.

Todo el trabajo debe tenerse en cuenta si el Dueño del producto va a utilizar la velocidad del equipo para la planificación del lanzamiento del producto, pero no todo el trabajo de desarrollo puede tener un límite de tiempo.

Así que:

Divide todo el trabajo del Equipo de Desarrollo en aquel cuya duración estiman (es decir, trabajan en el producto) y lo que no pueden estimar (como el trabajo para entender los requisitos a medida que el equipo mueve los PBI a Preparado). En cada Sprint, reserva tiempos periódicos para el trabajo no estimable, fuera del presupuesto del Sprint, y completa la mayor parte de cada tipo de trabajo que permita el bloque de tiempo.

O este otro patrón del Alto valor primero.(IV)

Que hace alarde del antiguo y conocido refrán “más vale pájaro en mano que un ciento volando”, y hoy por hoy los desarrollos a corto plazo deberían ofrecer valor lo antes posible.

Las cosas así:

Haz que tu equipo desarrolle primero los elementos del Producto de alto valor más esenciales.

Imagen basada en “A Scrum book”. James Coplien, Jeff Sutherland & The Scrum Pattern Group.

También usa patrones como El Clima de Ayer, Equipos que terminan más temprano aceleran más rápido e Illegitimus Non Interruptus no solo para hacer mejores predicciones de lo que planeas entregar sino también para llevar a tu equipo a niveles de desempeño grandiosos y entregar más valor en menos tiempo, quizás el doble del valor en la mitad del tiempo. Para saber más de estos y otros patrones puedes ir a:

https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/

https://luchosalazar.com/2020/06/17/patrones-scrum-un-enfoque-adaptativo-parte-2/

Donde encontrarás sendas presentaciones para descargar y videos para ver sobre el tema.

Para finalizar

Como siempre, permite que las personas comprometidas con el trabajo decidan qué hacer respecto a la estimación. Guíalos. Muéstrales beneficios de uno u otro enfoque, de una u otra práctica. Y también perjuicios. Contrasta con el camino ágil recorrido. No es lo mismo un equipo u organización que apenas están saliendo de los enfoques tradicionales a uno que ya lleva ciertos kilómetros transitados.

Si este último es tu escenario, la próxima vez que quieras estimar algo, estima el valor de lo que vas a entregar, no el esfuerzo que te lleva realizarlo o la complejidad de lo que vas a hacer.

Y aunque no hablé de #NoEstimates, este es un movimiento, una filosofía, una visión de pensar acerca de cómo hacer algo, no es una técnica o metodología. Bueno, quizás estas ideas y propuestas constituyan un aporte a esa tendencia.

Referencias

* Basado en una frase de la película Hannah Montana (2009) que viera con mi hija Pamela, de 12 años entonces: “la vida es cuesta arriba, pero la vista es genial”.

(II) ¶59 Granularity Gradient. A Scrum book. James Coplien, Jeff Sutherland & The Scrum Pattern Group.

(III) ¶23 Fixed Work. A Scrum book. James Coplien, Jeff Sutherland & The Scrum Pattern Group.

(IV) ¶51 High Value First. A Scrum book. James Coplien, Jeff Sutherland & The Scrum Pattern Group.

Imagen de la portada basada en:

  • Imagen de Natalia Ovcharenko en Pixabay
  • Imagen de Mike Cohn en www.mountaingoatsoftware.com
  • Imagen de Agile Poker Estimation Planning Cards by Clearly Agile, Inc.

miércoles, julio 15, 2020

Cómo los dueños de producto pueden gestionar mejor las historias de usuario



Los Dueños de Producto virtuosos:

  • Expresan claramente las historias de usuario
  • Ordenan las historias de usuario para alcanzar los objetivos y misiones de la mejor manera posible
  • Aseguran que las historias de usuario sean visibles, transparentes y claras para todos
  • Los Dueños de Producto virtuosos (que Crecen) se aseguran de que los miembros del Equipo de Desarrollo entiendan las historias de usuario al nivel necesario.
  • Se aseguran de tener una visión clara del producto que quieren
  • Consiguen información de los interesados, usuarios, consumidores, del entorno, del mercado, de la competencia
  • Saben más que cualquier persona a su alrededor, pero menos que todas ellas juntas

Estas y otras ideas, en la presentación que puedes ver aquí.



Un video resumen de la presentacuión puedes ver aquí.