Los Hábitos de un Director de Proyectos Eficaz: Las historias del proyecto Havannah

Continúa la traducción capítulo capítulo 23 del libro Agile Estimating and Planning, de Mike Cohn. En este segundo post (véase nota*) veremos la conveniencia de escribir tarjetas físicas y cómo puede organizarse una reunión de brainstorming para hacer que los miembros del equipo vayan deduciendo los requisitos (en forma de user stories). Es recomendable estructurar el brainstorming por temáticas para no dejar ninguna funcionalidad sin analizar.

Casi al mismo tiempo, los miembros del equipo pueden estimar el tamaño o complejidad de los requisitos mediante un juego conocido como planning poker, en el que se estima el tamaño y complejidad de cada historia en unidades llamadas story points.

Estas dos actividades (recopilar requisitos y estimar sus tamaños) son interdependientes porque, a veces, una historia de usuario muy grande hay que descomponerla en varias más manejables.

Una regla básica que hay que recordar es que las historias de usuario deben ser independientes, negociables, valorables, estimables, pequeñas y verificables (Independent, Negotiable, Valuable, Estimatable, Small, Testable -INVEST-).

A continuación se describe cómo transcurre la reunión inicial de análisis de requisitos en un proyecto ágil. Al finalizar la reunión (que puede durar entre 2 y 4 horas), los miembros del equipo del proyecto Havannah habrán consensuado los requisitos con 32 historias de usuario, y también habrá consensuado la estimación del proyecto en 146 story points.

¿Quiere saber cómo se hace?

(*) Siguiendo mi recomendación en un post anterior, he anotado estas historias en un tablero virtual de Evernote, que pueden acceder fácilmente a través de Evernote por web o desde su propio Evernote desktop, usando como usuario y contraseña la palabra “pmpeople”.

[…]

–Y bien… ¿cómo empezamos a escribir historias de usuario? –preguntó Francisco.
–Vamos a usar estas tarjetas –dijo Carlos, a la vez que le daba un paquete de tarjetas a cada persona–. A mí me gusta escribir historias de usuario con esta plantilla. –Carlos sacó un rotulador y escribió en la pizarra:

“Como [rol], quiero que [objetivo] para que [motivo]”

–Diana, ya que has pensado en Havannah más que el resto, ¿puedes empezar tú?
–Por supuesto –dijo la analista–. Comencemos con: “Como jugador, puedo deshacer un movimiento para corregir un error”.
–¿Es nuestra primera historia de usuario? –preguntó Paula, la responsable de pruebas.
–Así es. La voy a escribir en una tarjeta para que no la olvidemos –dijo Diana mientras escribía la primera historia de usuario de Bomb Shelter Studios.
–¿Hay que estimar el tamaño de esa historia ahora? –preguntó Alberto.
–Aún no, Alberto. Será más fácil si escribimos unas cuantas historias primero y luego estimamos sus tamaños al mismo tiempo –dijo Carlos.
–Me toca. Si tenemos una historia para deshacer, necesitamos otra para rehacer: “Como jugador, quiero rehacer un movimiento que he desecho antes para repetir una secuencia” –dijo Francisco.
–Buena historia, Alberto. Escríbela en una tarjeta –le dijo Carlos al responsable de productos.
–¿No sería mejor ir escribiendo en un documento electrónico? –preguntó Francisco.
–A lo mejor después. En una reunión como esta, es de gran ayuda tener tarjetas físicas –dijo Carlos.– Podemos escribir cada uno una historia cuando se nos ocurra. No necesitamos esperar que alguien la teclee.
–Y cuando tengamos que planificar, las tarjetas son incluso más útiles –añadió Santiago–. Podemos ordenar las tarjetas por prioridad o según lo que hagamos en cada iteración.

Francisco empezaba a ver las ventajas de usar tarjetas. Podía escribir notas adicionales o dibujar en las tarjetas. No podría hacer eso en su ordenador. Aún no sabía mucho sobre el nuevo “proceso ágil”, pero lo que había visto hasta ahora le gustaba. Con creciente entusiasmo, escribió su tarjeta.

