Comprometidos como EQUIPO con la primera iteración

Tercera 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 había escrito 32 historias de usuario, que tenían un tamaño de 146 puntos en total. 

En este post, los miembros del equipo dedican dos semanas a terminar otro proyecto mientras la analista Diana comienza la investigación de mercado con una encuesta a potenciales compradores. Al cabo de las dos semanas, el equipo se vuelve a reunir con Carlos, el coach en métodos ágiles, para planificar la primera iteración y comprometerse como equipo para terminar las historias más prioritarias. El resultado es un compromiso firme del equipo sobre 4 historias que miden 18 puntos.

¿Quiere saber cómo se planifica esta primera iteración?

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”.
 
[…]

–¿Qué hacemos ahora? Necesitamos trabajar dos semanas más en Deep Black & White antes de entregárselo al distribuidor –dijo Francisco.
–Mientras los demás trabajan en ello, yo voy a entrevistar a algunos compradores potenciales de Havannah –dijo Diana–. Quiero saber qué funcionalidades son las más importantes.
–¿Te llevará mucho tiempo?
–No, habré terminado antes de dos semanas –dijo Diana–. Reunámonos otra vez entonces, justo después de entregar Deep Black & White y antes de que Francisco nos invite a comer para celebrarlo.
–Suena genial. Me encargo de organizar la comida. ¿Unas hamburguesas, Diana? ¿O tiramos la casa por la ventana con unas pizzas?

Preparando la Investigación de Mercado

Al día siguiente, temprano por la mañana, Diana se puso a preparar la encuesta que debería enviar a los potenciales compradores del juego. Francisco le había pedido una reunión para saber cómo iba a priorizar las funcionalidades. Como responsable de productos, Francisco tomaría las decisiones finales, pero Diana sabía que él confiaría mucho en su investigación. Quería estar bien preparada antes de reunirse con él. Cuando llegó Francisco, Diana casi había terminado la encuesta.

–Buenos días, Diana –saludó Francisco a la analista–. ¿Podremos reunirnos finalmente durante la mañana?
–Por supuesto. He venido pronto para terminar la encuesta que quiero enviar. Me gustaría enseñártela.
–Adelante –dijo Francisco acercando una silla–. Cuéntame qué tienes.
–He impreso esto hace media hora –dijo Diana, dándole una copia de la siguiente tabla–. He añadido algunas preguntas más, pero en la copia tienes suficiente para hacerte una idea.

Francisco revisó la tabla que le había pasado Diana.

–¿Parece que preguntas dos veces lo mismo?
–La primera pregunta se denomina “forma funcional”, la segunda es la “forma disfuncional”, o lo que es lo mismo, que la funcionalidad no está presente. Hacer estas dos preguntas nos da más información que si solo preguntamos “cuánto te gustaría esta funcionalidad”. Así sabemos cómo se sentiría el usuario si la funcionalidad estuviera incluida y también cómo se sentiría si no estuviera incluida.
–¿Me puedes poner un ejemplo?
–Por supuesto. Imagina que preguntamos “¿Cómo te sentirías se pudieras hacer y deshacer movimientos?” y el usuario dice “lo esperaría”. Luego le preguntamos “¿Cómo te sentirías si NO pudieras hacer y deshacer movimientos?” Y el usuario dice “no me gustaría”. Así sabremos que esta funcionalidad es “básica” u “obligatoria” para este usuario.
–Continúa, de momento te sigo.
–Ahora imagina que le preguntamos al mismo usuario “¿Cómo te sentirías si hubiera un tutorial interactivo para ayudarte a aprender a jugar?” y responde que “me gustaría”. Luego le hacemos la pregunta disfuncional y responde que “le es indiferente”. Así sabremos que esta funcionalidad es “emocionante”, “inesperada” o “innovadora” para este usuario. Sabemos que no es básica para él, pero como “le gustaría”, sabemos que podría estar dispuesto a pagar por ella un poco más.
–Pero, ¿no podemos tener la misma información pidiéndoles que puntúen de 1-5, tal como hicimos con Deep Black & White? –preguntó Francisco.
–No exactamente –respondió Diana–. Una escala simple como esa solo nos dice lo mucho que valoran las funcionalidades los usuarios. No nos dice cómo pueden reaccionar si las funcionalidades no están presentes. Por ejemplo, en el caso de un coche, yo no puntuaría muy alto las ruedas, pero me enfadaría mucho si el fabricante no las incluye.
–¿A quién vas a enviarle la encuesta?
–Voy a enviarla por email a 500 miembros de algunos clubes de jugadores de Havannah que conozco. Muchos están en Europa o en grandes ciudades de EE.UU. A quien responda, le vamos a ofrecer un cupón de descuento de 10 $ en cualquiera de nuestros juegos. También voy a hacer algunas entrevistas por teléfono.

