En el desarrollo de software siempre habrá que estimar el tiempo en que nuestro equipo o un colaborador tarda en entregar un requerimiento. Este dato tiene sentido porque básicamente ayuda al negocio a hacer presupuestos y a evaluar ganancias. Es decir, a mayor tiempo de desarrollo, mayor gasto o inversión para pagar al desarrollador o equipo que desempeña la tarea. Recordemos que cada hora de programación, cuesta.
Otro punto a favor de estimar el tiempo de desarrollo, es para ayudar al negocio a saber cuándo se harán entregas que aporten valor al producto, y así poder plantear un pipeline congruente al beneficio del negocio mismo.
Por lo tanto, cada que te pidan una estimación de tarea, nos vemos obligados a mencionar el dato.
El problema
Sin embargo, aunque ya vimos que hace sentido estimar, es una realidad que cuesta trabajo calcular este valor. ¿Un día? ¿Una hora? ¿Un sprint? “Mañana queda”, “déjame ver”, “lo voy a evaluar” son frases que usan frecuentemente ante el cuestionamiento de tiempos de entrega.
Causa del problema
Hay demasiadas variables que hacen que sea difícil estimar el tiempo de desarrollo, además de que cada proceso laboral es distinto entre sí. Algunas de las causas más comunes son:
- Falta de definición del requerimiento. El requerimiento esta incompleto o hay ambigüedades. No existen todos los casos de uso o criterios de aceptación.
- Dependencias de equipos terceros. Es común que para que un requerimiento se cumpla, participen diferentes equipos, y estos trabajos en serie vuelven la estimación más complicada.
- Desconocimiento de la solución. Algunas veces, el requerimiento es tal que no se tiene certeza completa de cómo dar una solución, lo que hace complicada la estimación por que implica análisis y en algunos casos capacitaciones (comúnmente autodidacta) para poder entender e integrar la solución.
Solución
Por lo tanto, para evitar que la estimación sea de dedazo, presentamos una gráfica para dar visibilidad al equipo, a todos, en dónde se encuentra el requerimiento y no dejar que su solución sea un acto de fe. A continuación la gráfica:
Gráfica: Nivel de Esfuerzo y Tiempo en Software
La gráfica es una herramienta para tener una visión rápida de la estimación de tiempo y esfuerzo de un desarrollo. Éstos básicamente pueden ser:
- Nuevo requerimiento
- Mantenimiento de software
El Eje Y (lado izquierdo) nos indica qué tan cercano o alejado está el nuevo requerimiento o mantenimiento de su funcionalidad inicial. Mientras más cercano este al Eje X (hacia abajo) será más cercano a lo que inicialmente se desarrolló.
El Eje X (parte de abajo) nos indica qué tanto conocemos de la solución, tanto en la tecnología que usamos, como el conocimiento requerido para dar soluciones. Mientras más cercano este al Eje Y (hacia la izquierda) nos dará más certeza de la solución que debemos emplear.
Ejemplos
Pensemos en un auto. Tenemos un vehículo color rojo, que usa gasolina, que tiene sus cuatro llantas, motor, puertas, etc. Un auto común y corriente. Ahora pensemos en un requerimiento en forma de Historia de Usuario:
Como usuario quiero que el auto sea de color negro para que cumpla con mi colección de autos oscuros.
En este caso podemos suponer que cambiar el color del auto no cuesta tanto trabajo y además sabemos hacerlo. Por lo tanto el nivel de estimación de tiempo y esfuerzo podría estar ubicado así:
Vamos con otro ejemplo, citado de igual manera en Historia de Usuario:
Como usuario quiero que el auto sea convertible para poder disfrutar del aire y la vista cuando vaya manejando.
¡Wow! ¿Cambiar el auto para que sea convertible? Esto suena algo muy distinto al requerimiento inicial ¿no es así? Pero supongamos que vamos a asignar a nuestro mejor personal para hacer el cambio. Entonces nuestra requerimiento quedaría ubicado de la siguiente manera:
¿Por qué esta ubicada de esa manera? Podemos argumentar que aunque asignamos a nuestro mejor personal y sabe cómo hacer el cambio, este requerimiento esta muy alejado del funcionamiento actual, eso hace que el tiempo de desarrollo sea más tardado. ¿Imaginan cómo quedaría la estimación de tiempo y esfuerzo si nos ayudara un equipo sin experiencia en hacer un auto convertible?
Veamos un ejemplo más que complementa la idea:
Como usuario quiero que el auto sea híbrido para poderlo usar sin gasolina.
Aquí tenemos todo un reto. Cambiar el auto de uso de gasolina a híbrido.
Definitivamente algo nuevo. Podemos decir rápidamente que no esta cerca de la especificación inicial y además no tenemos personal que conozca cómo hacer este ajuste, por lo tanto, nuestra gráfica luciría así:
Ahora todos estamos de acuerdo en que el requerimiento llevará mucho tiempo de desarrollo, y queda claro en dónde ubicamos el esfuerzo.
Conclusión
Contar con una herramienta que nos apoye a comunicar el por qué de nuestras estimaciones y nos ayude a dar visibilidad a los equipos, es imprescindible en nuestra credibilidad como desarrolladores.
¿Y tú qué herramienta usas para estimar tus tiempos y esfuerzo de desarrollo?
Top comments (0)