Un caso de estudio ágil: El Proyecto Havannah

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”.
 
[…]
Era un largo vuelo, pero el congreso había merecido la pena. Volar de vuelta desde la 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