#3123 bueno, no sé si tendrá que ver. Desde hace 15-20 años hasta ahora la filosofía de desarrollo de software ha cambiado mucho. En mi empresa de desarrollo de software ya empleamos metodologías ágiles (scrum, kanban...) para las entregas de los proyectos.
Básicamente, el modelo anterior se basaba en el modelo de desarrollo en cascada, que contempla un único inicio y fin del proyecto entero (básicamente, "hacerlo tó de una" ):
El nuevo, con las metodologías ágiles basadas en los modelos de desarrollo iterativo e incremental, se garantizan pequeñas y periódicas entregas (suelen ser de 3 semanas) bien consolidadas que aporten valor al producto:
Esta utiliza mucho el control de versiones del código fuente, ya que podemos ver que el producto final se va actualizando en una "rama principal", pero mientras se va desarrollando pueden haber X subramas, una para cada parte del proyecto (modelos/assets, audios, texturas, animaciones, lógica general, librerías externas, definiciones y configuraciones según si es versión de desarrollo o no, y un larguísimo etc.). Imagino que para cada parte habrá diferentes equipos de trabajo con diferentes estudios y especialidades y posiblemente con un ritmo de trabajo diferente.
Es decir, se parte de unos análisis del proyecto iniciales (de requerimientos, de mercado, de casos de uso,) que suelen durar meses o años, en los que se enfoca todas las líneas generales del proyecto y ya algunos detalles. Después, los equipos de trabajo tendrán que desgranar todas las ideas que se quieren hacer en pequeñas tareas que cada miembro del equipo pueda asumir, luego desarrollarlas en una rama del código nueva, testearlas (con tests unitarios y con tests de integración con el resto del código) y finalmente integrarlas en la "rama principal". Todo esto cíclicamente cada X semanas a las que se le llama "sprint".
Cada sprint tiene un "Sprint planning" (al inicio, donde se detalla lo que se va a hacer durante el sprint) y un "Sprint Review" (al final, donde se ve si ha ido bien o lo que hay que mejorar) y a veces, "Sprint demo" (donde se enseña a la parte interesada, normalmente los jefes o directores del proyecto, lo avanzado durante el sprint). Además, cada día se suelen hacer "dailys", reuniones de equipo de unos 5/10 mins en los cada miembro comenta: 1) lo que hizo desde el daily anterior; 2) lo que va a hacer ese día; 3) si tiene algún bloqueo o problema que le impide seguir con su faena
Todo esto hace que para determinadas fechas no todo el trabajo esté completado y aún pueda estar pendiente de desarrollo, corrección o modificación.
Además, el control de versiones permite compilar versiones del juego, como las "tech preview" o "betas" con partes totalmente descartadas o desactualizadas (como las supuestas ramas de texturas o animaciones) pero sí con otras partes que les interese probar.
Si a todo eso le sumamos que en EE.UU. los programadores son carne de cañón y les inflan de tareas que tienen que cumplir antes en cada sprint, otros muchos son becarios/novatos que quizás son más lentos o les cuesta más resolver cualquier problema que se encuentren, el equipo de marketing gastándose los millones que no cobran los desarrolladores.... Ah y por supuesto no nos olvidemos que muy pocas empresa de desarrollo tienen o tienen buen equipo de testing, porque claro, quién narices va a pagar 30k anuales a un tío profesional por estar "jugando" a videojuegos todo el día.... y por lo tanto, aunque ese dinero se lo ahorran, el testing sigue siendo necesario, por lo que ¿qué mejor manera de obtener testing gratis y encima conseguir más ventas (y antes del lanzamiento) ofreciendo a los usuarios de probar una beta si reservan el juego?
Todo esto pa decir que sí, seguramente hasta pasado 1 año del lanzamiento no veamos un producto verdaderamente robusto
PD: esta filosofía de trabajo explica muy bien el éxito de productos como Fortnite o Warzone, que se basan en entregas que aportan valor al producto regularmente.