Fin del Sprint

El viernes debíamos cerrar el sprint, pero tuve que irme a Donosti por una boda, así que lo retrasamos a ayer lunes.

Al final casi logramos los objetivos. Solamente nos fallaron la tarea de la gestión del CPD (COLT, BT, TelVent), que se está alargando muchísimo, y la del L&F inicial, que el diseñador va saturado y no nos ha podido entregar las primeras maquetas.

Lo demás muy bien, acertamos bastante en las estimaciones. En eso ayuda el definir historias muy cortas (divide y vencerás!), la experiencia de cada uno y el hacer la estimación individualmente y discutirla en grupo. Así se aclaran dudas, salen a la luz potenciales problemas… Pero ya veremos en la siguiente.

Para el resumen del sprint convocamos a Carlos (coordinador del proyecto) y Roger (marketing) a que vieran la demo de lo que habíamos hecho, con el objetivo de que pudieran identificar carencias o simplemente pudieran tener una visión real del producto. Implicar al “Cliente” es fundamental en la metodología Scrum, y el poder ver cuanto antes el avance es muy importante.

El motor de recomendaciones tiene una calidad suficiente, similar a Amazon (según dicen). Tengo implementados dos métodos, el User Based Recommendation (USB) y el Item Based Recommendation (ITB). Dando el primero un mejor resultado, aunque me temo que cuanto más eventos tengamos, el USB irá a peor.

Como errores han salido el que no hemos definido correctamente lo que queríamos hacer. Nos pusimos a saco y a mitad de desarrollo nos dimos cuenta que no sabíamos a dónde íbamos. Para este sprint actual tenemos pocas historias funcionales, pero estas pocas las definiremos mejor.

El diagrama BurnDown funciona muy bien como indicador de progreso, es muy clara en cuanto al avance del trabajo.

Y el Product Backlog, aunque extenso, lo he refactorizado para que sea más claro y útil. Nos muestra, según las estimaciones iniciales, los story points totales del proyecto, que al comparar con los reales (nos quedan muy pocoso días hasta la salida a producción!) ya vamos viendo que debemos cerrar las funcionalidades de esta release.

Por último, además del Backlog y de los tickets en el Redmine, llevo el mantenimiento del GANTT para identificar hitos, asignaciones, fechas… Son 3 mantenimientos de la misma información y la verdad que es costoso. No hay alguna forma DRY de gestionar las múltiples vistas del proyecto?

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *