You are on page 1of 5

Capacitación en la era Scrum

Solar Oliver Patricia (2018)

Abstract: El aprendizaje en la era Scrum es un desafío con el que todos los que trabajamos
en capacitación y educación tendremos que enfrentarnos en algún momento, requiere un
cambio en nuestro paradigma cultural y un cambio en la forma en que se diseñan,
construyen e implementan los programas de capacitación. Si bien muchas instituciones han
instaurado la metodología de proyectos Scrum en sus áreas de desarrollo, es necesario
ampliar esa aplicación a los departamentos de capacitación, incluyendo un proceso de
construcción en paralelo, insertos en los equipos de producción, adaptando los roles
cotidianos a esta nueva metodología, al mismo tiempo que se utilizan recursos que sean
idóneos para ello.

Palabras claves: Sistema de trabajo en cascada, Ágil, Scrum, blacklog, dueño de


producto, Scrum manager, capacitación, objetos de aprendizaje.

Ya sea como un cambio organizacional planeado o no planeado, de origen interno o


externo, cada vez más organizaciones adoptan la metodología de trabajo Scrum. Se ve en
instituciones académicas y en empresas, grandes y pequeñas, pasando de ser una moda
a un mecanismo de adaptación, en una época donde el tiempo cada vez en un recurso más
valioso.
Scrum es una metodología de gestión de proyectos que forma parte de un grupo más
amplio, las llamadas metodologías “Agil” que como su nombre lo indica, buscan producir
resultados en el menor tiempo posible. Dentro de estas metodologías, Scrum se destaca
por ser un sistema de trabajo en paralelo que se adapta a necesidades cambiantes y en
evolución.
Operativamente, trabajar con la metodología Scrum significa que un proyecto completo
como un cambio tecnológico o el desarrollo de un emprendimiento, se divide en
componentes, ideas o tareas que se requieren para ello, cómo la lista de aplicaciones o
procedimientos que se deben poder realizar en una plataforma tecnológica o las áreas de
trabajo de un emprendimiento. Esas tareas se ordenarán según su nivel de prioridad,
viabilidad o por ser prerrequisito de otras. Cada tarea se dividirá en subtareas que se
realizarán en forma paralela por distintos miembros del equipo de desarrollo, teniendo en
un corto plazo, un producto utilizable.
Para trabajar con está metodología, lo primero que se debe considerar, es sacar de nuestro
repertorio cultural el sistema de trabajo en cascada con el que la mayoría nos educamos
y trabajamos hasta antes de Scrum, en que se partía de un levantamiento de necesidades,
para luego pasar a un diseño, luego una implementación y prueba, para solo al final de esto
tener un producto completo que cuando no es era el final, se consideraba un fracaso.
Cuando se trabaja con Scrum, al mismo tiempo habrá personas planificando,
desarrollando, probando y revisando distintas partes del producto, que al estar “terminado”,
será una versión o una parte de un todo mayor, por lo tanto, es un producto que no se
espera que sea definitivo, sino que evolucione y se perfeccione a medida que se valla
integrando con las otras partes del proyecto mayor y se valla evaluando por los clientes y
usuarios finales.
Cada una de los subproyectos o conjunto de tareas o ideas que crean un producto en
Scrum se denomina Sprint, las tareas que se seleccionan para cada sprint (por criterios
como costo, tiempo de desarrollo, viabilidad, pre-requisitos de otros, etc.) se seleccionan
según objetivos que permitan conformar un ciclo de desarrollo de producto, que tiene un
comienzo y un fin que no debiese exceder un plazo de 2-3 semanas.
Para no perder el foco del proyecto completo para el cual se crea un producto en cada
Sprint, lo que se construye se rige por un conjunto de fichas denominada Blacklog, el
Blacklog maneja una bitácora de todos los componentes del proyecto, subproyectos, tareas
o ideas, almacenando en cada una de las fichas que la componen, las especificaciones de
los requisitos y características que cada componente debe cumplir (redactada en lenguaje
de cliente o usuario final) que otorgan un panorama completo del requerimiento.
Por ejemplo, en el siguiente cuadro se puede leer que el primer componente de la ficha 1
es: “Mantenedor de usuarios: como un administrador, necesito crear usuarios, así podré
mantener la seguridad de la aplicación. La cual debe tener envío automático de usuario y
clave.

Ejemplo de redacción de una ficha de un Blacklog para un sistema de ventas en línea:

ID Componente Como un Necesito Así podré Notas


Mante_01 Mantenedor de Administrador Crear Mantener la Debe tener
usuarios usuarios seguridad envió
de la automático de
aplicación usuario y clave.
Mante_02 Mantenedor de Administrador Eliminar Mantener la Incorporar
usuarios usuarios seguridad bloqueo de IP
de la con 3 intentos
aplicación fallidos.

¿Qué metodología se utiliza para capacitar un proyecto Scrum?


