El trabajo final de la materia consiste en resolver una problemática de negocio a partir de la implementación de una solución basada en software. Hasta aquí puede sonar como tantos otros trabajos de una materia de una carrera de sistemas. Pero en nuestro caso hay un par de cuestione (que tal vez tampoco son tan novedosas) que a los alumnos les cuestan bastante.

La primera cuestión es que no hay «un enunciado» ni una lista de funcionalidades, hay un «cliente» (rol ocupado por uno de los miembros del equipo docente) con un problema de negocio, los alumnos deben relevar el problema y plantear un proyecto para solucionarlo. Son los alumnos los que tienen que identificar las funcionalidades, darles forma de stories validarlas con el cliente, diseñar, codear, testear e implementar. Parece una desafío usual en una carrera de sistemas pero a pesar de eso muchos alumnos no saben por dónde empezar. Incluso cuando se supone que en materias anteriores ya vieron técnicas para lidiar con relevamiento y modelado de dominio.

Otra cuestión es que el proyecto deben desarrollarlo en 3 semanas, con iteraciones semanales al estilo XP. Eso implica planificar el trabajo a alto nivel (release plan) y también semana a semana, ejecutar dando visibilidad en un esquema de entrega continua y al final de la semana revisar lo realizado tanto a nivel producto como a nivel proceso. Insistimos en que el trabajo sea time-boxed lo cual implica que en caso de retrasos negocien/gestionen alcance. No hay problema en que no logren completar el plan de la semana siempre y cuando lo gestionen. No puede ocurrir que prometan X y luego caigan sorpresivamente a la revisión con menos de X. Seguir este proceso les cuesta muchísimo, en parte porque no tienen práctica en planificación, es un tema que tal vez vieron en alguna materia anterior pero casi sin práctica. Lo otro que suele constarles mucho es la negociación/gestión del alcance. En general si planifican X, hacen lo imposible por cumplir con X cuando muchas veces sería mucho más conveniente gestionar un recorte de alcance o simplemente avisar el cliente que no llegarán a cumplir con el plan. Incluso en ocasiones dejan de lado las buenas prácticas (modularización, testing, convenciones, etc, etc) lo cual no hace más que aumentar/generar deuda técnica que deberán pagar en el corto plazo.

Una de las cuestiones más novedosas para los alumnos es tener que lidiar con dos ambientes cloud, uno de pruebas y otro de producción. Esto en general no lo han hecho en ninguna materia. Esto por momentos se convierte en un gran desafío cuando algo les funciona localmente pero no en los ambientes cloud. Si bien les damos la infraestructura pre-armada y acceso a un log centralizado, muchas olvidan escribir mensajes de log con cual es como si estuvieran a ciegas. Esta cuestión de «build for operations» es uno de los temas de la materia y no esperamos que traigan conocimientos previos.

Finalmente lo que más me llama la atención es cuando los alumnos no aplican los conceptos que hemos estudiado durante toda la materia. El trabajo final juega un rol de trabajo integrador, previo a eso los alumnos trabajan en tareas individuales donde ponen en práctica diversos conceptos. Luego en el trabajo final deben volver a aplicar los conceptos ya estudiados pero ahora en un problema más complejo y trabajando en grupo. Una y otra vez vemos grupos que parecen haberse olvidado por completo de todo lo estudiado.