–¿No son muchas preguntas 2 por cada historia de usuario? –preguntó Francisco.
–Voy a agrupar las historias de usuario por temas. Por ejemplo, tenemos dos historias de usuario para la música de fondo que podemos combinar en el tema “música de fondo”. Voy a agrupar las historias sobre la estética del juego. Por otra parte, no voy a hacer preguntas sobre grabar y recuperar partidas, porque ya sabemos que son obligatorias.
–Estupendo. Quiero estar seguro de que el cuestionario no resulta muy pesado o difícil. ¿Cómo vamos a procesar las respuestas?

–Quiero separar las funcionalidades en tres categorías. Primero las obligatorias. Estas suponen el coste de entrada, como grabar o recuperar partidas. La segunda categoría son las lineales: cuantas más, mejor. Imagino que los niveles de dificultad del juego entran en esta categoría. Cuantos más niveles de juego (como fuerte, medio, bajo), mejor. La tercera categoría son las funcionalidades emocionantes. Estas son aquellas que los usuarios no esperan, pero que cuando las ven, las quieren. Una buena selección de funcionalidades emocionantes y lineales, además de todas las obligatorias, pueden dar un juego atractivo para el usuario.

Antes de que Francisco pudiera responder, Alberto acercó su silla.
–Buenos días –dijo–. No he podido evitar escuchar parte de la conversación. Parece muy interesante. ¿Tendremos acceso el resto del equipo a los resultados de la encuesta?
–Claro que sí, Alberto.
–También me gustaría escuchar una o dos entrevistas telefónicas para oír lo que los usuarios tienen que decir, ¿puede ser? –preguntó Alberto.
–Por supuesto –dijo Diana–. Entender a los usuarios es beneficioso para todo el equipo. Cuanto más os involucréis los técnicos mejor para mí. Yo tendré vuestra opinión, y vosotros sabréis lo que dicen los clientes.
–De acuerdo –dijo Alberto–. Hoy no podré hacer llamadas contigo. Tengo que arreglar un fallo del motor de puntuaciones de Deep Black & White, pero cualquier otro día esta semana que hagas llamadas, házmelo saber.
–Así lo haré –dijo Diana.
–Veo que tienes un buen plan en marcha –dijo Francisco–. Es muy estimulante. ¿Tendrás algún resultado la próxima semana?
–Sí. El departamento de sistemas va a publicar la encuesta en la web mañana. Espero tener respuestas a partir de entonces.
–Genial. Gracias por enseñarme esto –dijo Francisco mientras se despedía.


Dos semanas después de escribir y estimar las historias de usuario, el equipo se reunió en la misma sala. 

–Hoy tenemos tres objetivos –dijo Carlos–. El primero es que vamos a planificar nuestra primera iteración de dos semanas. A continuación, Diana expondrá los resultados de la investigación de mercado. Por último vamos a hacer una estimación preliminar del plan de entregas y el calendario. ¿Alguna pregunta?

