Cómo utilizar SCRUM para crear E-learning

Todos hemos pasado por la tediosa experiencia en donde nuestro jefe nos impone una nueva metodología de trabajo, aplicada a medias y termina siendo un estorbo que hace que continuamente perdamos tiempo valioso rindiendo cuentas sin importancia a nuestro superior que intenta desesperadamente apegarse a un método.

Este texto es para que te asegures que al implementar a SCRUM no te suceda eso.

SCRUM ha sido usado en todas las áreas de creación de software por lo que el e-learning no es una excepción para terminar proyectos con un mayor índice de éxito que anteriormente.

Te presentamos aquí SCRUM enfocado en e-learning el plan se divide dela siguiente manera:

Primero el enfoque Ágil de SCRUM
Después hablaremos de las reglas de SCRUM,
A continuación de los ROLES.
Qué significa el proceso Iterativo.
Y finalmente, para qué no es SCRUM

1. EL ENFOQUE AGIL DE SCRUM

Cuando un equipo empieza a implementar SCRUM tiene que saber que el enfoque de este es en realidad estar lo más apegado que se pueda a las metodologías ágiles.

Al mismo tiempo recomiendo no variar de las reglas que el método propone. SCRUM tiene que ser usado muy completo porque ya viene en combo.

En realidad SCRUM sirve a estos valores, y si no se mantienen como meta entonces SCRUM resultará probablemente menos mucho menos útil de lo que se pretende.

Individuos e interacciones sobre procesos y herramientas.
- Se tiene que empezar por asegurar que los miembros del equipo de creación de cursos sepan a quién acudir y qué herramientas de edición de curso usar. En metodologías agiles es clave hacer antes este análisis de la persona y no solo darle las herramientas listas para usar.
Software funcionando sobre documentación extensiva.
- Esto significa que antes que querer satisfacer todas las demandas que se piden en la documentación, necesitamos hacer un software que sea continuamente útil y progresivamente mejor. Y eso es de más valor para el paso del proyecto que querer lograr todo funcional y excelente a la primera.
Colaboración con el cliente sobre negociación contractual.
- En vez de trabajar como dos partes separadas: una que exige algo y la otra que la tiene que cumplir a toda costa, ahora se trabaja en unión y colaboración continua para redirigir el proyecto conforme se va desarrollando y surgen nuevos discernimientos del diseño que está siendo continuamente actualizado.
Respuesta ante el cambio sobre seguir un plan.
- De la misma forma, se tiene que tener una dirección pero conforme el equipo va avanzando se van generando situaciones adversas que deben de ser solucionadas apuntando a la meta sin importar las diferencias entre el plan y la realidad. Estas situaciones tienen que ser solucionadas de manera integral y ágil.

También te tienes que apoyar en los 12 principios ágiles para saber hacia donde tienes que llevar esencialmente tu proceso de SCRUM,

Si SCRUM te dificulta más de lo que te ayuda al acercarte a estos principios, algo debes de estar haciendo mal.

2. LAS REGLAS DE SCRUM

No recomiendo usar SCRUM a medias, eso significa que tiene que ser considerado en su totalidad para que tenga sentido.

Existen 4 roles:

Equipo.
Maestro SCRUM,
Representante del producto.
Inversionistas.

Antes de empezar a rellenar el TABLERO SCRUM necesitamos tener una junta de planeación de aproximadamente 2 a 4 horas en dónde desmenucemos las tareas en bloques que cada quien pueda comprometerse a completar en SPRINTS.

LOS SPRINTS

Los SPRINTS son el tiempo otorgado al equipo para terminar con las tareas que se comprometió a realizar en un determinado tiempo establecido. Se recomienda que los SPRINTS duren entre 1 y 2 semanas idealmente antes de llegar a la RETROSPECTIVA.

LA RETROSPECTIVA.

Al final de cada Sprint el equipo se reúne para asegurar que cada quien haya logrado complir con su tarea al menos de la mínima forma. Entonces se hace la retroalimentación cada 1 o 2 semanas en dónde se involucran a todos los roles durante aproximadamente 2 horas (Con el inversionista no es sistemático).

Así, durante las reuniones refinamos y pulimos las historias que vienen para el siguiente Sprint.

SCRUM no acepta que las personas no entreguen algún resultado después de un SPRINT.

Es solo a partir de esto que se puede redirigir la nave concretamente.

EL TABLERO SCRUM

En el TABLERO SCRUM se colocan todas las tareas que se están haciendo al mismo tiempo durante el SPRINT

Suele tener un proceso del tipo:

Backlog,
Es el almacén de tareas que aún no deben de ser realizadas, están en espera.
Por hacer (To do)
Haciendo (Doing)
Hecho (Done)

La duración estimada que se le otorga a cada rol (excluido el inversionista – stakeholder) es de idealmente de entre 1 y 2 semanas.

3. EXPLICACIÓN DE ROLES

Los 4 roles qué va a adoptar un proyecto para implementar un sistema de gestión tipo SCRUM son los siguientes: un maestro SCRUM (SCRUM MASTER,un representante del cliente (PRODUCT OWNER); las PARTES INTERESADAS ( stakeholders) y claro, el equipo.

El maestro scrum:

Este rol tiene el deber de decidir cuántas historias van a hacer durante el sprint. No debe ser cualquier persona sino alguien que tenga habilidades sociales y que comprenda muy bien SCRUM.

Será con e que todos los demás roles tendrán el contacto directo.

Necesita tener el tiempo para ocuparse del equipo, es un elemento central de la estrategia y debe estar constantemente activo. Por lo tanto necesita ser alguien que tenga la posibilidad de otorgarle el tiempo que necesita diariamente a su rol. de SCRUM MASTER.

A él se dirijirán las personas.

El Representante del cliente (PRODUCT OWNER)

Para que el producto owner pueda otorgar refinamiento de calidad al proceso, vamos puliendo las historias de sprint en sprint.

Cuales son las características de la persona que encarna este rol.

Este sabe muy bien que es lo que quiere y necesita el cliente. Suele ser un experto de su rama a la vez que es un usuario final. Entiende cuál es el producto final que debe de ser realizado para que el cliente final este contento.

¿Qué tan adentro del equipo debe de estar el producto owner?

Entre más cerca mejor, y si el puede estar dentro del equipo, entonces la situación con él podrá ser óptima. Lo mejor es tener 1 solo. Si hay más de 1 y se pelean por saber que va a meterse al almacén de tareas (Backlog), es una mala práctica.

En la planeación, el Product owner trae el backlog perfecto. El es quien va aplicando prioridad tras prioridad para que el equipo después decida cómo es que tienen que hacer los SPRINTS.

En el caso del e-learning, el product owner podría ser un maestro, un entrenador, un capacitador, o cualquier otro que se encuentre en la primera línea de batalla con el aprendiz final y que sabe que es lo que quiere provocar y enseñar

En el refinamiento pulimos las historias que vienen para los demás SPRINTS, no para este, sino para el siguiente sprint, es esencial que el “product owner” raffine tanto como sea posible. Esa es su acción central.

El Equipo

El equipo está sujeto a cumplir con su tarea durante el sprint, sea la que sea. Tiene que estar terminada para la fecha de cierre del sprint. Normalmente un Sprint puede durar de una a dos semanas. Y representa toda la parte de ejecución del proyecto.

Trabaja en base a sprints de una a dos semanas que incluyen tareas asignadas por individuo para ser ejecutadas en este periodo.

Las partes interesadas, inversionistas (STAKEHOLDERS)

Estas partes deben de ser suministradas por información de objetos que ya estén terminados. No tienen porque meterse más a fondo en el proceso si lo que pidieron se está llevando a cabo.

El tablero SCRUM le ayudará a todos a saber que mostrarle a los stakeholders para que estos puedan observar el avance real del equipo y se guardarán aquellas cosas que no sean esenciales para ellos.

4. PROCESO ITERATIVO DE SCRUM

El proceso iterativo en SCRUM no es para redirigir el proyecto, sino para refinar los sprints, y obtener productos terminados después de cada SPRINT. La retrospectiva y la iteración se hacen enfocadas en la necesidad de replantear mejor el sprint siguiente.

5. PARA QUE SÍ Y PARA QUE NO USAR SCRUM

Dependiendo de la eficacia del equipo de creación de cursos, SCRUM podría ser util para llevar a cabo un proyecto largo y muy bien definido por un cliente intransigente.

Pero si el cliente esta experimentando, y el sakeholder planea tener muchos cambios durante el proceso, quizas no sea la mejor idea por que va a hacer que todos trabajen de más al no poder cambiar las tareas sino hasta el final del SPRINT:

Por eso SCRUM no es para hacer cambios en el proyecto de última hora. Es por ello que la planificación inicial es tan larga, por que tiene que entender que es a partir de ese momento de planificación que la dirección general va a ser tomada. Después los Sprints son para realizar el proyecto de hecho pero no para modificarlo sustancialmente en el camino.

SCRUM es muy útil para proyectos grandes y definidos, pero frente a la incertidumbre ha resultado inflexible frente a otro método conocido como KAN BAN que responde mejor a la incertidumbre