Ciclo de vida de los proyectos

February 24, 2012

Una de las cosas que más he echado de menos de mi formación en mi vida profesional es la importancia del ciclo de vida de los proyectos. Durante la carrera, al menos en la ULL, todo se centraba en conseguir desarrollar un (pequeño) proyecto. Durante los primeros años se centraban en enseñarnos a programar, después nos enseñaron algunas metodologías de programación clásicas, como Métrica 3 o el modulo en cascada, y en algunas asignaturas nombraron de pasada las metodologías ágiles. Sólo en unas pocas asignaturas se desarrollaban proyectos algo mayores, y en estos casos el objetivo se centraba más en enseñarnos algún área de conocimiento como procesamiento de lenguajes.

Sin embargo al llegar al mundo laboral, con esa idea interiorizada de conseguir sacar el proyecto adelante sin importar la calidad y mantenibilidad del código escrito, me topé con que, en la vida real, un proyecto siempre había que modificarlo a posteriori. Cuando tienes interiorizada dicha idea y tienes que modificar un proyecto sigues haciendo lo mismo, con lo que pones un parche. Después de un número de parches el código es una superbazofia que no hay Dios que mantenga. Es lo que se conoce como Legacy Code (código que cumple las expectativas del cliente, pero es caro de mantener). Si se prestase más atención a la calidad de código, en lugar de ir poniendo parches sin ton ni son, se refactorizaría, haciendo que las modificaciones se integrasen dentro del proyecto de un modo más natural y por tanto permitiendo una mejor mantenibilidad. Esto es Beautiful Code. Es muy difícil enseñar esto en una facultad, pero no por ello debería dejar de intentarse.

Estudié cuatro asignaturas relacionadas con la ingeniería del software (es posible que me equivoque en algún nombre):

  • Ingeniería del software de gestión I (donde nos enseñaron métrica, el modelo en cascada y otras metodologías clásicas)
  • Ingeniería del software (aquí no tengo claro lo que aprendí)
  • Gestión de sistemas de información (utilizando el PMBOK como base nos enseñaron cómo se debían gestionar los proyectos de los sistemas de información)
  • Laboratorio de ingeniería del software (desarrollamos un pequeño proyecto en equipos para una empresa)

De todas estas Ingeniería del software es probablemente una de las asignaturas menos útiles que he cursado nunca, el resto en general son bastante útiles, pero, al ser asignaturas cuatrimestrales, no se llega a comprender cómo de importante es el ciclo de vida.

Ahora mismo estoy siguiendo un curso llamado Software Engineering for Sofware as a Service. En él se enseñan metodologías ágiles, para comprender el ciclo de vida, es mejor tener un ciclo corto. Creo que este curso podría ser un ejemplo a seguir para alguna de las asignaturas que he mencionado con anterioridad. Por un lado se desarrolla un proyecto de manera iterativa, por otro lado un cuatrimestre permite ocho iteraciones de dos semanas o dieciseis iteraciones de una semana. Además las metodologías ágiles se están consolidando cada vez más en proyectos con clientes, puesto que se adaptan mucho mejor al cambio y los clientes nunca saben lo que quieren. Si lograsen que los alumnos de las distintas asignaturas relacionadas con ingeniería del software pudieran trabajar juntos asumiendo en cada caso el rol que corresponda en el equipo a la asignatura que estén cursando estoy seguro de que sería tremendamente positivo.