Un caso de estudio ágil: El Proyecto Havannah

Share
El siguiente caso de estudio es una
traducción del capítulo 23 del libro de Mike
Cohn titulado Agile Estimating and Planning.
Este capítulo, el autor, con la intención de
resumir y ejemplificar la mayoría de los
puntos clave del libro, desarrolla el caso
práctico de la experiencia del primer
proyecto ágil en una empresa ficticia
llamada Bomb Shelter Studios, en el que
participan las siguientes personas: 

Francisco: Responsable de productos.

Alberto: Programador.
Santiago: Programador.
Carlos: Coach en métodos ágiles.
Paula: Responsable de pruebas.
Rosa: Diseñadora gráfica.
Diana: Analista.
Laura: Directora financiera.
Felipe: Director general.

Este post reproduce la traducción del mencionado capítulo, desde que surge la necesidad
de probar métodos ágiles para gestionar un nuevo proyecto software hasta que comienza
la primera reunión de recopilación de requisitos en forma de “historias de usuario”. 
  

[…]

largo vuelo, pero el congreso había merecido la pena. Volar de vuelta desde la
Era un
costa este se hacía siempre largo y agotador, pero esta vez Francisco había
promocionado a primera clase canjeando algunas millas a cambio de un poco más de
espacio y confort. Francisco iba cómodo en su asiento, reflexionando sobre los
acontecimientos de la semana. 

Como responsable de productos en Bomb Shelter Studios, Francisco sabía que el

último juego que habían lanzado al mercado iba a ir muy bien. El juego había sido
bautizado con el nombre Deep Black & White. Básicamente, se trataba de una
implementación del juego del “Go”, muy popular en Japón, China y Corea, pero con
pocos seguidores en Europa, Norteamérica y resto del mundo. El equipo de
programadores había desarrollado una serie de algoritmos de inteligencia artificial que
hacían que el ordenador pudiera jugar al nivel conocido en el juego del Go como “5º
dan”. Esto quedaba todavía lejos del máximo nivel de los mejores jugadores (9º dan),
pero era un nivel muy elevado para cualquier jugador cliente de Bomb Shelter. 

Francisco estaba entusiasmado: En el congreso había negociado un acuerdo con un

distribuidor para toda Asia. Los ingresos por ventas en este mercado serían el
espaldarazo que le hacía falta a Bomb Shelter. Los seis meses de retraso que tuvo el
proyecto fueron difíciles, pero ahora parecen el final de una etapa empresarial: El fin de
Bomb Shelter como la pequeña empresa privada de la que fue socio fundador.

Desde sus difíciles comienzos tres años atrás, Bomb Shelter Studios se había convertido
en una empresa de desarrollo de juegos muy reconocida en el sector de los juegos de
estrategia. Además del último juego Deep Black & White, Bomb Shelter había
desarrollado muchos otros juegos (ajedrez, backgammon, reversi, bridge, damas,
mancala, etc.). Cuando se terminaba un juego, los derechos se vendían a un distribuidor
que se hacía cargo de la producción y la distribución, permitiendo que Bomb Shelter
pudiera centrarse en desarrollar nuevos juegos.

Mientras Francisco estaba en el congreso, el equipo de desarrollo, en la oficina de Santa

Bárbara, ya estaba pensando en un nuevo juego, Havannah, a punto de comenzar el
desarrollo. Debido a los problemas con Deep Black & White (no solo el retraso de seis
meses, sino también demasiados errores en la fase de pruebas y algunos problemas de
usabilidad descubiertos al final), Francisco era consciente de que necesitaban nuevos
métodos para planificar y desarrollar proyectos. 

Santiago estuvo investigando algunas ideas que el equipo tenía, y finalmente sugirió
usar lo que llamaban “proceso ágil” para el siguiente proyecto. Francisco no entendía lo
que eso significaba, pero estaba seguro de que necesitaban probar algo diferente: No se
podían permitir un nuevo retraso de seis meses en el próximo juego. Todos los
miembros del equipo estaban entusiasmados con el proceso ágil, y sabían perfectamente
lo que estaba en juego. 

Día 1: Lunes por la mañana

–Buenos días a todos –dijo Francisco al entrar en la sala de reuniones. Todavía faltaba
un minuto para las nueve, y casi todos ya estaban esperando. Eso era buena señal. A
pesar de que el equipo quedó exhausto por el empujón final de Deep Black & White, ya
estaban listos para empezar a trabajar en Havannah. 
–Buenos días, Francisco. He visto tu email sobre Deep Black & White. Una gran
noticia lo del acuerdo de distribución –dijo Alberto, el programador en C++ que había
codificado el motor de inteligencia artificial que hizo de Deep Black & White un juego
tan potente. 

–Toma un donut, Francisco –dijo Santiago, acercándole la caja casi vacía. 

–Gracias –dijo Francisco, acercándole la caja casi vacía. 

–Francisco, este es Carlos –dijo Santiago–. Carlos es un coach en métodos ágiles con
mucha experiencia. Le hemos traído para que nos ayude a aprender a trabajar de esta
nueva forma. 

Francisco y Carlos se saludaron. 

–Parece que estamos todos excepto Rosa –dijo Francisco-. Empecemos. Ya le

pondremos al día cuando llegue. Seguramente no vamos a hablar mucho del diseño
gráfico en esta reunión, de todas formas. 

–No podemos empezar, Francisco –dijo Carlos–. Esto es importante: Necesitamos a todo
el equipo. Buena parte de los beneficios del proceso ágil se producen cuando todos
participan. Rosa quizá no tenga mucho que decir sobre el motor de inteligencia artificial,
pero aun así, necesitamos su opinión si queremos conseguir el mejor juego que somos
capaces de hacer. 

–Ella siempre llega cinco minutos tarde los lunes. Tiene que dejar a su hijo en el colegio
los lunes, miércoles y viernes. Estará a punto de llegar –estaba diciendo Paula, justo
cuando Rosa abrió la puerta. 

–Siento llegar tarde, el tráfico –dijo Rosa, tomando asiento rápidamente. 

–Así pues, Diana, has empezado el análisis sobre Havannah –le dijo Francisco a la

analista-. Hace mucho que ya no pienso en el juego. Perdón por preguntar, pero ¿puedes
decirme cómo se juega otra vez? 

–Por supuesto, Francisco. En primer lugar, el tablero es como este –dijo Diana mientras
sacaba un tablero de madera de su bolso y lo ponía en la mesa. 
–Es para dos jugadores, que van colocando por turnos una ficha blanca o negra en el
tablero. Cuando una ficha se coloca en el tablero, ya no se puede mover. 

–Como en Deep Black & White –dijo Francisco. 

–Sí, pero al contrario que en el Go, aquí las fichas no se pueden capturar. El objetivo
en Havannah es ser el primer jugador en hacer un anillo, un puente o un tenedor. Quien
haga una figura primero gana el juego. 

–¿Y qué es un anillo, un puente o un tenedor? –preguntó Francisco, mientras Diana iba
colocando unas cuantas fichas en el tablero. 

–El anillo es la figura más sencilla. Es así. Un anillo es un conjunto de fichas conectadas
que encierran uno o más huecos. 

–Parece bastante fácil. ¿Dónde está la dificultad? –dijo Alberto, que ya estaba pensando
en el motor de inteligencia artificial para seleccionar movimientos. 

–Recuerda: el anillo es solo una de las formas de ganar. Se puede ganar también con un
tenedor o un puente –continuó Diana mientras colocaba más fichas en el tablero-. Un
puente conecta dos esquinas cualesquiera. Un puente puede ser una línea entre dos
esquinas no consecutivas, pero es más probable entre dos esquinas adyacentes:
–¿El jugador tiene que decir qué figura quiere hacer antes de empezar a jugar? –
preguntó Alberto.

–No, ahí está la gracia y también el reto. Puedes empezar intentando un puente, darte
cuenta de que no va a funcionar, y quizá intentar un tenedor, por ejemplo. 

–¿Qué es un tenedor? 

