Hace ya varios años, empecé a usar Scrum para organizar las prácticas de las asignaturas que imparto en la Universidad Rey Juan Carlos. En este caso, no me refiero a explicar Scrum, Agilidad, en la teoría, cosa que hago explícitamente en una de mis asignaturas, en la que, además, lógicamente, hay una práctica de Scrum.
En este caso me refiero al uso de Scrum en asignaturas que no cuentan explícitamente temas ágiles, como es, en mi caso, por ejemplo, la asignatura de Calidad Software, en la que también hago uso de Scrum como marco para ordenar las prácticas (que este caso concreto tienen que ver con cosas como testing, BDD o Integración contínua).
Usar Scrum como modelo para hacer prácticas, de casi cualquier cosa, en una asignatura, me ha dado muy buenos resultados, a mí, y entiendo, y espero que a los alumnos, que son el principal objetivo a beneficiar.
Hacer prácticas usando Scrum permite que los alumnos interioricen Scrum y la agilidad como método de trabajo, así lo pueden usar en su futuro laboral, donde raro es, en informática (y otros), que hoy encuentren un trabajo relacionado con software en el que no se lo pidan, o les toque, algo relacionado con Scrum (o ágil en general).
Y, además, para ellos es un punto más para cuando les llega la hora de buscar trabajo, ya que conocer, y haber usado, Scrum, es un punto más que positivo y que, por suerte, o por desgracia, los posiciona muy bien frente a otros candidatos, ya que son pocas las universidades que cuentan con profundidad cosas sobre agilidad.
Y, precisamente, por esto último, por si eres docente, con el objetivo de que la agilidad se enseñe más, me he decidido a contarte cómo yo aplico Scrum como guía para hacer prácticas, a ver si así animo a alguno más a hacerlo. Por intentarlo que no quede.
Los Sprint
Antes de empezar se hacen grupos de trabajo, equipos, que serán fijos durante toda la asignatura, como marcan las buenas prácticas del Peopleware… son equipos multifuncionales de menos de 10 personas.
Lo que hago es Sprints de unas 3 semanas. Según la duración del cuatrimestre, esto me da para, normalmente, 4 Sprints. Los Sprints suelen empezar unas semanas después del comienzo del cuatrimestre, para poder explicar cosas antes, que luego serán el objetivo del primer Sprint.
Y cada Sprint tiene su objetivo, por ejemplo, “Aprender técnicas de caja blanca para evaluar software”.
El Product Backlog
Al comienzo de cada Sprint, la primera clase de prácticas es una “Sprint Planning”. Durante ese Sprint Planning, explico las historias de usuario a completar durante el Sprint que empieza.
Para interiorizar la diferencia entre cascada y un ciclo de vida ágil, entre requisitos cerrados, tipo especificación de requisitos software, e historias de usuario, que el cambio es bienvenido frente al inmovilismo de una gestión de proyectos tradicional, y otros tantos, no doy el primer día de clase una lista completa de historias de usuario a completar en los 4 Sprints, sino que yo, haciendo de “Product Owner”, muestro una lista solo con las historias para el Sprint.
El Product Backlog es una lista de historias de usuario (o items de manera general). Son el qué se espera que se complete durante las semanas del Sprint. Esas historias tienen objetivos de la asignatura, son del tipo a, resumidamente (las historias tiene un formato más elaborado), “automatizar x pruebas con Calabash”, “Instalar Jenkins”, etc. Pongo esas historias porque son los objetivos de la signatura, pero igualmente, para ti podría ser “buscar los escritores Rusos más importantes del s. xix”.
Cada historia de usuario tiene un valor que las prioriza, como buen Product Backlog que se precie. La suma del valor de las historias propuestas para el Sprint da 10. Así, por si no les diera tiempo a terminarlas todas, deben priorizar para obtener el máximo valor, que viene a estar relacionado con obtener mayor nota.
El Sprint Backlog
Como es lógico, es tarea del equipo, es el cómo se organiza para resolver las historias de usuario. Es el cómo. Aquí hay libertad para usar pared y posit o, por ejemplo, Trello.
Daily, Sprint Review y Retrospectiva
Los Dailys son una recomendación, si bien es razonable que no puedan hacerlos diariamente.
La clase del último día del Sprint es el Sprint Review. Antes, además de las historias del Sprint, los alumnos deben haber hecho ellos una retrospectiva, para mejorar como grupo Sprint a Sprint. Y, para ello, normalmente, usan la técnica de la estrella de mar o la del barco.
Durante la clase Sprint Review los alumnos hacen una “demo” al Product Owner, que son los profesores. En la demo, por equipos, muestran cómo han completado las historias del Sprint, la demo y la Retro.
En el mundo real la retrospectiva se hace después del Sprint Review, pero en el caso que nos ocupa, por razones obvias, es más efectivo que los equipos la hagan antes y la cuenten durante la demo.
…
Bueno, seguramente me dejo algún detalle, pero lo esencial está escrito, espero que si das clases de algo, con prácticas, te puedan venir bien estos consejos y, ojalá, te anime a ser ágil también en el ámbito de la enseñanza.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Como ex-alumna de Javier y de dos de las asignaturas que imparte en la Universidad, puedo decir que estas clases y esta forma de trabajar (en mi caso) no se quedaron en las aulas. Yo por aquellos tiempos no sabía muy bien sobre que tema hacer mi proyecto, y fue la forma en la que trabajé en clase lo que hizo que apareciera mi objetivo ya no sólo a nivel de Trabajo Fin de Grado, sino profesional. Creó que se tendría que extender diferentes formas de docencia, y no hablo de agilidad, sino de las que te abren los ojos de como va a ser el mundo después de ser estudiante, que te cuenten como es el mundo fuera de la uni.
Javier,
muy buena iniciativa (¡y consecuente!).
Yo lo utilizo desde hace unos años para el seguimiento de proyectos de fin de carrera y de máster, y los resultados son muy buenos, tanto para el alumno como para mi.
A nivel más amplio, formé parte de un consorció que presentó un proyecto Erasmus+ para pilotar en España la metodología holandesa Eduscrum, para clases de secundaria y universidad, pero no nos lo aprobaron. A ver si encuentro aliados para volverlo a empujar, aunque sea sin la financiación de la CE.
Alex / itnove.com
Yo el problema que veo es que no todo el mundo es Javier (no tienen su capacidad, ni su experiencia, ni su motivación, ni su vocación).
Yo sin haber estudiado nada de agilidad antes de entrar en el mercado laboral, nada más empezar, intenté hacerlo muy bien. Y «muy bien» es que iba con la idea de que nada es imposible, sólo hay que trabajar con más ganas. Y me encontré con un «qué ganas tengo de que me manden un becario sin pretensiones». A cuadros me quedé. Y repito, aún cobrando una miseria, sólo quería hacer las cosas bien, aplicar lo que sabía y aprender más de la experiencia.
El último trabajo que tuve, por mencionar algo de aquel todo que aguanté, me cambiaron de sitio 4 veces en un sólo día.
Yo lo he intentado, pero no he encontrado mi sitio en esta profesión. Hacer las cosas sin calidad, como has dicho en alguna ocasión, en esta profesión (y yo creo que en más de una profesión) es hacerlas mal. Y estar 8 horas al día (si no son más) rompiéndote la cabeza intentando buscar el hilo conductor de un código que sólo tiene hilos para tejer deuda técnica… Es terrible para la salud mental. Súmale perlitas como las que he contado y acaba uno de la cabeza que ya no sabes ni cómo te llamas.
¿Recuerdas los «formularios para cumplir safe»? Desviaciones del estilo en el aula son peores. Yo he estado en una clase en la que el profesor nos obligaba a ponernos nuestra propia práctica al comienzo de la asignatura. ¿Con qué criterio elige uno una práctica anual al comienzo de un curso? Y orientación ninguna, que al docente el tiempo no le sobra.
Yo creo que es un error muy grande que uno que ni sabe ni quiere aplique agilidad. Del calibre del bilingüísmo de secciones europeas a toda costa.
Vamos de mal en peor, estamos perdiendo todos.
We are sold. Hemos quebrado como sociedad.
Qué gran labor Javier! Ya me parecía increíble que durante la carrera se impartiera agilidad y scrum pero que además puedas adaptarlo en otras asignaturas y vayan ganando esa experiencia es una gran ventaja competitiva con la que saldrán al mundo laboral tus alumnos. Un saludo.
Pregunto, como hipotético caso de un padre que quiere una vida digna en el sector para su hijo. ¿Cómo hago para que no mermen su talento en centros educativos en los que el inglés que le enseñan le va a hacer más mal que bien a largo plazo? ¿Cómo hago para que esa agilidad mal implementada por parte de docentes que no tienen capacidad o disposición no asiente en mi hijo un torrente de desconocimiento? ¿Está mi hijo abocado al fracaso por razones ajenas a su capacidad y voluntad?
Un artículo relativo a esos jóvenes talentosos buscando un futuro acorde a sus expectativas: «A los soñadores se les toma por tontos en España, mientras que EE UU invierte en ellos».
En la actualidad este tipo de iniciativas, así como la comentada por Alex, eduScrum (http://eduscrum.nl/en/), deberían implementarse en etapas muy tempranas del proceso educativo.
Repito, aún a riesgo de caer cansino, es que es muy importante que no se olvide que hay muchos tipos de «profesionales» por ahí sueltos. Bear in mind this: Supervising teamwork has become very simple with eduscrum; the students do most of the work.
Que yo estuve en una clase en la que para explicarnos la ley física del mínimo esfuerzo el profesor hizo el símil con que era la ley que domina a los seres humanos.
Yo entiendo que Javier, primero te has preparado bien, vía formación y experiencia, y después implantas poco a poco, empezando por prácticas. Implantas, evalúas, concluyes, reajustas y repites el proceso. Eso en sí mismo es mejora contínua. Un equipo auto organización no es un equipo al que se le tira a la piscina y se le dice: venga, aprended a nadar y ayudaos los unos a los otros porque mi trabajo es mirar desde la orilla. Y esto último está pasando, sobre todo cuando el product owner es un patán de los de ley de mínimo esfuerzo.
Dejo como ejemplo de desviación lo siguiente: no explico teoría, aplico metodología de descubrimiento (sin orientación ninguna, ni doy bibliografía, ni doy webgrafía ni nada de nada), monitorizo las estaciones del aula, hago intersección de lo descubierto por los equipos y de ahí saco los contenidos a evaluar. Sacan buena nota todos. Yo no les he enseñado nada y realmente no sé si han aprendido algo, pero lo parece, ellos están entretenidos y yo soy un tío muy ágil.
Esto que cuento yo lo he sufrido como alumno.
Que todo se puede utilizar de dos formas: para bien o para mal. Y que la mayoría de la gente no tiene ganas de hacer el cambio y además no les hace falta para vivir, que ya tienen «la vida resulta». Y la agilidad les viene perfecta para hacer cada vez menos. Y en la privada antes o después se ve a estas personas, pero en la pública… Un horror.
Yo no estoy de acuerdo con lo aqui escrito, pienso sinceramente que hay muchos factores que no han podido ser considerados en cuenta. Pero valoro mucho vuestra exposiciòn, es un buen post.
Saludos