No hace mucho, el propietario de una empresa de software, alguien que no estudió ingeniería informática, me preguntó si yo lo había hecho. Cuando le contesté afirmativamente me preguntó qué era lo que se estudiaba en la facultad en el ámbito de la gestión de proyectos y la ingeniería de software. El contexto donde la pregunta fué formulada era inmejorable: un curso sobre SCRUM y metodologías de gestión Agile. No era yo la única que había estudiado la carrera, éramos en el curso una muestra representativa en cuanto a educación universitaria en informática se refiere. No es extraño que una discusión muy interesante siguiera.
La duda era cómo se podía incluir metodologías Agile en el plan de estudios de una facultad de informática. Y no tiene fácil respuesta.
El propietario de la empresa comentó que a finales de los años 80, los que como él ya trabajaban en el mundillo informático, viendo el desorden que había en los proyectos, creyeron que los estudios de ingeniería de software eran la solución. Se decía que uno de los objetivos de la carrera era la de formar a profesionales que dominasen metodologías ordenadas e “hiciesen las cosas bien”.
En efecto, a finales de los 80 y durante los 90 (yo me gradué en 1999) se estudiaba el modelo Waterfall en las asignaturas de ingeniería de software. No es extraño y refleja los estándares de la industria al respecto. Tampoco niego que es mejor el Waterfall a no utilizar ninguna metodología. Pero en el momento en el que nos encontramos, en el que las metodologías Agile están copando el mundo anglosajón y buena parte del europeo, quizás llegue el momento de revisar qué se está estudiando en nuestras universidades.
Durante mi época de estudiante, los profesores provenían predominantemente del ámbito académico. No se habían encontrado con los cambios de opinión del cliente, con las modificaciones a última hora o con tiránicas restricciones de tiempo y presupuesto.
Una alumna más joven que el resto y que había acabado la carrera recientemente, comentó que un profesor sí les había hablado de SCRUM y XP. Curiosamente, dicho profesor provenía del mundo corporativo y compaginaba las clases con labores menos académicas. Así que actualmente se estudian las metodologías Agile en la universidad, averiguamos los más veteranos. Nos quedamos satisfechos.
Pero luego una duda me asaltó. Vislumbré un potencial problema, arraigado en la forma en la que se enseña en las universidades. Mi preocupación es cómo al enseñar las nuevas metodologías a alumnos que aún no están en el mercado laboral y que no se han peleado con los problemas que Agile intenta solucionar, puedan ellos entender realmente los beneficios.
Pese a alegrarme al oír como el mundo de la enseñanza refleja como las empresas se adaptan a la realidad utilizando nuevas metodologías, ¿podrán los alumnos entender el porqué están proliferando estas metodologías? ¿su verdadero valor?
¿Cómo se puede hacer entender a un alumno lo que se va a encontrar en el mundo de la empresa? ¿No sería útil un modelo de prácticas más adecuado a la realidad? Los informáticos trabajamos, la mayoría de las veces, en proyectos. ¿No sería una buena idea que los profesores actuasen como clientes, cambiando los requerimientos, rechazando proyectos, etc.? De esta forma, en sucesivas asignaturas, los alumnos aprenderían a usar SCRUM y verían las ventajas que realmente aporta.
Curiosamente un alumno contó que uno de sus profesores (allá en los 80!) le rechazó una práctica y cuando él protestó, le contestó: “¿Acaso esperabas que la primera versión me gustase?”. A él se le quedó grabada la conversación por lo inusual. Y después, cuando se sumergió en el mundo laboral y se dió cuenta que era el pan nuestro de cada día, le dio a la actitud del profesor el reconocimiento que merecía.
Si no se hace así, me asusta pensar que los estudiantes verán SCRUM o XP como el modelo Waterfall. Una manera como otra de hacer las cosas. Le planteé mi duda a la chica que había estudiado XP en la facultad. Y ella me respondió que, precisamente, así lo había visto. Como una anécdota.
