Antes de que se forme cualquier equipo y se comiencen a planificar las diferentes tareas hay que pasar por algo ineludible: la estimación del esfuerzo y el tiempo.
En una serie de entradas del blog me gustaría tratar técnicas de estimación, desde las clásicas como COCOMO II hasta las ágiles como
planning poker, comentando cómo hemos llevado a cabo estimaciones dentro de los equipos en los que he estado trabajando.
El esfuerzo en proyectos de ingeniería civil como hacer una carretera, se puede tangibilizar en los kilómetros que se tienen que construir y el tiempo se derivaría de este esfuerzo. Por ejemplo, si tenemos que hacer 1000 kilómetros con 10 personas que son capaces de realizar 12 km al día se estima que el proyecto durará aproximadamente 83 días. En proyectos software el esfuerzo se mide en persona-día que es el trabajo que una persona es capaz de realizar en un día.
Tan pronto como el comercial de tu empresa ha "mal vendido" un proyecto ya empiezan las presiones: ¿cuánto va a costar hacer esto? ¿en cuánto tiempo lo tendréis?,quiero un plan de proyecto para entregárselo al cliente... uno se queda estupefacto ante tanta prisa y cúmulo de peticiones sobre todo porque internamente piensa "cómo puedo decir el tiempo que tardaremos si ni siquiera se lo principal: ¿qué hay que hacer?" y, cuando empezamos en esto de gestionar proyectos, nos lanzamos a la piscina por eso del que dirán y contestamos: esto estará en 3,5 meses y necesitaré a 5 personas... !craso error!
Antes de empezar a hablar de técnicas y métodos para estimar hay dos reglas que, en mi opinión, son fundamentales:
1.- Estimar significa estimar. Algo tan trivial como esto no siempre parece obvio y, sobre todo, no es fácil hacerlo entender al equipo de ventas. Si a mi me preguntan: ¿cuánto tardo en viajar de Madrid a Valencia? suelo contestar que, basándome en mi experiencia en otros viajes previos, aproximadamente entre 3,5 y 4 horas. Uno nunca sabe si va a encontrar tráfico, si va a parar a tomar un café o si el coche se va a averiar en el camino. Por eso es importante siempre dar un rango en las estimaciones y no parecer que la cifra que das no tiene ninguna incertidumbre.
2.- El rango es inversamente proporcional a la información y el momento en el que se haga la estimación, esto es, si estamos en una fase temprana o disponemos de muy poca información no nos podemos negar a dar una estimación, pero si podemos dar un rango muy amplio y viceversa, si ya disponemos de mucha información el rango puede disminuir.
Siempre me gusta esta figura, el famoso cono de la incertidumbre de Boehm donde se puede ver que dependiendo de la fase en la que nos encontremos (en el caso de un desarrollo en cascada) si damos una estimación en una fase temprana esta puede variar desde un 25% hasta un 400%.
Pongamos un ejemplo: nuestro equipo de ventas nos dice "nuestro cliente quiere un portal web para gestionar sus productos, ¿cuánto vais a tardar?", nosotros intentaremos obtener toda la información posible para, usando nuestra técnica preferida, dar una estimación. Después de reunirse el equipo se estima que el proyecto durará 10 semanas y nuestra contestación sería: entre 2,5 y 40 semanas. Las reacciones, claro está, pueden ser muy diversas, la más común sería: "hombre, vaya estimación dáis, con ese rango yo no puedo vender nada" pero nuestra respuesta debería ser: "mi grado de incertidumbre es tan grande como el tuyo, tan pronto tengamos más detalles sobre el proyecto podremos afinar más". He dicho "debería ser" porque, al final, de ese rango suelen coger los números más favorables a su venta ;-)
En este post nuestra intención era introducir que es estimar proyectos software sin entrar en detalle, una vez que sabemos que el proceso era obtener información de qué hay que hacer, aplicar una técnica y ofrecer unos resultados en las siguientes entradas del blog hablaremos de tecnicas y compartiremos ejemplos. Para los que no puedan esperar aquí tenéis el conocido método "estimación de mi jefe": si nos dicen que tiene que estar en 2 días, subid a la siguiente unidad temporal y multiplicarlo por dos. Casi con total seguridad serán 4 semanas de trabajo real ;-)
|
Entradas