–Una buena forma de escribir todas las historias es… –comenzó a decir Carlos.
–¿Quieres decir todas, Carlos? –le preguntó Santiago al nuevo coach del equipo.
–Sí, en cierto modo. Me gustaría emplear esta reunión para escribir tantas historias como podamos. Deshacer y rehacer son historias muy pequeñas. No necesitamos que nuestras historias sean tan pequeñas. De hecho, podríamos combinarlas.
–De acuerdo, lo haré –dijo Francisco y se puso a escribir una nueva tarjeta– ¿Cómo indicamos que esta tarjeta está relacionada con estas otras? ¿Las numeramos?
–No, simplemente raja las dos primeras –dijo Francisco Carlos– Ya no las necesitamos.

Francisco rajó las dos primeras tarjetas por la mitad, y escribió la nueva historia: “Como jugador, me gustaría deshacer y rehacer movimientos”.

–Carlos, Francisco no ha incluido una razón en la tarjeta. No hay un “para que…”. ¿Eso es un problema? –preguntó Alberto.
–¡Eh, que estoy aprendiendo! –se defendió Francisco.
–En realidad –clarificó Carlos– no siempre necesitamos una frase “para que…”. Si ayuda a hacer la historia más clara, debe usarse, pero no merece la pena preocuparse por eso, especialmente en una historia como esta, en la que resulta obvio por qué un usuario podría querer hacer eso.
–Carlos, has dicho que queremos escribir todas las historias hoy, aunque sea a alto nivel. Asumo que podremos añadir más luego, ¿verdad? –preguntó Rosa.
–Por supuesto. Pensaremos más historias en adelante. De lo contrario, significaría que no pensamos con la creatividad necesaria. No quiero pensar que no seremos capaces de descubrir ideas mejores a las de hoy. El propósito de escribir “todas” las historias hoy es para que seamos todos conscientes –a alto nivel– de las funcionalidades posibles. Esto ayudará sobre todo a Santiago y Alberto a pensar en la arquitectura del juego e incluso en cómo deben diseñar el motor de movimientos.
–Estupendo Carlos, suena genial. Sigamos. ¿Empezamos a escribir historias todos a la vez?
–Podríamos hacerlo –dijo Carlos– pero es mejor si aplicamos algún tipo de orden. Analicemos qué hará un usuario durante las distintas fases del juego (antes de empezar, durante la partida y después) –los miembros del equipo asintieron–. Nada más cargarse el juego, ¿qué querrá hacer cualquier usuario?
–Comenzar una partida.
–Restaurar una partida grabada previamente.
–Elegir el grado de dificultad.
–De acuerdo, pongámoslo por escrito –dijo Carlos.

Brainstorming para escribir Historias de Usuario

Unos minutos después, el equipo había escrito estas nueve historias:

–Carlos –preguntó Francisco–. Si estas historias son cosas que un jugador puede querer hacer antes de comenzar el juego, ¿por qué incluimos “Como jugador, quiero que el juego tenga música de fondo”? ¿No se trata de algo que el jugador quiere mientras está jugando, no antes de jugar?
–Simplemente estamos haciendo un brainstorming sobre historias de usuario –respondió Carlos– No vamos a monitorizar qué historias ocurren antes o después del juego. Solo uso esta distinción para que nos ayude a pensar qué necesitamos que haga el juego, de principio a fin.
–De acuerdo. ¿Qué hacemos ahora?
–Ahora pensaremos qué quiere hacer un usuario durante la partida.

El equipo respondió a la pregunta de Carlos escribiendo las siguientes historias:

–De acuerdo, supongo que ahora podríamos avanzar a las cosas que un usuario puede querer hacer después de terminar una partida –dijo Francisco.
–No hay mucho que un jugador quiera hacer después de la partida. Antes no hemos pensado en grabar el juego, añadámoslo ahora –dijo Paula.
–Un jugador puede querer también retroceder y anotar movimientos. Deep Black & White permite hacerlo –dijo Rosa.– Puedo hacer una anotación como “Pensaba jugar en en la posición A3”.
–De acuerdo. Escribamos estas historias –dijo Carlos. Obteniendo esta otra lista:

–¿Qué viene ahora, Carlos? –preguntó Alberto.
–Mientras le dais los últimos toques a Deep Black & White, las dos próximas semanas, Diana va a seguir con el análisis del producto.
–Sí –añadió Diana–. Quiero validar con usuarios potenciales las características que creen que son más importantes.
–Pero antes de terminar hoy, deberíamos crear una estimación de alto nivel para cada historia –dijo Carlos.
–De acuerdo, estimemos. Pero después de un descanso de diez minutos–dijo Alberto.

**Estimando Historias de Usuario en “Puntos-Historia” (Story Points)**

