Ir al contenido principal

Primer contacto con el agilismo

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

Entradas populares de este blog

Mi primer toma de contacto con un refinamiento de Scrum

 Como he comentado en un artículo anterior, he trabajado durante muchos años en empresas que no usaban la metodología ágil. Los requerimientos venian dados por un analista (en el mejor de los casos, otras veces venía directamente de consultores con poco o ningún bagaje en tecnologías de la información); y normalmente eran unos documentos extensos, muy detallados, con gráficos, ... incluso notas o indicaciones técnicas. A mi personalmente me gustaban esos documentos, todo quedaba muy detallado, claro y conciso, pero esto mismo produce su gran debilidad, que hablaré más detenidamente de ello en otro artículo. Estando acostumbrado a trabajar con dichos documentos, me sorprendió bastante, primero con desconfianza y con el paso del tiempo con agrado, mis primeras sesiones de refinaminamiento, o también conocidas como refinements . El equipo de desarrollo al completo más el product owner (PO), nos reuníamos una o un par de veces semanalmente para hablar de los requerimientos. A diferencia de

Antes de ser ágil

Hace unos cinco años y medio, empecé a trabajar en una nueva empresa internacional, donde la sede principal está situada en otro país, la empresa tenía negocio en dicho país y en otro más, y además abrieron la sede en España donde yo me uní. En ese momento yo tenía catorce años de experiencia en empresas de IT, principalmente como desarrollador de software en distintos lenguajes y tecnologías, en escritorio y web, pero también había realizado labores de analísta y coordinador de equipos de trabajo. Cuando digo que que trabajé en rol de analísta, no me refiero al gran demandado y polivalente "analísta-programador", que sí, que también tuve ese título en otra empresa, sino a meramente "analísta". ¿Qué hacía como analísta? Básicamente me llegaban solicitudes de requisitos de compañeros consultores, los cuales trataban directamente con el cliente final. Algunos de estos consultores tenían el clásico corte de comercial, otros, en cambio, sí tenían background en tecnologí