Esta es la segunda, y última, parte del post que empecé el jueves pasado, sobre la reflexión de Cockburn, del que tendremos gran suerte de tenerlo como “Keynote”, el próximo 20 de octubre, en Madrid, en la Peopleware – Agile Management #PAM2016, sobre por qué deberíamos ver el desarrollo software como un juego colaborativo.
Viendo al desarrollo software como un juego colaborativo
Comenta Cockburn, aunque he sintetizado mucho (de nuevo, te recomiendo leer el artículo original), que la mayoría de los juegos son competitivos, como damas, las tres en raya, etc., son juegos en los que uno gana y otro pierde. Pero que, sin embargo, hay otros juegos que son colaborativos, como, por ejemplo, el desarrollo software.
El desarrollo software es un juego finito, que busca un objetivo con un grupo de personas cooperando. El juego es cooperativo, porque las personas en el equipo se ayudan entre sí para alcanzar la meta. Y, a la vez, es competitivo entre equipos, de diferentes empresas y, a veces, dentro de la misma empresa.
El objetivo del juego es crear un sistema de trabajo. Y, por lo general, el objetivo es crear un sistema lo más rápido posible, cumpliendo con otros factores o subobjetivos: facilidad de uso, costes, mínimos defectos, etc. Hay quien juega mejor y hay quien juega peor, hay quien tiene más técnica y quien menos.
Y se trata de un juego de recursos limitados: tiempo y presupuesto.
Además, es un juego finito, ya que termina oficialmente cuando se cumple el objetivo. A veces, el punto de terminación es la entrega del sistema.
Cockburn suele poner el ejemplo de la escalada, diciendo que el desarrollo de software se parece. Es un trabajo en grupo, con gente más experimentada que otra, con técnica, con objetivo. Y para muchos escaladores… el momento de llegar a la final de la subida, de terminar el juego, es triste, señala el final del juego, cosa que suele pasar con los juegos cooperativos en general. Comparado con el desarrollo de software, a veces los desarrolladores software no quieren terminar su diseño, porque entonces termina la parte divertida de su trabajo.
Hay un caso especial de “juego” en desarrollo software, que difiere de un desarrollo típico en empresa, y es el de los desarrollos “open source”, porque no es un juego de recursos limitados, ni es finito. Cualquier número de jugadores puede aparecer y el juego se abandona tan pronto como deja de ser interesante para los jugadores.
Terminando
¿Qué es el desarrollo de software? Si el desarrollo de software es realmente una ciencia, se puede aplicar el método científico a la misma, cosa que no sucede. Si es realmente ingeniería, entonces se podría aplicar técnicas de ingeniería conocidas, cosa que tampoco sucede.
Sin embargo, no es ninguna de las anteriores. Se trata de un «juego», un juego de velocidad y la cooperación dentro de equipo, en competencia contra otros equipos. Un juego contra el tiempo y un juego mental. Un juego en el que “apuestas” dinero para ganar.
Viendo el desarrollo de software como un juego que da mejores ideas de dónde gastar dinero, cómo estructurar sus equipos y cómo deberían asignarse esfuerzos.
El artículo original es mucho más extenso, incluida una sección de aquello que te conté en 2011, que debería haber una metodología para cada proyecto, que como ya está contado me lo ahorro y no extiendo más el post.
Espero que te haya gustado.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- OKRs sin Lado Oscuro, IA para OKRs y alternativas para evaluarlos - 25 julio, 2024
- Por qué seguimos usando técnicas ágiles anticuadas: Efecto Einstellung - 18 julio, 2024
- Cómo crear una IA personalizada (me llevó meses, pero te lo enseño en 2 min) - 11 julio, 2024