Arquitectura de datos

Estimar tareas o funcionalidades

Una de las cosas sobre las que se discutió en la lista de agile-spain y que me animó a escribir estos posts sobre estimación fue si era conveniente o no estimar las tareas técnicas.

Cuando en este post hable de tareas me referiré a tareas técnica (construir un servicio, definir una tabla, documentar, etc). En contrapartida tenemos las funcionalidades queson directamente utilizables por el usuario y le aportan valor. Desde el punto de vista del desarrollo de software, existen varias actividades en las que nos vemos forzados a estimar, las más importantes son:

· Evaluar si es razonable o no presentarse a un proyecto cerrado, y que coste y tiempo podemos ofertar.

El problema precisamente está en que esta evaluación se realiza en el momento dehacer la oferta, que es justo donde tenemos menos información sobre el proyecto, y por tanto, menor precisión en la estimación. Además la estimación deja de ser una estimación y se transforma en un contrato.

En este sentido los proyectos cerrados son muy arriesgados. La única circunstancia en la que el riesgo sería aceptable es que el proyecto que se presupuesta sea muy similar a otros quehayamos hecho en el pasado, y que el tamaño de éste no sea muy grande. Aquí lo único que podemos hacer es estimar el tamaño del proyecto en comparación con proyectos pasados. Para ello podemos hacer una captura de requisitos de alto nivel y asumir un entorno tecnológico y arquitectura similar a la de proyectos pasados.

· Release plan. En el release plan nos comprometemos a definir quefuncionalidades se pondrán en producción en que momento. La release plan se puede hacer de dos formas: orientada a fecha u orientada a funcionalidad.

En la primera las fechas de entrada en producción son críticas y lo que estimamos es cuanta funcionalidad podrá entrar para esa fecha. O sea, tiempo fijo, alcance variable.

En la segunda modalidad el alcance es fijo y lo que es variable es el tiempo,intentando estimar cuándo podremos poner en producción un conjunto predefinido de funcionalidad.

Si lo pensáis bien, en ninguna de las dos actividades anteriores es necesario estimar tareas.

¿Por qué? Simplemente porque ni a mi jefe ni a mi cliente le interesa saber cuanto voy a tardar en hacer una tarea. Lo que les interesa realmente es cuando voy a tener disponible tal funcionalidad, releaseo proyecto y cuanto me va a costar. Algunos diréis, sí, sí, pero es que yo descompongo en tareas, las estimo y después las sumo. Yo os digo que estais gastando dinero inútilmente en analizar una funcionalidad para ver que tareas os salen, y que vuestro margen de error no va a disminuir significativamente con respecto a una estimación directa de la funcionalidad. Dicho esto, ¿cómo estimo entoncesuna funcionalidad? Como dije en mi anterior post, los seres humanos somos buenos estimando por comparación, por lo tanto lo sensato es comparar la funcionalidad a estimar con otras similares implementadas en circunstancias similares en el pasado.

Como veis no es necesario descomponer, ya que a nadie, excepto a nosotros,

le importan las tareas, y el método que propongo es más sencillo ybarato.

Comparar una funcionalidad con otras ya hechas es más simple que hacer

un análisis de que tareas se necesitan para realizar la funcionalidad, y después estimar cada tarea por separado.

Existen un par de dificultades en la regla anterior de “no analizar”. La primera es que lo que estemos estimando sea de tamaño “grande”. Según lo explicado en el anterior post, cuanto más grande y amás largo plazo estimemos, peor precisión obtendremos. Podríamos pensar en comparar un proyecto cerrado con otro proyecto cerrado implementado anteriormente, pero normalmente los proyectos son lo suficientemente grandes como para que nuestro error de estimación no sea práctico. Lo mismo se aplica con las releases y los release plan.

También puede ocurrir con las funcionalidades que sean...