En el mundo de los proyectos informaticos en general, hay muchas , pero muchas formas de mantener el control de un proyecto. Desde ponerte unos milestones, pasando por cronogramas de tiempo en hojas de calculo, hasta trabajar con el conocido PMBOK para proyectos grandes (muy grandes). ¿Pero cuanto control necesitamos nosotros realmente , para poder terminar nuestro proyecto?

Los ejemplos mas claros sobre control de proyectos lo podemos sacar de los desarrolladores de juegos desktop. Por un lado es conocido el sindrome del "tiempo se acaba" que sufren muchos desarrolladores de juegos desktop, en donde por tratar de cumplir los objetivos en un cierto limite de tiempo, empiezan a correr con el proyecto, bajando la calidad de los mismos. Llendonos al otro extremo, existen aquellos proyectos que por falta de control en los mismos nunca terminan, lo que se conoce como Vaporware.

En lo personal el desarrollo de Xeno, lo estoy llevando en base a lapiz y papel y un metodo fotocopia de la Metodologia Scrum (la cual recomienndo le den una leida), solo que para una sola persona. Basicamente se trata de primero tener una idea no muy definida de lo que se quiere hacer (osea un RTS via web). Despues divides tu juego en varias partes iniciales (mis diferentes modulos) y te enfocas en una parte que te sea facil de hacer (o mas divertida de hacer) hasta que este usable por si sola (mi modulo de batallas). Ahora no tengan miedo de añadir, eliminar o modifcar estos modulos. Piensen en ellos como puntos de una ruta. Si llegado a un punto el camino esta bloqueado, pueden tomar otra ruta . Mi sugerencia seria que empiezen por la parte que tengas mejor definida en tu cabeza.

Ahora al trabajar en una seccion, la subdivido en versiones de la misma. Actualmente estoy en la 0.4.9 del modulo de batallas , ya casi para llegar a la version 0.5. Mi avance es subjetivo y no utilizo una metrica precisa, me quitaria flexibilidad. Simplemente calculo mentalmente que requerimientos debe de tener la version 0.5 para ser diferente a 0.4. Esto hace que la version 0.5 pueda tener muchos mas cambios que la version 0.4 o que por ejemplo la 0.6 tengas el doble de cambios o solo la mitad. Con tal que cumpla el objetivo y halla un avance, no hay problema. Eso si es importantisimo que cada una de las versiones sea funcional por si sola. Es decir que cumpla su objetivo.

El proximo post tratara de pequeños tips que pueden ayudar a llevar a cabo sus proyectos de cualquier clase. Eso si la intencion es aplicarlo a equipos pequeños de personas, que a mi parecer son mas eficientes que equipos de muchas personas. algo asi como el "Equipo de cirugia" que penso Fred Brooks en su ya clasico libro "The Mythical Man-Month".