–Lo que vamos a hacer ahora –reanudaba Carlos la reunión– es estimar cada historia con un número de story points.
–¿Qué son los story points? –preguntó Francisco.
–Un story point es una estimación adimensional del tamaño y complejidad de una historia de usuario –contestó Carlos–. Supongan que decidimos que grabar una partida son 3 puntos. Si pensamos que restaurar una partida grabada tendrá el mismo esfuerzo, diremos 3 puntos también. Si es un poco menos, diremos 2 puntos.
–Entonces ¿los números no significan nada? –preguntó Francisco.
–Solo relativamente. Un 2 es el doble de un 1. Un 8 es cuatro veces un 2. Es lo único que importa –aclaró Carlos–. Vamos a estimar jugando al “planificación-poker” (planning poker) –Carlos le entregó a cada uno una baraja de cartas con los valores 1, 2, 3, 5 y 8.

Procederemos así: Diana nos leerá una historia de usuario. Podemos comentar y debatir. Después, cada uno elegirá una de estas cartas y las mostraremos todos al mismo tiempo. Si todos estamos de acuerdo, esa será la estimación. Si no, discutiremos nuestras estimaciones y la propia historia de usuario durante un par de minutos, y repetiremos el proceso hasta que nos pongamos de acuerdo.

Carlos contestó algunas preguntas sobre esta técnica y después le pidió a Diana que leyese la primera historia: “Como jugador, puedo iniciar una nueva partida”.

–La primera o segunda historia deberían ser siempre las más difíciles, ¿no?– añadió Santiago–. Puesto que estimamos las historias por comparación con otras, es difícil cuando no hay contra qué comparar. Solo podemos decir si esta historia inicial es grande o pequeña. Si después de estimar cuatro o cinco decidimos cambiar la estimación de esta primera, eso se puede hacer.
–¿Qué queríamos decir con esta historia?– preguntó Alberto–. No tengo claro lo que significa iniciar una nueva partida.
–Esta historia la escribimos cuando estábamos pensando lo que querría hacer un usuario después de arrancar la aplicación –dijo Diana–. Dijimos que probablemente querría empezar una nueva partida o recuperar una antigua. Esto era todo lo que queríamos decir.
–¿Incluye pintar un tablero vacío y la configuración inicial para que el sistema pueda empezar la partida? –preguntó Alberto.
–Creo que sí. No creo que el tablero tenga que ser muy vistoso para esto. Ya tenemos otra historia para hacer la pantalla agradable estéticamente, pero sí es cierto que en esta historia requiere que el sistema dibuje un tablero de Havannah en la pantalla.

Carlos esperó unos segundos mas para ver si había más preguntas.

–Está bien. Ahora, que todo el mundo elija una carta con la estimación de la historia.
–Es un 1 –dijo Alberto, enseñando su carta a todos.
–Aún no, Alberto –dijo Carlos–. Todos necesitamos la oportunidad de pensar en ello sin ver la estimación de los demás. Hacerlo así evita cualquier tipo de condicionamiento –hizo una pausa–. Parece que todos tienen su carta. Denles la vuelta, por favor.

Carlos repasó las puntuaciones: desde los 1 de Alberto y Rosa hasta el 5 de Paula.

–¿Por qué un 5, Paula? –preguntó Carlos.
–Pienso que la historia será una de las grandes –respondió.
–Ni de lejos –argumentó Alberto–. Todo lo que se necesita es una interfaz de usuario donde un jugador pueda pulsar el botón de “Nueva Partida” y entonces que salga un tablero vacío de Havannah. El tablero no tiene que ser muy estético, y tampoco hay que permitir que el usuario ponga fichas, ya tenemos otras historias para esto. Esta historia es de las fáciles.
–De acuerdo, no lo había pensado así– dijo Paula.

Carlos permitió que la discusión se prolongase un poco más. Después volvió a pedir que todos eligieran una carta con su estimación. La mayoría eran ahora 1, salvo el 2 de Paula. Carlos reabrió el debate y le preguntó a Paula si podía estimar un 1, a lo cual Paula se mostró de acuerdo. Finalmente, la primera historia se estimó con 1 punto.

–Vamos con la siguiente historia –dijo Diana, leyendo– “Como jugador, puedo recuperar una partida grabada”.

