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”

• 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 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”).

• 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).

• 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].

• 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.

• 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.

• 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.

• [1] Introducción a la estimación y planificación ágil, de Xavier Quesada.
• [2] Presentación de estimación y planificación ágil, de Mike Cohn, donde se puede ver un ejemplo de triangulación de tamaño de historias, clasificándolas según su puntuación para poder compararlas.
• Planificación ágil vs planificación tradicional
• Videos cortos sobre planificación ágil

 

• planificación_iteración
• planificación_proyecto