Aprendiendo a estimar

Después de alguna milestone con desviaciones, de quejas (no sin razón) del equipo por la poca fiabilidad de las estimaciones, hemos decidido cambiar la forma de estimar, mejor dicho hemos decidido cambiar el momento de estimar.

No me resigno a no estimar (en pro de la supuesta mega agilidad) y  si no llegamos y el proyecto no se entrega no pasa nada, ni al “llegamos como sea” aunque sea no duermo. Ni trabajar por demás ni trabajar para nada.

Hemos pasado por varios métodos y todos con poco acierto, Pert, delphi, experiencia, etc. El problema de que la estimaciones no funcionen en iteraciones de menos de un mes no es tanto la desviación como la desconfianza del equipo en el propio hecho de estimar. Hasta el punto de preguntarse de que sirve estimar o que aporta. Antes de seguir con la nueva forma que hemos adoptado intentaré responder a esa pregunta :

¿De que sirven y que aportan las estimaciones?

  • Descubrir riesgos.
    La mejor forma de mitigar los riesgos es atajarlos pronto. ¿Imaginas descubrir un riesgo en el último sprint antes de sacar un milestone?. Yo no quiero ese estrés.

  • Construir confianza.
    La empresa necesita confiar en las estimaciones para poder tomar ciertas decisiones, por ejemplo: Merece la pena hacer el proyecto?, merece la pena implementar esta feature?, llegara dentro de la ventana de mercado?, necesitamos mas gente en el equipo?, etc..
    La confianza también hará que el equipo pueda trabajar a un ritmo mas sostenible, más importante aún, el equipo necesita creer en las estimaciones para trabajar cómodo, de lo contrario la mayoría del tiempo trabajarán como si las estimaciones fueran un losa sobre sus espaldas.

  • ¿Cómo puedo saber que requisitos meter en mis iteraciones y cuales pasar a la siguiente sino los estimo?

  • ¿Cómo puedo evitar tener que hacer mil horas extras sino sé que requisitos meter y quitar?

Como programador y project manager me encuentro entre los dos y entiendo a los dos: Entiendo que la empresa necesita una estimación para saber si un proyecto es rentable, para saber si entra en el mercado, etc. Y como programador entiendo que hay cosas que no se pueden ser estimar hasta que te pones a trabajar en ello por un tiempo. Os preguntaréis como diciendo esto puedo apoyar-pedir que se haga una estimación.. Básicamente es porque creo que hay una solución intermedia.

Una cosa más, las estimaciones son solo eso, estimaciones.

Tal y como dice Craig Larman lo normal de las desviaciones es que sean mas certeras a medida que avanzas en las iteraciones, como se puede ver en la grafico de abajo.

cone the uncertainty

El problema viene cuando tus iteraciones son completamente diferentes unas de otras, como si fueses proyectos completamente diferentes, con una fuerte carga de I+D. Básicamente esto es con lo que vivimos en nuestro equipo. Por lo que nosotros no ganamos más seguridad a medida que avanzamos. Después de alguna iteración y a través del gráfico de avance nos hemos dado cuenta de que las estimaciones siempre se iban, o cortas o largas, pero no eran certeras y después de unos días la situación de repente se estabilizaba como si de repente el equipo hubiera visto la luz. Y claro que ve la luz, básicamente lo está ocurriendo es que el equipo es capaz de analizar una vez que se ha metido en harina, después de 2 días pegándose con el proyecto, de ver el código, de empezar a lidiar con el problema de verdad, es cuando pueden decirte con más seguridad que tienen por delante.

Lo que vamos a intentar es mover el momento de la estimación. Hasta ahora el equipo desglosaba los requisitos elegidos (normalmente por el cliente) en tareas y las estimaba, dependiendo de la estimación se quita o añade para cumplir dentro del time-boxing, después el equipo empezaba a desarrollar. Ahora se le entregará al equipo los requisitos, el equipo durante unos días (no más de 3 ó 4) empezará a desarrollar (sí, a lo bruto) y después de esos días el equipo se reunirá de nuevo, en ese momento hará el desglose en tareas y las estimaciones de las tareas.

Avance de la iteración
Amarillo: Estimado. Verde: Real. En la línea verde puedes ver como después de unos días la estimación se estabiliza

Ya comentaremos el resultado, si ha sido un completo desastre o si ha tenido algún resultado positivo.

Si tienes algún comentario, corrección por favor házmelo saber que como dice el título, estoy aprendiendo.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s