Estimación (3): Técnicas ágiles

Acabo con este post la serie dedicada a la estimación. Aunque no lo parezca, entre el primer artículo y el segundo de esta serie ya he explicado lo más importante de la estimación en proyectos ágiles. Todo se resume en cinco reglas sencillas:

1. No estimes si no lo necesitas. Normalmente se estima para adelantar una previsión a los interesados en el proyecto y para evaluar si algo se debe implementar o no.
2. Sólo debe estimar personal experto, que haya construido software similar en el pasado.
3. Estima por comparación, y no usando unidades absolutas.
4. No compares cosas dispares, tanto en tamaño como en nivel de abstracción. Por ejemplo, tareas con historias de usuario, o historias de usuario con releases.
5. No necesitas estimar tareas.

La regla número 2 nos la dice explícitamente Scrum: el PO sólo estima el valor y el equipo de desarrollo estima el coste. Cada uno estima dentro de su área de conocimiento. Ninguna de las partes debe admitir presiones por parte de la otra para que cambie su estimación. Se asume un equipo experto, si algún miembro es un junior, yo recomiendo no darle mucho peso a su estimación, pero que participe en ella para que vaya cogiendo experiencia.

La forma más sencilla de aplicar la regla número 3 es no permitir usar unidades absolutas, como horas, dinero, etc. Simplemente se coge una funcionalidad a estimar y se pregunta, ¿en qué grado esta funcionalidad es más grande o pequeña que esta otra? ¿En qué grado el cliente valora más esta funcionalidad que aquella otra? A dichas preguntas se debe responder en unidades relativas, por ejemplo, «es el doble», «es similar», «es un 123% mayor», etc.

Si a la regla número 3 le añadimos la 4, obtenemos una escala de medida relativa pero que a la vez está simplificada. Si sólo debemos comparar cosas que sean similares, ¿tiene sentido decir que esta funcionalidad es 100 veces más grande que esta otra? No. Claramente las dos cosas que estamos comparando no se encuentran al mismo nivel. Otro problema es intentar obtener una precisión en la estimación absurda, similar o incluso mayor a nuestro margen de error. No es razonable estimar que tal funcionalidad es 1.07 veces más grande que tal otra, cuando normalmente nuestro margen de error es mucho mayor de un 7%. Para reforzar estas ideas se han propuesto varias escalas de medida, y al realizar una estimación no se puede asignar un valor que no aparezca en la escala.

La más famosa de dichas escalas es la escala de Cohn. En la escala de Cohn se admiten los siguientes valores: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. Si os fijáis en escalas pequeñas tenemos 0, 1, 2 y 3, admitiendo que podemos tener cierta precisión. A escalas más grandes, 5, 8, 13, 20, 40 y 100, hay huecos. Estos huecos indican que no debemos invertir esfuerzo en ajustar nuestra precisión ya que estaríamos excediendo el margen de error que normalmente tenemos al estimar.

Siguiendo con el razonamiento que defiendo a lo largo de toda esta serie, ¿tiene sentido decir que una funcionalidad es 20 veces mayor que otra? Seguramente no, y estemos comparando funcionalidades en escalas muy distintas de tamaño. Normalmente una funcionalidad mayor que 5 u 8 se etiqueta como épica. De hecho las funcionalidades épicas normalmente no caben en un sprint, y por lo tanto no son aptas para ser implementadas. Si en vez de Scrum usas kanban, tampoco te salvas, ya que si introduces en el sistema funcionalidades de tamaño muy variable, tanto tu tiempo de entrega como tu productividad se van al garete (teoría de colas). Por lo tanto las funcionalidades épicas son carne de analista funcional, no se aceptan en la fase de desarrollo y deben ser analizadas y descompuestas con más rigor.

