En este artículo se analiza el impacto en el desarrollo de videojuegos de la metodología ágil. Es un sector con algunas particularidades muy concretas, y coincido con el autor prácticamente en casi todo, aunque lo que hace es, básicamente, criticar los peores aspectos de la ‘ola ágil’.
Estoy completamente de acuerdo en su desprecio por el ‘fanatismo’… una cosa es que los conceptos teóricos del modelo de desarrollo ágil me convenzan, y otra cosa es utilizar Kanban o Scrum como palabras mágicas que van a resolver todos los problemas y nos llevan al paraiso en la tierra.
Primero, considero mucho más importantes los principios del manifiesto ágil que las metodologías que se desprenden de él. Me gusta el concepto de dar más prioridad al software funcional que a la documentación, pero eso no es una carta blanca que permite no documentar porque el proceso lo dice. No estoy diciendo con esto que las metodologías ágiles sean erróneas, sino que es muchísimo más importante, en mi opinión, tener un conocimiento de las ideas que hay detrás, y después desarrollar tu propia metodología, recogiendo las cosas que te resulten más útiles de unas u otras.
Como bien dice el autor del artículo, parece que ha llegado el momento en el que ‘Ágil’ y ‘Scrum’ son términos intercambiables, es decir, que la gente se queda con la parte ‘brillante’, que le da más juego a su currículum, y no con la teoría que hay detrás. Creo que es muy común haber salido de un proyecto manejado con los parámetros del desarrollo clásico tan espantado, que buscas cualquier cosa que te prometa que el siguiente proyecto va a salir mejor… como ha habido (o sigue habiendo) una moda de Scrum, te agarras a él, sin conocer muy bien de qué va la película, aferrándote al término como si fuera una varita mágica.
Me parece mucho menos importante seguir los preceptos del Scrum que utilizar las herramientas que se proponen como ayuda:
…esas cosas, que tienen un impacto directo y fácilmente mensurable en el desarrollo del proyecto, y menos importante el hecho de dibujar en un tablón las cosas de una forma o de otra.
Hablando de desarrollo basado en tests, hay una parte interesante del artículo, en la que se menciona un estudio de Microsoft en el que se analizan datos empíricos de sistemas desarrollados utilizando el desarrollo basado en tests y otros en los que no. Creo que son relevantes los resultado. Cito (y traduzco yo mismo):
Los resultados de los casos de estudio indican que la densidad de errores pre-release [..] descendió entre un 40 y un 90% comparado con proyectos similares que no usaron TDD (desarrollo basado en tests). Además de esto, los equipos experimentaron un incremento entre el 15 y el 35% de tiempo de desarrollo inicial desde la adopción del TDD.
Quiere decir que, al utilizar la TDD el tiempo de desarrollo en la fase inicial aumenta entre un 15 y un 35%, comparado con una disminución del nº de defectos muy superior. Para el autor del artículo, este incremento en el tiempo inicial de desarrollo no compensa ante el nº de errores eliminados, y en esto no estoy en absoluto de acuerdo. Es probable que nuestra diferencia de opinión se basa en que trabajamos en productos software distintos: para nosotros, cada sistema que desarrollamos está pensado para que nunca (mientras el cliente quiera) dejemos de trabajar en él, mientras que el desarrollo de un videojuego es un proyecto que tiene una fecha límite de presentación. Nosotros siempre pensamos en los proyectos a medio y largo plazo, y para esto, tener una buena suite de tests regresivos desde el principio es fundamental (de hecho, en proyectos antiguos los echamos de menos enormemente).
Finalmente, en lo que sí estoy de acuerdo, y lo que más me preocupa, es su afirmación de que el mayor problema de las empresas que afirman utilizar desarrollo ágil es que es muy fácil usarlo como una excusa para no hacer una buena dirección del proyecto, para no hacer planificación o para hacer una gran bola de barro teniendo la excusa de que “nosotros hacemos Scrum, así que tiene que funcionar”.
