En The Game Kitchen empezamos a aplicar Scrum desde hace ya 7 años, y con el paso del tiempo lo hemos ido haciendo nuestro: nos quedamos solo con aquellas prácticas que hacen que el proyecto fluya y se disfrute del proceso.
¿Qué es SCRUM?
No me quiero extender mucho en explicar los conceptos básicos porque ya han sido sobradamente descritos a lo largo y ancho de internet, pero al menos podemos comentar lo que yo creo que son los pilares del método:
- El principal problema que viene a solucionar esta metodología es el siguiente: Al no tener el ser humano la capacidad de adivinar el futuro, toda planificación hecha al inicio es necesariamente imprecisa. Aún peor, en un proyecto largo, conforme avanza el tiempo, la planificación va sirviendo cada vez menos y se va recurriendo más a la improvisación.
- En vez de contemplar un desarrollo al completo de muchos meses, la metodología propone cortar el desarrollo en N periodos de poca duración (típicamente de 1 mes). Esos períodos se llaman Sprint.
- La metodología propone un protocolo a desarrollar durante cada Sprint, y que por tanto se repite una y otra vez hasta que el proyecto se termina.
- La pieza clave del protocolo es el Sprint Meeting, celebrado entre el fin de un sprint y el comienzo del siguiente. El objetivo de esta reunión es crear una planificación para el siguiente sprint, para la que se haya tenido una visión realista del estado del proyecto (tras el sprint anterior) y de los nuevos requisitos, oportunidades o necesidades que hayan surgido por el camino.
La importancia del incremento en desarrollo de videojuegos
En cada nuevo sprint debes dedicar lógicamente un cierto grado de esfuerzo a meter más contenido y features nuevas al juego. Pero es muy importante también dedicar un cierto porcentaje de esfuerzo a iterar aquello que ya está en el juego pero que todavía no funciona al nivel esperado. Para decidir a qué elementos le vamos a dedicar esfuerzo durante el nuevo Sprint es de vital importancia empezar el meeting jugando al juego para ver el estado real del mismo. La última build del juego hecha al finalizar el sprint anterior, se denomina el incremento.
Es importante garantizar que el incremento contiene una demostración de todas las features que se hayan desarrollado durante el sprint. Para conseguirlo, es importante que el equipo al completo pase a tiempo del modo “añadir cosas” al modo “comprobar que todo está ahí y está funcionando” con tiempo suficiente. Al final del artículo comentamos más detalles, como parte de la preparación del siguiente sprint meeting.
Beneficios colaterales de la presentación del incremento
Los miembros del equipo siempre tienden a trabajar muy concentrados en sus propias tareas. Ésto hace que se vaya perdiendo la noción de lo que está pasando más allá de sus propias pantallas de ordenador. Transcurridas una o dos semanas, es normal que nadie tenga ni idea de cuanto lleva aportado cada compañero, ni del avance global que ha experimentado el proyecto en su conjunto.
La presentación del incremento es un momento genial para que todos los miembros del equipo tengan una visión holística del progreso real del proyecto, y normalmente observamos que todo el mundo se siente motivado al ver todo lo que se ha avanzado en equipo.
Mindsets de planificación y ejecución
A través de la experiencia hemos encontrado que la verdadera productividad se alcanza cuando todo el mundo llega a primera hora y tiene muy claras las tareas que tiene que hacer durante el día, priorizadas por importancia o factores de dependencia con otros miembros del equipo. Por el contrario, si después de cada tarea entramos en el estado mental de preguntarse ¿y ahora qué me toca? estaremos seguramente operando por debajo de nuestras capacidades.
Para conseguir eso, tenemos que dejar la planificación lo más resuelta posible durante los sprint meetings:
- Ordenar las tareas por importancia.
- Ordenar las tareas por dependencias con otros miembros del equipo:
- Las tareas de audio, arte y programación tienen los requisitos de diseño bien definidos.
- Las tareas de diseño de niveles, tiene los assets de arte, audio y programación disponibles.
- Definir tareas atomizadas y descritas con precisión.
Duración de los Sprints
Nuestros sprints normalmente duran:
- Un mes: Sólo durante los dos o tres meses iniciales de proyecto. Estas etapas requieren mucho trabajo de investigación y experimentación, y tampoco es posible tener un incremento ejecutable con el que trabajar, así que tener reuniones con todo el equipo más frecuentes tampoco tendría un beneficio muy claro.
- Dos semanas: Una vez superadas las etapas iniciales, la mayoría de nuestros sprints son de esta duración. Hemos encontrado que es el equilibrio perfecto entre la cantidad de tiempo de producción que se invierte en reuniones, y la calidad de la planificación.
- Una semana: Cuando nos acercamos al cierre de una build para una entrega. La naturaleza de las tareas pide iterar más y cerrar características ya presentes, en vez de introducir nuevas.
- Un día: Para los últimos días de una entrega. Jugamos al incremento (compilado la tarde anterior) y decidimos cuál es la mejor estrategia para aprovechar ese día de cara a tener la mejor build posible al final del día.
La serie de artículos sobre Scrum y desarrollo de videojuegos continua con:
