Caso de Estudio Ágil (4/5): Release Planning

By Jose Barato

May 18, 2021

17 minutes read

Cuarta entrega de la traducción capítulo capítulo 23 del libro Agile Estimating and Planning, de Mike Cohn. En el post anterior, el equipo del proyecto Havannah estaba manteniendo una reunión con una agenda de tres puntos:

Planificar la primera iteración.
Revisar los resultados de la investigación de mercado.
Hacer una estimación preliminar del plan de entregas y el calendario.

El primer punto de la agenda concluyó con el compromiso firme del equipo sobre 4 historias de 18 puntos. A continuación se cubrirán los puntos 2º y 3º, para lo cual es necesario priorizar las 29 historias restantes. Una forma de hacerlo es usar el modelo del profesor Noriaki Kano:

El modelo de Kano sirve para determinar si las características de un producto son obligatorias (insatisfacción si no están), lineales (cuantas más hay, mayor satisfacción producen) o emocionantes (satisfacción si están, pero no hay insatisfacción si no están). El proceso habitual para llegar a estas conclusiones es plantear una encuesta a los usuarios con preguntas funcionales (cómo se sentirían si la característica estuviera presente) y disfuncionales (cómo se sentirían si la característica NO estuviera presente). Una vez se reciben las respuestas, la siguiente tabla permite clasificarlas en 6 categorías: obligatoria, lineal, emocionante, contrario, cuestionable, indiferente.

A continuación se describe cómo transcurre la segunda parte de la reunión. El resultado de la reunión es que el proyecto durará 7 iteraciones (14 semanas). ¿Por qué? Porque a una velocidad de 18 puntos por iteración, en 7 iteraciones daría tiempo a asumir los 132 puntos previstos en la release. ¿Por qué 132 y no los 146 puntos de todas las historias? Porque el Product Owner no quiere que se dedique esfuerzo a las que resultan indiferentes para el público objetivo (6 puntos) y cree que puede ahorrarse una funcionalidad emocionante de 8 puntos. El equipo ya tiene una estimación para la duración del proyecto, pero el coach insiste en que esta estimación no debería publicarse, sino que es mejor decir que el proyecto durará entre 12 y 20 semanas. ¿Por qué?

Planificando la Entrega (Release Planning)

Cuando todos volvieron y se sentaron, Francisco reanudó la reunión. –Diana, cuéntanos los resultados de tu investigación de mercado.

–Lo que he hecho –dijo Diana– ha sido enviar unas 500 solicitudes por email para responder una encuesta por internet. También he entrevistado por teléfono a unos 35 potenciales compradores. En total, tenemos respuestas de 75 prospectos. El objetivo de la encuesta era descubrir qué funcionalidades son obligatorias, emocionantes y lineales. Las obligatorias deben incluirse. Las emocionantes, o inesperadas, no hay que incluirlas todas, pero incluir unas pocas permitirá hacer el juego más atractivo y cobrarlo un poco más caro. Las lineales son aquellas que cuantas más incluyamos, más clientes tendremos. Algunos ejemplos de funcionalidades lineales son los caballos de un coche, los canales de la televisión por satélite, y el número de niveles de dificultad del juego. No voy a explicar los detalles de la investigación (hay buena literatura como el capítulo 11 del libro de Mike Cohn, titulado Priorizing Desirability). Aquí he resumido los resultados:

–Diana, aquí hay muy pocas filas, nosotros tenemos más historias –dijo Paula–. ¿Cómo es eso? –Cuanto mayor es el cuestionario, menor el número de respuestas –dijo Diana–. He agrupado las historias según mi criterio. Por ejemplo, el tema “estética agradable” en la tabla cubre las tres historias relativas a estética, pantalla de relieve y piezas y tablero de metal o madera. Por otro lado, si agrupamos demasiadas historias en una pregunta, las respuestas pueden perder su utilidad. –Veo que las tres primeras columnas son los tipos de funcionalidades que acabas de comentar, Diana. ¿Qué significa “indiferente”, “contrario” y “cuestionable”? –preguntó Rosa. –Buena pregunta. “Indiferente” significa que el encuestado no tiene una preferencia clara –contestó Diana–. Según se han planteado las preguntas, podemos distinguir las respuestas poco meditadas. Esto pasa por ejemplo cuando alguien dice que no le gusta la música de fondo, pero tampoco le gusta que no haya música de fondo. A veces la gente malinterpreta las preguntas o se confunden cuando van muy rápido. Por lo que respecta a las categorías “contrario” y “cuestionable” no son muy significativas en este caso, hay muy pocas. –Diana, ¿entiendo bien? –preguntó Rosa–. Dice que “oponente débil” y “oponente medio” son obligatorios. Sin embargo, “oponente fuerte” es a la vez obligatorio e indiferente. ¿No hay que escoger el mayor número? –Sí, oponente débil y medio son obligatorios. La razón por la que tenemos dos picos en oponente fuerte es porque seguramente hay dos audiencias (los que ya juegan bien al Havannah y los que no). Los que ya juegan bien consideran que un oponente fuerte es algo básico para animarse a comprarlo. Los novatos nos están diciendo que tienen suficiente con un oponente medio. –Lo que a mí me sorprende, Diana, es que no hay muchas funcionalidades en esta lista que la audiencia considera “emocionante” –dijo Francisco, más preguntando que afirmando.

