Dijkstracciones: Scrum y XP: planificación de Sprint II

Scrum y XP: planificación de Sprint II: "

Despues de siglos sin escribir nada ya toca seguir con la serie de entradas sobre Scrum y XP, ultimamente he tenido mucho trabajo y poco tiempo para escribir, a partir de ahora espero volver a tener un ritmo más regular publicando entradas en el blog, bueno, al menos eso espero...

En la entrada anterior hablamos sobre la reunión de planificación de sprint, abordamos los requisitos previos que debian cumplirse antes de la reunión y la primera parte de la reunión, en esta entrada intentaré explicar la segunda parte de la reunión, en la que se lleva a cabo el trabajo realmente duro: planificar las historias

División de la historia en tareas

Las historias son funcionalidades definidas desde el punto de vista del product owner, en otras palabras, una historia debe ser algo que aporte valor al cliente, cosas como por ejemplo 'permitir que los usuarios se validen a través de un servidor LDAP'. Lo primero que hace el equipo con cada historia es dividirla en tareas ya desde el punto de vista tecnico para poder estimar mejor la historia. Por ejemplo el equipo podría dividir la historia anterior en cosas como:

Crear una nueva implementación de la interfaz de validación que utilize LDAP

Crear una nueva opción de configuración que permita elegir entre validación LDAP u otras

Sincronizar los usuarios del LDAP con los de nuestra base de datos

Una vez que la historia queda divida en tareas técnicas el siguiente paso consiste en estimar lo que nos costará realizar la historia. Aqui hay dos posibilidades:

Dividir N historias en tareas y luego estimarlas todas

Estimar una historia justo despues de dividirla en tareas

En nuestro caso preferimos dividir primero en tareas todas las historias que más o menos sabemos que entrarán en el sprint y luego estimarlas, si despues de la estimación vemos que cabe alguna historia más pues cojemos la siguiente del PB y la dividimos en tareas.

Estimación en puntos de cada tarea

Ahora pasamos a estimar en puntos cada tarea, la estimación de la historia completa es simplemente la suma de puntos de las tareas definidas para esta por el equipo. Para la planificación nosotros utilizamos la conocida tecnica de la planificación poquer (lo escribo así, porque si lo escribo bien el blog no me deja publicar la entrada..., y llevo toda la tarde pegandome con esto :P, supongo que será cosa del anti-spam o algo similar que no le gusta la palabra po.. ya sabeis...)

Esta tecnica es muy simple, cada miembro del equipo cuenta con un baraja con varias cartas como las de la imagen, el Scrum Master inicia la ronda de estimación para una tarea, cada miembro del equipo pone una carta sobre la mesa (boca abajo claro :P ) y cuando todos han decidido se levantan las cartas y se decide la estimación como el valor más aproximado a la media de lo que todos han dicho.

Mucho más importante que elegir el valor medio es la discusión que se produce entre los miembros del equipo cuando se ponen valores muy dispares, si por ejemplo alguien estima la tarea en un día y otro la estima en 5 esta claro que algo raro esta pasando, o bien el que estima en 1 día conoce alguna forma de terminar la tarea muy rapido (por ejemplo alguna librería que solventa el problema que el resto no conoce), o bien el que estima en 5 ha visto algún problema que del que el resto no es consciente (de integración con otros modulos, de viabilidad tecnologica o lo que sea).

Esto de la planificación poquer a algunes les parece 'algo poco serio', sin embargo yo creo que es todo lo contrario, mucho menos serio me parece cualquier estimación kilometrica tipo condena de las de 6 meses y un día... aunque le dejes al desarrollador una semana para que estime en detalle, da igual, no va a acertar, probablemente ni se acerque, y cualquier empresa tiene un historico de estimaciones desviadas que lo demuestra, así que despues de llevar años y años fallando en todas y cada una de las estimaciones que se hacen... ¿porque no intentarlon otros enfoques?

