¿Qué tan ágiles son los puntos de función??

Muchas organizaciones han aprendido que pueden controlar mejor sus proyectos de software estimándolos con puntos de función.. Al mismo tiempo, vemos que cada vez más organizaciones tienen una forma ágil de trabajar, generalmente aplicando Scrum. La gran pregunta es si los puntos de función permanecen en pie. ¿Scrum los arroja por la borda?? ¿O los puntos de función todavía tienen valor en un mundo ágil?? En este blog, Jolijn Onvlee y Rini van Solingen muestran qué fricciones y similitudes existen.

Ágil / Scrum

Ágil (con Scrum como el enfoque más utilizado) es adoptado por un número creciente de organizaciones como la solución al fracaso de grandes proyectos de TI. Comenzando a entregar software directamente, cada dos semanas, un cliente recibe información directa sobre el progreso y el valor agregado. Los usuarios ya no tienen que esperar por la funcionalidad con el mayor valor comercial. Adicionalmente, el flujo continuo de retroalimentación conduce a sistemas valiosos que funcionan, mucho mas rápido. De echo, con el uso de Scrum, un gran proyecto de TI se divide en muchos proyectos pequeños. Esto facilita la respuesta a nuevos conocimientos y reduce enormemente la complejidad de todo el proyecto..

Scrum maneja las especificaciones del sistema de una manera drásticamente diferente. El producto se describe solo en términos generales (llamó al Pila de Producto).Luego, al principio, solo se elaboran en detalle aquellas partes que tienen el mayor valor comercial y las tesis se entregan rápidamente. Después de esta entrega, se vuelve a determinar el valor comercial más alto., desarrollado y entregado, etcétera. De esta manera es posible un ajuste constante. Esto reemplaza la idea original de un proyecto que ofrece un resultado predefinido.. La estimación del alcance de suministro completo ya no tiene sentido, simplemente porque todo el alcance ya no se elabora en detalle. El punto en el horizonte puede cambiar en cualquier momento..

Fricción

Scrum maneja la estimación y el presupuesto de manera diferente a un enfoque más tradicional y sistemático. El enfoque tradicional a menudo utiliza el análisis de puntos de función. (FPA) para cuantificación. FPA se utiliza para estimar cuánto costará fabricar el software y cuánto tiempo lleva entregarlo.. Un punto de función se utiliza como métrica para determinar el tamaño del sistema.. Este dimensionamiento se realiza sobre la base de las especificaciones funcionales.. Es necesario cierto grado de detalle de lo que vas a hacer para FPA.

Entonces parece que los puntos de función y Scrum no encajan. Después de todo, el primero quiere una especificación completa por adelantado y el otro quiere cuestionar y actualizar la especificación en cualquier momento y no entra demasiado en detalles. Los sprints dentro del enfoque de Scrum son demasiado cortos y demasiado variados para estimarlos en función de los puntos de función. Al mismo tiempo, también dentro de las organizaciones ágiles, existe la necesidad de controlar los costos. "Veremos al final cuánto ha costado" es inaceptable para la mayoría de las organizaciones. Eso significaría que Agile crea anarquía en el gasto de TI, que es una tontería. Incluso con Scrum, un cliente necesita control. El propietario del producto desea mantener una visión general de los resultados de todos estos esfuerzos. (objetivo) y cuanto tiempo y dinero ha costado al final (presupuesto). Y ahí es precisamente donde FPA tradicional ofrece una solución.

Similitudes

Si observa en detalle la combinación de FPA y Scrum, ves que se refuerzan en lugar de debilitarse. Después de todo, FPA ayuda a establecer el alcance general (el lugar en el horizonte) y el presupuesto adecuado. Scrum ayuda a realizar las funciones con el valor comercial más alto dentro de ese presupuesto primero. Tan pronto como sea posible, los comentarios se introducen en el proceso de entrega.. Retroalimentación en dos frentes: primero, si el alcance general es correcto y, en segundo lugar, si todo el problema se puede resolver dentro del presupuesto.

En la práctica, esto significa que la cartera de pedidos del proyecto se determina a nivel global.. Dentro de Scrum, es una práctica común que la parte del producto con el valor comercial más alto ya tenga una cantidad significativa de detalles.. Este nivel de detalle (preferiblemente para varios sprints) suele ser suficiente para hacer un análisis de puntos de función. Luego, puede usar ese análisis para determinar el número total de puntos de función para todo el trabajo pendiente extrapolando. Dentro del método FPA, esto será permitido.

Scrum y FPA son amigos

En breve, Scrum y FPA pueden ayudarse y fortalecerse mutuamente de manera excelente. Los puntos de función le ayudan a controlar los gastos totales. Al usar Scrum, permanece flexible en función de los conocimientos. En última instancia, es usted quien debe resolver el problema general.. Tan rápido, tan bueno y tan barato como sea posible. En este área, los puntos de función y Scrum tienen un objetivo común.
Entonces Scrum y FPA son amigos. La pérdida de control y exceder el presupuesto es la (común) enemigo!

Triunfos rápidos

Ganancias rápidas en la combinación Scrum y Function Points

1. Concretización más rápida de la cartera de productos
   El Product Backlog es la descripción de todos los requisitos no implementados que deben realizarse.. En la parte superior del Product Backlog están los elementos que son más importantes para el negocio y solo esos elementos se resuelven en detalle.. El tamaño de la Pila de Producto se puede concretar usando FPA. Muestra FPA qué se requiere funcionalidad. Por lo tanto, FPA proporciona un resumen de la cartera de productos en términos funcionales..
2. Objetivo medible
   Un registro de producto detallado para los primeros seis sprints es suficiente para hacer un FPA estimado (ISO / IEC 24570 Método de medición del tamaño funcional de Nesma). El número de puntos de función se puede extrapolar al total. Así, La última meta (el lugar en el horizonte) se puede cuantificar, y el resultado final se hace tangible, sin necesidad de especificaciones detalladas para todo el producto.
3. Medición más sencilla del "valor añadido"’
   La velocidad a la que un equipo entrega software se mide en puntos de historia.. Estas son estimaciones relativas del tamaño de la obra.. Estos puntos de la historia no deben confundirse con los puntos de función.. Ni siquiera se parecen el uno al otro (excepto en el nombre, por supuesto). Los puntos de función miran hacia afuera y consideran el proyecto en general. Los Story Points están orientados hacia adentro y ayudan a evitar que un equipo Scrum muerda más de lo que puede masticar.. Sin embargo, en Scrum, es difícil expresar el valor entregado. sin embargo, esto se puede hacer de manera excelente en términos de: Puntos de función!
4. Ayuda para priorizar la funcionalidad
   Un aspecto importante de Scrum es determinar la funcionalidad deseada con el mayor valor comercial., que luego se recogerá en el próximo sprint. Con el FPA estimado, la lista de deseos total – y dentro de eso, los próximos sprints – se puede medir de forma sencilla, también con respecto a la agrupación de funcionalidades. La imagen general se mantiene y los cambios son rastreables..
5. Asistencia para realizar estimaciones
   Estimar es tarea del equipo. Hacer un presupuesto siempre es (y permanece) un negocio complicado. Después de todo, un equipo no tiene bola de cristal y antes de que te des cuenta, Las estimaciones se utilizan como si fueran garantías.. Estimaciones de Scrum con puntos de historia, pero estos son relativamente: comparable al equipo pero no más allá. Puntos de función, sin embargo, son absolutamente comparables. Los puntos de función son comparables entre proyectos y no solo se pueden medir de antemano, pero también durante y después de un proyecto. Así, el equipo recibe ayuda adicional para realizar estimaciones.
6. Detectando mejoras
   Debido a que FPA proporciona una medida objetiva, se puede usar en la retrospectiva del proceso Scrum para mostrar una mejora.. Para que puedas ayudar a los equipos a aprender unos de otros y a detectar los principales factores inhibidores..
7. Confirmación del caso de negocio para Scrum
   Si bien muchas organizaciones están entusiasmadas con Scrum, Se puede escuchar rumores a través de la vid de que los procesos de Scrum incluyen más reelaboración (avanzando la comprensión) que los encarecerá. Se puede determinar el número de puntos de función de la funcionalidad nueva y mejorada y, por lo tanto, se puede establecer la productividad tanto de la adaptación como de todo el proceso.. Entonces el caso de negocio se puede determinar objetivamente.

Este blog se publicó originalmente como artículo de opinión en Guía de automatización (en holandés).

 

Sobre los autores

Jolijn Onvlee (jolijn@onvlee.com) es un especialista y consultor independiente de FPA, auditor y conferenciante en el campo de la calidad, gestión de presupuesto y productividad. Jolijn también ha trabajado durante muchos años como presidente y miembro de la junta de Nesma..

Rini van Solingen es CTO en Prowareness (rini@scrum.nl) y profesor de la Universidad Técnica de Delft. Rini es el autor del libro. “El poder de Scrum”; ahora también publicado en francés, Aleman e ingles.