RS: planificación de sprint

Nuestros sprints son de una semana, empiezan el lunes y terminan el viernes. Planificamos en el daily standup meeting del lunes por la mañana. Pero el daily no queremos que pase de los 20 minutos (mejor seria no pasar de los 15). Asi que las últimas dos semanas, terminabamos el meeting sin haber cerrado la planificacion semanal, sin tener las tareas estimadas y por tanto, sin conocer cuál era el objetivo a cumplir. Eso hace que al terminar la semana no sepamos si lo hemos hecho mejor o peor. Dejamos de ser predecibles cuando pasa esto.

Por este motivo, la reunion del lunes podrá estirarse hasta un máximo de una hora con tal de que todos podamos estimar y comprometernos a entregar determinada funcionalidad el viernes, o por lo menos a intentarlo.

Aunque nuestra hora de meeting son las 9.30am, el lunes desplazaremos la hora lo que haga falta para que estemos todos. Esta semana faltaron personas que al no estar en el meeting de planificación no pudieron aportar su conocimiento. Eso llevó a que yo escogiera como prioritaria una tarea que en realidad no lo era, porque ya teniamos una funcionalidad parecida, hecha en código existente pero no lo sabíamos. Era una funcionalidad que conocía la persona no estaba. La tarea que se ha implementado hacía falta pero no era tan prioritaria en el sprint de la semana que ha terminado.

Por otro lado existe preocupación porque no estamos colocando las clases en los namespaces más adecuados, ni los ficheros en las carpetas adecuadas. El problema es que si no están en un lugar intuitivo podemos repetir funcionalidad. Para esto la code review juega un papel importante, por lo que hay que seguir haciendo incapié en ella. A parte de eso, la persona que detecte que se ha puesto un fichero en el sitio incorrecto o un namespace que no corresponde, debe actuar de manera concreta, bien modificando el código o bien avisando por email a los compañeros, diciendo exáctamente por qué no es correcto y cómo solucionarlo.

En el código legado sigue habiendo horrores que nos están haciendo daño pero la preocupación por la ubicación de clases y ficheros es un tema recurrente así que vamos a intentarla solventar, tomando acciones concretas y constructivas.

Esta semana hemos resuelto graves problemas de concurrencia que teníamos. El trabajo ha sido duro porque hemos invertido mucho tiempo y escrito pocas líneas de código y eso da mala sensación, pero el resultado es muy bueno. Hemos aprendido bastante y sabemos qué cuestiones debemos considerar desde ya, para que nuestro código esté preparado para la concurrencia. Escribiré un post sobre nuestros descubrimientos con Linq2Sql y concurrencia pronto.

En las últimas semanas hemos hecho muy poco pair programming porque buena parte del equipo pensaba que así avanzaríamos más teniendo la fecha de entrega muy cercana. La realidad es que no podemos cuantificar si ha salido adelante más trabajo o no, pero lo que sí hemos hecho es introducir deuda técnica y aumentar en desconocimiento de lo que los demás hacen, lo que lleva a la duplicidad del código. Falta comunicación. Sabemos que la próxima semana volvemos a nuestro ritmo habitual, intentando hacer las cosas lo mejor posible y sabiendo que cuando dos personas trabajan juntas y bien concentradas, nos acercamos más a ello.

 

Enjoyed reading this post?
Subscribe to the RSS feed and have all new posts delivered straight to you.
  • http://www.carlescliment.com Carles

    Hola Carlos.

    En primer lugar, felicitarte porque muy pocos equipos son capaces de hacer sprints de una semana. ¡Vaya ritmo!

    Hay dos cosas que llaman la atención de este post; la primera es que terminéis la iteración un viernes. ¿Significa que desplegáis siempre el último día de la semana? Supongo que vuestros clientes no necesitan soporte los fines de semana, en caso contrario, ¿sería mejor terminar cualquier otro día el sprint?

    Otro de los puntos chocantes, y este creo que es grave, es que falten miembros del equipo en los daily meetings. Si no han sido casos aislados y excepcionales, creo que es una de vuestras prioridades para los próximos sprints. Los daily meetings son sagrados!

    Muchas gracias por compartir vuestros éxitos y dificultades.

  • Adrián Perreau de Pinninck

    Carlos, trabajáis todos en el mismo sitio o distribuidos. Yo no tengo cojones a hacer sprints de 1 semana en un equipo distribuido.

  • http://www.carlosble.com Carlos Ble

    Hola!
    Carles nosotros nos comprometemos a que el viernes podemos subir a UAT (preproducción) software que aporta valor al negocio. Pero eso no significa que el viernes se ponga en produccion. Nuestros requisitos son tan cambiantes que a la semana siguiente hay que agregar o modificar comportamiento antes de la subida a produccion.
    En cuanto a la ausencia en el meeting, se debiá a baja por enfermedad 🙂

    Tened en cuenta que NO hacemos scrum, no son sprints de scrum. Simplemente el lunes vemos qué tareas hay por hacer, estimamos lo que creemos que podemos tener para entregar el viernes, y trabajamos duro toda la semana para tenerlo. Hay veces que el jueves paramos de añadir funcionalidad, el viernes se prueba en UAT y el mismo viernes por la noche se pone en produccion. Los fines de semana apenas tenemos usuarios.

    El equipo no está del todo distribuido, solo teletrabajo yo. Trabajamos en el mismo horario haciendo pair programming remoto. Creo que no sufrimos ninguno de los males de los equipos distribuidos.

    Gracias por el feedback 🙂

  • https://twitter.com/DaniOrtube dani ortube

    Hola, hoy hemos hecho la reunión de planificación de Sprint os cuento como ha sido:

    Antes del meeting de planificación, los dos product owners, Guillermo y yo, hemos elegido las tarjetas que necesitamos esta semana.

    Como acción de mejora de la retro del viernes, salió que antes del meeting todos nos leeríamos las historias de usuarios para estar en contexto y hacer más efectivo el meeting, así que le hemos dedicado 15 minutos cada uno individualmente.

    En el meeting, hemos repasado cada tarjeta y la hemos estimado sacando dedos. No ha sido difícil llegar al consenso

    Una vez que estaba todo estimado hemos hecho la suma en horas y lo hemos contrastado con nuestra capacidad. (Contamos que cada pareja rinde 6 horas/día)

    Hemos dedicado 2 horas, nos hemos sentido totalmente centrados y que ha sido fluido.

    Hemos incluido todas las necesidades que los PO necesitaban y todo el equipo estaba muy contento después

    Como mejora para la siguiente: todavía ha habido alguna tarjeta (este también es un aspecto que estamos mejorando de anteriores Retros) que le ha faltado mayor claridad en los ejemplos de validación y ha dificultado la estimación.

    También adelantar la hora del meeting que hoy hemos empezado a las 11.30 y casi se nos junta con la comida. Intentaremos que sea antes y un poco más corto para empezar a darle caña antes.

    Veremos al final de la semana como ha ido 🙂