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
Publicar un comentario