Tras dos minutos de discusión sobre lo que tendría que hacer esta historia, Carlos les pidió que eligieran una carta. No hubo consenso en primera ronda. Santiago argumentó que esta historia era el doble de grande que la primera porque implicaba configurar un tablero vacío, leer la partida grabada desde un fichero, y colocar en el tablero las piezas jugadas. Convencido por sus argumentos, el equipo estimó esta historia con 2 puntos.

Descomponiendo las historias grandes

–Siguiente: “Como jugador, puedo elegir el nivel de juego del ordenador”. Estimemos esta– dijo Santiago.
–Eso es el motor de selección de movimientos entero– dijo Alberto.– Va a ser duro. ¿Podemos saltarnos esta y volver a ella después de estimar alguna otra de las grandes?
–De acuerdo, por mi parte –dijo Santiago.
–Un momento– dijo Rosa. –Yo entendía que esta historia consistía en dejar que el usuario elija el nivel de dificultad. Esto es sencillo. Con uno o dos campos en la pantalla bastaría.
–Es lo que yo pensaba cuando la escribí.– dijo Francisco.
–Está bien pero, entonces, necesitamos otra historia que diga: “Como jugador, puedo jugar contra el ordenador con distintos niveles de dificultad”. –dijo Rosa.
–¿Podemos descomponerla más? –preguntó Alberto.– Creo que va a ser muy grande. ¿Qué os parece: “Como jugador, puedo jugar contra el ordenador con nivel bajo”? Y también: “Como jugador, puedo jugar contra el ordenador con nivel alto y con nivel medio”?
–Por supuesto, hagámoslo– dijo Santiago.– Empecemos por la historia para que el jugador seleccione el nivel del juego. Que cada uno elija una carta. ¿Listos? Denles la vuelta. –Todos habían puntuado un 1– A mí me parece razonable. Estamos diciendo que es igual que: “Como jugador, puedo iniciar una nueva partida”.

Hubo asentimiento general sobre que las dos historias eran del mismo tamaño.

–Ahora puntuemos: “Como jugador, puedo jugar contra el ordenador con nivel bajo” –sugirió Alberto, impaciente por hablar de las historias relacionadas con el motor de movimientos que probablemente sería el encargado de programar.– ¿Cómo de bajo debería ser el nivel de juego de nuestro motor de movimientos?
–No debería jugar aleatoriamente– dijo Diana.– Pero tampoco muy potente. Este juego es ya bastante duro. A la mayoría de la gente le lleva tiempo decidir qué es un buen movimiento. Pero incluso a un nivel bajo, nuestro motor tiene que saber si es mejor hacer un anillo, un puente o un tenedor, considerando lo que está haciendo el jugador.
–De acuerdo, estimemos– dijo Alberto.
–Espera– dijo Paula.– ¿Cómo vamos a probar esto? Parece que va a ser muy complicado.
–Buena pregunta– dijo Carlos.– ¿Alguna idea? –miró alrededor de la sala.
–Una forma sería identificar un conjunto de posiciones posibles, ver qué sugiere el motor, y preguntar a un buen jugador si esos movimientos son buenos o no –dijo Rosa.
–Buena idea, pero ¿podemos automatizarlo?– preguntó Diana.– Tenemos que automatizar las pruebas para detectar si el motor empieza a hacer movimientos malos, como pasó en abril con Deep Black & White. Si eso ocurre, debemos saberlo inmediatamente.

–Por supuesto– contestó Paula.– Podemos tener un fichero que relacione las posiciones de las fichas con los movimientos que el motor debería responder.
–Puede haber más de un movimiento aceptable– dijo Alberto.– Ese fichero debería permitirnos especificar múltiples respuestas.
–Estupendas respuestas. Ahora no tenemos que diseñar ese fichero, basta con saber que habrá algunas opciones. Estimemos la historia– dijo Carlos.

Se hizo el silencio en la sala mientras cada persona pensaba qué implicaría esa historia. Cada uno eligió una carta y las mostraron al mismo tiempo.

