Este es el 3º artículo de una serie sobre Scrum y desarrollo de videojuegos. Los artículos anteriores son:
- Introducción a la metodología (Scrum y desarrollo de videojuegos 1)
- Cómo sacarle provecho al Sprint Meeting (Scrum y desarrollo de videojuegos 2)
El día a día
Cada miembro del equipo empieza su jornada en Hack’n’Plan, revisando cuáles son las tareas que le tocan para hoy. Después, hacemos un “daily” o “stand-up” en nuestro server de Discord, todo el mundo tiene que leer lo mensajes de los demás, y escribir uno propio en el que resuma: ¿qué hice ayer? ¿qué voy a hacer hoy? ¿qué necesito de los demás?
Ejemplo del «stand-up» en Discord
De la última parte se desprenden las dependencias, y si tienes alguna con alguien o alguien la tiene contigo, te pones de acuerdo con esa persona, intentando encajar esa necesidad en tu planificación diaria.
Después, cada uno coge su primera tarea en Hack’N’Plan y la mueve de la columna “Planned” a la columna “In Progress”. Cuando crees que has terminado con tu tarea, y ya está subida al repositorio de código, volvemos a Hack’N’Plan y la movemos a la columna “Testing”. Por último hay que asegurarse de que se queda asignada a la persona encargada de comprobarla, que normalmente es un diseñador (aún no tenemos testers en el equipo).
Planificación de un Sprint de Blasphemous (mostrando sólo tareas de los programadores).
Nuevo incremento y preparación del siguiente Sprint meeting
Importancia de una buena integración
Durante todo el Sprint los miembros del equipo han estado trabajando cada uno en lo suyo, y es importante que se garantice que todos los elementos introducidos por cada uno trabajan bien en conjunto. Para conseguirlo el equipo necesita tiempo suficiente para realizar una buena integración.
Lo que hacemos nosotros es sacrificar un día de producción para hacer una buena integración y preparación del siguiente Sprint Meeting. El último día de cada Sprint, suele ser un viernes, lo dejamos exclusivamente para garantizar la integración correcta de todo lo que se ha añadido, mejoras de carácter cualitativo, y “hacer los deberes” para poder determinar muy bien las tareas durante el siguiente Meeting.
Generación del incremento candidato
Siguiendo con el ejemplo, si el último día es el viernes, el jueves a última hora procuramos que haya una build candidata que incluya el incremento. Asumimos que van a fallar algunas cosillas en esa build, y durante el viernes se le dará un repaso, haciendo los arreglos necesarios sobre la marcha,hasta que todo funcione como es debido. Recordemos que es imprescindible que se pueda jugar a todo el incremento de forma analítica.
Peer review
El último día también se aprovecha para que cada miembro del equipo analice el trabajo de los demás. Se trata de buscar y proponer mejoras en la forma que se haya implementado cada característica, con la idea de detectar elementos que en el futuro vayan a convertirse en problemas.
Buscaremos cosas como: código sin documentar o implementado a la carrera, sin pensar en la escalabilidad, nomenclaturas mal aplicadas, malos entendidos en la comunicación de requisitos, o simplemente esas “ideas felices” y/o “ñapas” a las que todos recurrimos de vez en cuando.
Entre las cosas que se detecten, algunas de ellas se les podrá dar solución durante el mismo viernes, o simplemente se quedará anotada la necesidad de resolverla durante el siguiente sprint.
El incremento fuera de la build
A veces hay progresos interesantes que no se producen dentro de la build del juego, como por ejemplo los de narrativa, arte concept o bocetos musicales. Es importante recordar a las personas indicadas del equipo que preparen una versión “enseñable” para que puedan transmitir ese progreso al resto de compañeros del equipo. Por esto entendemos un paso tan sencillo como exportar a JPG algunos de los PSD, o hacer un render de un modelo 3D, y otras veces cuando hay avances de diseño más complicado hay que llegar hasta el punto de hacer una presentación PPT sencilla pero efectiva.
Archivos que componen un incremento
Histórico de incrementos
Nuestros sprints los nombramos como AÑO-MES-LETRA, es decir 2018-1-A sería el primer Sprint del mes de Enero. A uno o dos días del fin de sprint, se crea en nuestro control de versiones una carpeta llamada por ejemplo \trunk\scrum\2018-1-A, que usaremos para dejar una copia de la build del incremento, los bocetos de arte y audio, y otros documentos necesarios para transmitir a todo el equipo el estado del progreso.
Además de que es conveniente tener todos los materiales para la reunión reunidos en un único sitio, también es útil para generar materiales de marketing (making offs, etc) en el futuro, cuando esté próxima la fecha de lanzamiento del juego.
La serie de artículos sobre Scrum y desarrollo de videojuegos continua con:
- Haciendo la metodología más divertida (Scrum y desarrollo de videojuegos 4) (PROXIMAMENTE)