Lo inverso ocurre con funcionalidades de tamaño 0. En este caso se consideran tan pequeñas que no merece la pena de gastar esfuerzo en estimarlas. Normalmente representan un nivel de abstracción por debajo del que estamos tratando. Podría se una tarea en vez de una funcionalidad, o un simple detalle de ésta. En general cuando tenemos varias cosas de tamaño cero, o bien las descartamos por estar en un nivel de abstracción inadecuado, o bien las fusionamos si están relacionadas entre si.

Si tenemos en cuenta estas dos prácticas, podemos llegar a la conclusión de que la escala de Cohn, aunque útil para principiantes, no es realmente lo que buscamos. Así llegamos a la otra escala que se usa mucho: tallas de camiseta. Los valores admisible son S, M, L y XL. Las funcionalidades XL se consideran épicas. Sólo se aceptarán funcionalidades S, M o L. Este sistema simplifica el proceso de estimación y evita que caigamos en las trampas de estimar en horas o con una precisión irreal. La dificultad de este sistema estriba en que la capacidad del equipo debe medirse también en tallas de camiseta. Por ejemplo: en un sprint el equipo será capaz de 1 funcionalidad L, 2 M y 4 S. Esto puede causar problemas de estilo de «si tenemos 1 funcionalidad L, pero no hemos escogido ninguna que sea M o S, ¿podemos escoger otra funcionalidad L?».  Una posible solución es definir equivalencias entre tallas: 1 L son 2 M y 6 S, pero 1 M son 2 S.

Otra posible solución para este problema es simplemente no usar una escala. En esta modalidad las funcionalidades o bien son épicas o no lo son. En este caso se deben descomponer todas las funcionalidades de forma que sus tamaños no sólo sean comparables, sino muy similares y constantes.  De esta forma el proceso de estimación se simplifica enormemente, y si se hace bien se reduce la variabilidad de las funcionalidades a implementar. Esto último es especialmente importante, ya una mayor variabilidad implica peores estimaciones y también peor productividad (de nuevo teoría de colas). De esta forma acercamos bastante Kanban a Scrum, donde realmente estaríamos haciendo Kanban si la capacidad de nuestro equipo fuera siempre igual a su límite de WIP. También nos permite estar alineados con la regla 1. La dificultad de esta técnica radica en que tanto el equipo como PO deben ganar mucha experiencia estimando, analizando las funcionalidades y conociendo la capacidad de la otra parte. Por lo tanto sólo lo veo factible en equipos muy maduros.

Finalmente, la regla número 5 simplemente nos indica que tanto al PO como a los stakeholders del proyecto no les interesa saber la descomposición en tareas del proyecto. Si las funcionalidades se descomponen o no en tareas, y si éstas se estiman o no, es una cosa del equipo de desarrollo. Al PO no el interesa el Sprint Burndown, ni el Task Board, sino el Project Burndown, el reporte de bugs y el flujo acumulado de entrega de funcionalidad. Como excepción a esta regla tenemos el caso en el que parte del equipo de desarrollo pertenece al cliente, o que tal vez no hay un equipo sino varios equipos de especialistas que forman un pipeline. Para asegurar una correcta coordinación, puede ser razonable hacer un plan de tareas y llevar un seguimiento de éstas, pero obviamente esta forma de estructurar equipos no es la recomendada en un proyecto gestionado de forma ágil.

Como apunte meramente personal, mi posición con respecto a la estimación es bastante pesimista, ya he visto muchas veces como hasta la estimación más cuidadosa fracasaba, y como planes muy bonitos plantados sobre un «project» se iban al garete en cuanto tenían el más mínimo contacto con la realidad. Mi opinión personal es que hay que estimar en formato «rápido y sucio», y el proceso de desarrollo que uséis debe estar preparado para trabajar con este tipo de estimaciones aproximadas. Bueno, pues con esto acabo la serie sobre estimación, espero que os haya sido útil.

Read Full Post »

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.

Read Full Post »

Estimación (1): ¿Hasta que punto se puede?

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.

Read Full Post »