Hola a todos, aquí estoy después de un buen tiempo. La verdad es que tanto el trabajo como algunos asuntos personales me han tenido bastante ocupado y no he podido escribir mucho; pero ojeando la lista de correo de agile-spain me han dado ganas de escribir sobre un tema: la estimación.
La verdad es que existe bastante controversia entre si es conveniente estimar o no y cómo ha de hacerse correctamente. Los que me conocéis ya estareis anticipando mi respuesta: estima sólo lo justo y necesario y no te esfuerces en ser más preciso de lo que realmente necesitas o puedes. Este es el enfoque que cualquier profesional pragmático debería usar y olvidarse de cualquier postura “idealista”. Para aplicar esta idea en la práctica debemos antes tener claro qué es estimar, cuál es nuestro objetivo a la hora de estimar, y que grado de precisión podemos esperar de forma realista de nuestras estimaciones.
En el contexto del desarrollo de software, estimar es la actividad que realizamos para predecir el coste de realizar una tarea y/o implementar una unidad de funcionalidad, basándonos en nuestra experiencia pasada con tareas o funcionalidades similares. ¿Qué grado de precisión podemos esperar de tales estimaciones? Pues básicamente todo depende de la cantidad de experiencia que tengamos. Si no hemos tenido experiencia en tareas similares en el pasado, nuestra estimación resultará inútil. Ojo, experiencia en actividades similares, no experiencia en cualquier cosa. Por lo tanto sólo existen dos maneras sensatas de estimar:
- Usar un sistema informático, que gracias a una amplia base de datos de mediciones de cuanto se tardó realmente en el pasado en hacer tareas similares, y mediante un modelo estadístico, nos ofrezca un intervalo de confianza de cuanto esfuerzo necesitaremos en realizar una tarea. Hago énfasis, intervalo de confianza, no una “media”.
- Usar personal experto en el entorno tecnológico que se va a usar, que tenga un entendimiento claro de la tarea que se va a hacer y con experiencia a sus espaldas. Este personal de nuevo nos podrá ofrecer un intervalo como estimación.
En este sentido no debería estimar ni el cliente, ni personal senior pero no familiarizado con la tecnología a usar, ni nadie no implicado en la construcción del software. Esto coincide con lo que nos dice Scrum de que sea el equipo de desarrollo quien estime y no el PO. Sin embargo tampoco recomiendo que estime el personal junior, tal vez puede intentar estimar para aprender, pero no habría que darle mucho peso a su estimación. Quizás esto último no sea muy ágil, pero a mi me parece de sentido común.
En cualquier caso, existe un límite natural a la precisión de nuestras estimaciones:
- Cuanta menos variabilidad exista entre las tareas mejor estimaremos, ya que nuestra experiencia pasada será más representativa. Variabilidad en cualquier aspecto: tecnología, tamaño, complejidad, funcionalidad, etc.
- Las predicciones sobre tareas/funcionalidades grandes son menos precisas que las hechas sobre tareas más pequeñas. Esto es especialmente cierto si hablamos de precisión relativa (%).
- Las predicciones a largo plazo son siempre menos precisas que las hechas a corto plazo. Esto es debido a que cuanto más tiempo pueda transcurrir, más posibilidad hay de que ocurran imprevistos o de que las circunstancias cambien o varíen.
- La experiencia más reciente suele ser más representativa que la más antigua, ya que se han podido producir cambios en nuestro entorno. Por ejemplo: nuevas tecnologías, cambios en el equipo (para mejor o para peor), etc.
- El ser humano es mejor estimando por comparación entre objetos del mismo tipo. Somos muchos más precisos adivinando que una tarea es aproximadamente un 50% más grande que otra tarea del mismo tipo, que intentando asignar tiempo o dinero directamente a cada tarea por separado.
O sea, para que tenga sentido el esfuerzo y dinero que vamos a gastar en estimar se deben cumplir algunos prerrequisitos:
- Tener personal con experiencia en las tareas y tecnologías implicadas.
- Que haya poca variabilidad en las tareas a estimar, es decir, que sean similares en todos los aspectos relevantes.
- No malgastar esfuerzos, y usar un grado de precisión realista a la hora de estimar, en función del tamaño de lo que estemos estimando y la escala de tiempo. Podemos hacer una estimación grosera, en meses, de una tarea que está en la escala de años, y una más fina de horas para una tarea que está en la escala de una jornada, pero es absurdo estimar con precisión de días una tarea en la escala de un año.
- Usar estimaciones relativas (por comparación) en vez de absolutas. Es importante no comparar dos cosas que estén en escalas distintas, tanto de tamaño como de tiempo.
Mientras no se cumplan los anteriores requisitos no tiene sentido ponerse a estimar, ya que simplemente los resultados obtenidos no nos servirán de nada. Si no se cumplen estos requisitos lo mejor es “adivinar” y “tirarse a la piscina”, ya que es igual de preciso pero más barato.
¿Radical? Pensadlo bien ¿Para que queremos estimar? En el fondo siempre que estimamos lo hacemos para asumir un compromiso con nuestro cliente, ya sea directamente o indirectamente a través de nuestros jefes: ¿cuándo estará terminado? ¿Podréis acabar esta funcionalidad antes de la semana que viene? ¿Te comprometes a hacer el proyecto en este tiempo y con tanto dinero? El hecho de asumir un compromiso nos lleva a correr el riesgo de no cumplirlo, y como tal lo debemos evitar a no ser que sea absolutamente necesario. En caso de que realmente necesitemos comprometernos formalmente debemos evaluar el nivel de riesgo de no cumplir esta promesa, lo cual depende sobre todo de la precisión de nuestra estimación. Por lo tanto, siguiendo el razonamiento de este post, no tiene sentido estimar si nuestra precisión no es aceptable, ya que estaríamos ante un riesgo incontrolado.
Así que ya sabeis, la próxima vez que monteis un plan de proyecto para un proyecto cerrado, o que comprometais una fecha de entrega, pensad antes si vuestras previsiones realmente tienen sentido, y no gasteis dinero en absurdos cálculos basados en cosas como los “puntos función”.
En próximos post abordaré la polémica sobre si estimar tareas o funcionalidades, y distintas técnicas ágiles para hacerlo.
