Desde el inicio del desarrollo de software las estimaciones han sido un dolor de cabeza. Según algunos artículos que he leído, dada la poca madurez que tiene la ingeniería del software y el hecho de querer copiar herramientas de otras ingenierías han hecho que estemos chocando contra pared cada vez que nos pidan una estimación y su comparación con la realidad. A partir de muchos elementos, como el mencionado anteriormente, es que se han desarrollado múltiples metodologías o herramientas de trabajo para mejorar entre otros las estimaciones de las actividades que se deben llevar a cabo para obtener un producto o software terminado (con todo lo que implique terminado –completo, que haga lo que debe, terminado según el tiempo comprometido, etc.-).
Dentro del mundo de la gestión profesional de proyectos, apoyados en las buenas prácticas que propone el Project Management Institute – PMI, existe un área de conocimiento para la gestión del tiempo, la cual expone una serie de procesos y herramientas que se enfocan en crear la mejor estimación posible del proyecto, las actividades y tareas a desarrollar (en etapas tempranas del proyecto). Además de otras áreas que apoyan a la gestión del tiempo para mejorar las estimaciones, por ejemplo, la gestión del riesgo, basados en el conocimiento que exista sobre el producto (o servicio) que se pretende construir y el nivel de incertidumbre que tenga el proyecto. O también áreas como alcance, recursos humanos, entre otras.
Hace unos años, el PMI ha incorporado como parte de sus buenas prácticas el uso de elementos agiles para el desarrollo y la gestión de los proyectos. En este caso me quiero enfocar en algunas herramientas que pueden ayudar mucho a mejorar las estimaciones para el desarrollo de proyectos de software, sin que se limiten a este ámbito y a un movimiento (que no necesariamente este impulsando el PMI) sobre la no estimación (#NoEstimates).
En el PMBOK (2013), dice que la estimación de la duración de las actividades tiene como beneficio establecer la cantidad de tiempo para finalizar cada actividad y tener una de las entradas fundamentales para la construcción del cronograma del proyecto. Para esto se propones algunas técnicas y herramientas como por ejemplo:
• Juicio de expertos
• Estimación análoga
• Estimación paramétrica
• Estimación por tres valores
• Etc.
He utilizado de casi todas estas propuestas para estimar las actividades de desarrollo de software en mis proyectos, apoyados en la experiencia del equipo de proyecto, en las herramientas que nos ayuden a tomar las mejores decisiones, en la cantidad de información que tengamos sobre el productos que vamos a construir, entre otros. En muchas ocasiones durante la ejecución de las tareas, algunos de los tiempos que podemos ahorrarnos en algunas tareas los invertimos en otras en las que haya hecho falta tiempo, y vamos nivelando el tiempo total estimado. Sin embargo, el tema de las estimaciones siempre es complejo y es difícil de atinar. (Sobre todo en etapas tempranas de un proyecto.)
Los movimientos llamados de prácticas ágiles se basan en algunos principios base, entre los que está el desarrollo del producto (software en este caso) de forma empírica, así el conocimiento del producto que debemos desarrollar procede de la experiencia durante su desarrollo y la toma de decisiones con forme pasa el tiempo y conozco más. El problema es que necesitamos iniciar a construir la solución para conocerla cada vez más, y siempre debemos dar una estimación de cuánto va a tardar el proyecto, que recursos voy a necesitar, cuánto va a costar, etc.
En el mundo ágil no se recomienda hacer estimaciones a corto plazo con una base de tiempo (horas, días, semana, etc.), sino más bien sobre el esfuerzo y complejidad de las tareas y actividades a completar o en base a el conocimiento que tengamos de lo que hay que hacer. Incluso para las estimaciones a largo plazo (al inicio del proyecto) podemos dar una medida de esfuerzo o de comparación con respecto a experiencias ya vividas.
Estimaciones ágiles: Cono de la Incertidumbre
El cono de la incertidumbre es el evolucionar de la incertidumbre durante el desarrollo del proyecto. Al inicio conocemos poco de los requerimientos y necesidades por lo tanto la incertidumbre es mayor, con forme avanzamos y conocemos más el negocio, sus reglas y otros, el nivel de incertidumbre baja y según el proyecto puede llegar a desaparecer. Sin embargo esto último sucede hacia etapas avanzadas o finales del proyecto. (Ver la siguiente figura)
Existen proyectos, en donde puede implicar un ambiente en el cual la evolución de la incertidumbre es lenta o muy lenta, lo que puede parecer que es una evolución estática. En un contexto como estos la planificación detallada antes de iniciar el desarrollo puede ayudar a bajar los niveles de incertidumbre y los niveles de riesgos asociados a este conocimiento previo. Así el cono de incertidumbre decrece rápidamente al inicio del proyecto.
Ahora bien, en software específicamente además de la cantidad de conocimiento que exista antes de iniciar o no el proyecto, existen muchos elementos que hacen incrementar el nivel de incertidumbre, por ejemplo: cambios del negocio o los procesos, cambios tecnológicos, políticas internas o externas, entre muchos otros. El trabajo para esclarecer más los requerimientos y bajar esa incertidumbre es algo constante durante todo el proyecto.
Estimaciones en ambientes inciertos o poco claros
Dado que es un hecho, el que nos van a solicitar estimaciones (tiempo en este caso) aún en etapas incipientes del proyecto, debemos basarnos entre otros, a supuestos que esperamos se cumplan. Para esto hacemos uso de estimaciones de orden de magnitud, las cuales pueden estar muy distantes de la realidad. En estos casos las prácticas ágiles proponen optar por reducir la precisión de las estimaciones en función de cuánto conocimiento se tiene sobre el ESFUERZO que se necesita para estimar. Así los requerimientos, necesidades o ideas que se tengan sobre lo que hay que construir se pueden clasificar en distintos niveles de precisión.
• Alto nivel: las llamadas EPIC (épicas: bloque funcional) Que pueden ser estimadas según su tamaño relativo entre ellas, por ejemplo se puede utilizar una métrica como el tamaño de una camisa: XS, S, M, L, XL.
• Nivel medio: Historias de usuarios (funcionalidades) Que se estiman en base a puntos de historia, utilizando por ejemplo la serie de Fibonacci para darle un peso relativo.
• Bajo nivel: tareas o actividades que se pueden estimar en horas (de conveniencia en escala de menos de un día de trabajo).
Al iniciar con el levantamiento de los requerimientos principales del producto o servicio a construir, creamos un Product Backlog (pila del producto) compuesto por bloques funcionales. Cada bloque o requerimiento (según el nivel de precisión) se coloca en el product backlog en el orden que indique el valor que puede generar al negocio. O sea, en la parte de arriba del product backlog se colocan las EPIC o historias de usuario que tenga mayor valor para el producto a construir. Una segunda regla al momento de construir nuestro product backlog es que en la parte de arriba estén los bloques funcionales con mayor nivel de detalle y mayor claridad de lo que hay que hacer. Conforme bajamos entre los ítems del product backlog el nivel de detalle es menor. De esta forma, si una EPIC estuviera entre los primeros lugares del product backlog, debe ser descompuesto en historias de usuario. Con esto vamos identificando el detalle solo de las primeras entradas del product backlog.
Para la estimación de los ítems de alto nivel, es difícil al inicio del proyecto, y con el poco conocimiento que exista del producto o el detalle de sus características o aspectos técnicos, que podamos dar una estimación en días o semanas o meses, sin embargo, nos sería más natural poder dar una estimación relativa según comparaciones de tamaño, en este caso, utilizando las medidas de tamaño de camisas. Así damos una estimación según complejidad y esfuerzo relativo a la o las funcionalidades y el conocimiento que tengamos.
Para las historias de usuarios aplicamos un ejercicio similar al anterior. De igual forma damos una estimación relativa. En este caso utilizamos como ejemplo la serie de Fibonacci con algunas modificaciones, (0, 1, 2, 3, 5, 8, 13, 21, 40…, 100 lista de valores que vamos a utilizar para estimar). Cuando asignamos un valor de 2 a una historia de usuario, esto significa que requiere aproximadamente el doble de esfuerzo que una historia de usuario con un valor de 1. Y una historia de usuario con un valor de 3 requiere aproximadamente el triple de esfuerzo que una con un valor de 1, y una medida más que la historia de usuario con un valor de 2. De nuevo es más natural medir los valores según el esfuerzo y complejidad. De esta forma no debemos dar valores en horas o días.
Cuando llegamos al nivel de clasificación bajo, hablamos de tareas o actividades que se van a realizar durante un sprint de desarrollo (Sprint: iteración, es un bloque de tiempo, entre 1 y 4 semanas, durante el cual el equipo crea un incremento de producto terminado, potencialmente utilizable). En la reunión de planificación tomamos las historias de usuario de la parte superior del product backlog y las descomponemos en las tareas a ejecutar para ser completadas.
Ahora bien, si tenemos un product backlog base o inicial, y hemos estimado el tamaño de los ítem (sean EPICs, Historias de Usuario o tareas) cómo sabremos ¿cuál sería el tiempo aproximado para completar este product backlog? Una forma de calcular seria utilizar la “velocidad del equipo”.
Velocidad del equipo
La velocidad del equipo se mide según la cantidad de puntos de historias de usuario que puede completar durante un sprint. Entonces, asumamos el siguiente ejemplo:
a) Tenemos un producto backlog con 1000 puntos de historia de usuario. (asumiendo que todos los ítems tiene una estimación en puntos)
b) Nuestro sprint está compuesto por bloques de tiempo de 3 semanas.
c) Nuestro equipo de desarrollo puede completar 120 puntos de historia en cada sprint, aproximadamente.
d) ¿Cuánto tiempo tardara en desarrollar el producto?
a. Los 1000 puntos del product backlog / 120 puntos que completa el equipo por sprint = 8.33. O sea se ejecutaran aproximadamente 9 sprint para completar el product backolog.
b. Si cada sprint es de 3 semana, 3 * 9 = 27 semanas. Aproximadamente 6.75 meses.
¿Cuál sería el “pero” con este ejemplo?
Debemos de antemano conocer la velocidad del equipo, y esto solo se logra trabajando durante el proyecto. Sé dice que luego de 4 a 7 Sprint’s se puede tener la velocidad aproximada de un equipo. Adema de considerar múltiples factores como: sinergia del equipo, capacidades y competencias, la teoría de formación de equipos de Tukman, entre otros.
Lo anterior nos coloca en una desventaja para poder estimar el proyecto en etapas tempranas, aún para platear una posible propuesta de proyecto antes de ingresar en el listado de iniciativas del portafolio de proyectos de la organización.
Método Delphi de banda ancha para estimar un proyecto
Este método se puede explicar de la siguiente forma:
a. Identifique un grupo de expertos y proporcióneles una definición del proyecto.
b. Pida a cada experto que estime una cantidad de esfuerzo y complejidad, incluyendo listado de las principales tareas con su estimación de esfuerzo.
c. Comparta los resultados y repita el proceso, hasta que tenga estimaciones de consenso.
Una ventaja de este método es la participación de varias personas expertas en la identificación de las tareas a realizar y sus estimaciones. Además la estimación en conjunto elimina sesgos personales, juicios u otros factores.
Con el método Delphi de banda ancha podemos además:
a. Crear una estructura detallada del trabajo
b. Definir la base del esfuerzo necesario
c. Calcular el tamaño del desarrollo
d. Identificar los principales problemas que pueden afectar el desarrollo
e. Etc.
#NoEstimates
“¿Cómo podemos estimar cuando todavía no sabemos o entendemos la solución?”
Desarrollar software es por naturales imprevisible y no repetitivo, como lo puede ser construir un bicicleta, dado que el producto que estamos creando es desconocido hasta el momento que lo hacemos.
Entonces, estimar tiempo y esfuerzo es casi imposible. Incluso es perjudicial para el proyecto, dado que cierra la puerta a los cambios o los puede limitar mucho. Limitar los diseños emergentes, las buenas ideas, la creatividad y la innovación.
Pero no podemos cerrarnos a que no van a darse cambios en el proyecto, por lo tanto si aceptamos que los requerimientos pueden cambiar, entonces, debemos aceptar que la fecha de finalización también a va cambiar.
Si no tendremos una lista cerrada de requerimientos desde el comienzo del proyecto, entonces no podremos tener una estimación precisa.
A menos que tengamos por delante una aplicación tipo empotrada o embebido, la cual está definida una lista finita de funciones a realizar, no es posible tener la lista de requerimientos definidos desde el inicio del proyecto.
Para quienes defienden el movimiento #noEstimates, con una visión clara, un propósito definido, y una lista de requerimientos de alto nivel podemos construir una aplicación. “¿qué sentido tiene buscar una estimación precisa y condicionar todo el proyecto a ella?”
Por ejemplo en #noEstimate se dice que durante un sprint, se comprometen a desarrollar el mejor avance (productos) posible para el tiempo que tarde el sprint.
#NoEstimates es todo un reto, para la cultura de nuestras organizaciones y para los equipos de desarrollo mismos.
Bibliografía
• Javier Garzas, (2014). “Gestión de proyectos ágil… y las experiencias de más de 12 años de proyectos ágiles”
• Javier Garzas, “Cómo sobrevivir… A la planificación de un proyecto ágil”
• Sito de Javier Garzas, http://www.javiergarzas.com, consulta 15 enero 2017.
Deja tu comentario