Para realizar un programa de capacitación relacionado a un proyecto que se desarrolla con
metodología Scrum, necesariamente se debe seguir esa misma metodología de trabajo.
Una de las principales razones para ello, es que, si se espera contar con un producto
terminado para enseñar cómo se usa, lo más probable es que nunca se sepa a tiempo
“cuándo” se está frente a ese producto.
Hay que recordar que quienes están diseñando el producto o proceso, están trabajando al
mismo tiempo de quienes lo programan o construyen, por lo que cambios en el programa o
construcción producirán cambios en el diseño, a su vez las pruebas de un componente
pueden producir cambios en la programación de otro componente, que también producirán
cambios en el diseño. También es necesario recordar que el producto de cada Sprint, es
un producto utilizable, de este uso es posible que se levanten mejoras necesarias que
conllevarán un perfeccionamiento del producto, que requerirá que se trabaje en otro Sprint,
que dará como resultado un producto mejorado.
Si se espera mucho el producto ya estará siendo utilizado por otros equipos que están
desarrollando otra fase del proyecto o estará en manos del usuario final, Por lo cual la
capacitación o será innecesaria (si el usuario se adaptó y lo intentó por si mismo) o será un
impedimento para que el producto se utilice adecuadamente e incluso puede hacer peligrar
el resto del proyecto.
Si se espera poco y se considera como final un producto intermedio, se tendrá una
capacitación que puede estar obsoleta antes de que se empiece a aplicar.

¿Cómo se puede aplicar la metodología scrum a la capacitación?


Para empezar, es necesario conocer la metodología a fondo y será necesario trabajar la
gestión del cambio para dejar de pensar y trabajar en forma de cascada.
El levantamiento de las necesidades de capacitación debe ser lo más flexible posible,
y debe estar activa durante todo el proceso de construcción de la capacitación, que
también se debe estructurar en torno a unidades mínimas similares al Sprint.
Estas unidades mínimas ya existen como metodología y se conocen como objetos de
aprendizaje (OAs) tienen como características ser autocontenidos y auto-explicativos, es
decir tienen inicio, desarrollo y final, logrando un cierre cognitivo que permite que sea
captado como una unidad e idea completa, breve y fácil de recordar.
Retomando el mismo ejemplo de la misma ficha que se revisó anteriormente, un objeto de
aprendizaje podría ser cómo ingresar al administrador, otro objeto indicaría cómo crear un
usuario, un tercero como eliminar un usuario, etc.
Varios objetos de aprendizaje constituyen una unidad de aprendizaje, que, siguiendo el
ejemplo anterior, sería el mantenedor de usuarios. Esta unidad debiese tener coherencia
con una o más fichas del Blacklog.
Cada unidad de aprendizaje forma parte de un programa de capacitación, que para este
ejemplo sería el sistema de venta en línea que está contenida en el Blacklog completo.
De esta forma, los cambios o evolución de un producto en específico conllevan cambios o
evolución de un objeto de aprendizaje y no de toda la capacitación, permitiendo que se
tenga claridad de que es lo que cambia para poder enseñarlo y se le puede dar el plus al
proceso de capacitación de constituir un elemento de información y gestión del cambio.
Es necesario recordar que la metodología Scrum requiere trabajar en paralelo, por lo tanto,
las personas a cargo de construir los materiales de capacitación necesariamente deben
trabajar en conjunto con quienes desarrollan el producto, durante los mismos periodos, en
la forma más integrada posible, como parte integral del equipo.

¿Cómo ordenar el proceso de capacitación en este escenario?