–Es así, Francisco –dijo Diana mientras añadía más fichas al tablero–. Un tenedor
conecta tres lados, no esquinas. Las esquinas no son lados, así que no pueden usarse en
un tenedor. Si pueden usarse en un puente. 

–Va a ser un reto programar el motor de movimientos. Con tantas formas posibles de
ganar y tantos espacios en el tablero, las combinaciones son muchísimas.

–Tienes razón, Alberto –dijo Diana–. Mucha gente piensa que este juego es más difícil
que el ajedrez porque hay más opciones y porque no se pueden usar libros de fin de
juego, como en el ajedrez. En el ajedrez, cuando quedan pocas piezas, es posible usar un
libro de mejores jugadas. En ese momento ya no hace falta que el motor deduzca los
movimientos. En el Havannah, hay demasiadas piezas y demasiadas posiciones. 

–No querrías programar un juego sencillo. ¿Verdad, Alberto? –bromeó Santiago, el otro
programador. Alberto puso cara como si hubiera preferido un juego más sencillo, esta
vez.

–No te preocupes. La buena noticia es que como sabe jugar muy poca gente, no
necesitamos un motor tan potente como el de Deep Black & White –dijo Diana, viendo
que Alberto se relajaba un poco–. Al final querremos un motor potente, sí, pero no en la
primera versión. Un motor potente que gane a la mayoría de los jugadores la mayoría de
las veces será suficiente. 

–De acuerdo, Diana. ¿Alguna otra regla que tengamos que saber? –preguntó Francisco. 

–No, ya está. Las reglas son simples, pero el juego te hace pensar de verdad. Por eso
pensamos que se venderá bien a los clientes que ya compraron otros juegos. 

–Entonces, ¿ya tienes el documento de requisitos? 

–Aún no, Francisco. Según nos ha enseñado Carlos sobre desarrollo de software en
proyectos ágiles, hay que hacer que todo el equipo colabore en la recopilación de los
requisitos. 

–Ciertamente –añadió Carlos. Vamos a empezar la reunión de hoy escribiendo “historias

de usuario”. Son frases breves describiendo la funcionalidad, pero desde la perspectiva
del usuario. Por ejemplo: “Como jugador, quiero grabar un juego en el que estoy a la
mitad”. 

–Eso parece bastante fácil. ¿Qué hacemos con las historias de usuario una vez
terminadas? 

–Estimaremos el tamaño de cada una y las priorizaremos. Después decidiremos qué

funcionalidades entregamos y cuándo –dijo Carlos. 

Ir al siguiente post
Este texto se ha traducido del libro:
Agile Estimating and Planning
Mike Cohn. Prentice Hall, 2012
Las historias del proyecto Havannah
Share

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:
Como jugador, puedo iniciar una nueva partida
Como jugador, puedo recuperar una partida grabada
Como jugador, puedo elegir el nivel de juego del ordenador
Como jugador, me gustaría ser capaz de jugar contra otra persona desde
mi ordenador
Como jugador, me gustaría que la apariencia del juego fuera agradable
estéticamente
Como jugador, me gustaría ser capaz de elegir entre tablero y fichas de
madera o metal
Como jugador, quiero ser capaz de ver un tutorial interactivo para el
juego
Como jugador, quiero que el juego tenga música de fondo
Como jugador, puedo elegir la música de fondo

–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: 

Como jugador, me gustaría deshacer y rehacer movimientos

Como jugador, quiero colocar una ficha en el tablero usando el ratón o
bien el teclado
Como jugador, quiero que un indicador visual muestre de quién es el
turno
Como jugador, me gustaría que un indicador visual indicase la última
ficha jugada (¿parpadeando?)
Como jugador, me gustaría pedir pistas algunas veces
Como jugador, me gustaría ser capaz de grabar partidas
 Como jugador, quiero
