Exprimiendo Scrum: Scrum y el control del proyecto (I): el avance

Burndonw Chart 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!

14 comentarios en “Exprimiendo Scrum: Scrum y el control del proyecto (I): el avance”

  1. Cuanta razón tienes Rodrigo, los clientes (con todo mi respeto que son los que pagan) son como un burro con orejeras, ellos lo primero que buscan es la resolución en nuestro software de sus principales necesidades, y una vez cubiertas si ven carencias ya se encargan de recordarnoslas, pero una vez tienen su software funcionando (aunque sea en parte) su percepción es muy buena, y hace que sean mas comprensivos y colaborativos. Y la responabilidad de que el cliente tenga esta percepción es del jefe de proyecto, bien no solo recortando en caso de no llegar, sino en distinguir lo que el cliente realmente quiere.

  2. Muy chulo Rodrigo, las métricas esas grandes olvidadas, y no sólo olvidadas, ¿qué medices de cuándo se usan de modo prescriptivo sin conocer lo que hay detrás?? jejej anda que no hemos comentado eso veces en las charlas ehhh 🙂

  3. @Jose Antonio: La colaboración con el cliente es clave, en mi opinión es una precondición si queremos que nuestros proyectos sean exitosos.

    @Luis: Ya te cuento, lo hemos comentado en el blog, en dotNetMania y en un motón de charlas… pero toda evangelización es poca…

    Un saludo!!!

  4. @Sentach: Debería haber sido así siempre. Desactivé la sindicación de todo el contenido de los post por error. En realidad creo que los lectores deben elegir el modo de lectura que más les guste web o rss…

    ¡Un saludo!

  5. La velocidad debe existir unicamente como valor de referencia “oculto” es decir, solo debe hablarse de velocidad en el despacho del jefe de proyecto, ningún integrante del mismo debe tener constancia ya que puede condicionar su trabajo “yo soy muy poco productivo, he de ir más rápido…”. Digo que debe existir como valor de referencia “oculto” pq el jefe de p. debe tener un coef para p.e. dado un cambio en la metodología evaluar si este mejora la velocidad de desarrollo o la empeora.

    Cuidado con esto Rodrigo “Alargar la duración del proyecto es siempre una mala idea…estamos lanzando un mensaje erróneo al equipo de desarrollo: no pasa nada si os retrasáis…”.

    En mi humilde opinión tras muchos años desarrollando tengo un lema; “Merece la pena un retraso a cambio de una notable calidad”, es decir mas vale una vez colorao que cien veces amarillo.

    Podrías ser más explicito con “¿Cómo podemos mejorar la velocidad?”, no lo he entendido bien

    Julio Trujillo. Copermática.

  6. Hola:

    La idea me parece estupenda y yo actualmente lo estoy montando en mi empresa.

    ¿Nos puedes explicar cómo hacerlo en un gráfico excel o pasarnos un ejemplo?

    Muchas gracias por adelantado

  7. Hola Julio:

    En Scrum las métricas y en general toda la información sobre el proyecto debe ser pública. Los peligros de las agendas ocultas en los proyectos son bien conocidos.

    En el caso de las métricas lo importante es nunca caer en el error de usarlas para medir personas. Las métricas miden el proceso y en concreto en Scrum miden la velocidad del conjunto del equipo para poder estudiar su evolución y pensar en como mejorarla y ver si las mejoras introducidas realmente son tales… pero sobre todo para usar esa velocidad con base a la hora de estimar el trabajo que podremos hacer a futuro en un tiempo dado.

    Sobre la calidad, la clave es no dejarla para el final. Dejar la calidad para el final siempre introduce riesgos y sobreesfuerzos en los proyectos. Es mejor mantener el nivel de calidad necesario a lo largo de toda la vida del proyecto. Siguiendo esta recomendación, tampoco tendría sentido alargar el proyecto. Sobre esto ya he escrito antes:
    http://geeks.ms/blogs/rcorral/archive/2006/09/02/En-el-software_2C00_-la-calidad_2C00_-no-es-opcional.aspx
    http://geeks.ms/blogs/rcorral/archive/2007/01/18/evitar-quebraderos-de-cabeza-al-final-de-los-proyectos.aspx

    Cuando hablo en este post de “¿Cómo podemos mejorar la velocidad?”, me refiero a que mejorar la velocidad es un proceso lento. Si un proyecto está retrasado, no debemos esperar que logremos superar velocidades pasadas de manera repentina. Ni siquiera añadir más personal suele tener, a corto plazo, el efecto deseado de mejorar repentina la velocidad.

    ¡Un saludo y muchas gracias por tus interesantes comentarios!

  8. i’ve been thinking of ways to also fix my basement collider. finally i have found the right information that i need. it’s been a couple of weeks since the collider was broken. i have tried everything, but to no avail. good thing Joe Holt, a friend of mine, have come across your article. thank you so much for this one. it really helps.

Deja un comentario

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