Estimación (2): ¿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 que son 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 de hacer 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 que hayamos 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 que funcionalidades 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, release o 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 entonces una 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 y barato. 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 a má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 especialmente grandes. ¿Qué hacemos? Pues simplemente dividir. Dividir proyectos en releases, dividir releases en funcionalidades y funcionalidades grandes en otras más pequeñas. Dividir hasta que la precisión que podamos alcanzar con cada trozo sea razonable (y no más). Pero, ¿no es lo mismo ésto que el caso anterior de dividir una funcionalidad en tareas? No. Veamos las razones:

• Al cliente le interesan las funcionalidades, no las tareas. El cliente evaluará el resultado final en función de las funcionalidades entregadas. Por lo tanto el plan de proyecto debe expresarse en funcionalidades, y no en tareas, para que el cliente pueda hacer un seguimiento que pueda entender (¿Se nos retrasó esta funcionalidad?¿Cuántas funcionalidades nos quedan?)
• Funcionalidades y tareas están en dos niveles de abstracción diferentes. Podemos dividir un proyecto en releases, y estas en funcionalidades, y las funcionalidades en otras más pequeñas, que no abandonamos el nivel de abstracción que representa el “qué tiene que hacer el sistema”. El realizar estas divisiones y refinamiento de la funcionalidad es en realidad el “análisis funcional”. Las tareas están en otro nivel de abstracción, el “cómo pensamos construir el sistema nosotros”. En este sentido el salto entre funcionalidad y tareas es más brusco y propenso a error, y realmente hacerlo es parte del “diseño técnico”. ¿Queremos empezar a hacer el diseño técnico antes de planificar y estimar?

La otra dificultad se produce cuando no tenemos experiencia previa con algún proyecto o funcionalidad similar, es decir, no existe nada con lo que comparar. En general en esta circunstancia nuestra estimación va a ser muy arriesgada hagamos lo que hagamos. Estaríamos tentado de analizar dicha funcionalidad en tareas, con la esperanza que las tareas que salgan nos resulten familiares y podamos estimarlas. Esto es un error. Reflexionemos, si no tenemos experiencia con este tipo de funcionalidad, ¿cómo vamos a ser capaces de hacer el análisis y diseño técnico de la funcionalidad para descomponerla en tareas de forma precisa? Sí, podemos hacer esta descomposición, pero seguramente esté mal, o nos falten tareas o no hayamos tenido en cuenta las peculiaridades (para nosotros desconocidas) de esa funcionalidad o proyecto. Existe otra forma mejor, y es hacer una prueba de concepto, o “spike”. Invirtamos algo de dinero en hacer una implementación a pequeña escala de lo que queremos estimar, y usemos el conocimiento adquirido para hacer nuestra estimación. Sí, es más caro y lento, no es perfecto, pero es menos arriesgado que el enfoque anterior.

Finalmente, desde un punto de vista más específico de Scrum, existe otra razón para no estimar las tareas. Recordemos que la planificación en Scrum se basa en el ordenamiento de ítemes en el backlog en función de su ROI. El ROI se entiende como la relación entre el valor del ítem y su coste y/o tamaño. Es decir, en Scrum no sólo se estima el coste sino el valor. Si descompongo una funcionalidad en tareas y estimo cada tarea por separado, no sólo debo estimar el coste de cada una de ellas, sino su valor. Como el valor de una tarea es cero, el ROI de cada tarea es cero también. ¡ Si sumo el ROI de todas las tareas me sale que el ROI de la funcionalidad es cero ! Esto ocurre debido a que hemos sido inconsistentes y hemos cambiado de nivel de abstracción alegremente. Una señal de que hemos violado el nivel de abstracción pertinente es que las cuentas no salen, ya que el todo es mayor que la suma de las partes.

En el próximo post contaré algunas técnicas de estimación ágiles.

About these ads