–Alberto, se supone que hay que elegir solo una carta, no todas. ¿No te has decidido?
–No tengo una carta suficientemente grande, así que las elijo todas– el programador enseñó las cartas con 1, 2, 3, 5 y 8 puntos.– Suman 19. Me parece bien.
–Tengo cartas más grandes: 13, 20, 40 y 100– dijo Carlos, repartiendo más cartas a cada persona.– Esperaba que no las necesitáramos.
–¿Por qué esperabas que no las necesitáramos?
–Considerando las historias que hemos estimado hasta ahora, cualquier historia de 100 puntos no cabría en una iteración. Sería demasiado grande. Lo mismo es cierto para el resto de números que acabo de pasaros. Está bien que tengamos algunas historias grandes, y es normal estimarlas con valores grandes. Pero tenemos que recordar que tendremos que descomponerlas antes de trabajar en ellas para que quepan en una iteración. También hemos de recordar que las estimaciones de funcionalidades muy grandes son poco precisas (tienen mayor rango de incertidumbre).
–Así pues, Alberto, ¿piensas de verdad que son 19 puntos?– preguntó Santiago mirando la carta de 18 que tenía en la mano.
–Por supuesto. El motor tendrá que reconocer si el jugador está intentando hacer un anillo, puente o tenedor. Va a tener que decidir qué figura debería tratar de hacer, y si debe atacar o defender. Incluso el más sencillo de los motores va a llevar algún tiempo desarrollarlo.
–Tú sabrás, pero 19 es mucho. –dijo Santiago.
–Paula, ¿por qué piensas que son 3 puntos? –preguntó Carlos, focalizando la discusión en los valores divergentes.
–Las pruebas no parecen difíciles. No creo que tenga mucho que hacer. Crearé esos ficheros de pruebas y ya está.
–Sí pero estamos estimando la historia completa, no solo nuestra parte. Las pruebas pueden puntuar 3, pero hay que tener en cuenta el tiempo de Alberto, también –explicó Carlos.
–¡Ah!, entonces Alberto tiene razón –dijo Paula.– Esta historia va a ser de las grandes.
–Veamos si tiene razón. Escojan de nuevo una carta y hagan una reestimación basándose en lo que acaban de oir –instruyó Carlos. Hizo una breve pausa para asegurarse de que todos tenían tiempo de pensar– Denles la vuelta.

Todas las cartas mostraban un 20 esta vez.

–Parece que les has convencido a todos, Alberto –dijo Carlos.– Sin embargo, 20 puntos son muchos para una sola historia. Alberto, ¿hay alguna forma de descomponerla? Quizá con un motor incluso menos potente la primera vez? Después se mejoraría antes de la primera entrega.
–No se me ocurre –dijo Alberto. Meditó por un momento y luego continuó.– Podríamos hacer que atacase siempre, tratando de hacer su figura ignorando los movimientos del jugador, pero no me parece una buena idea.

–¿Y si solo reconociese anillos? –preguntó Rosa.– Podríamos olvidarnos de los puentes y los tenedores (solo al principio). Alberto: ¿podrías programar un motor que jugase atacando y defendiendo pero solo intentando formar (y bloqueando) anillos?
–Claro. Podría funcionar. Podemos descomponer en tres historias, una para cada forma.

Todos estuvieron de acuerdo, y estimaron estas tres nuevas historias:

–Cuando estas tres historias eran una, la estimamos con 20 puntos. Ahora son 21. ¿No deberíamos quitar un punto? –preguntó Francisco.
–No. Las estimaciones son lo que son, no tienen por qué ser tan precisas –respondió Carlos.– Descomponer historias nos ayuda a conocer mejor lo que hay que hacer. La estimaciones de las descomposiciones no tienen que sumar la estimación de la historia original, necesariamente.
–Alberto, ¿qué deberíamos hacer con las historias para el motor de dificultad media y alta? ¿Quieres una historia para cada uno, o prefieres descomponer en anillos, puentes y tenedores de la misma manera?
–Una historia por cada uno. Pienso que deberíamos definir nuestro motor de dificultad media como uno que nunca mete la pata –dijo Alberto– quizá no siempre haga el movimiento óptimo, pero nunca comete errores muy graves. Podemos probarlo como dijimos antes, y también podemos hacer que algunos buenos jugadores lo prueben. Mientras haga movimientos razonables, es suficiente. Para el motor de dificultad alta, podemos aumentar la restricción para que solo haga el mejor movimiento que pueda encontrar. Considerando el rendimiento, podemos determinar lo complicado que puede ser el motor.
–Entonces, ¿cómo quieres escribirlo en forma de historias? –preguntó Francisco.
–Creo que así es suficiente: “Como jugador, puedo jugar contra un motor medio” –respondió Diana.
–Sí –se mostró de acuerdo Carlos–. En la tarjeta de la historia puedes anotar la condición de satisfacción: “siempre juega movimientos razonables para un buen jugador humano”.

