Cómo ejecutar Combat Agile en pŕacticas del curso
Durante la práctica de esta asignatura los cambios más importantes respecto a Scrum oficial son:
- El Scrum Team se forma conforme indica la guía docente de la asignatura aunque puede apoyarse en los profesores del curso para las cuestiones que necesite asesoramiento. Podría solicitar que el profesor de la asignatura participe en algún evento como la Planning en el rol de Scrum Master, aunque se espera que los alumnos sean autónomos en el uso de Combat Agile.
- Antes de empezar con la implementación debe ser definido el nivel mínimo de la práctica para ser considerado apta. Para hacer esta definición es esencial utilizar todas las herramientas conocidas (diagramas UML, diseño de interfaces de usuario, herramientas colaborativas, etc…), especialmente las herramientas visuales como el Impact Map.
- El proceso de definición es un proceso iterativo, no debe hacerse primero el diseño de clases y luego las interfaces de usuario. Se partirá del uso de herramientas visuales y con la actualización conjunta de todo lo dicho anteriormente, se irá mejorando cada elemento con el resultado de cada iteración de los otros (hay que mantener la coherencia).
- Es necesario el trabajo en equipo, la comunicación y puesta en común por los alumnos que sean designados formando un equipo. No se trata de prácticas sesgadas donde cada alumno haga sólo la parte de su rol. Utilizar este enfoque perjudica al seguimiento de la metodología y hará que se ponga en riesgo el éxito de la práctica en equipo.
Durante la subfase de prácticas los cambios son:
- Los Developers son los alumnos y con carácter general se trabajará en pareja.
- El Product Owner debe ser nombrado. Se tendrá un DIM en la UCO como Tutor-Unidad y un Cliente. En función del grado de conocimiento sobre Scrum del Tutor-Unidad habrá dos opciones:
- Si el Tutor-Unidad conoce el rol de Product Owner sería la situación ideal. Debe quedarle claro en ese caso que él es el responsable de La Pila.
- Si el Tutor-Unidad no fuera el Product Owner deberá ser nombrado como tal uno de los alumnos.
- El rol de Scrum Master será desarrollado por el Tutor-Profesor si no puede representarlo el Tutor-Unidad (ver guía docente para las prácticas del año anterior en el canal de #practicas). Si el Scrum Master no está en la misma ubicación que los Developers será más difícil que participe en los eventos, con lo que debe mantenerse el contacto lo más estrecho posible y tener actualizados diariamente los artefactos. Se debe coordinar dónde y cuándo se llevarán a cabo los eventos en los que participa el Scrum Team al completo (Planning, Review y Retro). Además el Tutor-Profesor también puede abortar el Sprint justificadamente.
Hay que aprovechar al tutor asignado (o profesores antes de la subfase de prácticas) para que ejerza de Scrum Master. Lo normal es que surjan muchas dudas así que debería ser habitual preguntarle.
El error más común de los alumnos a la hora de implementar es perder el foco:
- Dedicar más tiempo del necesario a perfeccionar algo que ya alcanzó la DoD
- No aprovechar las herramientas visuales y perder de vista el objetivo de negocio que persigue un entregable o a quién y qué valor aporta
- Navegar en exceso en google cuando se está haciendo una búsqueda. Se debe tener muy claro qué se está buscando y terminar cuando se haya conseguido la información necesaria para seguir trabajando
- Posponer la toma de una decisión por miedo a elegir una equivocada
- No preguntar al Scrum Master pensando que “esta tarde en casa lo arreglo”
- Completar la duración de un Sprint con elementos de corta duración menos prioritarios que los previstos para el siguiente Sprint.
Para evitar caer en estos errores es fundamental la correcta gestión del Product Backlog empezando por la Sprint Planning.