Diario de Programación

Hace unos días un compañero mio acudió a las charlas de Autentia + Agile Spain: Introducción a Scrum y le dieron cinco o seis mazos de cartas para la planificación de tareas por poker. Hoy, un poco a modo de prueba, hemos hecho el juego con un par de tareas para ver cómo iba el asunto. Por si alguien no lo conoce, cuento primero en qué consiste el juego de planificación con cartas. Después, cuento la experiencia concreta, que ha sido muy positiva, sobre todo por una utilidad imprevista que tiene este juego.

En el juego de planificación por poker, cada desarrollador tiene un mazo de cartas en el que aparece en cada una de ellas un número de una serie de fibonnaci (es decir, 1, 2, 3, 5, 8, …). Estos números representarán el tiempo (en horas o días) que cada uno de los desarrolladores piensa que se va a tardar en implementar una tarea concreta.

Al empezar el juego, se coge una de las tareas a hacer y se habla de ella hasta que queda concretada y se sabe exactamente qué es lo que hay que hacer y lo que no hay que hacer en esa tarea. Una vez hecho esto, cada desarrollador pone una de las cartas con el tiempo que estima encima de la mesa, pero boca abajo. Cuando todos han echado carta, se destapan. Se coge al que ha echado la carta más alta y al que ha echado la carta más baja para que expliquen por qué creen que esa tarea va a llevar tanto tiempo o tan poco. Una vez explicado, todos vuelven a echar las cartas boca abajo y se repite el proceso, hasta llegar a un consenso.

Pues bien, aquí nuestra experiencia.

Cogemos como tarea una lista de ciertos datos que tenemos en nuestra aplicación. Hay que implementar esa lista de forma que esos datos se guardan en memoria en un ejecutable que ya tenemos y que hace de servidor. Otros ejecutables con interface gráfica de usuario se conectan por socket con el servidor y obtiene dicha lista para pintar en un JTable. Hay botones de crear, editar y borrar. Los de crear y editar abren un formulario con unos diez campos simples (enteros, fechas, cadenas de texto, etc). Ya tenemos la estructura de la aplicación echa de hace tiempo y los sockets abiertos y funcionando. Sólo hay que hacer la lista en el servidor, los mensajes concretos que van y vienen por el socket y la parte de interface gráfica de usuario. Decidimos que no hay persistencia en base de datos de momento.

Echamos las cartas boca abajo y luego destapamos. Yo, que fuí el más optimista, puse tres días. El siguiente puso 5. Un compañero que lleva unos pocos meses con nosotros y de momento está aterrizando sacó la carta de "no tengo ni idea". Y el último compañero puso 20 días.

El compañero de los 20 días fue el primero en hablar. El conoce mejor el proyecto y estaba teniendo en cuenta para esta lista que, por un lado, hay unas ayudas disponibles para el usuario que le ayudan a decidir los valores a introducir en los formularios y contaba con que había que hacer las ayudas. Nuestro servidor, además, debe admitir la creación de datos en esa lista de otro servidor externo, también por socket, y los datos enviados por ese servidor son prioritarios sobre los del usuario, por lo que el usuario no puede borrar o editar dichos datos (es decir, habría que añadir algo de privilegios para la edición/borrado de cada uno de esos datos). Mi explicación, por supuesto, fue que no había considerado que hubiera que hacer ahora todo eso, sino limitarse solamente a usuario con servidor.

Aclaramos el punto de que de momento no tenemos en cuenta las ayudas ni el servidor externo. Volvemos a votar y esta vez salen dos cartas con cinco días (yo incrementé un par de días por otros detalles que había dicho mi compañero) y otras dos cartas de ocho días. Como finalmente uno de los desarrolladores es novato y posiblemente sea de los que más desarrollo vaya a hacer en este tema, acordamos los ocho días.

Y es en este momento cuando me he dado cuenta de una cosa muy importante de la planificación por poker. Cuando lo leí inicialmente, ví una serie de ventajas, como el que se estime entre varios o el que de alguna forma "se obliga" a "mojarse" con los tiempos a todos, la gente es menos reacia a echar una carta boca abajo que a decir un tiempo de viva voz, sobre todo si es novato y le toca el primero en hablar. Sin embargo, la gran ventaja no es ninguna de estas.

La gran e inesperada ventaja de este juego es que ayuda claramente a definir/decidir qué es exactamente lo que hay que hacer en la tarea y a asegurarnos que todos hemos entendido lo mismo. A pesar de haber hablado antes de ella, entre lo que entendí yo y lo que entendió mi compañero de los 20 días había una gran diferencia. Precisamente este juego de planificación ha ayudado claramente a que el alcance de esa tarea quedara mejor definido y lo que es más importante, a asegurarnos que todos hemos entendido lo mismo.

Pero no es oro todo lo que reluce, lo de las cartas tiene una pega importante: Hicimos la reunión en una sala que da a un pasillo y la sala tiene mucha cristalera. Cualquiera que pase y no sepa de que va el tema, pensará que estamos jugando al tute, a la brisca, a la escoba o cualquier otra cosa….

Ahora en serio, esta vez fue un poco de prueba, pero creo que vamos a empezar a usarlo por sistema, no ya por la planificación de tiempos en sí, sino por asegurarnos que todos entendemos lo mismo en cada tarea.

Entradas relacionadas:

• No hay entradas relacionadas.