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
Cada día iba descubriendo algo nuevo de Scrum, por un lado el aire que se respiraba en la oficina bajo Scrum parecía menos tensionado o estresado que en otras oficinas sin metodologías ágiles, lo cual era bastante bueno, sin embargo cuando el sprint llegaba a su fi, los días anteriores, es cierto que algunas veces se respiraba más agobio, pero nada preocupante. El trabajo se organizaba en periodos bi-semanales, llamados sprint. Cada sprint arracanba y terminaba el mismo día de la semana, cada dos semanas. ¿En qué se trabajaba en un sprint? Para contestar a esta pregunta hay que hablar de lo que es un sprint planning, en siguientes artículos hablaré más detenidamente sobre esta sesión, ahora contaré mis impresiones de lo que viví. Nos reunimos todos, desarrolladores, QAs, y el producto owner. Este último empezó repasando el sprint actual, que se estaba a punto de cerrar, para ver si se había terminado todo el trabajo, o quedaba algo por finiquitar. Lo que no se había podido terminar por