Planificando la Iteración (Iteration Planning)

–Entonces, ¿qué vamos a desarrollar primero? –preguntó Rosa.
–Quiero empezar con el motor de movimientos –dijo Alberto– es nuestro mayor riesgo.
–Ninguna objeción por mi parte –dijo Santiago, el otro programador del equipo–. ¿Hay algo en que podamos ayudar, Alberto? Normalmente, todo lo que se refiere a inteligencia artificial es cosa tuya.
–Sí que hay cosas que podéis hacer. Gracias –dijo Alberto–. Me ayudaría mucho porque me preocupa el nivel de rendimiento que debería presentar el motor fuerte.
–Bien, comencemos por la historia Como jugador, puedo jugar contra un motor débil que reconozca solo anillos. ¿Es esa la que quieres hacer primero, Alberto? –preguntó Diana.
–Sí. Lo primero que tendríamos que hacer es programar las clases que controlan el estado del tablero, de quién es el turno, y cosas así. Santiago, aquí tú puedes ser de gran ayuda.
–De acuerdo. ¿Cuánto crees llevará? ¿Un par de días?
–Un par de días intensos. Digamos 16 horas –respondió Alberto.
–Alberto, queremos apuntar cada tarea en una tarjeta. Escribe eso en una tarjeta y apunta 16 horas para que no olvidemos la estimación –dijo Carlos.

Alberto escribió en una tarjeta: Codificar las clases de gestión de estados (16 h).
–¿Pongo mis iniciales para recordar que es mi tarjeta?
–No. Aunque parece que tú vas a ser quien la haga, es mejor si no asignamos trabajos a personas concretas por ahora.
–Yo voy a tener que hacer las pruebas –dijo Paula–. No llevará mucho, pero es el primer código de programación de este proyecto y quiero asegurarme de que las configuro bien. Digamos que las pruebas llevarán 10 horas. –escribió otra tarjeta con el texto: Escribir pruebas automáticas para las clases de gestión de estados (10 h).
–Carlos, me dijiste antes que tengo que descomponer mi trabajo en partes más pequeñas –dijo Alberto–. No puedo decir simplemente que escribir el motor de movimientos llevará 2 semanas, ¿verdad?
–No, no puedes. Al identificar tareas, queremos que ocupen entre 1-16 horas. Idealmente, habría que poder terminar una cada día, lo que significa que en media no deberían superar las 5-6 horas, porque siempre hay otras cosas que hacer cada día.

–En ese caso –dijo Alberto– La forma de programar esto sería primero tener un motor de movimientos que pueda poner fichas en 6 hexágonos seguidos, sin oponente que lo impida. Haré que comience en un lugar aleatorio del tablero y haré un anillo en 6 movimientos. Después, lo programaré para que haga un anillo incluso si el oponente intenta bloquearlo. Después cambiaré a la parte defensiva de anillos. Haré que el motor intente bloquear a otro jugador que intente hacer un anillo. Así es suficiente para esta historia, en mi opinión.
–De acuerdo. Escribiré una tarjeta que diga: Hacer que el motor busque un anillo sin bloqueos. Eso es lo que has dicho que harías primero –dijo Santiago.
–Eso seguramente ocupa la mayor parte del día. Apunta 6 horas, por favor –dijo Alberto.
–Alberto, no te lo tomes a mal, pero tú siempre tiendes a ser optimista al comenzar un nuevo motor –dijo Rosa, la diseñadora gráfica.
–Sí, tienes razón. Haz que sea el doble, mejor –dijo Alberto.

Santiago tachó el 6 y escribió 12 horas en la tarjeta. Entonces Carlos dirigió la discusión para estimar las otras tareas que Alberto había identificado.

–¿Hay otras tareas que no hayamos identificado para esta historia? –preguntó.
–Deberíamos incluir tiempo para pruebas –dijo Paula–. Si Alberto me entrega el código resultante de sus tareas, yo puedo automatizar las pruebas inmediatamente después. Cuando encuentre un fallo, el código aún estará fresco en su cabeza y lo podrá arreglar rápidamente. He ido escribiendo las tareas de prueba en estas tarjetas mientras Alberto escribía las suyas de programación. Todavía no he podido estimarlas. ¿Podemos hacerlo juntos ahora?

Al terminar con las tareas de la historia Como jugador, puedo jugar contra un motor débil que reconozca solo anillos, ya tenían las siguientes tareas para esta historia:

• Codificar las clases de gestión de estados [16]
• Escribir pruebas automáticas para las clases de gestión de estados [10]
• Hacer que el motor busque un anillo sin bloqueos [12]
• Escribir pruebas automáticas para anillo sin bloqueos [12]
• Hacer que el motor busque un anillo incluso si el oponente hace bloqueos [8]
• Identificar los casos de prueba para intentar hacer un anillo con bloqueos [4]
• Automatizar las pruebas para intentar hacer un anillo con bloqueos [4]
• Hacer que el motor intente bloquear a un oponente que intenta hacer un anillo [12]
• Identificar los casos de prueba para bloquear a un oponente que intenta hacer un anillo [4]
• Automatizar las pruebas para bloquear a un oponente que intenta hacer un anillo [2]

–Esto hace un total de 84 horas en esta iteración. El trabajo se reparte entre Alberto, Santiago y Paula –dijo Carlos–. Basándome en lo que he estado viendo aquí durante un par de días, creo que deberíais planificar sobre 6 horas por día y persona de trabajo productivo. El resto de cada día se va en contestar emails, hablar con otros equipos de proyectos, vuestras reuniones diarias, las 4 horas cada dos semanas que dedicamos a estas planificaciones, etc.

–A mí me parece razonable.
–A mí también. Quizá estemos más cerca de 5 horas productivas al día, pero puedo conseguir 6 al día en este proyecto si me propongo evitar algunas distracciones de cada día –dijo Santiago.
–Ahora que hemos descompuesto la primera historia en tareas –dijo Carlos– la pregunta que tenéis que responder es si podéis comprometeros a finalizar la historia.
–¿La historia o las tareas? –preguntó Francisco–. ¿A qué nos comprometemos?
–Buena pregunta, Francisco –dijo Carlos–. El compromiso es con la historia. Se identifican las tareas como un medio para ver cuánto trabajo implica. Dado que el compromiso es con la historia, no solo con las tareas, es importante pensar en esto como un compromiso del equipo completo. Al final de la iteración, no quiero que Santiago diga que él ha terminado con las clases de gestión de estados, pero Alberto no ha terminado. Eso no sería un buen resultado. Podéis pensar en términos de tareas, pero tenéis que comprometeros con las historias.
–Interesante –dijo Francisco–. Me gusta la distinción.
–Yo me comprometo con esta historia –dijo Paula–. Tengo 36 horas de tareas de pruebas. Con 6 horas al día por 10 días, tengo 60 horas disponibles.
–Y entre Alberto y yo, tenemos 48 horas de tareas de programación. No será un problema –dijo Santiago.
–Estupendo. Ya hemos planificado nuestra primera historia y nos hemos comprometido –dijo Francisco–. Avancemos con la siguiente más importante.

–Francisco, antes de eso, veamos la disponibilidad de todos para las próximas dos semanas –dijo Carlos–. Hemos dicho que asumiríamos 6 horas al día, pero ¿alguien tiene vacaciones u otras ausencias previstas?

–Yo iba a tomarme dos días. Tengo un par de cuadros en una exposición en San Francisco, así que tengo que estar allí –dijo Rosa.
–Yo probablemente estaré un día fuera. El viernes o el lunes –dijo Francisco.
–Mis padres vienen a la ciudad la próxima semana. Estar con ellos mucho tiempo me pone de los nervios, así que ¡yo pensaba trabajar hora extra! –bromeó Diana.
Mientras hablaban, Carlos anotaba las posibles ausencias en la pizarra de la sala:

• Francisco
• Alberto (1 día)
• Rosa (2 días)
• Santiago
• Paula
• Diana

–Esta lista de ausencias será útil a la hora de determinar con cuántas historias nos podemos comprometer –explicó Carlos.

–Gracias, Carlos –dijo Francisco–. ¿Cuál es la siguiente historia más importante?
–A mí me gustaría la de jugar contra otra persona –dijo Diana.
–Estaría bastante bien –Alberto se mostró de acuerdo–. Nos permitiría programar la lógica que reconoce cuándo el juego se ha ganado. Podríamos añadir fácilmente la s funcionalidades de deshacer y rehacer mientras avanzamos la programación del primer motor de movimientos.
–Descompongamos en tareas Como jugador, me gustaría ser capaz de jugar contra otra persona desde mi ordenador –dijo Francisco.

En poco tiempo descompusieron la historia en las siguientes tareas:

• Producir tablero y gráficos simples [4]
• Dibujar tablero vacío [2]
• Hacer click en hexágono añade una ficha del color adecuado [4]
• El ordenador reconoce cuándo una ficha complete una figura ganadora [6]
• Diseñar las pruebas [6]
• Automatizar las pruebas [8]

–Y bien, como equipo, ¿pueden comprometerse a terminar esta historia además de la primera? –preguntó Carlos.
–Espera. ¿No está relacionada esta historia con otra que escribimos? La que dice Como jugador, quiero que el ordenador reconozca una figura ganadora. La hemos incluido como parte de las tareas –dijo Paula–. ¿Deberíamos quitarla?
–No sé. La hemos incluido por casualidad. Veamos si podemos comprometernos con el trabajo que hemos identificado. Si no podemos, podemos quitarla haciendo que los jugadores decidan cuándo han ganado –dijo Diana–. ¿Qué pensáis vosotros? ¿Podemos comprometernos con esta historia también?
–Sí –dijeron Alberto y Santiago a la vez.
–A mí me parece bien –dijo Rosa.
–Yo creo que no –dijo Paula.
–¿Qué estás pensando, Paula? –preguntó Carlos a la analista de pruebas.
–Entre las dos historias, yo tengo 50 horas. Ya sé que estamos suponiendo que tenemos 60, pero aun así me parece mucho para mí. Habrá que ver cómo va.
–Ten en cuenta que las tareas de pruebas no están asignadas solo a ti, Paula –dijo Carlos–. Todos pueden hacerlas. Si tú te retrasas un poco, se supone que los demás cogerán una de estas tareas.
–Desde luego. Yo hago pruebas habitualmente –dijo Rosa–. Quiero empezar algunos diseños de tableros esta iteración, pero eso puede esperar si se me necesita con las pruebas.
–Gracias, Rosa –dijo Paula–. Incluso sin ayuda, creo que puedo comprometerme con esta historia. Pero estoy cerca del límite.

La discusión avanzó con la siguiente historia: Como jugador, puedo jugar contra un motor débil que reconozca solo puentes. Cuando terminaron de discutir qué tareas estarían incluidas en esta historia y el esfuerzo asociado, el equipo había estimado la siguiente lista:

• El motor sabe buscar un camino de una esquina otra (es decir, un puente) [4]
• Identificar y automatizar las pruebas para diseñar un puente simple [6]
• El motor sabe hacer un puente entre obstáculos [12]
• Identificar las pruebas para hacer un puente entre obstáculos [6]
• Automatizar las pruebas para hacer un puente entre obstáculos [4]
• El motor sabe cuándo desistir de intentar un puente [8]
• Identificar las pruebas para desistir de intentar un puente [4]
• Automatizar las pruebas para desistir de intentar un puente [2]
• El motor sabe bloquear a otro jugador que intenta un puente [4]
• Identificar las pruebas para bloquear a otro jugador que intenta un puente [4]
• Automatizar las pruebas para bloquear a otro jugador que intenta un puente [4]
• El motor sabe elegir entre poner una ficha para intentar un puente o un anillo [16]
• Identificar las pruebas para elegir entre intentar un puente o un anillo [6]
• Automatizar las pruebas para elegir entre intentar un puente o un anillo [2]