El equipo discutió esta historia un poco más, jugaron planning poker y acordaron 8 puntos para esta estimación.

–Y entonces supongo que también tendremos la historia: “Como jugador, puedo jugar contra un motor fuerte” –dijo Francisco.
–Esta es al menos el doble de grande que la del motor medio –dijo Alberto–. Dijimos 8, pero no hay carta para 16. ¿Decimos 13 o nos inventamos la de 16?
–Lo que deben hacer –dijo Carlos– es pensar que las cartas son cubos. Si esta historia mide 16, no va a caber en un cubo de 13. No queremos inventar nuevos valores porque parecería que buscamos demasiada precisión. No sabemos si mide 13, 16 o 19. Es importante recordar que son estimaciones, no certezas.
–De acuerdo. Pienso que el motor fuerte es entre 2 y 3 veces más grande que el medio –dijo Alberto–. Eso significa que está entre 16-24. Puesto que 24 no cabe en un cubo de 20, ¿debería estimar 40? Eso parece muy alto. No es 5 veces más grande que el motor medio.
–No debes estimar 40 –respondió Carlos–. Son cubos, pero piensa que el contenido es arena, no agua. Puedes echar un poco más arena por encima.
–Estimemos, pues –dijo Alberto–.
Basándose en lo que acababan de oír, todos dijeron 20.
–Entonces esta historia mide 20 –dijo Carlos–. Dejémoslo así de momento. Seguramente necesitaremos descomponerla más adelante.
–¿No tenemos que descomponerla ahora como hicimos con el motor débil? –preguntó Alberto.
–No, podemos hacerlo más adelante, cuando estemos cerca de programar esa historia –dijo Carlos–. Sabremos más entonces y no ganamos nada por descomponerla hoy.

Independizando unas historias de otras

–Bien, sigamos– sugirió Diana.– La siguiente historia es “Como jugador, me gustaría ser capaz de jugar contra otra persona desde mi ordenador”. Se refiere a dos jugadores en un ordenador pasándose el tablero o el ratón y poniendo fichas alternativamente. Todo lo que queremos es que el ordenador nos avise cuando alguien gana.
–Las otras funcionalidades siguen activas, ¿verdad?– preguntó Paula.– Dos jugadores humanos pueden querer deshacer y rehacer, o pedir pistas.
–Sí– respondió Diana.
–Creo que deberíamos añadir la historia: “Como jugador, quiero que el ordenador reconozca una figura ganadora” –dijo Alberto.
–¿No es parte de las historias del motor de movimientos?
–Sí, pero si la extraemos podríamos hacerla por separado y eso nos permitiría programar muy rápido una versión de humano contra humano, mientras seguimos trabajando en el motor de movimientos.
No hubo objeciones, y la nueva historia se estimó con 2 puntos.
–Alberto, ¿eso no rebaja la estimación de las historias del motor débil? –preguntó Francisco.
–No necesariamente. Podríamos dejarlas como están. También podríamos reducir las historias de 8 puntos a 7 si quieres.
–No. No queremos hacer eso –dijo Carlos. –eso hace que los números parezcan muy precisos. Si queremos bajarlo a 5, sí podríamos. Si no, dejémoslo en 8.
–No, 5 es muy bajo –dijo Alberto.
–De acuerdo. Volvamos a la historia: “Como jugador, me gustaría ser capaz de jugar contra otra persona desde mi ordenador”.

Después de dos rondas de planning poker, se consensuó la estimación en 3 puntos.

–La siguiente historia es: “Como jugador, me gustaría que la apariencia del juego fuera agradable estéticamente” –leyó Diana.
–Por fin, una de las mías –dijo Rosa, la diseñadora gráfica.
–Sí, pero no me gusta cómo está escrita –dijo Santiago.– Es ambigua y grande. Me gusta la siguiente: “Como jugador, me gustaría ser capaz de elegir entre tablero y fichas de madera o metal”. ¿Qué más hace falta para ser “agradable estéticamente”?
–Tenía que ver con la apariencia global del juego –respondió Francisco.– Seguramente no habrá muchos menús, pero queremos que tengan buen aspecto. Queremos que los elementos de los menús estén en sitios lógicos. Al cargarse el juego, queremos una pantalla atractiva con relieve. El tablero y las fichas son la interfaz de usuario completa. Habrá probablemente algún diseño de fondo detrás del tablero. Rosa necesita tiempo para hacerlo.
–Suena bien. ¿Podemos descomponer en historias separadas? –preguntó Santiago.
–Podríamos –dijo Diana– pero sería difícil. Creo que los elementos de menú deben desarrollarse en el contexto de las funcionalidades que necesiten opciones de menú. Rosa ¿qué piensas de tener una historia para una pantalla de relieve y otra para el diseño de fondo?
–Por mi parte, bien. Obviamente las voy a desarrollar por separado en cualquier caso.
El equipo avanzó rápidamente sobre el siguiente grupo de historias.

