Contexto del artículo
Este artículo fue escrito para una serie de exposiciones sobre agilidad en el año 2015, pero debido a que el tema sigue siendo una problemática en muchas empresas aún hoy, he decidido publicarlo.
Ahora sí, vamos…
Problemática Actual (sigue siendo actual!!!)
Todos sabemos y en todos lados dice que la estimación de proyectos de Software es sumamente complicada y que casi casi se necesita de un milagro o una iluminación espiritual para obtener un valor más o menos aproximado.
Como ingenieros, estamos acostumbrados a construir cosas muy complejas y a las estimaciones que ya son complejas, las solemos hacer, más complejas aún, haciendo que esta tarea sea una actividad muy desgastante. Suelo encontrarme que, en algunos equipos, se van incorporando nuevas cosas y factores, haciéndolas más y más difíciles de defender. En otros casos, el número final, lo coloca alguien que hace años no programa o que no conoce el equipo o perfil de los miembros que lo compondrá, esto en el mejor de los casos y en el peor, lo termina colocando alguien que ni siquiera pertenece a la disciplina de Ingeniería de Software.
Por lo tanto, podríamos hablar de tres problemáticas:
Hacer más complejo algo que ya es complejo
La estimación de proyectos de software la realiza una persona o en el mejor de los casos varias, pero que hace ya muuuuuucho tiempo no programan, es más ni conocen los procesos que usan sus equipos para programar.
Se inicia con la estimación de esfuerzo (horas, semanas, meses) cuando se debería partir de la estimación de tamaño (complejidad).
Sobre la aclaración de estas tres problemáticas se basa el artículo…
Los Puntos
El origen de la complejidad en la estimación del software radica en que es un intangible, esto hace difícil aplicar unidades de medidas utilizadas para establecer el tamaño de trabajos tangibles. Por esto hace ya muchos años, surgieron los Puntos.
Los puntos atienden esta situación de poder ponderar el tamaño del software que se necesita estimar. En nuestra disciplina, el tamaño esta relacionado con la complejidad,
tamaño = complejidad
Ahora bien, pero que son los puntos?
Son valores relativos, no fijos, establecidos por el equipo que construye el software, por lo tanto, se basa en el tamaño relativo de un requerimiento (normalmente una historia de usuario) con relación a otro, basándose en la experiencia previa “real” del equipo.
No se trata del tamaño en tiempo, sino de la comparación entre el tamaño relativo contra un estándar. Para definir el estándar, el equipo deberá consensuar una visión común de la escala que utiliza.
En la práctica, cada miembro de un equipo deberá pensar al momento de estar estimando, que tanto mas o menos complejo es lo que está analizando contra una unidad previamente consensuada por el equipo (se recomienda que esa unidad sea 1 punto o una unidad pequeña). Bajo este enfoque, si lo que estamos analizando es el doble de complejo o el triple de complejo a ese valor estándar, entonces elegirá el valor 2 o 3.
Ahora bien, seguro estarán pensando al leer esto, que siempre dependerá del skill que tenga la persona, porque algo que es más complejo para una persona no lo es para otra. Al igual que este factor existen muchos otros, que de enumerarlos harían este artículo demasiado largo y complejo y atentaría con cumplir con su objetivo. Entonces solo comentaré para este caso en particular, que es sumamente primordial establecer ciertas reglas relacionadas a conformar el equipo que realizará estas estimaciones, como por ejemplo buscar en lo posible que los miembros tengan skills similares dentro del grupo de estimación.
Pero entonces, si no uso tiempo, como calculo la duración de un proyecto
La manera de calcular la duración de un proyecto o una release se basa en el conocimiento de la cantidad de puntos en promedio que un equipo puede hacer en un periodo de tiempo.
Es decir, si le pido a alguien que se dedica a pintar paredes que me calcule cuanto tiempo le llevará pintarme una, seguramente me pedirá los m2 (los puntos en nuestra disciplina) o me pedirá verla para que en base a la cantidad de m2 que realiza su equipo por día o semana, pueda pasarme el tiempo (esfuerzo) y calcular la inversión.
Entonces en el software hacemos lo mismo, en base a los puntos del proyecto o la release y conociendo la cantidad de puntos en promedio que el equipo puede realizar (Velocidad en Scrum) en un periodo de tiempo (Sprint en Scrum), entonces puede calcular la cantidad de periodos o tiempo que le llevará para atender esos puntos.
Recomendaciones finales
Realizar estimaciones colaborativas.
Mantener simple la estimación! Esto no significa no prestarle atención, es más al inicio deberá de realizar trabajos de análisis de estimaciones para asegurar que sean confiables y coherentes a medida que avanza en la madurez del nuevo enfoque.
Asegurar la trazabilidad de las estimaciones al momento de pasar de estimaciones de paquetes de trabajo grandes a pequeños, esto permitirá determinar la certeza de nuevas estimaciones respecto a estimaciones en etapas tempranas.