Scrum y XP: planificación de sprint I
Seguimos adelante con la serie de artículos dedicados a Scrum, una vez que conocemos el proceso de scrum y los distintos roles que participan en un proyecto Scrum ya podemos ir entrando en más detalle en las distintas practicas. Para empezar vamos a ver como se desarrolla una reunión de planificación de sprint.
De todas las reuniones de Scrum la de planificación de sprint es la más "dura" y la más larga, como hay muchas cosas que contar he dividido esta entrada en dos partes, en esta primera me centrare en los requisitos previos antes de empezar la reunión y la primera parte de la reunión donde se definen aspectos generales del sprint, en la segunda parte (que espero publicar en breve) entraré a explicar el método de planificación que seguimos para las historias y sus tareas.
Objetivos de la reunión planificación de sprint
El objetivo de esta reunión es claro: seleccionar una serie de historias del product backlog y construir con ellas el sprint backlog, es decir, la lista de historias sobre las que el equipo de desarrollo trabajara durante el sprint que terminará con la demo donde se demuestren las funcionalidades implementadas
En esta reunión el product owner y el equipo deben ponerse de acuerdo en que historias se implementarán durante el sprint. El product owner informará al equipo de que tareas son más prioritarias y el equipo estimará estas tareas para determinar cuantas se pueden abordar dentro del tiempo de duración de sprint. Esta reunión supone un compromiso entre las partes, el product owner se compromete a no interferir en el desarrollo del sprint (no introducir nuevas historias o modificar sobre la marcha el alcance o la descripción de otras) y el equipo se compromete a intentar sacarlas adelante.
A partir de ahora intentare ir detallando paso a paso como llevamos a cabo estas reuniones:
Paso 0: Pre requisitos, ¿que necesito antes de empezar la reunión?
Un sala de reunión:
Parecerá obvio, pero alguien se tiene que encargar de reservar una sala :P, esto es tarea del scrum master. Es importante tratar de encontrar un lugar donde reunirse sin interrupciones y si es posible con algún aprovisionamiento en forma de refrescos y algo de picar jeje, que suele ser larga (esto ultimo no es imprescindible pero puede ser buena idea :P )
Asegurarse que todos los interesados asistan:
De nuevo parece obvio, sin embargo es una tarea importante ajustar la agenda de todo el mundo para que puedan asistir todos los interesados. Es fundamental que el product owner asista a esta reunión, de echo se podría decir que el product owner es el "protagonista principal", es donde se va a decidir que se va a hacer con su producto así que debe estar presente si o si. Si se quiere hacer scrum hay que tomarse muy en serio estas reuniones y todos los involucrados deben ser conscientes de eso para ajustar sus agendas y posibles compromisos de modo que estén disponibles en estas reuniones. A esta reunión debe asistir el PO, el SM y todos los desarrolladores, también pueden asistir otras gallinas pero no pueden participar en la reunión, sólo como observadores.
En nuestro caso estas reuniones son como una "liturgia", nadie se las pierde y todos somos conscientes de su importancia, nuestro product owner actual es un "creyente" de scrum y fue uno de sus principales impulsores. Sin embargo en otros casos quizas lo más dificil sea conseguir que el product owner se involucre con el equipo, esto es facil que ocurra en organizaciones que estén empezando con scrum y la figura de product owner la ocupen jefes de proyecto, jefes intermedios o incluso comerciales que viven lejos del equipo de desarrollo. Es fundamental para el éxito de cualquier proyecto scrum tener un PO implicado y consciente de sus responsabilidades en el proyecto, que asista con rigor espartano a todas estas reuniones. Que no nos ocurra eso de que el PO llama a ultima hora que no puede venir porque tiene tal o cual compromiso y luego a las dos semanas vuelva a aparecer para decir que no esta de acuerdo con el sprint backlog, preguntate si tu product owner es una gallina. (creo que me encanta scrum por poder usar estas expresiones :P)
Un product backlog priorizado:
El product owner debe hacer sus deberes antes de esta reunión, es necesario disponer de un product backlog priorizado antes de empezar. Normalmente no se tienen sólo las tareas que se pretenden incluir en el sprint sino algunas más ya que dependiendo de la dificultad de las tareas y la estimación de los desarrolladores puede ser posible incluir más de las el product owner tenga previsto, o menos por supuesto.
Otro problema habitual en equipos nuevos con scrum es que el PO no sabe expresar lo que quiere en forma de historias, podríamos dedicar una entrada entera para hablar de que es y que no es una buena historia, algunos pequeños consejos:
- Las historias deben tener un alcance bien definido, por ejemplo algo como ”La aplicación debe integrarse con aplicaciones de contabilidad existentes en el mercado" no es una buena historia, habrá que definir con cuales!, y habrá que definir que se entiende exactamente por "integrarse".
- Las historias tiene que ser funcionalidades pequeñas y concretas no divagaciones, se trata de ir añadiendo funcionalidad poco a poco, historias del tipo "El sistema debe disponer de mecanismos de seguridad a la altura de los mejores del mercado" no es obviamente una historia valida.
- Las historias deben decir "el que" y no "el como", cada uno a lo suyo vamos, historias tipo:”La aplicación escribirá trazas de la actividad de los usaurios usando log4j” tampoco son buena idea. El equipo que es quien entiende de cosas técnicas toma decisiones técnicas, el PO que es quien sabe del negocio toma decisiones de que tiene que hacer el producto para aportar valor al negocio. Exceptuando casos donde la tecnología elegida sea parte del valor que aporta el producto suele ser mala idea que un PO tomo decisiones técnicas para las que normalmente no esta preparado
La tarea sin duda más dura de la planificación es convertir las historias en cosas que puedan ser estimadas por el equipo y incluidas en un sprint backlog, la parte crucial de esta reunión es precisamente que el equipo y el PO salgan con las ideas claras de lo que se va ha hacer y lo que no durante el sprint.
Ahora que ya lo tenemos todo, vamos a empezar la reunión!
Paso 1: Definición del sprint
Lo primero es definir en lineas generales el sprint, esto implica definir varias cosillas, normalmente nosotros lo hacemos en este orden:
Ponerle nombre al sprint
Se trata de elegir un nombre corto que sintetice lo mejor posible la tarea que se va ha desarrollar en el sprint, por ejemplo: "Definición e implementación de un API's SOAP de acceso al sistema". La idea es que este nombre sirva para explicar rápidamente al resto del mundo en que estamos trabajando y para tener todos un objetivo común claro en la cabeza, que cualquiera se acerque a la sala del equipo de desarrollo y con solo leer el nombre ya tenga una idea de a que esta dedicada la gente.
Un efecto muy positivo de poner buenos nombres a los sprints se empieza a notar cuando llevas unos cuantos y con un sólo vistazo a la lista con los nombres de los sprints realizados tienes un histórico fenomenal del trabajo realizado por el equipo en los últimos meses y de la dirección que se ha ido siguiendo en el desarrollo del producto. Es habitual que alguien solicite en algún momento un histórico de este tipo para saber en que ha ido trabajando el equipo, nosotros antes de utilizar scrum teníamos que recurrir a una mezcla de cosas para poder dar esta información, cosas como: los logs de subversión, las entradas en la herramienta de inputación de horas, diagramas de gannt normalmente desactualizados con más mentiras que verdades :P, y por supuesto a la memoria de cada uno de los desarrolladores..., agitese todo esto y obtenga su histórico.
El calendario del sprint
En primer lugar definimos la duración del sprint, aunque la recomendación es que todos tengan idéntica duración en nuestro caso la duración de los sprint la variamos unos pocos días hacia arriba o hacia abajo sobre todo en función de donde caiga el día de la demo (tratamos de evitar demos los lunes :P, nuestro día preferido para la demo es el viernes) o bien intentamos que el fin de sprint no coincida con días libres o vacaciones de algún miembro del equipo (no siempre se puede claro esta, pero tratamos en la medida de lo posible de estar todos para la demo). Normalmente nos suelen quedar sprint de entre 3 y 4 semanas
Una vez definida esta duración implícitamente hemos definido el día de la demo: un día después del fin de sprint. La retrospectiva la hacemos el mismo día de la demo, las demos suelen ser a las 10 de la mañana con una duración de aproximadamente una hora, el resto del día lo usamos para la retrospectiva y lo que surja (siempre hay cosas que hacer o irse mirando). También fijamos la fecha de la siguiente planificación de sprint, normalmente es el día después de la demo, aunque en ocasiones hemos dejado un día entre retrospectiva y planificación, casi siempre por cuestiones de agenda.
Calculo del número de puntos disponibles:
Utilizamos "puntos" para realizar las estimaciones, es decir, no decimos "esta tarea son 23,3 horas" sino que decimos "esta tarea son 2 puntos". En nuestro caso hemos echo la equivalencia de "un punto = un día ideal de trabajo", esto es, lo que consideramos daría tiempo en ocho horas ininterrumpidas de trabajo.
Una vez ya hemos definido los días de duración del sprint se pregunta a cada desarrollador su previsión de disponibilidad, aunque lo ideal es que todo el mundo este al 100% involucrado en el sprint esto nunca ocurre, siempre surjen cosas, por ejemplo "tal día tengo que asistir a una reunión con unos clientes" o "tal día voy a una conferencia de no se que", o "tengo que ayudar en otro proyecto". También es necesario considerar el tiempo empleado en la resolución de incidencias de versiones anteriores del producto que tengan prioridad máxima y haya que arreglar. Con todo esto en mente cada desarrollador indica en porcentaje su tiempo de dedicación durante el sprint. Luego se toman estos datos y se aplica la siguiente sencilla formula para obtener los puntos disponibles en el sprint:
(días de sprint*porcentaje de dedicación(desarrollador1))+...+(días de sprint*porcentaje de dedicación(desarrolladorN))*Factor de Corrección
El factor de corrección es simplemente un número entre 0 y 1 que simboliza el porcentaje de tiempo de un día de trabajo que realmente se aprovecha, dado que los puntos son días ideales y los días nunca son ideales ester porcentaje sirve para afinar un poco mejor la planificación. Nosotros actualmente utilizamos un 0,7
Posteriormente en la segunda parte de la reunión se pondrán puntos a cada tarea y se meterán en el sprint las que de tiempo, normalmente nunca sale exacto, nosotros solemos incluir una o dos más de las que realmente entran.
Definir el concepto de sprint terminado
Esta es una practica que estamos empezando a aplicar en los últimos sprint, igual que cada historia tendrá una definición de terminado el sprint también necesita una. Hemos detectado que sistemáticamente terminábamos los sprint de forma muy "atropellada", es decir, llegamos muy justos terminando historias y descuidamos algunas tareas que no son propias de ninguna historia concreta pero que si lo son para dar el toque final al producto y dar por cerrado un sprint. Por ejemplo actualmente manejamos una lista como esta:
- El código de todas las historias desarrolladas en el sprint integrado en la rama principal del sistema de gestión de versiones. Habitualmente trabajamos en un branch durante el sprint y mezclamos con el trunk al final del sprint, en ocasiones también hemos creado branch para algunas historias concretas, pero independientemente de la política de branches que tengamos (que explicaré más adelante en otra entrada) al final del sprint el código de todas las tareas tiene que estar integrado en la rama principal, es decir, lo que no este en la rama principal no esta en el producto. Esto implica que la demo se hace con el producto que hay en la rama principal, una practica poco recomendable es hacer las demos con productos no integrados en la rama principal o peor aún, con código que sólo esta en el equipo de un desarrollador concreto y no esta en el control de versiones.
- Revisión de métricas: de ajuste a la guía de estilo (checkstyle), posibles errores (findbugs), de código duplicado (simian) y de cobertura de pruebas. Antes de dar un sprint por terminado revisamos que todas estas métricas siguen en números aceptables, aunque esto es algo que hay que hacer en el día a día hemos definido esto para antes de cerrar un sprint darle un ultimo vistazo.
- Verificación de la corrección de los entregables:Verificar que el entregable esta correcto, el entregable puede ser algo tan sencillo con un .jar o un .war o bien puede ser un instalador complejo con múltiples opciones. Es habitual que sólo verifiquemos que los productos en desarrollo funcionan pero luego nadie se preocupe de instalarlo en un equipo "limpio" y verificar que todo esta bien
- Desplegar la aplicación en servidores de pruebas, al final de cada sprint montamos la aplicación en varios servidores de pruebas (en nuestro caso concreto tenemos que ser compatibles con varios) y contra varios SGBD (MySQL, Oracle y SQLServer actualmente) y la dejamos montada para que cualquiera pueda acceder a la ultima versión.
- Escribir un guion para la demo, la demo si queremos que salga bien hay que prepararla aunque sea simplemente escribiendo un pequeño guion de que vamos a contar, en que orden, a que nivel de detalle etc,etc.
Esto son sólo ejemplos de cosas que hacemos en nuestro equipo de desarrollo antes de cerrar un sprint, cada equipo tendrá diferentes items en esta lista, sin embargo es importante tener esta lista para ser conscientes de que tareas hay que hacer para dar un sprint por cerrado, por nuestra experiencia si estas tareas no se hacen explicitas al final lo que ocurre es que sencillamente no se hacen o se hacen a medias.
Y con esto damos por cerrada la primera parte de la reunión, a continuación empieza lo duro de verdad :P, ir planificando cada una de las historias y discutiendo los detalles de estas con el PO, en la siguiente entrada os contare como o hacemos.