Nuestra experiencia despues de mas de un año usando este tecnica es muy positiva, si bien al principio nos equivocamos bastante hemos ido aprendiendo de los errores y ahora nuestras planificaciones son mucho más precisas. Que no quiere decir esto que acertemos siempre, no somos nostradamus, pero si ajustamos bastante bien y como mucho se nos puede quedar una historia fuera del sprint, evidentemente ayuda que las historias sean cortas y los sprints también sean cortos, de modo que si algo se queda fuera pues tampoco es ningún drama, será la historia menos prioritaria y estará lista para el siguiente sprint en dos semanas.

Definición de terminado de una historia

Otro punto critico es definir los criterios para dar una historia por terminada, en las tarjetas de cada historia dejamos un hueco para rellenar donde pone: '¿Como probarlo?', si se cumplen las condiciones que que se indiquen en el '¿Como probarlo?' más lo que hemos definido que tiene que cumplir cualquier historia damos esa historia por cerrada.

Esto que parece facil cuando uno lo piensa en la practica es bastante complejo, en definitiva cuando defines como probar una historia estas definiendo el alcance de la misma, y no simpere es facil, es importante ponerse a definir esto junto con el product owner porque pensando en como probar la historia surjen muchos detalles que ayudan a que se entienda mejor el alcance de la historia tanto por parte del product owner como por parte del equipo.

Por ejemplo para la historia del LDAP podría ser algo tan simple como 'entrar a la aplicación y cuando se nos pida usuario y password introducir los de un usuario creado en el LDAP, deberiamos poder entrar a la aplicación y en nuestra base de datos se crearía el nuevo usuario sincronizandolo con la información del LDAP'.

Fijaros que simplemente con la definición anterior pueden surjir varias dudas: ¿Que información debemos sincronizar?, ¿Cuando el usuario entre por segunda vez volvemos a sincronizar la información?, ¿Si ya tenemos un usuario en nuestra base de datos con el mismo nombre que otro de LDAP que hacemos?

Estas dudas las tendrá que resolver el equipo junto al product owner y decidir que hacer en cada caso completando y haciendo lo más precisa posible la definición de terminado. En muchas ocasiones nos ha pasado que creiamos haber entendido perfectamente una historia y al ponernos a definir esta parte nos hemos dado cuenta de que no teniamos la misma visión sobre la historia que el product owner. Una de las mejores cosas de esta reunión de planificación es precisamente hablar 'cara a cara' con el dueño del producto y no que todo se reduzca a un documento de especificaciones, por supuesto ambiguo.. siempre son ambiguos, que el equipo entiende como buenamente puede...

Además de el '¿Como probarlo?' de cada historia tenemos una serie de condiciones que tienen que cumplirse para dar cualquier historia por terminada, estas son generales a cualquier historia y deben cumplirse siempre:

Aceptación: El criterio de cómo probarlo está acordado, escrito, y el programa supera la prueba. Ultimamente hemos empezado a escribir primero las pruebas funcionales de aceptación antes de tirar uno sóla linea de código de la aplicación. Tenemos pendiente revisar herramientas como fitnesse o concordion para mejorar en este apartado

Pruebas: El código desarrollado supera las pruebas unitarias y la cobertura de pruebas ha sido revisada y considerada aceptable por el equipo.

Calidad del código: revisar que el código cumple con las normas de estilo definidas. Por lo menos verificar que añadido el nuevo código para la historia no se disparan las graficas de incumplimiento de normas de manera alarmarte. Para mejorar esta gestión estamos introduciendo el uso de sonar, magnifica herramienta por cierto.

i18n: El código desarrollado está internacionalizado. Es una caracteristica que se debe cumplir en toda nuestra aplicación, no tiene sentido definirla historia por historia como un criterio de aceptación.

Trazable: El código desarrollado tiene integrado el log.

Documentado: Existe una documentación de desarrollo sobre la historia.