–Cierto, pero solo porque haya pocas funcionalidades emocionantes eso no significa que el producto mismo sea emocionante –contestó la analista–. Recuerda que las funcionalidades “emocionantes” son inesperadas. Si me compro un Porsche, probablemente habrá pocas cosas verdaderamente inesperadas, pero el coche en sí sería muy emocionante. Sin embargo, estoy de acuerdo con lo que creo que estás pensando. Cada producto debería tener al menos una o dos funcionalidades “emocionantes” (cosas que hagan que el usuario diga “¡Guau!”). La encuesta nos dice que no hemos encontrado suficientes todavía. Por eso es por lo que pedía más tiempo durante la iteración para profundizar más en la investigación. Quiero tener unas cuantas discusiones abiertas con algunos participantes de la encuesta. Espero que esto nos permita encontrar una o dos funcionalidades “emocionantes”. –Estupendo, Diana. Muy ilustrativo –dijo Francisco–. ¿Alguien tiene más preguntas para Diana? –Francisco esperó un momento antes de continuar–. En caso contrario, hablemos que lo que hay que incluir en la primera entrega de Havannah. Nadie tenía más preguntas. Inmediatamente se pusieron a planificar la entrega priorizando las funcionalidades. –Aquí están las historias que yo considero obligatorias y que ni siquiera se me ha ocurrido plantear en el cuestionario –dijo Diana, mientras ordenaba estas tarjetas en la mesa de la sala. Entre todas sumaban 32 story points:

–Ninguna de estas historias debería sorprender –continuó Diana– hacemos todo esto en todos nuestros juegos. Es el coste de entrada. –En esta otra parte de la mesa voy a ordenar las historias que los usuarios nos han dicho que consideran obligatorias –Diana ordenó otro grupo de tarjetas. Entre todas sumaban 56 puntos:

–Diana, ¿por qué incluyes el motor fuerte? –preguntó Alberto–. ¡Yo encantado! pero según acabamos de hablar, es a la vez obligatorio e indiferente para algunos usuarios. –Buena observación, Alberto –dijo Diana–. Mi recomendación es considerarlo obligatorio porque pienso que muchos usuarios van a superar lo que pensamos como motor medio. Esos usuarios se van a aburrir con el juego si no incluimos el motor fuerte. –De acuerdo. Francisco estaba disfrutando. En el pasado, el equipo le había dejado la definición del producto a él (como responsable de productos) y a Diana (como analista). Le gustaba que estaban participando activamente en estos debates, lo cual solo podía beneficiar al nuevo producto. –La otra historia que he incluido como obligatoria es Como jugador, me gustaría ser capaz de jugar contra otra persona desde mi ordenador. La he incluido como obligatoria porque hemos dicho que sería un buen hito para el proyecto. –Las del siguiente grupo –dijo Diana mientras colocaba otro conjunto de tarjetas– tienen una valoración lineal. Esto es, cuantas más de estas, mejor, pero ninguna es obligatoria. Entre todas sumaban 32 puntos:

–El buen diseño gráfico no es opcional –dijo Rosa– Necesitamos la pantalla de relieve y tableros y fondos atractivos. –Yo no he dicho que sean opcionales, Rosa –dijo Diana–. Tienes razón, los necesitamos. Hay una cierta línea por debajo de la cual no podemos caer, y el juego necesita ser estéticamente agradable, que es como lo he preguntado en la encuesta. Son funcionalidades lineales, porque cuantas más, mejor. Dos tableros para elegir son mejores que uno, pero tres sería incluso mejor. –De acuerdo, tiene sentido –dijo Francisco–. Veo que has colocado otro grupo de tarjetas, ¿qué tipo de historias son estas? –Son las funcionalidades “emocionantes”. Los compradores potenciales no las esperan, pero deberíamos incluir un par porque disparan la satisfacción. Y como dije antes, incluir algunas “emocionantes” significa que podemos cobrar más caro el juego, también–. Diana colocó estas 4 tarjetas, que sumaban un total de 20 puntos:

