Estimación y planificación ágil - Resultados del quinto encuentro ágil en Barcelona

En este encuentro se compartieron experiencias sobre los siguientes temas:

  • Gestión de dependencias entre objetivos de proyecto.
  • Estimación del proyecto por parte de todo el equipo, utilizando días ideales o bien puntos de historia de usuario.
  • Planning Poker para hacer una estimación inicial del proyecto rápida y fiable.
  • Uso de la velocidad de desarrollo para ir proyectando el final del proyecto.
  • Pruebas de concepto para realizar estimaciones.
  • Estimación y planificación de iteración basada en compromiso.
  • La estimación ágil ayuda a crear “conciencia de equipo”
Foto de grupo estimacion y planificacion agil
 
 
Estimación y planificación de proyecto
 
 
Dependencia entre objetivos del proyecto
 
  • Los objetivos (en forma de historias de usuario) que forman la lista de objetivos priorizada del proyecto (Product Backlog) deben ser lo más independientes posibles, para poder demostrarlas y enseñarlas al cliente con la seguridad de que están completadas. De esta manera, el cliente puede tomar decisiones objetivas basándose en los resultados que ya está obteniendo del proyecto y en la velocidad de desarrollo del equipo.
  • Si hay objetivos que son muy dependientes, se puede hacer varias cosas:
    • El objetivo que genera más dependencias se pone antes en el Product Backlog. Los objetivos dependientes se sitúan en algún punto por detrás.
    • En alguna situación puede ser interesante juntar varios objetivos dependientes en uno. Sin embargo, con objetivos excesivamente grandes es más difícil medir el progreso del proyecto y cuesta más tiempo completarlos, por lo que si hay un retraso se tarda más en que sea visible. Por ello, para observar un avance regular en el proyecto, es mejor que los objetivos tengan un tamaño similar y no sean demasiado grandes.
 
La estimación la lleva a cabo el equipo
 
  • La estimación no la realiza el cliente / Product Owner, por que no es él quien se va a “ensuciar las manos” y luchar por cumplir con fechas.
  • Todo el equipo realiza la estimación para:
    • Reforzar el compromiso de todo el equipo respecto a las fechas que dan al cliente.
    • Reforzar el compromiso de cada miembro del equipo respecto al resto.
    • Hacer que todo el mundo se sienta oído.
  • La estimación se puede realizar utilizando alguna de las siguientes unidades:
    • Días ideales: los días necesarios para que el equipo pueda completar un objetivo, sin considerar interrupciones. Para pasar a días reales hay que aplicar un factor de corrección que puede ir del 60 % al 70 % de dedicación real al proyecto. Asimismo, habrá que tener en cuenta un margen para imprevistos como bajas por enfermedad, etc.
    • Puntos de historia de usuario: la complejidad que tiene cada historia de usuario. Un equipo en un proyecto determinado es capaz de completar un número semi-regular de puntos de historia cada iteración (“velocidad”).
 
Planning poker
 
La técnica de planning poker permite hacer una estimación inicial del proyecto rápida y fiable, dado que todos los miembros del equipo comparten sus diferentes informaciones y expresan su opinión sin sentirse condicionados por el resto.
A continuación se puede ver diferentes barajas de cartas de planning poker.
 
cartas-planning-poker
 
Cada número significa un peso / esfuerzo / complejidad para completar un objetivo (historia de usuario). La numeración de las cartas está basada en la sucesión de Fibonachi. La distancia entre números crece conforme se hacen mayores. De esta manera, se facilita la decisión sobre qué tamaño tiene un objetivo.
¿Es un 5 o un 8?. No vale la pena entretenerse en pensar si es un 5 o un 6, ni en el error por no intentar buscar esta precisión, dado que se compensará por encima y por debajo con el resto de estimaciones.
 
 
jugando-planning-poker.jpg
José Raya, Jordi Pradel y Alexis Roqué haciendo una demostración de Planning Poker
 
Planning Poker es un proceso iterativo de planificación. Funciona de la siguiente manera:
  • El cliente lee un objetivo (historia de usuario escrita en una tarjeta).
  • El equipo le hace preguntas para entender su alcance.
    • Las respuestas importantes se pueden apuntar en la propia tarjeta como detalles del objetivo o condiciones de satisfacción.
    • Pueden aparecer nuevas historias de usuario.
  • Cada miembro del equipo piensa en el esfuerzo necesario para completar el objetivo y todos muestran sus tarjetas simultáneamente, de manera que no están condicionados por las estimaciones de los otros.
  • Las personas que están más alejadas del consenso explican por qué su votación es más alta (hay algún problema en el que nadie más ha pensado o el resto no ha tenido en suficiente consideración) o más baja (conocen una manera sencilla de resolver el problema, resolvieron algo muy parecido en un proyecto anterior, etc.).
  • El equipo vuelve a votar, hasta que alcanza un acuerdo. No hay democracia, dado que todos deberán comprometerse a que ese objetivo se va a acabar con el esfuerzo acordado (se supone que no hay una persona que siempre vota de manera singular y a la que nunca se puede convencer).
Diversas personas manifestaron que con esta técnica el equipo ha ido mejorando mucho la precisión de sus estimaciones. De hecho, existen diversos estudios que concluyen que la sinergia que produce esta estimación conjunta es mucho mejor que la de una única persona por separado (típicamente la del jefe de proyecto o un senior en un proyecto tradicional).
 
