Estimar no debe ser un compromiso

Matriz Stacey

Desde que estoy metido en el mundo del desarrollo de software me ha causado mucha intriga estimar, recuerdo que hace unos años tuve una conversación con un colega y amigo que era jefe de proyecto, le pregunté ¿cómo puedes estimar un proyecto completo, cerrar fechas, hasta firmar un contrato si aún el equipo no se ha puesto a desarrollar? No recuerdo exactamente su respuesta, pero fue algo del estilo: haces un análisis de todos los requerimientos, diseño y teniendo en cuenta los recursos calculas cuanto tiempo tardaras en entregar.

Me quede con la sensación de que estimar nunca sería una ciencia exacta y que por más fina que fuera la toma de requerimientos y el diseño, siempre falta algo y por ende esa fecha que se dio en un principio nunca se cumpliría, ya sea porque los requerimientos no están claros, por que el cliente no sabe lo que quiere, porque no se conoce la tecnología a utilizar, etc. Se me ocurre una lista larga de porqués.

Antes de conocer el Agile cuando tenía la oportunidad o digamos mejor la obligación de estimar una tarea me sentía en una encrucijada ya que el estimar se convertía en un compromiso y pensaba que si me equivocaba mi credibilidad como informático estaría cuestionada.

Lo cierto es que al estimar he experimentado lo que bien se muestra en la matriz de Stacey, cuando lo que tenía que hacer estaba más claro y la tecnología a usar era de mi total dominio la estimación era muy fácil, luego según esos requerimientos eran menos claros y la tecnología a usar de menos dominio esa estimación se hacía más compleja.

En la actualidad estimar no ha cambiado mucho, referente a la matriz todo sigue igual.

Con Agile lo que sí ha cambiado o mejor lo que se pretende cambiar es que estimar no se convierta en un compromiso, la estimación por el contrario es una herramienta para que el equipo determine la complejidad que tiene esa tarea a realizar y es esa complejidad la que sirve de base para establecer cuanto tiempo se invierte en una tarea.

Y bueno ¿Cómo hacerlo?

• Evitar a toda costa que estimar se convierta en un compromiso, sobre todo cuando al momento de estimar estamos en el Complex o más allá (según la matriz), ya que el compromiso limita la creatividad y agrega presión al equipo.
• Aceptar que la estimación no siempre  puede ser correcta, no es una ciencia exacta,  por lo tanto se debe permitir re-estimar. Actúa rápido, falla antes y soluciona rápido.
• De la baraja del planning póker usar estas cartas:

Para determinar la complejidad, el rango es: 2 fácil, 5 medio y 13 complicado.  Si se usa una carta menor de 2, es que la tarea se puede hacer en una hora (algo muy sencillo), si se usa una carta mayor de 13 es necesario pensar en dividir la tarea

• Si el equipo no conoce su velocidad, es necesario que exista un consenso sobre a cuánto tiempo se refiere los puntos de historia, es decir, por ejemplo: 2 medio día, 5 un día, 13 tres días.
• Una vez el equipo conozca su velocidad la unidad de tiempo será real y no estimada.

·         

Tenemos que tener claro que siempre será necesario estimar, de hecho en nuestra vida siempre estimamos, desde cuanto tiempo tardare en llegar a la oficina, cuantos cafés me tomare hoy, etc. No estimar es prácticamente impensable, el punto está en que esa estimación tiene que dejar de ser la última palabra, es decir, no es una ciencia exacta y por eso es susceptible de fallos. Lo cual me lleva de nuevo a la matriz de Stacy, debemos procurar estar en lo Simple y cuando salgamos de esa zona actuar rápido para poder re-estimar si es necesario.

Aclaración, el post es solo mi opinión personal, no tiene por qué ser absolutamente cierto.

Bueno algunos dirán: ¡mi cliente no aceptara que las tareas se re-estimen!, para eso existen los contratos ágiles, pero eso es un tema que abordare en otro post.



ref. Autentia Planning Poker
https://play.google.com/store/apps/details?id=com.autentia.android.scrum&hl=es