Os traigo otro clásico, otro debate que se ha convertido ya en tradicional, el de comparar, digo casi equiparar, puntos función con puntos historia. Suele darse en aquellos lugares que vienen de un entorno más clásico y tradicional, usando puntos función, y quieren dar un ligero paso a la agilidad… usando puntos historia, pero sin dejar muy lejos el pasado.
Total, como ambos tienen la palabra “puntos” en su nombre pues… serán lo mismo ¿no? Pues no, no. Vamos con algunas diferencias…
Los puntos historia miden tamaño en función del “esfuerzo” y los puntos función tamaño en función de la “complejidad”
Los Puntos Función son una métrica, obtenida tras aplicar una formula, que pretende establecer el tamaño en función de la complejidad de los requisitos. Para más datos, hace ya sus añitos te dejé por estos lugares algo que ya hasta suena a antiguo: Los puntos función. Una breve introducción a la estimación software.
Los puntos historia son una unidad usada, normalmente, para establecer el “tamaño” de una historia de usuario en función del esfuerzo. Una historia de usuario de 2 puntos historia se estima que requerirá el doble de esfuerzo que una historia de 1 punto historia. Ya lo hemos contado varias veces (en el libro el libro “Cómo sobrevivir… A la planificación de un proyecto ágil” de 233 Grados de TI, en los post Como estimamos proyectos Scrum o en general ágiles y en ¿Qué es la velocidad en un proyecto software?).
Los puntos historia trabajan con requisitos poco documentados (si falta información se busca la interacción entre personas) y los puntos función necesitan requisitos exhaustivos
Los puntos función suelen venir de la mano del ciclo de vida en cascada, del proyecto cerrado, de la especificación de requisitos pormenorizada. Necesitan requisitos altamente detallados, usualmente en papel, para poder sacar de ellos todos los datos necesarios para lanzar las formulas de su cálculo. Datos del tipo a ficheros que tocará la implementación de ese requisito, procesos, entradas, salidas (así resumidamente, que no quiero hacer complejo el post).
Los puntos historia suelen usarse con historias de usuario, recuerda lo de la historia de usuario en las metodologías ágiles.
Los puntos historia se basan en la experiencia y los puntos función en formulas
Los puntos historia se obtienen desde el conocimiento global del equipo, su experiencia, y los puntos función en base a formulas predefinidas (obtenidas por otros en función de datos estadísticos, aunque el calculo final se tenga que parametrizar según el caso concreto)
Los puntos historia no están ni mucho menos tan normalizados como los puntos función
Lo cual no es ni mucho menos un problema, es una forma diferente de ver las cosas. Mientras que los puntos historia se asignan normalmente desde el conocimiento compartido del equipo (véanse técnicas como el planning poker), para los puntos función hay numerosas, arduas, complejas y amplias normas y metodologías para su cálculo, véanse algunas de muchas… ISO 20968:2002 Mk II Function Point Analysis, ISO 20926:2009 IFPUG, ISO/IEC 19761 COSMIC-FFP o ISO/IEC 24570 NESMA.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Javier, estoy de acuerdo con el tema central de tu articulo no tienen nada que ver un método con el otro pero me gustaría puntualizar alguna cosa.
Los Puntos de historia son un valor relativo que solo vale para comparar la complejidad de unas historias con otras para un equipo determinar pero no da una idea de las horas necesarias para su desarrollo.
Dentro de los puntos función existen muchos métodos que solo comparten la palabra Puntos, son diferentes y sus objetivos son distintos por eso no deben englobarse. Por ejemplo: IFPUG, NESMA,COSMIC, MK-II, SiFP, EQFP, FiSMA, etc.
Estos métodos son independientes del ciclo de vida del proyecto, se asocia con el ciclo en cascada porque son métodos que se vienen empleando desde hace mucho tiempo,el primero data de 1979 pero perfectamente se pueden aplicar a requisitos capturados en cualquier ciclo de vida.
Dependiendo del método de puntos función puedes necesitar mayor o menor detalle pero también eso depende del tipo de aplicación a medir, por ejempo el método FFP de COSMIC se utiliza para medir, sobre todo, sistemas en tiempo real donde las interacciones tienen que tener un nivel de detalle muy grande por lo cual el método utiliza ese nivel de detalle.
En otros como el método de IFPUG, el más extendido, se puede utilizar cualquier documentación o una persona, sí se puede recurrir a un experto que conozca la aplicación y te dé detalle de la misma. Lo que se necesita conocer es que hace funcionalmente el software o que debe hacer. Si esto se sabe se puede medir.
Por último, la reseña que indicas de la normalización es debido a que ISO publicó un estandar para métodos de medición funcional del software (ISO FSM (ISO/IEC 14143-1:2007) al cual intentaron ajustarse los métodos existentes, es decir utilizar un marco de definiciones común para hablar de lo mismo pero no implica un nivel de complejidad grande.
Gracia por el artículo.
Un saludo.
Julián.