Exprimiendo Scrum: Scrum y el control del proyecto (I): el avance
Un aspecto clave en la gestión de proyectos ha sido, es y será el control del proyecto. Dentro del control del proyecto se consideran una gran variedad de aspectos, diferentes según el autor que se consulte, pero hay dos que destacan de manera clara sobre el resto: el avance y la visibilidad. Es evidente que existen otros aspectos relacionados con el control del proyecto, pero me centraré en esos dos. En este primer post hablaré sobre la avance y en una segunda entrega, hablaré sobre la visibilidad.
Pensad un poco, cuando un gerente o un comercial o un director se acerca a los implicados en un proyecto ¿qué es lo que siempre pregunta?. Las dos grandes preguntas que todo equipo de desarrollo responde continuamente son: ¿Está hecho ya? ¿Cuánto queda para que este hecho? Da igual si esto se aplica a tareas, requisitos o el proyecto entero, esas son las preguntas que siempre respondemos. Se hace evidente que si esta es la realidad, sería conveniente adecuar lo que nuestra metodología aporta a esta realidad. Las cuestiones antes comentadas parecen simples de responder, pero, ¿en cuántos proyectos estas preguntas encuentra una respuesta clara?.
Scrum se apoya en dos conceptos clave para darnos las respuestas que necesitamos: el concepto de 'hecho' y la velocidad como principal métrica.
El concepto de hecho
En la gestión de proyectos, uno de los aspectos que siempre se han remarcado es que tanto las tareas (unidad básica de gestión de proyectos) como las historias de usuario, escenarios, requisitos o casos de uso (unidad básica de liberación de valor de los proyectos) deben ser binarias. Es decir en esencia tenemos que poder distinguir si están completadas o no. Una puerta solo puede estar cerrada o abierta, una tarea o un requisito solo pueden estar completados o no. Las tareas y los requisitos que no están completadas no suman valor, no añaden progreso al proyecto. Esto se hace evidente si tenemos en cuenta que el 10% final de toda tarea o requisito se lleva el 90% del tiempo. ¿Cual es el progreso de un requisito descompuesto en cinco tareas si todas ellas están al 90% de progreso si lo miramos desde el punto de vista del valor liberado para el cliente? ¡Cero!. En las metodologías ágiles y por lo tanto en Scrum, la principal métrica de progreso es el valor liberado para el cliente. Recordemos uno de los principios del manifiesto ágil: 'El software que funciona es la principal medida del progreso'.
Otro aspecto relevante es tener en cuenta que el nivel de hecho no es igual para todos los proyectos de Scrum. En la gran mayoría de las implantaciones de Scrum en las que participo el nivel de hecho viene definido de manera estándar de un modo similar al siguiente: una historia de usuario se considera hecha si el código esta escrito, se a compilado correctamente en una build de integración diaria, todas las pruebas unitarias se han ejecutado satisfactoriamente y con cobertura suficiente, el tester ha realizado al menos las pruebas de humo en una build que integre el escenario, y el tester ha comprobado que el escenario ha pasado las condiciones de aceptación establecidas inicialmente por el producto owner. Evidentemente este nivel de hecho puede ser o no suficiente. Algunos proyectos en los que he participado añaden nuevas condiciones: que el manual de usuario incluya la documentación necesaria para la historia, que todas las pantallas de la historia estén traducidas, que las haya revisado el departamento jurídico… Establecer lo que entendemos por hecho es algo que debemos establecer de manera explicita en todo proyecto de Scrum. Se trata de una condición imprescindible para poder confiar en las métricas de progreso que recopilemos.
La velocidad es la clave
En las metodologías ágiles, la velocidad de desarrollo, entendida como el trabajo realizado frente al trabajo que hemos estimado que nos queda por hacer es la principal métrica. Utilizar la velocidad como principal métrica está fundamentado en que incrementos en este aspecto del desarrollo son síntoma claro de mejora del proceso de desarrollo. Si desarrollamos más rápido, es que desarrollamos mejor. Además es una métrica difícilmente sesgable, problema habitual cuando trabajamos con métricas, si para mejorar la velocidad de desarrollo sacrificamos por ejemplo la calidad, olvidándola, o el equipo, forzándole por encima de su capacidad o cualquier otro aspecto, tarde o temprano esto se verá reflejado en la velocidad. Además la velocidad es una métrica que nos permite estimar con facilidad cuando el proyecto estará concluido o que magnitud de funcionalidad se debe quedar fuera para cumplir una fecha concreta.
Implantar una métrica de progreso clara, nos permite informar a partes ajenas al desarrollo de cuál es el comportamiento del proyecto de manera analítica, explícita y difícilmente rebatible. Esto hace que el resto de los afectados por un proyecto puedan actuar en fase a datos. Los comerciales no comprometen fechas imposibles, los redactores técnicos pueden planificar cuando podrán comenzar a capturar pantallazos de la documentación, el departamento de calidad final sabrá cuando debe esperar carga de trabajo relacionada con nuestro proyecto, etc… No es lo mismo contarle a tu jefe que crees que el proyecto va retrasado que enseñarle un burndown chart que muestra sin lugar a dudas que el proyecto va retrasado… En el primer caso la respuesta será 'Hombre, Rodrigo, mira que eres pesimista hombre, si ese retraso, que yo no creo que exista, lo solucionáis vosotros con trabajo duro' y tu sales del despacho de tu jefe con cara de que has caído otra vez en el juego de las bolitas de los trileros… Lo bueno de las métricas claras es que ¡hasta tu jefe las entiende!, son datos, no sensaciones y son difícilmente rebatibles.
Mirad el burdown chart que muestra la imagen que ilustra el post. En el eje X tenemos el trabajo que hemos estimado que nos queda por hacer. En el eje Y tenemos los 20 sprints con los que contamos para completar la funcionalidad. Ahora mismo hemos completado el sprint 10, si duda se trata de un momento excelente para hace una replanificación. Viendo la línea de tendencia (línea morada discontinua) se hace evidente que no vamos a completar todo el trabajo que estimamos que nos queda. Estamos alejados de la línea idea (línea verde fina), y lo que es peor, no parece que converjamos hacia ella. Se hace visible para cualquiera que no vamos a completar toda la funcionalidad. Es más, según el gráfico, al ritmo que vamos, no vamos a completar requisitos por al menos 60 puntos de estimación (punto final de la línea de tendencia). Los números nos dan la verdad, absoluta, irrebatible… incluso para tu jefe :). 'Donde no ha mata no hay patata' que dicen en mi pueblo.
En esta situación se hace evidente que lo único que podemos hacer para completar toda la funcionalidad son dos cosas: alargar la duración del proyecto o mejorar la velocidad.
Alargar la duración del proyecto es siempre una mala idea y un mal síntoma. Es una mala idea, porque si movemos la fecha de fin estamos lanzando un mensaje erróneo al equipo de desarrollo: no pasa nada si os retrasáis… y la realidad es que cuando los proyectos se retrasan siempre pasa algo. Inevitablemente el equipo de desarrollo se va a 'relajar'. ¿Recordáis lo que pasaba cuando os alargaban la fecha de un examen? Yo llegaba igual de bien o del mal preparado… Es un mal síntoma, porque ¿realmente necesitamos toda la funcionalidad? Vale que sí, que nos creemos que la necesitamos… ahora pensad en el proyecto de más éxito en el que hayáis trabajo… ¿Entregasteis TODA la funcionalidad? ¡Probablemnte no!, pero si ¡entregasteis toda la funcionalidad más importante!. Si nos vemos en la necesidad de alargar un proyecto es porque hemos cometido un error de base: no nos hemos centrado en liberar primero la funcionalidad que mayor valor tenia para el cliente. Recordad: 20% de la funcionalidad 80% del valor… pero claro para esto debemos haber priorizado por el valor. Si nos vemos en la necesidad de alargar el proyecto es porque no hemos liberado la funcionalidad importante en primer lugar. Recordemos de nuevo los principios del manifiesto ágil: 'Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor'.
¿Cómo podemos mejorar la velocidad? Pues no hay balas de plata en esto. Es muy difícil mejorar la velocidad a saltos, la velocidad se mejora en pequeños incrementos no en grandes saltos. ¡Ahora necesitamos un gran salto!... Que no va a ocurrir… Asumámoslo… Si somos responsables solo podemos pensar en recortar funcionalidad por 60 puntos de estimación. Puede parecer traumático, pero no lo es… ¡si hemos hecho primero aquellas partes que más valor liberan para el cliente del proyecto!. Es muy probable que el cliente ni siquiera note que hemos recortado la funcionalidad… los clientes perciben y miden valor… no funcionalidad.
A veces, puede ocurrir que el burndown chart del proyecto muestre que vamos sobrados... al menos en teoria... en la práctica yo no lo he visto, así que ni comentaré la situación. Si os véis en esa situación, enhorabuena, por una vez váis a acaba el proyecto antes de tiempo y sin recortar absolutamente nada de funcionalidad...
Resumiendo: el concepto de hecho y la velocidad como métrica nos van a permitir medir el avance de nuestro proyecto de una manera analítica, basada en datos, que exige poca burocracia y que nos permite tomar decisiones informadas en lugar de decisiones basadas en percepciones.
Evidentemente para que este enfoque funcione tenemos que tener un proceso explicito, sano y ágil de estimación.
¡Espero vuestros comentarios!