Ir al contenido principal

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 los documentos de análisis, cada ticket (requerimiento) contenía muy poca información: Un título, una descripción, y a lo sumo algún que otro caso de uso (llamados también escenarios). El PO nos explicaba el motivo por el que cada requermiento era necesario, y la conversación empezaba entre todos, especialmente entre los más veteranos del producto, viendo dónde/cómo encajaba dicha petición dentro del producto, inconvenientes técnicos, etc... Las dudas funcionales o de producto nos la resolvía el PO, y el alcance técnico los desarrolladores o QAs que más tiempo llevaban en la empresa trabajando.

Y llegaba el momento de la estimación, y esto sin dudas alguna era lo que más me llamaba la atención. ¿El motivo? No se estimaba en tiempos, nada de horas ni dias, se estimaba en una cosa llamada user story points (o puntos de historia de usuarios para los amigos). Se estimaba por votación, cada persona (excepto el PO) usaba una maza de cartas diseñasdas para estas votaciones, y votábamos con puntos del 0 al 13, donde 0 significaba nada de esfuerzo, y el 13 el máximo esfuerzo. Normalmente no había historias de usuario de más de 5 puntos. ¿Y que era 1 punto, o 2 puntos, qué significaba eso? Buena pregunta, pues por ejemplo: Si sabes que un requerimiento similar que hiciste recientemente se estimó en el pasado en 2 story points, entonces por comparación, al ser esfuerzos similares, este también será 2. En cambio si pensaba que era aproximadamente la mitad de esfuerzo, entonces era 1 punto. En otro artículo más adelante, y ya basado en mucha experiencia en el tema, explicaré como hacer buenas estimaciones basandonos en esfuerzos.

¿Y cómo sabía el PO cuantó tiempo se tardaría en cada requerimiento? Bueno, inicialmente no lo sabía, aunque lo podía intuir por su experiencia previa en dicho equipo de Scrum, pero lo maravilloso de Scrum es que el equipo se compromete a tener todos los tickets incluidos en el sprint cuando este termine (2 semanas en nuestro caso), teniendo en cuenta que siempre hay cierto riesgo de no completar el sprint, y que lo que más probabilidad de terminar es lo que está más arriba en el backlog del sprint, y lo que más riesgo tiene son los elementos que ocupan las posiciones más inferiores.

¿Interesante verdad? Para mi lo fue, pero debo decir que esta forma de afrontar nuevos requisitos tiene muchas ventajas respecto a la forma clásica o tradicional, que espero tener tiempo de ir comentando en futuros artículos. Creo que ya he escrito bastante en este contando mis primeras impresiones :)

¿Recordáis vuestra primera toma de contacto con las sesiones de refinamiento basados en Scrum? 

Comentarios

Entradas populares de este blog

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

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í