Haciendo la metodología más divertida (Scrum y desarrollo de videojuegos 4)
Este es el 4º y último artículo de 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)
- Gestionar el día a día del desarrollo (Scrum y desarrollo de videojuegos 3)
Aligerando el peso de la metodología
Si ya conocía Scrum o tienes tu propia forma de aplicarlo, quizás hayas notado que no hemos ni mencionado algunos de sus principios y conceptos. A pesar de que empezamos aplicando “Scrum de libro”, con el paso del tiempo hemos llegado a descartar por completo algunas de las prácticas más tediosas y que no tenían un beneficio directo para nosotros:
- Product Owner: Cuando dejamos de trabajar para clientes externos, la figura del product owner dejó de tener sentido. La inteligencia colectiva del equipo hace las veces de product owner.
- Project Backlog: Para nosotros mantener un backlog de proyecto que tuviera algún sentido se fue haciendo cada vez más difícil, así que acabamos por eliminarlo. Tenemos un milestone llamado Backlog, pero lo usamos para aparcar tareas que se han decidido aplazar hasta nuevo aviso. La función del Project Backlog como fuente de tareas para el Sprint Backlog la puede cumplir el productor (apoyado en su cronograma de alto nivel), así como los leads de arte, diseño y programación.
- Estimación de tareas, planning poker, etc: No hemos conseguido que ninguna estimación de tareas nos llegue a funcionar, así que simplemente lo hacemos a ojo: cuando están las tareas repartidas entre los miembros del equipo y priorizadas, cada uno avisa de si hay demasiadas, o demasiado pocas, y se actúa en consecuencia.
- Scrum master: La figura del Scrum master solía ser una de mis responsabilidades en el pasado. Hoy por hoy, la cultura agile está tan asumida en el equipo que apenas tengo que intervenir como Scrum master.
La importancia de mejorar continuamente los procesos
Nuestro primer videojuego basado en una IP propia, The Last Door, nos enseñó a trabajar cómo lo hacemos hoy en día. Al ser un desarrollo episódico, nos generaba una oportunidad de oro entre episodio y episodio para analizar nuestros procesos y poder así mejorarlos. Más tarde aprendí que eso que haciamos se llamaba Critical Stage Analysis, y es un tipo especial de post-mortem que en vez de al final, se hace durante el desarrollo del proyecto. En un artículo futuro hablaremos más sobre como hacer un C.S.A. en vuestros proyectos.
De momento, no me gustaría dejar pasar la oportunidad de poner en valor la oportunidad que tenemos durante el propio sprint meeting de volvernos «meta» y tener un pequeño debate sobre cómo estamos aplicando la metodología. Cuando detectéis que algo no marcha bien, podéis aprovechar el momento entre Sprint y Sprint para decidir que vais a probar a hacer algo de forma diferente: ¿que tal si el siguiente sprint lo hacemos más corto/largo? ¿que tal si incluimos estos detalles que echamos de menos en la descripción de las tareas?
Para saber más
En este libro encontraréis todos los detalles y prácticas de Scrum y otras metodologías ágiles aplicados al desarrollo de videojuegos. Su lectura hace unos 7 años puso los cimientos de cómo afrontamos hoy por hoy los desarrollos. No puedo más que recomendartelo si te interesa profundizar en el tema.
Conclusiones
Esperamos que os sirva de ayuda conocer cómo trabajamos en The Game Kitchen. Este proceso desde luego no tiene porqué ser el mejor para vuestro equipo, no es más que a lo que hemos ido llegando sprint tras sprint, parándonos cada cierto tiempo a preguntarnos qué nos funciona y qué no, y probando cosas nuevas.
Os animamos a compartir vuestras experiencias y prácticas propias en este campo, utilizando los comentario del artículo. ¡Seguro que es muy ilustrativo!
