Puntos de historia versus puntos de función, ¿cuál es la diferencia y por qué es importante? Los puntos de la historia son indicadores arbitrarios del esfuerzo esperado. Son inconsistentes e inadecuados para su uso como métrica principal en proyectos de software. Le recomendamos que cambie a los puntos de función COSMIC estándar ISO y dé 14 razones para ello.
Puntos de historia versus puntos de función, ¿cuál es la diferencia y por qué es importante? Los puntos de la historia son indicadores arbitrarios del esfuerzo esperado. Son inconsistentes e inadecuados para su uso como métrica principal en proyectos de software. Le recomendamos que cambie a los puntos de función COSMIC estándar ISO y dé 14 razones para ello.
¿Qué son los puntos de historia?
En proyectos de software ágiles, un punto de historia (SP) es la cantidad de esfuerzo acordada por un equipo para realizar un trabajo. Las tareas se estiman en la cantidad de SP necesarios para realizar el trabajo. Los puntos de la historia son una "moneda local" arbitraria. No existen reglas estrictas sobre qué tan grande debe ser un punto de la historia. Ni siquiera forman parte de la Guía Scrum. La magnitud de un punto de la historia varía de un equipo a otro. También puede variar con el tiempo. Un punto de la historia y la estimación del tamaño de una pieza de trabajo en los SP es solo la “suposición colectiva” del equipo en un momento dado utilizando una métrica inconsistente. Básicamente, los puntos de la historia son un proxy poco confiable durante horas. según Mike Cohn. Para conocer aún más desafíos con SP, consulte Problemas con los puntos de la historia.
¿De dónde vienen los Story Points?
Los puntos de la historia fueron una creación de algunos de los firmantes del Manifiesto Ágil. Sólo los utilizan equipos de desarrollo de software ágiles. Uno de los principios fundamentales del desarrollo de software ágil es que los equipos se autoorganizan. En consecuencia, se ha convertido en una práctica aceptada que también inventen sus propios indicadores de esfuerzo. Los puntos de la historia difieren de un equipo a otro y también cambian con el tiempo. En consecuencia, son inconsistentes y poco confiables para cualquier propósito de gestión. Cualquier referencia a la “velocidad ágil” basada en los puntos de la historia presentados tiene sólo un mérito modesto como indicador de la tasa de progreso.
Permitir que el equipo determine su propia métrica de tamaño/esfuerzo tiene cierto valor para mejorar la cohesión del equipo. Además, es útil tener un medio para estimar el trabajo auxiliar (tareas que no son específicas para brindar funcionalidad), aunque también se podría usar una simple estimación en horas.
Los problemas con los puntos de la historia
- Los puntos de la historia son inconsistente, con el tiempo y de equipo a equipo.
- Ellos no se puede utilizar como métrica básica en proyectos
- Ellos son inadecuado para contratos
- generalmente son inadecuado para la mejora de procesos
Puntos de historia versus puntos de función COSMIC
| Propósito / Beneficio | Puntos de Función CÓSMICA | Puntos de la historia |
|---|---|---|
| Bueno para la estimación de sprint | Sí | Sí |
| Bueno para dimensionar aplicaciones | Sí | No |
| El tiempo dedicado a dimensionar las historias de los usuarios mejora la calidad | Sí | Sí |
| Consistente entre equipos | Sí | No |
| Consistente en todas las organizaciones e industrias | Sí | No |
| Adecuado para contratos de desarrollo | Sí | No |
| Contratos de Desarrollo con alcance incierto. | Sí | No |
| Adecuado para el aprendizaje organizacional | Sí | No |
| Ayuda a reducir los costos del desarrollo subcontratado. | Sí | No |
| Adecuado para predecir e informar sobre la calidad | Sí | Un poco |
| Adecuado para estimaciones tempranas de tamaño y costos. | Sí | Un poco |
| Bueno para la estimación del proyecto. | Sí | Un poco |
| Bueno para dimensionar trabajos no funcionales. | No * | Sí |
| Bueno para dimensionar la cartera de software y planificación de alto nivel. | Sí | No |
| El tamaño se puede automatizar | Sí | No |
| Bueno para informes a nivel de junta directiva (de actividades de desarrollo y mantenimiento) | Sí | No |
| Bueno para comparar la productividad del equipo. | Sí | No |
* Muchos requisitos no funcionales pueden en realidad rearticularse como requisitos funcionales.
El factor más importante a la hora de determinar un proyecto de software es el tamaño del software que se entregará. También hay muchos otros factores importantes. Pero el tamaño es el #1. Sin una moneda común para el tamaño del software, los proyectos son difíciles de estimar, son incluso más difíciles de medir y, si no se pueden medir, son muy difíciles de gestionar.
Inconsistente
Las estimaciones de puntos de la historia son específicas del equipo que realiza el trabajo. Un punto de la historia es en realidad una representación del esfuerzo estimado para realizar algún trabajo. Por lo general, solo hay una "sensación" del tamaño. A medida que los miembros del equipo van y vienen, la opinión sobre la cantidad de esfuerzo para realizar un trabajo puede fluctuar, por lo que la magnitud de un punto de la historia puede cambiar. En consecuencia, las estimaciones de tamaño en puntos de la historia no tienen sentido para las comparaciones con otro equipo, y mucho menos con otro proyecto, organización u otra industria.
Prematuro
Los equipos ágiles suelen estimar el tamaño en puntos de la historia sólo unas semanas antes de realizar el trabajo. Esto hace que la planificación a largo plazo del director del proyecto sea realmente muy difícil.
“El factor más importante en un proyecto de software es el tamaño del software. Y la mejor manera de medir el tamaño del software son los puntos de función COSMIC. “
Las organizaciones necesitan mejorar
En la mayoría de las organizaciones es prácticamente imposible poder mirar hacia adelante o hacia atrás en un proyecto y utilizar puntos de la historia para comparar o conocer las características de un proyecto sobre otro. Los puntos de la historia inhiben el aprendizaje.
La métrica principal en un proyecto de software
Las preocupaciones clave al gestionar un proyecto de software son: tamaño, esfuerzo, tiempo, calidad y riesgo del software. Las organizaciones necesitan métricas consistentes para todos estos. Si conoce el tamaño, puede determinar rápidamente las métricas adecuadas de calidad, cronograma y recursos. El tamaño es la métrica fundamental. Los puntos de la historia combinan el tamaño del software y el esfuerzo, por lo que no se puede medir ninguno de los dos adecuadamente.
Las organizaciones necesitan medidas indiscutibles para estimar y aprender.
Si puede estimar consistentemente el tamaño del software que se entregará y tiene datos de desempeño sobre proyectos anteriores comparables, puede determinar rápidamente el esfuerzo y el cronograma estimados y, por lo tanto, los recursos necesarios. Esto no se puede hacer con puntos de la historia cuando no está claro si miden el tamaño o el esfuerzo. Lo que hace que la gestión de proyectos sea mucho más fácil y eficaz es tener un conjunto indiscutible de métricas con las que trabajar. Depender únicamente de los puntos de la historia inhibe el aprendizaje y la mejora organizacional.
Los puntos de la historia no son adecuados para el desarrollo subcontratado
Los puntos de la historia no tienen cabida en los contratos de desarrollo subcontratados. Por ejemplo, no se puede tener un contrato para entregar 100 puntos de la historia, porque no existe una comprensión absolutamente consistente de la magnitud de un punto de la historia. El resultado de esto es que el cliente no tiene visibilidad de la relación calidad-precio ni forma alguna de controlarla.
La calidad sufre
Los contratos ágiles tienden a caracterizarse por la incertidumbre y la falta de detalles sobre los requisitos antes de contratar a un contratista de desarrollo. Como resultado, la mayoría de los contratos para desarrollar software son esencialmente tiempo y materiales basado. En un contrato de T&M es difícil negociar un precio por la funcionalidad de una calidad determinada por un costo determinado. Muchos proveedores aceptarán formar un equipo que ofrezca cualquier funcionalidad que solicite el cliente. En muchas circunstancias que ha visto el autor, la organización de desarrollo también tiene derecho a cobrar por el esfuerzo de corregir errores en el software que ha entregado. Pueden ganar tanto dinero corrigiendo sus propios errores como desarrollando la funcionalidad en primer lugar. Para abordar este problema. Proponemos contratos basados en un precio fijo firme por punto de función con restricciones de calidad basadas en defectos descubiertos por punto de función.
Los puntos de historia pueden inflar los costos
En un contrato de desarrollo subcontratado a menudo vemos retrasos y sobrecostos causados por un trabajo de mala calidad. A menudo, los problemas de calidad son causados por el cliente que ha proporcionado requisitos de calidad deficientes. Puede que no sea de interés comercial para la organización de desarrollo cuestionar la calidad de los requisitos o incluso señalar los peligros de continuar. Independientemente de cuál de las partes tenga la culpa de crear el trabajo adicional, a menudo es de interés comercial de la organización de desarrollo permitir que los problemas de calidad causen el retraso y luego recibir un pago adicional por realizar el trabajo de reparación. ¿Cómo es esto culpa de los puntos de la historia? Los puntos de la historia perpetúan la ambigüedad, y esa ambigüedad conduce a contratos de T&M en lugar de un contrato basado en un precio unitario firme por la funcionalidad entregada.
"El uso exclusivo de Story Points en contratos subcontratados perpetúa la mala calidad y los costos más altos".
DETÉNGASE, hay una manera mejor y ha estado aquí todo el tiempo.
Puntos de función COSMIC: el mejor amigo del director de desarrollo
Pocos administradores de software son realmente conscientes de que existen estándares universales probados para medir el tamaño de la funcionalidad del software. La idea de medir el tamaño funcional existe desde hace mucho tiempo. El Function Point es el software equivalente a medir peso en Kilos.
La edición más actualizada es COSMIC Function Point (CFP). Es el refinamiento moderno de una técnica probada. Es gratis (código abierto) y se basa en principios fundamentales del software, por lo que es de aplicación universal.
El proceso de medición se llama dimensionamiento funcional y es una forma de medir el tamaño de la funcionalidad del software utilizando una métrica que es siempre la misma y, por lo tanto, comparable entre equipos, proyectos, organizaciones e industrias.
- ¿Por qué es mejor?
- Supera todas las limitaciones de los puntos de la historia como se mencionó anteriormente.
- Está probado y maduro (un estándar ISO)
- ¿Por qué no había oído hablar de él antes?
- En definitiva, no ha estado de moda.
- Hasta ahora, realizar el trabajo de medición ha llevado mucho tiempo.
- ¿Debería utilizar CFP además de los puntos de la historia?
- Sí, puedes seguir usando puntos de historia junto con CFP.
- Los puntos de la historia funcionan para mí, ¿debería cambiarlos?
- Depende de a quién te refieres con "yo". En algunos equipos de software internos (maduros y estables), los puntos de historia pueden funcionar bastante bien para estimar historias de usuario y sprints, y hay pocas razones para cambiar en lo que respecta a un equipo individual. Pero, por todas las razones enumeradas anteriormente, las debilidades permanecen a nivel organizacional. Estas debilidades nunca se superarán si continúas usando solo los puntos de la historia.
“El factor más importante en un proyecto de software es el tamaño. Y la mejor manera de medir el tamaño es usando puntos de función COSMIC”
Lea más para obtener evidencia adicional del uso exitoso y alta previsibilidad de la CFP en proyectos ágiles
Conclusión y recomendación
Recomendamos que cualquier equipo que ya esté usando puntos de historia continúe haciéndolo. Además de esto, también deberían medir su software en Puntos de Función Cósmica. Limite el uso de SP al trabajo dentro del equipo de desarrollo. Al analizar estimaciones, métricas contractuales, capacidad de sprint y gestión de proyectos, utilice únicamente CFP. Con el tiempo, es posible que ya no utilice SP y se centre en el tamaño funcional del software entregado.
Obtenga más información sobre los puntos de función COSMIC: toda la documentación completa del método COSMIC está disponible para su descarga gratuita en www.cosmic-sizing.org. Le sugerimos comenzar por leyendo esta introducción al dimensionamiento COSMIC . El método de dimensionamiento se basa en principios fundamentales de la ingeniería de software y es muy fácil de aprender.
Por Colin Hammond, director ejecutivo de ScopeMaster Ltd y Carlos Symons, Cofundador de COSMIC