–Después de los “emocionantes” –continuó Diana– las otras dos historias eran las que los encuestados dijeron que le resultaban indiferentes. Creo que no debemos añadirlas. No creo que vendamos más juegos o a mayor precio por añadir funcionalidades que les resultan indiferentes a los compradores. Diana colocó estas dos tarjetas:

–¡Esto es estupendo! –dijo Francisco–. Es mucho más de lo que solemos tener a estas alturas. Buen trabajo, Diana. ¿Has conseguido toda esta información a partir de las encuestas? –Sí. El cuestionario es intencionalmente ligero y solo pregunta a los usuarios cómo se sentirían si la funcionalidad estuviera presente o ausente. Al agrupar las historias por temas, el cuestionario tiene solo 24 preguntas. Incluyendo la explicación inicial, por teléfono solo tardaba unos 15 minutos. El tiempo medio cuando lo rellenaban por web es de 7 minutos. Una persona tardó 40, pero sería debido a alguna interrupción. –Entonces, Francisco, ¿cuáles son nuestras prioridades? –preguntó Santiago.

–Bien, lo primero es hacer todas las obligatorias (las que identificó Diana y las que identificaron los encuestados). –Eso son 88 story points, según nuestra estimación –dijo Santiago. –Por lo que respecta a las que Diana considera lineales, estoy de acuerdo con Rosa: necesitamos un buen diseño gráfico –dijo Francisco– Esas historias también deberían entrar. Y tampoco me imagino salir sin música de fondo. Quizá sin que el usuario pueda cambiar de canción, pero es solo un punto. Así que por ahora, digo que lo quiero. Y necesitamos ayuda online. No todos los que compran el juego saben jugar. –Así que quieres todas las lineales. Esto supone 32 puntos más –dijo Santiago. –Ya lo sé. Lo quiero todo, ¿verdad? Como cualquier responsable de productos.

–A mí me parece bien. Solo te recuerdo que quieres el producto fuera en 4 meses. Por ahora tenemos 120 puntos. –¿Va a llevar esto más de 4 meses? –preguntó Francisco, un poco preocupado. –Todavía no sé. Primero veamos qué es lo que quieres, y después veremos cuánto esfuerzo supone –dijo Santiago. –De acuerdo –dijo Francisco–. En cuanto a los “emocionantes”, creo que necesitamos las pistas, y me gustaría el tutorial. Quizá podamos prescindir del tutorial o de la ayuda online, pero por ahora quiero planificar ambos. También me gusta la idea de decirle al usuario cuándo ha hecho un mal movimiento justo después de que lo haga. –Recuerda que son 8 puntos –dijo Alberto–.Voy a programar el motor de movimientos para encontrar buenos movimientos. Puedo mejorarlo para encontrar malos movimientos, pero no es trivial. –Es lo que estoy viendo. Planifiquemos sin eso por ahora, pero incluyamos la historia sobre advertirle de que está a punto de perder. –Eso son 12 puntos de la lista de “emocionantes”. ¿Quieres algo de la lista de “indiferentes”? –preguntó Santiago. –Pues no –dijo Francisco–. ¿Cuál es el total ahora? –Tenemos 88 puntos de la lista de obligatorios, 32 de la lista de lineales, y 12 de la de los emocionantes. Hace un total de 132 –dijo Santiago. –¿Y lo vais a hacer en 2 iteraciones? –preguntó Francisco, con una sonrisa. –Si podemos, lo haremos. –En serio, ¿cómo podemos saber cuánto tardaremos? –Lo mejor sería esperar 3 iteraciones y contestarte después –explicó Carlos–. Después de cada iteración, podemos sumar los puntos de las historias que hemos finalizado. A eso lo llamamos velocidad. Nuestra velocidad cambiará de iteración a iteración, pero en media debería mantenerse relativamente estable con el tiempo.

–Sí –añadió Alberto–. Nuestras estimaciones pueden estar mal, o podemos tener buena o mala suerte con una historia… –Después de 3 iteraciones, deberíamos poder tener una buena medida de lo rápido que el equipo progresa. Podemos dividir el trabajo total pendiente por esta velocidad, y el resultado nos dirá el número de iteraciones pendientes –dijo Carlos. –¿Y esa estimación será buena? –preguntó Francisco. –Debería. Después de 3 iteraciones, se tiene una idea precisa de cuántos puntos pueden hacerse en una iteración de 2 semanas –dijo Carlos. –Tengamos en mente que voy a hablar con algunos compradores potenciales para descubrir más “emocionantes” –dijo Diana–. Como he dicho antes, nuestros “emocionantes” parecen un poco “flojos”. Deberíamos añadir algunas funcionalidades más. –¿Hay alguna manera planificar el cronograma ahora? –Por supuesto, Francisco –dijo Carlos–. Habéis planificado hacer 4 historias en esta primera iteración. Podemos sumar los story points y a eso llamarlo nuestra velocidad esperada. No sabemos si será esa, pero es nuestra estimación inicial. –Ya lo he hecho –dijo Paula–. Suman 18:

–¿Cuántas iteraciones durará el proyecto si nuestra velocidad es 18? –Unas 7. Tenemos 132 puntos. Serían 126 puntos (7×18=126) más 6 puntos a repartir durante las 7 iteraciones –dijo Paula. –¿Podemos decir 7 iteraciones? –preguntó Francisco. –Podemos, pero no debemos –replicó Carlos–. Preferiría dar la estimación en forma de rango. Si tenemos suficiente trabajo como para ir a una octava iteración, deberíamos decir que el proyecto durará entre 6 y 10 iteraciones. –No me gustaría que el proyecto durase 20 semanas, pero también dices que podría terminar en 12 ¿verdad? –preguntó Francisco. –Podría. Pero también podría durar 20 –respondió Carlos firmemente. Puedes ayudar a que no dure 20 semanas eliminando funcionalidades de baja prioridad si la velocidad nos demuestra que vamos camino de 10 iteraciones. Tened en cuenta también que Diana está buscando proactivamente más funcionalidades. Si viene con algo más, tendremos que extender el plazo o quitar un número equivalente de funcionalidades. –De acuerdo. Puedo justificar entre 12-20 semanas a los demás ejecutivos –dijo Francisco. Digamos que ese es nuestro plan inicial.

–Francisco, debo reiterar que lo mejor que se puede hacer es esperar al menos 2 semanas, dejemos que el equipo haga una iteración, y entonces basemos nuestra estimación inicial en una observación de la velocidad real –dijo Carlos. –Entendido. Pero todo el mundo quiere tener al menos una idea de cuál será el plazo de este proyecto. –Hazles saber que podrán tener mejor información cada 2 semanas. Especialmente sabremos mucho más después de las primeras 3 iteraciones –añadió Paula. –¿Así que tenemos que planificar en qué trabajaremos en cada iteración? –preguntó Francisco. –Realmente, no –respondió Carlos–. Lo más importante es saber en qué vamos a trabajar durante la siguiente iteración. Eso hicimos cuando planificamos la primera iteración. Lo siguiente más importante es saber aquellas funcionalidades de menos prioridad que quizá entren en la entrega o quizá no. –Entiendo por qué quieres saber las prioridades más importantes, ¿pero por qué las menos importantes? –dijo Francisco. –No es muy importante para esta primera reunión, pero cuando nos acerquemos al final de la entrega, a veces es importante. Por ejemplo, no querríamos que la publicidad dijese “Ahora con música de fondo” si esa es una funcionalidad que podría suprimirse en el último minuto.

–De acuerdo, pero, ¿por qué no dedicar algún tiempo hoy planificando qué haremos en cada iteración? –No tiene sentido –dijo Carlos–. Dentro de 2 semanas, sabremos mucho más que ahora. ¿Por qué planificar lo que haremos en una iteración hasta que no tengamos que hacerlo? En un proyecto más largo, particularmente con múltiples equipos que necesitan coordinar el trabajo, podríamos prever 2-3 iteraciones delante. Pero no lo necesitamos en este proyecto.

–¿Entonces hemos terminado con la planificación de la entrega? –preguntó Francisco. –Sí. Voy a recoger las tarjetas que has dicho que quieres en la entrega, y ese es nuestro plan –dijo Carlos–. Antes de que nos reunamos de nuevo, dentro de 2 semanas, Diana y tú deberíais hablar sobre las historias e identificar las más prioritarias para la siguiente iteración. En la reunión, hablaremos de por qué queréis estas historias. Los demás podrán pedir que incluyáis una o dos que quieran hacer porque suponen riesgo o porque aprenderán mucho haciéndolas. Pero la última decisión sobre la priorización la tendréis vosotros. –No te lo tomes a mal –dijo Francisco– pero ¡me he quedado a medias! –Así es –dijo Carlos– pero seleccionar lo correcto que hay que hacer a continuación es un trabajo de todo el equipo. Si los programadores hubieran elegido un conjunto de funcionalidades técnicas no visibles, yo les habría parado y les habría puesto a trabajar en otras historias. Creo que deberías estar contento con las historias se han elegido. –¡Entusiasmado! Será genial ver todo esto dentro de 2 semanas.

# Etiqueta # Gestión de proyectos sin procesos # Herramienta de gestión de proyectos digitales # Herramienta de gestión profesional de proyectos # Software de gestión de portafolios de proyectos # Software de gestión de proyectos de construcción # Software de gestión de proyectos farmacéuticos # Software de gestión de proyectos SaaS

Caso de Estudio Ágil (4/5): Release Planning

Planificando la Entrega (Release Planning)

Publicaciones relacionadas Comentarios