Para ordenar la capacitación lo ideal es trabajar con los roles de scrum y olvidar los roles
del trabajo en cascada. El equipo de trabajo en Scum tiene la siguiente estructura:
1.- Dueño del producto: Es quien aporta ideas sobre el producto final dando forma a cada
una de las fichas que conforman el Blacklog, es la voz del cliente y del producto y está
enfocado en ello durante todo el proyecto. Homologado a los roles de capacitación, sería el
encargado de realizar el levantamiento de las necesidades de capacitación que, en este
caso, se hace en forma permanente. Debe ser quien revise los productos de capacitación
con el dueño del producto real, con quien debe estar en continua comunicación para estar
alineado con los cambios y avances del proyecto que se está enseñando a utilizar.
Idealmente debe participar en la mayoría de las reuniones del equipo de producción,
especialmente en las reuniones diarias y en la etapa de retrospectiva (revisión del producto
al final de cada Scrum).
2.- Scrum Master: es el encargado de facilitar y asegurar los procesos de trabajo, mantiene
el flujo de la comunicación a todos los que requieren la información, mantiene los
procesos, acompaña y vela por las condiciones de trabajo del equipo, y se encarga de
tomar nota y solucionar los obstáculos en el proceso de construcción. Es quien debe
acordar con el dueño del producto los cambios en las fichas y Blacklog necesarias por la
mejora continua, o su interacción con otros Scrum, siendo el responsable de comunicar
adecuadamente esos cambios a todos los involucrados. Homologando a los roles de
capacitación, por lo general este rol no existe, aunque podría ser asimilable al del diseñador
instruccional + coordinador, pues requiere por una parte el manejo técnico del proyecto y
por otra parte, la coordinación logística de los procesos que se van realizando en forma
paralela. Este rol también debiese estar informado de todo el proceso y trabajar en forma
alineado con el Scrum Master del proyecto real, teniendo acceso permanente al Blacklog
para hacer la retroalimentación necesaria al dueño del procedimiento para que reorganice
prioridades y mantenga actualizadas las necesidades de capacitación. Para la gestión del
trabajo utiliza una herramienta conocida como Burndown Chart en que se mantiene un
detalle de cada tarea, responsable, tiempos estimados y reales, para alinear los ciclos de
trabajo a los tiempos del proyecto.
3.- Equipo: está conformado por los distintos profesionales que trabajan en el proyecto, los
que se reúnen diariamente 15 minutos con el scrum master y el dueño del proceso para
revisar los avances del día anterior, lo que harán durante el día y los obstáculos que se les
presentan, deben trabajar como equipo aunque realicen cosas distintas, lo que se suele
entender como que deben trabajar en un mismo espacio físico, sin embargo lo que se
requiere es que estén en contacto permanente para que puedan tomar acuerdos sin tener
que hacer reuniones especiales, siendo un desafío que aún enfrentan las instituciones que
trabajan con esta metodología, el poder manejar los espacios físicos de trabajo para que
permitan la concentración y trabajo eficiente al mismo tiempo que permite la comunicación
de los equipos. Homologado a los equipos de capacitación, se pueden definir que el equipo
variará según el tipo de objetos de aprendizaje que se estén desarrollando, pudiendo incluir
desde diseñadores gráficos hasta editores lingüísticos. El desafío mayor de cambio en la
forma de trabajo de estos equipos estará dado por el trabajo en paralelo, lo que significa
que los diseñadores gráficos debiesen estar construyendo elementos para los OAs al
mismo tiempo que otros estén trabajando en los guiones, todos alineados e informados
sobre lo que se está construyendo y su lugar dentro del panorama o proyecto total.
La ejecución del proceso de capacitación de proyectos Scrum también debe cambiar, si en
el modelo de cascada la capacitación iba al final de la construcción y era definitiva, en los
proyectos Sccrum debe ser incremental y perfectible. Es importante considerar que esto
no significa que parta siempre desde 0, pues debe considerar solo los cambios que se
produjeron desde la última capacitación, pero haciendo siempre un repaso rápido de lo
que ya se debiese saber. Para ello es necesario seguir un criterio técnico, que logre separar
lo principal de lo accesorio y en especial, determinar aquellas claves cognitivas que
permitan que quien reciba la capacitación logre hacer nexos y nuevas asociaciones sin caer
en la confusión. Posiblemente deberá considerar distintos formatos de OAs y en especial,
plazos de capacitación acordes al aprendizaje continuo.
Otro foco especial que se debiese siempre considerar en un proyecto Scrum, es la
capacitación de quienes trabajan en un producto, si bien hay una gran diferencia entre los
procesos informativos (que deben contener toda la información, de la forma más eficiente
posible que permita la consulta permanente de los datos) con los procesos
instruccionales (que buscan que el receptor aprenda lo más importante de lo que se le
está enseñando, para actuar con esos aprendizajes de forma autónoma e independiente),
capacitar a los equipos de trabajo, sobre lo que se está construyendo desde la perspectiva
de cómo funciona, cuál es su objetivo dentro del producto final, cuál es la recepción de
los usuarios, los errores que se han cometido y las buenas prácticas que se han
detectado, es un motor que puede hacer una gran diferencia en los proyectos Srum, que
necesariamente deben evitar duplicar funciones, realizar cambios que afecten otros sprint
y especialmente hacer productos funcionales que se vallan perfeccionado.

Referencias bibliográficas
Baños, e. g. propuesta metodológica usando scrum y pmbok, para la gestión de proyectos de ti de la jefatura
de informática de una unidad ejecutora del sector transportes.

Evans, G. W., & Johnson, D. (2000). Stress and open-office noise. Journal of Applied Psychology, 85(5), 779-
783. http://dx.doi.org/10.1037/0021-9010.85.5.779

Lucero, M. M. (2003). Entre el trabajo colaborativo y el aprendizaje colaborativo. Revista iberoamericana de


Educación, 33(1), 1-21.

Ramirez, C. E., & Gil, M. D. P. G. (2013). Modelo de mejora del proceso de capacitación para desarrolladores
de software en PYMES basado en ambientes ágiles (Doctoral dissertation, Disertación Doctoral en
Ingeniería de Software, Puebla: Departamento de Posgrado, Universidad Popular Autónoma del
Estado de Puebla).

Solis C. (2017) Curso: Aprende Srum. Linkedin. https://www.linkedin.com/learning/aprende-scrum/presentacion-


del-curso-aprende-scrum

You might also like