poder abandonar el juego
Como jugador, quiero
reiniciar la partida para
rendirme y comenzar de
nuevo
Como nuevo jugador,
quiero acceder a un
sistema de ayuda online
Como jugador, quiero que
todas las fichas que
componen la forma
ganadora parpadeen para
que yo pueda distinguir la
figura ganadora
Como jugador novel, me
gustaría que el sistema me
advirtiese que acabo de
hacer un movimiento malo
y que se me dé la
oportunidad de deshacerlo
Como jugador novel, cuando es mi turno, me gustaría que el sistema me
mostrase cualquier posición que debería jugar, porque si no lo hago, el
sistema jugará en esa posición y ganará
Como jugador, me gustaría que el sistema tardase no más de dos
segundos en mover (en un PC de 2 GHz)

–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: 

Como jugador, quiero que el sistema registre cuántos juegos he ganado y

perdido (¿por grado de dificultad?)
Como jugador, quiero hacer anotaciones en juegos grabados
Como jugador, me gustaría avanzar movimientos para revisar una partida
ya jugada
Como jugador, puedo grabar una partida

–¿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: 

Como jugador, puedo jugar contra un motor débil que reconozca solo
anillos (8)
Como jugador, puedo jugar contra un motor débil que reconozca solo
puentes (5)
Como jugador, puedo jugar contra un motor débil que reconozca solo
tenedores (8)

–Cuando estas tres historias eran una, la estimamos con 20 puntos. Ahora son 21. ¿No
deberíamos quitar un punto? –preguntó Francisco. 

qué ser tan precisas –respondió
–No. Las estimaciones son lo que son, no tienen por
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: 

Como jugador, me gustaría deshacer y rehacer movimientos [2]
Como jugador, puedo iniciar una nueva partida [1]
Como jugador, puedo recuperar una partida grabada [2]
Como jugador, puedo elegir el nivel de juego del ordenador [1]
Como jugador, puedo jugar contra un motor débil que reconozca solo
anillos [8]
Como jugador, puedo jugar contra un motor débil que reconozca solo
puentes [5]
Como jugador, puedo jugar contra un motor débil que reconozca solo
tenedores [8]
Como jugador, puedo jugar contra un motor medio [8]
Como jugador, puedo jugar contra un motor fuerte [20]
Como jugador, me gustaría ser capaz de jugar contra otra persona desde
mi ordenador [3]
Como jugador, quiero que el ordenador reconozca una figura ganadora
[2]
Como jugador, quiero una pantalla de relieve cuando el juego comienza
[5]
Como jugador, quiero un diseño de fondo integrado con los tableros [5]
Como jugador, me gustaría ser capaz de elegir entre tablero y fichas de
madera o metal [8]
Como jugador, me gustaría pedir pistas algunas veces [1]
Como jugador, quiero ser capaz de ver un tutorial interactivo para el
juego [8]
Como jugador, quiero que el juego tenga música de fondo [5]
Como jugador, puedo elegir la música de fondo [1]
Como jugador, quiero colocar una ficha en el tablero usando el ratón o
bien el teclado [3]
Como jugador, quiero que un indicador visual muestre de quién es el
turno [2]
Como jugador, me gustaría que un indicador visual indicase la última
ficha jugada (¿parpadeando?) [2]
Como jugador, me gustaría ser capaz de grabar partidas [3]
Como jugador, quiero poder abandonar el juego [1]
Como jugador, quiero reiniciar la partida para rendirme y comenzar de
nuevo [1]
Como nuevo jugador, quiero acceder a un sistema de ayuda online [8]
Como jugador, quiero que todas las fichas que componen la forma
ganadora parpadeen para que yo pueda distinguir la figura ganadora [3]
Como jugador novel, me gustaría que el sistema me advirtiese que acabo
de hacer un movimiento malo y que se me dé la oportunidad de
deshacerlo [8]
Como jugador novel, cuando es mi turno, me gustaría que el sistema me
mostrase cualquier posición que debería jugar, porque si no lo hago, el
sistema jugará en esa posición y ganará [3]
Como jugador, me gustaría que el sistema tardase no más de dos
segundos en mover (en un PC de 2 GHz) [8]
Como jugador, quiero que el sistema registre cuántos juegos he ganado y
perdido (¿por grado de dificultad?) [3]
Como jugador, quiero hacer anotaciones en juegos grabados [3]
Como jugador, me gustaría avanzar movimientos para revisar una partida
ya jugada [5]