–¿Podemos comprometernos con esta historia, también? –preguntó Rosa.
Francisco apreció que esta vez fuese un miembro del equipo quien preguntaba si se podían comprometer. Esto le gustaba mucho más que cuando tenía que preguntar él, como responsable de productos.
–Yo he ido sumando mientras hablábamos –dijo Santiago, levantándose de la silla–. Aquí está mi tabla:

–No sé el resto de vosotros, pero yo solo puedo comprometerme 4 horas diarias durante las próximas dos semanas –dijo Rosa.
–Por nuestra parte de programación, creo que podemos comprometer 2 programadores 30 horas cada semana –dijo Santiago.
–De acuerdo –dijo Alberto.
–Sin embargo, creo que ya no podemos asumir más carga –dijo Santiago–. Además, es mucha carga de pruebas solo para Paula.
–Yo ayudaré con las pruebas –dijo Rosa.
–Yo también –dijo Diana–. Probablemente no seré capaz de automatizar, pero sí puedo ayudar a especificar buenos casos de prueba.
–Con buena ayuda, yo me siento cómoda con este plan para las pruebas –dijo Paula–. Creo que nos podemos comprometer.
–¿Todos están cómodos con el plan? –preguntó Francisco.

Todos lo estaban.

–Me gustaría añadir unas cuantas tareas más a la iteración, solo para asegurarme de que las tenemos en cuenta –dijo Diana–. Necesito hacer unas cuantas más entrevistas a jugadores. Todavía no hemos comentado mi investigación de mercado, pero han salido algunas cosas que quiero profundizar. Estaría bien que yo dispusiera de unas 12 horas para seguir con la investigación. Puedo pasar el resto del tiempo con las pruebas, no obstante.
–A mí me gustaría hacer algunos bocetos sobre las fichas y los tableros, para hacerlos circular. Siempre se tarda mucho en tener buenos comentarios sobre el diseño. Me gustaría dibujar 4 tableros y 4 juegos de piezas. Necesito 4 horas para cada diseño, 16 horas en total.
–Me parece razonable –dijo Francisco–. Añadamos este esfuerzo.
–Así pues, con todo lo que hemos enumerado, ¿todos estamos cómodos y comprometidos? –preguntó Santiago–. Son 224 horas en total hasta ahora. Como somos 5 en el equipo (Alberto, Paula, Rosa, Diana y yo), está cerca de 5 horas al día por persona, si bien no somos intercambiables.
–Y además –dijo Carlos– es más probable que tengan que añadir trabajos en medio de la iteración, más que se eliminen trabajos.

Todos acordaron que el nivel de esfuerzo era el adecuado (ni muy duro ni muy suave). Todos se comprometieron como equipo a entregar estas 4 historias en dos semanas:

• 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, quiero que el ordenador reconozca una figura ganadora [2]
• Como jugador, me gustaría ser capaz de jugar contra otra persona desde mi ordenador [3]

Fantástico –dijo Francisco–. Es estupendo pensar que conseguiremos este grado de avance visible tan rápido. Normalmente se tarda más antes de tener algo para enseñar.

–Hagamos un descanso de 15 minutos –dijo Carlos–. Cuando volvamos, veremos el siguiente punto de la agenda: la planificación de las entregas. Quiero tener una estimación inicial sobre cuánto durará el proyecto.

Ir al siguiente post
Ir al post anterior

Este texto se ha traducido del libro:

Agile Estimating and Planning

Mike Cohn. Prentice Hall, 2012