Al entrar a trabajar en una empresa donde imperaba ser ágil, las metodologías con mismo nombre, y el framework de Scrum, me chocó todo un poco al principio, y pasados los primeros días el choque fue mayor aun.
Es cierto que la oficina llevaba poco tiempo en funcionamiento en nuestra ciudad, eramos muy pocos, y toda la oficina estaba inmersa en conocer los productos, el código, y empezar a ser mínimamente productivos, es decir, en aquel entonces no había grupos de trabajo a pleno rendimiento, ni eran sabios en la parte funcional donde se implementaba.
Dadas estas circunstancias, y a la metodología ágil de Scrum, la forma de trabajo fue muy distinta a lo que yo estaba acostumbrado, no era mi zona de confort.
Por un lado teníamos unas sesiones mañaneras llamadas "stand up" o "dailies", donde había que decir que se había hecho el día anterior, que se iba hacer en el día presente y si habías tenido algún bloqueo o impedimento. Teóricamente estas sesiones no debían pasar los 15 minutos, aunque normalmente siempre nos pasabamos de tiempo. Era curioso como ver a compañeros decir "hoy tendré terminado esto", y al día siguiente decir lo mismo, o incluso decir "está casi terminado", incluso esto se repetía a veces diariamente, es decir, algo que un compañero decía "hoy lo tendré listo", a los dos días "estaba casi listo". En mi concepción mental de mis anteriores trabajos, estas situaciones hubieran desencadenado en muchas preguntas del responsable de grupo, ver si el desvío en tiempos afectaría en cascada al resto de tareas siguientes que estuvieran relacionadas con esta, pensar como aligerar tiempos por otro lado, hasta la lamentable pregunta de ¿es necesario hacer un esfuerzo extra? etc...
Sin duda alguna lo que más me llamó la atención fueron las sesiones de refinamiento donde nos reuniamos todos, un par, o incluso, tres veces por semana, para conocer y estimar "user stories" (historias de usuario). ¿Qué es una user story? Ahora sé que que podríamos decir que es un pequeño incremento de valor para la aplicación, es decir, una pequeña mejora o nueva funcionalidad que hace que el producto tenga más valor (a muy grandes rasgos). Pues bien, una persona con un rol llamado "product owner" (también conocido como dueño de producto) nos explicaba el motivo porque esa user story era necesaria, y que había que desarrollar en ella. Una vez explicada, verbalmente porque de literatura eran unas pocas frases, los desarrolladores hubicábamos dicha funcionalidad en la aplicación, la entendiamos, hacíamos preguntas, y finalmente la estimábamos, pero ojo, no en tiempo en horas o días, sino en algo llamado "story points" (puntos de historia), siendo un valor numérico incremental donde 0.5 implicaba poco esfuerzo, 1 el doble de 0.5, 2 doble esfuerzo de 1, y así sucesivamente... Pero no se hacía mención alguna al tiempo empleado. Esto para mí era insólito por doble motivo: No había una descripción funcional ni técnica especificando claramente qué hacer, tampoco detalles o sugerencias técnicas de implementación; ¡¡ y tampoco había estimaciones en tiempo !! ¿cómo se iba a poder planificar esto? Era una incógnita para un profano en Scrum.
En el siguiente artículo continuaré relatando mis primeros contactos con otras ceremónicas Scrum, aunque debo reconocer que la que más me llamó la atención y más me sorpredió fue la de refinamiento.
Comentarios
Publicar un comentario