Nuestro primer sprint

 

Hoy Viernes hemos terminado nuestro primer sprint de una semana. Aunque he ido hablando sobre el scrum-sprint estos días, voy a hacer aquí un pequeño resumen de cómo ha ido y las conclusiones finales.

El Lunes hicimos el sprint planning y cogimos 4 historias de usuario, dos de un proyecto y otras dos de otro. La estimación para estas historia, fue de 20, 20, 13 y 40 (total 93). Luego las subdividimos en varias tareas.

El primer daily scrum (Martes) fue un poco decepcionante. Una tarea de 1 hora, consistente en instalar una nueva versión, llevó todo el día a la persona que la había cogido. Había gente (de otros grupos) que había metido cosas en CVS que no compilaban y hubo que "perseguirles" hasta conseguir que se arreglaran los fallos.

El segundo día (Miércoles) fue demasiado bueno. Una de las historias de usuario era corregir un paquete de incidencias y llevaron mucho menos tiempo del estimado.

El tercer día (Jueves) entró en lo normal, se termnaron las tareas esperadas y se comenzaron las últimas.

El cuarto día (Viernes) cerramos todas las tareas excepto dos de la última historia de usuario. Hicimos nuestra demo con el jefe de proyecto y se cumplieron tres de las cuatro historias de usuario (la cuarta, como comento, estaba inacabada).

En el sprint review, estas fueron las conclusiones:

  1. Al ser el primer sprint con scrum, comparamos la forma de trabajo con la anterior (que básicamente es cada uno va a su bola y se apañan como puede tirando de quien puede). La conclusión general es que todos trabajamos mucho más centrados, teniendo claro que tenemos que hacer y que la colaboración entre nosotros es más fluida, ya que estamos todos en lo mismo. En concreto, un miembro mencionó que de esta forma yo le hacía más caso. Mi excusa es que normalmente ando en mil lios, pero de alguna forma ahora tengo más claro qué lío es más prioritario.
  2. El problema del compilado ha surgido también en el segundo equipo de scrum en el que participo, así que parece que eso requiere que se le de una solución ya.
  3. Como pega de nuestra forma de trabajo ahora con Scrum, hemos visto que seguimos con la inercia de antes. De hecho, los miembros del equipo casi casi hicieron ellos solos cada una de las historias de usuario. Sí, colaboraron entre ellos, pero digamos que cada uno dedicó un 80% del tiempo a "su historia" y la causa principal es que dos de los miembros estaban tradicionalmente centrados cada uno en uno de los proyectos, así que cada uno de ellos cogió la historia de usuario de "su proyecto". Acordamos, que dentro de lo posible, en el próximo sprint, intentaremos centrarnos todos más en la primera historia, luego en la segunda, etc.
  4. También hemos visto que nos hemos dedicado a otras tareas fuera del sprint (interrupciones), pero que muchas de ellas podrían haber sido previstas con antelación.
  5. La última historia que quedó sin hacer, fue más un problema de "ingenuidad" que de problema real. De esa historia quedaron por hacer dos tareas… ¡ que no son de nuestro grupo !. Nosotros programamos en java y esas dos tareas son de una persona de otro departamento que programa en ADA (y de hecho, esas dos tareas son de codificar en ADA). El responsable de producto y esa persona son del mismo departamento y el responsable de producto nos transmitió la urgencia de esa historia de usuario, por eso se metió en el sprint. Nuestra "ingenuidad" fue no haber metido/hablado con esa persona y su disponibilidad, haberla metido en el grupo de Scrum, o directamente "capar" la  historia para que fuera "todo menos esas dos tareas". En fin, marcamos la historia como no cumplida y así aprenderemos de nuestros errores.
  6. Parece que va a ser problemático preparar demos cada semana, ya que de cinco días, entre el planning y las demos, casi perdemos dos. Menciono la existencia de Kanban y se menciona la posibilidad de hacer sprints de dos semanas, pero con planning de lunes a lunes. De momento decidimos hacer otro sprint más con demo el Viernes.

Aquí el gráfico con las historias acabadas, en el que vemos la última sin terminar

sprint terminado

y aquí nuestro burndown chart, en el que vemos el asombroso avance del segundo día al ser las incidencias más sencillas de lo esperado. Sin cumplir las 16 horas de la última historia de usuario que debería haber hecho la persona del otro departamento, que, por cierto, no va a estar disponible hasta mediados del mes que viene. En cualquier caso, parece da la impresión de que fuimos optimistas estimando y que nos ha "sonado la flauta" con esas incidencias, que nos han permitido terminar el sprint con cierta dignidad.

burndown chart

El lunes debemos empezar nuestro segundo sprint, pero se nos presenta un problema: uno de los miembros tiene el día ocupado con otra cosa. O prescindimos de él, o hacemos un mini planning para empezar el Lunes con los que estamos y hacemos el planning en serio el martes.

Esta entrada ha sido publicada en scrum y etiquetada como , . Guarda el enlace permanente.

3 respuestas a Nuestro primer sprint

  1. JC dijo:

    Sobre tus dudas, dos consejos, basados en mi experiencia con scrum.

    – la planeacion se debe hacer el dia señalado, esté quien esté. a no ser que la mayoria este ocupado con otras cosas, se debe plantear el cambio de dia (lo hemos tenido que hacer solo en una ocasion).

    – Respecto al orden de insercion en el sprint, lo que hacemos es colocar las historias, partirlas en tareas y estimar cada una de ellas. al final, se decide si una historia permanece en el sprint, se elimina, o se planean tareas para dos o mas sprints.

    Me gusta la idea del poker, voy a proponerla a mi grupo a ver que opinan.

    Saludos . jC

  2. ¡Enhorabuena! No ha estado nada mal, por lo que se ve.

    Para el lunes, calculad la velocidad de este sprint (sospecho que 53 puntos correspondientes a las 3 primeras historias) y sumadle un poquito porque, por lo que cuentas de la historia incompleta, podríais haber hecho un poco más. Coged historias del backlog hasta estos ¿70 puntos? Salvo que metáis en el equipo al programador en Ada, que puede ser un poco «chungo» si es que sólo programa en Ada.

    Te digo todo esto porque es muy importante adquirir «velocidad de crucero» y ser conscientes de cuál es. A partir de tener un ritmo constante de trabajo se pueden plantear incrementos sostenibles de productividad.

    ¡Ánimo!

  3. Pingback: Diario de Programación » Blog Archive » Ventajas de la reunión diaria

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.