Spikes en Scrum

Un Spike en Scrum es una tarea de investigación que se compromete en un Sprint. Es una manera excepcional de trabajar cuando sentimos que no tenemos suficiente información para darle al cliente una expectativa realista de lo que hay que hacer. El objetivo del Spike es averiguar esa información para poder bajar a tierra esas expectativas y poder realizar una estimación adecuada a la cual el equipo se pueda comprometer en la siguiente reunión de planeamiento del próximo Sprint. El resultado de la tarea es un documento con la información obtenida en la investigación.

Los Spikes son una muy buena opción para que los equipos verifiquen cosas que no conocen y necesitan conocer para entender la complejidad de cierta funcionalidad para que pueda ser estimada apropiadamente o para simplemente averiguar si algo es técnicamente posible o no.

Los Spikes también son llamados Tracer Bullets (balas trazadoras), ya que te indican una dirección a donde apuntar o a donde ir. La única diferencia entre estos conceptos es que los Spikes tienen una duración preestablecida (time-boxed) y no se trabaja teniendo en cuenta que el resultado va a ser utilizado en el proyecto directamente, mientras que los Tracer Bullets no tienen límite de tiempo y su resultado va a ser utilizado.


Una utilización de los Spikes que apliqué hace poco, es en una relación de dependencia técnica con el cliente. Nosotros teníamos que desarrollar cierta funcionalidad, el front-end de una página web, teniendo en cuenta APIs del cliente. La experiencia siempre nos indicó que esas APIs estaban incompletas, su documentación no era suficiente o que no cumplían el propósito para lo que se las iba a utilizar. Para dejar de errar en las estimaciones de estas funcionalidades dependientes, utilizábamos Spikes para explorar a fondo estas APIs, mejorar su documentación, pedir que las modifiquen para adaptarse a lo que íbamos a construir, y dejar un documento completo para que en el siguiente Sprint puedan ser estimadas y posteriormente desarrolladas correctamente.

Agile Game Development with Scrum

Agile Game Development with Scrum de Clinton Keith se basa en la aplicación de metodologías ágiles: Scrum (principalmente), Lean y Kanban en la industria del desarrollo de videojuegos.

Básicamente este tipo de proyectos tiene cuatro fases definidas: concepto, pre-producción, producción y post-producción o cierre. Sin utilizar metodologías ágiles, estos proyectos sufren muchos problemas.

Por ejemplo, se gasta mucha plata para tener un prototipo jugable y darse cuenta si el proyecto vale la pena o no. Aplicando Scrum, es posible tener entregas parciales jugables que nos dan una idea temprana de a donde se dirige el juego y si vale la pena continuar el proyecto (cuanto antes nos enteremos de esto, mucho mejor).

Luego es muy común que en las etapas de producción se descubra que ciertos conceptos que no se cerraron en pre-producción, temas no terminados o evaluados al 100%, causen mucho retrabajo y la necesidad de cortar ciertas partes del juego por temas de presupuesto. Lo que se logra con esto es que se termine lanzando al mercado un producto pobre. Si se hubiese explorado un concepto a fondo, sin dejar deudas a futuro, como se sugiere en las metodologías ágiles, se podría haber lanzado un producto mucho mas fuerte. Un ejemplo hipotético: para un juego en pre-producción se estableció que el personaje principal puede saltar 10 metros. Sin probar esto, se empezaron a producir los niveles del juego teniendo esto en cuenta. Cuando un productor juego la primera versión del juego (tarde si no se trabaja ágilmente) y vio que este largo era ridículo, se habían creado un montón de niveles teniendo esto en cuenta y el retrabajo va a ser muy costoso. Otro ejemplo puede ser trabajar teniendo en cuenta que las paredes pueden romperse, para luego descubrir que la tecnología actual no soporta eso. Desastroso en ambos casos.

Otro error al dejar deudas a futuro son las interminables "death marches" en el cierre de un juego, donde se hace mucho overtime para cerrar defectos que son mucho mas costosos de cerrar al final del proyecto que si se resolviesen durante la iteración donde son creados. Las metodologías ágiles sugieren terminar lo que se comienza a desarrollar y no dejar los defectos a futuro. Se suelen dejar defectos para un último sprint de estabilización y polishing, siempre que el riesgo de retrabajo sea mínimo.

Muy buen libro para reforzar los conocimientos de Scrum y enterarse bien como se desarrolla un típico proyecto de desarrollo de videojuegos, y como se puede mejorar utilizando metodologías ágiles.

Mejora Continua en Scrum

Scrum no es un proceso, es un esqueleto o framework muy simple que está preparado para que el equipo mejore iteración a iteración. No describe como llevar a cabo un proyecto, sino nos describe un conjunto de reglas y prácticas para administrar o gerenciar efectivamente un proyecto.

Luego de implementar scrum en un proyecto, en la segunda o tercera iteración, tuvimos ciertos problemas y un miembro del equipo me comento que hubiese preferido contar con un experto en scrum para que todo sea más fácil y que las cosas hubiesen salido bien desde el primer momento.

Luego de reflexionar sobre ese comentario, me doy cuenta que realmente aprendimos mucho todos al comenzar a implementar con Scrum sin tener gran experiencia en el proceso. El aprendizaje que logramos al chocarnos con ciertas ideas y preconceptos quedo mucho más aferrado a nosotros por haber descubierto nuestros errores en equipo y aplicar y percibir las mejoras logradas.

Teniendo siempre presente los lineamientos de Scrum, respetando las retrospectivas y tomando acciones para mejorar sprint a sprint, se puede mejorar y apreciar el cambio rápidamente. Es muy valioso ver al equipo estimar cada vez mejor en las reuniones de planeamiento de cada sprint, descubrir las cosas que no tuvieron en cuenta.

Scrum permite ir rápido lentamente. Las mejoras que valen la pena surgen cuando uno se toma el tiempo necesario para darse cuenta cómo se puede ir más rápido. El framework que Scrum provee ayuda a reforzar esta idea.