Cómo sobrevivir a las estimaciones de software

Una de las preguntas mas peliagudas que un desarrollador tiene que responder semanalmente es “¿cuanto vas a tardar en hacer esto?” Que es muy probablemente lo que le preguntó el papa Julio II a Miguel Ángel cuando le encargó decorar la bóveda de la Capilla Sixtina.
Existen diversas técnicas formales de estimación, las que funcionan están basadas en apuntar cuánto se tardó realmente en realizar una tarea similar en el pasado y estimar que se tardará mas o menos lo mismo en completar la nueva tarea. Para el desarrollo en territorio desconocido existen también varios métodos especulativos incluidos algunos tan divertidos como el planning poker donde los programadores realmente apuestan cuánto van a tardar.

Dilbert Software Estimation

No repasaré los métodos cuantitativos, que dan de si como para un libro entero de ingeniería de software. Aunque cualquiera que trabaje en un proyecto de software debería como mínimo conocer cuatro cosas:

1) los fundamentos del modelo COCOMO y el Software-Engineering-Economics de Boehm.
2) cómo funcionan las historias de usuario y los product backlogs en Agile, sobre lo que hay una breve introducción aqui y más extensamente en el libro de Mike Cohn.
3) qué es PERT y CPM.
4) cuales son las tecnicas de optimización global.

Otro libro recomendable es Software Estimation: Demystifying the Black Art.

Me voy a centrar en las estimaciones que no queda más remedio que sacar de un sombrero.

La primera pregunta que hay que hacer en respuesta a la pregunta “¿Cuánto vas a tardar en hacer esto?” es “¿Para qué quieres saberlo?”.

Normalmente se quiere saber porque el tiempo esta asociado al consumo de recursos o a una fecha de compromiso con el cliente. Pero no es lo mismo una cosa que la otra. Quizá el consumo de recursos sea flexible porque se puede pedir más dinero a los inversores pero la fecha de compromiso con el cliente no sea nada flexible porque hay que contratar una campaña de publicidad en televisión, anunciando la nueva web, cuya programación no se puede cambiar de ninguna manera una vez acordada con la cadena emisora. O puede que la fecha sea necesaria porque hay que asignar recursos en otro departamento que está a la espera de recibir el nuevo software.

Es decir, lo primero que hay que hacer es determinar el ámbito del problema y la precisión que debe tener la estimación.

Lo siguiente que hay que hacer es una lista de pre-requisitos para que la estimación sea válida. Por ejemplo, puede que la resolución implique revisar un código antiguo que nadie conoce bien y que quizá no se pueda modificar alegremente, o puede que solucionar un defecto en el diseño de la base de datos requiera unos privilegios de administración otorgados por un tercero que puede tardar un tiempo indeterminado en despachar un ticket de soporte. En general, la causa mas común de retrasos en equipos Agile es que se esté esperando a algo que debe ser proporcionado por una fuente externa que no es Agile, entonces el equipo se convierte en un grupo de personas esperando “eficientemente” a que alguien más haga algo. Es importante que el cliente entienda y acepte los pre-requisitos.

Una vez acotado el ámbito del problema y la precisión requerida y acordados los pre-requisitos, lo siguiente es decir: “No sé cuánto tardaremos, pero lo sabré dentro de X horas/dias”. Explicando que se necesita tiempo para evaluar detenidamente la información disponible antes de poder hacer una estimación. Si el cliente insiste en este punto en obtener una estimación una respuesta posible es: “La media entre dos horas y dos meses, dependiendo de lo que nos encontremos durante el análisis detallado del problema”.

No obstante lo anterior, si el responsable de la planificación de proyecto no esta presente en la reunión, hay sólo tres respuestas que un programador debe dar a cualquier petición de estimación:

a) “Es imposible hacer eso”.
b) “Es extraordinariamente difícil y peligroso hacer eso”.
c) “Eso debemos hablarlo con el jefe de proyecto”.

A veces hay que educar a los usuarios porque no conocen el proceso de desarrollo. A veces no entienden que aunque una madre haga un niño en nueve meses, dos madres no pueden hacer un niño en cuatro meses y medio. Otras veces no entienden que sólo es posible fijar dos de los tres lados de triangulo coste/calidad/tiempo. Y en otras tienen problemas para priorizar por el método MoSCoW (Must have, Should have, Could have, Won’t have). Si este es el caso, es muy conveniente hacerle saber al cliente que un software grandioso es aquel que hace unas pocas extraordinariamente bien y no aquel software que sirve para todo pero no es bueno para nada.

En el caso de que no quede ningún otro remedio que responder, puede ser útil aplicar el Principio de Scotty que consiste básicamente en estimar a ojo de buen cubero, añadir un 50% de tiempo a la estimación y reportar la cifra inflada. Aunque una nota de aviso sobre esto: funciona para dar estimaciones al cliente final, pero no para hacer estimaciones internamente en el equipo de desarrollo. Esto es debido a que si se permite que los desarrolladores estimen unilateralmente cuando terminarán el software, entonces nunca lo terminarán porque, por su propia naturaleza, un software nunca esta terminado.

Si se ha fallado en las estimaciones previas la credibilidad estará en entredicho. En tal caso lo mejor es suponer que las siguientes estimaciones se desviarán en la misma medida en que se desviaron las anteriores. De hecho, esta capacidad de extrapolación es presuntamente una de las ventajas de Agile. Si se estimó que una tarea al inicio del proyecto tardaría dos dias y tardó realmente cuatro entonces es posible conjeturar desde casi el principio que todo el proyecto tardará el doble de tiempo del inicialmente estimado. Si el proyecto pinta mal entonces “más vale ponerse una vez (muy) colorado que ciento amarillo”. En un proyecto que requiere reingeniería hay que resistir a muerte y cueste lo que cueste las presiones para dar fechas optimistas. Esto no siempre es fácil porque lo habitual es hacer rodar la cabeza del responsable de desarrollo que incumplió sistemáticamente los plazos y substituirlo por otro que promete que si puede cumplirlos. Y luego decapitar a este segundo también y a todos sus sucesores hasta que el proyecto se completa o se cancela.

Por ultimo, si no se tiene realmente ninguna idea y hay forzosamente que responder, entonces decir “dos semanas”, que es lo que dura como mínimo un sprint y lo que se tarda en hacer circular el curriculum actualizado.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Bookmarks
Esta entrada fue publicada en Casos Prácticos. Guarda el enlace permanente.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *