Las actividades de estimación son fundamentales en la planeación y ejecución de los proyectos de desarrollo de software, donde sus principales objetivos son: 1) estimar el esfuerzo requerido para desarrollar en su totalidad los requerimientos del producto de software; 2) estimar el impacto de los cambios, durante la ejecución del proyecto; 3) estimar el alcance que tendrá cada incremento o sprint. Estos objetivos se convierten en los insumos más relevantes de los decisores (director de proyecto, sponsor del proyecto, gerencia) para determinar el rumbo de proyecto, inclusive su continuidad o no. El propósito del presente blog es comparar la técnica de estimación Function Point Analysis (FP) con Story Points (SP) en el contexto de desarrollos ágiles. ¿Por qué comparar estas dos técnicas? Si bien SP es parte de SCRUM y por ende es el método predilecto de los equipos ágiles, también es cierto que FP es empleado ampliamente en la industria, incluyendo contextos ágiles. Estas dos técnicas se basan en la noción de tamaño del software, para luego aplicar un factor de productividad (o velocidad en el caso de SP) que permita determinar el esfuerzo requerido para el desarrollo. No pretendo determinar cuál es mejor, pero si ilustrar sus ventajas y desventajas, las cuales puedan ser tenidas en cuenta en el instante de seleccionar una u otra en un determinado contexto. Esto lo presento a través de dos secciones: i) comparación según buenas prácticas y aspectos del proceso de estimación y ii) conclusiones prácticas.

Comparación

A continuación, se presentan la comparación de las dos técnicas, empleando criterios tomados como una adaptación de buenas prácticas de un proceso de estimación según Jogersen (2004) y Jogersen-Boehm (2009).

CONCLUSIONES PRÁCTICAS

1. A pesar que los dos métodos emplean la noción de tamaño, en FP la medida está restringida a “tamaño funcional y de datos”, excluyendo factores de complejidad y del contexto del proyecto (como experiencia del equipo, distribución física, etc). Mientras que en SP la medida si incluye la complejidad y otros aspectos que afecte el desempeño del equipo. La aproximación de FP permite separar con mayor claridad dos intereses: el tamaño y la productividad. Esta separación brinda las siguientes ventajas: a.  Reducir las discusiones de estimación al no tener que mezclar en un solo instante estas dos variables. Es mucho más fácil comparar tamaños funcionales (número de campos de entrada de datos, columnas, tablas involucradas). b.  No hay que interpolar el esfuerzo derivado por factores de complejidad y de contexto del proyecto a la estimación de cada componente o historia de usuario. Estos factores, seguramente, son inherentes a todo al proyecto y no a un componente en particular.
2. Los dos métodos pueden ser empleados para estimar la completitud del proyecto, siempre y cuando la información esté disponible (expresada en requerimientos funcionales, historias de usuario o verbalmente). En cualquier caso, se requiere que quien está estimando comprenda el alcance del desarrollo.
3. Los dos métodos pueden ser empleados por el equipo para estimar el tamaño de cada incremento/Sprint y adquirir compromisos. FP exigirá mayor responsabilidad puesto que sus resultados pueden ser comprendidos y confrontados por stakeholders externos al proyecto.
4. En un desarrollo incremental o por Sprints, el análisis y diseño del modelo de datos es generalmente “descuidado” en la estimación, surgiendo interrogantes como: a.  Supongamos que tenemos dos historias de usuario similares en tamaño (ej: capturan el mismo número de campos), pero para una de ellas el modelo de datos que la soporta ya fue diseñado y para la otra no. ¿Las dos tienen el mismo número de SPs? b.  ¿Cómo varia la velocidad/productividad a medida que el proyecto avanza y el modelo de datos es más estable y con mayor completitud?
5. A nivel organizacional, FP brinda mayor valor: mantener históricos de productividad; comparar productividades entre proyectos (comparar tecnologías, ambientes de trabajo, sectores, etc).
6. Si los componentes o historias de usuario son fragmentadas (tajadas) en múltiples Sprints, FP presenta una anomalía al ser empleado para determinar las historias de usuario a incluir en un Sprint. Por ejemplo, si una funcionalidad es inicialmente desarrollada en el Sprint 1 y luego mantenida en el Sprint 2, el tamaño en puntos funcionales se contará dos veces.
7. Si los incrementos o Sprints son muy cortos (una o dos semanas), FP no es apropiado pues las estimaciones en pequeño pueden presentar grandes desviaciones.
8. Si la estabilidad de los requerimientos es muy baja, y cada incremento/Sprint contiene un alto porcentaje de refactoring, SP es más adecuado. En FP las tareas de refactoring no aumentan la funcionalidad percibida por el usuario, por lo cual el total de puntos funcionales aportado por estas tareas será cero.
9. Si el Backlog contiene un alto porcentaje de ítems no funcionales, SP es más adecuado, ya que los estimadores pueden brindar pesos a tareas tales como afinamientos, aplicación de estilos gráficos, y adición de reglas de negocio individuales. Es importante anotar que en estos casos, la estimación será un juicio de expertos tradicional, pues los estimadores no tendrán una “funcionalidad de referencia” para comparar. En este caso es más adecuado SP, no por su principal virtud (brindar un estimado de tamaño al comparar con un referente), sino por la libertad del método de dar un valor sin adherirse a reglas bien definidas.

BIBLIOGRAFÍA

Jogersen (2004), M. JøRgensen, A review of studies on expert estimation of software development effort, Journal of Systems and Software, v.70 n.1-2, p.37-60, February, 2004 Jogersen-Boehm (2009), Barry Boehm, Stan Rifkin, Magne Jørgensen, “Software Development Effort Estimation: Formal Models or Expert Judgment?”, IEEE Software, vol. 26, no. , pp. 14-19, March/April 2009