Historias dependientes

–¿Qué hacemos con esta historia? –preguntó Paula, señalando a la tarjeta: “Como jugador, me gustaría pedir pistas algunas veces”.
–¿Qué quieres decir?
–Si tenemos el motor de movimientos, esta historia es muy sencilla. Solo hay que pedir al motor de movimiento que sugiera un nuevo movimiento, pero para el jugador en vez de para el ordenador. Esto sería trivial. Pero si no tenemos el motor programado, esta historia tiene que ser al menos tan grande como programar todo el motor de movimientos.
–Tenemos una dependencia: podemos hacer esta funcionalidad solo después de tener el motor –dijo Alberto.
–Sí, pero no creo que ese sea el problema en este caso –dijo Santiago.– Lo normal es programar el motor de movimientos antes que la funcionalidad de dar pistas. La dependencia no nos ha de preocupar. Podemos ignorarla. O si nos preocupa que se nos olvide, podemos anotarla en la tarjeta. De cualquier forma, la historia puede estimarse suponiendo de que el motor ya existe.
Todos se mostraron de acuerdo. La historia se estimó con 1 punto.
–¿Qué habríamos hecho si hubiésemos querido tener la funcionalidad de pistas antes que el motor?
–Algunas veces no se puede ignorar una dependencia y hay que vivir con ella –explicó Carlos–. La mayoría de las veces, sin embargo, se pueden ignorar. Si quisiéramos ignorar esta dependencia, podríamos programar el código que le permite a un usuario pedir una pista, mostrar la pista y si quiere, hacer el movimiento por el usuario. Para obtener la pista, tendríamos que tener un objeto en el sistema llamado GeneradorDePistas. Finalmente, GeneradorDePistas invocará al motor de movimientos para obtener una buena pista. Pero por ahora, podría devolver o bien el primer espacio libre o un espacio libre al azar. De esta forma, terminaríamos la historia de las pistas incluso antes de empezar el motor de movimientos.
–Tendríamos que recordar más tarde que hay que hacer que GeneradorDePistas invoque al motor de movimientos –dijo Alberto.
–Sí –dijo Carlos.– Podríamos hacer otra historia del tipo: “Como usuario, quiero tener buenas pistas, no solo cualquier tipo de pista”.

–Sería nada más que cambiar una línea de código –dijo Alberto.–Borraríamos lo que GeneradorDePistas hacía para encontrar un espacio vacío y en su lugar invocaríamos al motor de movimientos. Mediría 1 punto, como la historia original. Parece como si no hubiéramos ganado nada.
–Ah –dijo Carlos.– Por eso es útil algunas veces tener cartas con el número 0. Queremos una historia para que no se nos olvide que hay que cambiar el código, y por otra parte es tan simple que no supondrá apenas esfuerzo.
Carlos le dio a cada persona otra carta de planning poker con un 0.
–Las he guardado porque no quería que las usárais antes de explicar cómo son las historias de 0 puntos. Ahora cada persona tiene una baraja de cartas con los números: 0, 1, 2, 3, 5, 8, 13, 20, 40 y 100.
–En nuestro caso, no obstante, vamos a añadir el soporte para pistas después de que el motor esté construido, ¿de acuerdo? –preguntó Francisco.
–Sí, mantenemos 1 punto para esa historia –respondió Santiago.

El proceso de estimación continuó de esta forma hasta que el equipo hubo estimado todas las historias escritas.

Resultado del Brainstorming: 32 historias y 146 puntos

Las historias y sus estimaciones se muestran a continuación:

Ir al siguiente post
Ir al post anterior

Este texto se ha traducido del libro:

Agile Estimating and Planning

Mike Cohn. Prentice Hall, 2012

Los Hábitos de un Director de Proyectos Eficaz

Páginas

Buscar este blog

24 de febrero de 2013

Las historias del proyecto Havannah