Algunos consejos y trucos:
  • Elegir un objetivo de tamaño típico en el proyecto como patrón con el que comparar el resto de objetivos y asignarle una puntuación de carta también media (por ejemplo un 5).
  • Puede ser conveniente no jugar con las cartas más altas, ya que el error de estimación es mucho mayor (además, objetivos tan grandes dificultan ver el progreso y se tarda más en hacer visible si existen problemas en el proyecto). Notar que en la fotografía de las barajas se han apartado las cartas más altas para no jugar con ellas.
  • Dada la dificultad de empezar a trabajar con puntos de historia y no con esfuerzo en días ideales, para facilitar el empezar a utilizar Planning Poker se puede hacer el símil de que, por ejemplo, dos puntos de historia corresponden a un día ideal.
  • Comparar el tamaño que se va dando a cada objetivo respecto al de otros (triangulación). Ver ejemplo en [2].
 
Velocidad de desarrollo
 
Los puntos de historia permitirán medir la velocidad que tiene el equipo completando objetivos a lo largo e las iteraciones (puntos de historia por iteración) y de esta manera ir proyectando el final del proyecto.
  • Las 2-3 primeras iteraciones la velocidad es más inestable (debido a la complejidad propia de un proyecto: dominio/ requisitos nuevos, tecnología nueva, personas nuevas) y después se va estabilizando, con lo que ya es posible utilizarla para hacer predicciones. Si no se estabiliza, posiblemente es por que existen problemas subyacentes que lo impiden (en la organización, en la estabilidad del equipo, etc.) y que habrá que solucionar.
  • Las estimaciones (y la velocidad) se ven afectadas cuando se introducen nuevas tecnologías o conceptos de negocio en medio del proyecto, aunque después se vuelven a estabilizar.
 
 
Pruebas de concepto para realizar estimaciones
 
  • Si existe incertidumbre para realizar una estimación de un tipo de objetivos (historias de usuario), se puede hacer un spike o prueba de concepto extremo a extremo en una iteración anterior a su desarrollo. Esta investigación permite conocer el grado de dificultad de completar algo y poder estimar mejor las siguientes iteraciones, donde se desarrollarán las historias de usuario reales.
  • La prueba de concepto debe realizarse dentro de un timebox, para obligar a tomar decisiones y no dedicar un tiempo excesivamente largo a investigar.
 
 
Estimación y planificación de iteración basada en compromiso
 
En la reunión de planificación de iteración (Sprint Planning) el equipo va seleccionando objetivos del Product Backlog (historias de usuario) y descomponiéndolos en tareas. Escoge tantos objetivos como cree que es capaz de completar en una iteración (commitment driven sprint planning). La velocidad permite verificar (checkpoint) que el total de puntos de historia de la nueva iteración es congruente con las anteriores iteraciones, si están escogiendo demasiados objetivos o demasiado pocos.
Cada miembro del equipo que escoge una tarea hace su estimación en horas delante de todos, de manera que:
  • Se compromete respecto a sus compañeros.
  • Evita estimaciones demasiado optimistas (que comprometerían las fechas del proyecto) o demasiado pesimistas (que atentarían contra la competitividad de la empresa). De esta manera se disminuyen y ajustan los buffers.
 
La estimación ágil ayuda a crear “conciencia de equipo”
 
Como consecuencia de las técnicas descritas, la estimación ágil crea conciencia de equipo. Todos participan, tienen voz y voto. Cuando se produce una equivocación en una estimación, se ha equivocado todo el equipo. Por ello, no es para individualistas. No sirve que alguien diga “Yo he hecho mi parte de la historia de usuario”.
 
 
 
Agradecer a DoubleYou, agencia de publicidad que utiliza prácticas de Scrum y XP en sus proyectos, la cesión de sus instalaciones, los snacks y las bebidas.
 
Agradecer a Telefónica I+Dque también utiliza prácticas de Scrum y XP en sus proyectos, las barajas de cartas de Planning Poker que regaló a los asistentes.
 
Para apuntarse a los próximos encuentros en Barcelona sobre temas ágiles: http://agile-spain.wikidot.com/quedadas-barcelona
 
 
Para saber más

 

Comments

Hola. Muy interesante el tema pero tengo una duda.

Qué sucede con este tipo de estimación cuando el número de actividades es muy grande? Yo manejo planes con hasta 1300 actividades, con un tiempo de duración de máximo 5 días y me preocupa pensar que esta puede ser una solución a la estimación, debido únicamente al tiempo que habría que invertir en estimar todas las actividades. Funciona o no este método para proyectos tan grandes?

Muchas gracias.

Es importante notar que la planificación de un proyecto ya no es orientada a tareas/actividades, ya no es un project plan con su WBS (o EDT) con el que planificar la microgestión de todo el proyecto, dado que el umbral de prediccción de cómo se van a hacer y transcurrir las cosas es bajo. En cambio, se trata de un plan de producto, está orientado a objetivos/features/requisitos de alto nivel.

Así pues tenemos una estimación inicial de cada objetivo/feature/requisito del proyecto, que se va ajustando durante el propio proyecto (especialmente después de cada demostración). Al inicio de cada iteración es cuando se hace el desglose de las tareas para conseguir cada objetivo. Ver http://www.proyectosagiles.org/planificacion-iteracion-sprint-planning

Tu comentario nos ayuda a enriquecer el articulo

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <p> <span> <div> <h1> <h2> <h3> <h4> <h5> <h6> <img> <map> <area> <hr> <br> <br /> <ul> <ol> <li> <dl> <dt> <dd> <table> <tr> <td> <em> <b> <u> <i> <strong> <font> <del> <ins> <sub> <sup> <quote> <blockquote> <pre> <address> <code> <cite> <embed> <object> <strike> <caption>
  • Lines and paragraphs break automatically.

More information about formatting options

CAPTCHA
Este formulario es para impedir el abuso de spambots.
Image CAPTCHA
Copy the image characters keeping the upper/lower case.