Integrado: el código esta integrado con la rama principal de desarrollo y es posible descargarlo de algún lugar y ejecutarlo para probar la historia. Vamos que no vale con 'works on my machine', la historia debe estar integrada con el resto de la aplicación y funcionando.

Estas son las normas que nosotros mismo nos hemos impuesto cumplir para dar una historia por terminada, depediendo del contexto cada equipo debera definir las suyas. Esto que puede parecer mucha cosa para cada historia es fundamental si no queremos estar generando constantemente deuda tecnica, no se trata solo de terminar las historias, hay que terminarlas bien. Y es importante hacer entender esto al PO, que no son caprichos de desarrolladores quisquillosos, es que si no hacemos estas cosas luego lo vamos a pagar con un proyecto inmantenible donde añadir o modificar algo empieze a costar cada vez más y más. Me gusto una frase que lei el otro día no recuerdo donde 'El factor que más influye en la productividad de hoy es la calidad del código que escribiste ayer'

Problemas y malos habitos

Durante el año que llevamos aplicando estas tenicas hemos detectado algunos problemas que pueden echar al traste estas reuniones o convertirlas en totalmente improductivas:

El Product Owner no tiene claras la historias. Este es el mayor problema en estas reuniones, que el product owner no tenga claro que es exactamente lo que quiera, que solo tenga 'ideas vagas' y en cuanto el equipo empieza a preguntarle detalles no sepa responder adecuadamente. Cuando ocurre esto al final las reuniones se eternizan porque se dedica más tiempo a discutir el alcance de las historias (que el PO debería tener claro antes de acudir a esta reunión) que realmente en planificar las historias. Cuando ocurre esto el SM tiene que ponerle las pilas al PO para que haga su trabajo, y esto no siempre es facil porque es habitual que el PO sea alguien con más peso en la jerarquia de la empresa. Esto es habitual en organizaciones clasicas que se pasan al agilismo, pero bueno aqui el SM tiene que hacer uso de unos de los valores que exigia XP: 'el coraje' :P

Los miembros del equipo son de nivel muy diferente, esto nos es que sea un problema en si mismo, pero un desarrollador senior puede estimar algo en un punto y un junior en 5. Lo importante aqui es que el junior no se deje influir por las estimaciones del senior, si hacemos esto al final saldremos de la reunión con un sprint que podrían asumir 5 seniors, pero nosotros tenemos 1 senior y 4 junior!!. Cada cual debe tratar de ser sincero con lo que EL tardaria en terminar la historia.

Estimaciones para cubrirse las espaldas, la gente que viene de otros modelos tiende a sobrestimar (y a veces mucho) para cubrirse las espaldas, es importante dejar claro que en Scrum lo que importa es ser realista y si luego no se puede cumplir algo tampoco se viene el mundo abajo, estamos haciendo entregas parciales cada 2 o 3 semanas, si en una entrega parcial en lugar de 3 historias van 2 y se deja la otra para el siguiente sprint NO PASA NADA. Lo importante es que la gente no estime siempre 3 puntos más 'por si acaso' hay que evitar la cultura del castigo si no llegas a la estimación y fomentar una cultura de sinceridad y colaboración entre el equipo y el PO. Si hay confianza la gente dejara de usar las estimaciones como armas arrojadizas y dedicarse a dar cada uno su mejor esfuerzo por sacar las cosas adelante. Ya se que esto suena muy bonito pero en ciertas organizaciones es más utopico que otra cosa, pero bueno, hay que intentarlo!!.

Fin de la reunión y al tajo!

Cuando ya hemos estimado todas las historias que podemos acometer dentro del sprint (a veces estimamos una más por si luego tenemos tiempo) damos por finalizada la reunión, nos llevamos nuestras cartulinas a la sala de trabajo las pegamos en la pared y empieza un nuevo sprint!.

En las siguientes entradas trataré como llevamos el tema de las demos y la retrospectiva, una vez visto esto ya entraré en materia con la parte que más me gusta, las practicas puramente tecnicas como pruebas unitarias, integración continua y todas estas cosas.