Puntos de historia

0

Empecemos con un ejemplo:

Pepe, el gestor de proyectos, tiene que estimar el coste de hacer el sistema de gestión de usuarios de una nueva aplicación. Siguiendo su intuición y las buenas prácticas de PMBOK desmonta el paquete de trabajo en tareas, lo suficientemente pequeñas  como para poder ser estimadas. Para hacer la estimación involucra al equipo haciendo una mezcla entre técnicas Delphi y el método PERT. Llegan a la conclusión de que el sistema de login tendrá un coste de 75 horas de trabajo, con 10 horas en reservas. Hasta aquí, el trabajo de Pepe es impoluto, para quitarse el sombrero. Comienza el proyecto y cuando llega la tarea, el programador que la coge es junior, con lo que el trabajo le tarda 150 horas, el doble de lo planificado.

Esta historia es muy común en desarrollo. Más de lo que debería. En nuestro entorno nos podemos encontrar con programadores que en una determinada tarea tardan hasta 10 veces menos que otros. Queda claro entonces que la unidad de medida “horas de desarrollo” no es válida, a menos que sepamos perfectamente quién lo va a desarrollar.

Unidades de medida evolucionadas

Cuando las organizaciones comienzan a caer sistemáticamente en este problema, tengan o no PMO, comienzan a dar vueltas sobre qué unidad habría que utilizar para la medida. Al final acaban con una de estas dos opciones:

  • Medir económicamente el coste de desarrollo
  • Utilizar el concepto de “hora de programador senior” y aplicar multiplicadores al programador junior, al experto, para corregir las estimaciones una vez escogida la persona que va a desarrollar.

La primera opción consiste en hacer la estimación para un perfil concreto y aplicar el coste por hora. Así a lo mejor las 75 horas de desarrollo se traducen en 2.000 €. Cuando pongamos al desarrollador junior, que cobra la mitad, al tardar 150 horas, se mantiene su coste.

En la segunda opción los programadores junior tienen un multiplicador x2, con lo que una estimación de 75 horas de desarrollador senior se convertirá en 150 horas de desarrollador junior.

¿Hemos resuelto el problema? en parte sí, pero hemos creado otros.

Problemas de estas unidades de medida

Problemas con la estimación económica

Los problemas principales con esta estimación vienen de dos necesidades para su aplicación:

  • El sueldo de las personas debe ser conocido.
  • El ratio sueldo/productividad debe ser constante.

Si no conocemos el salario y por extensión el coste de todas las personas involucradas, no podremos usar esta medida. Esto puede ser un problema en algunas organizaciones más opacas, que no desea que los salarios de la gente sean públicos. En estos casos este sistema no se puede aplicar.

El segundo punto es todavía más restrictivo. ¿Se da en tu organización que si una persona cobra el doble, saca el doble de trabajo? Normalmente no. El salario no sale de una fórmula de productividad, sino de una continua negociación que depende de muchos factores. Ya os he dicho que he visto casos de personas haciendo el trabajo de otras 10 veces más rápido y cobraban el doble.

Si esto no se cumple nos encontraremos con que nuestra unidad de medida sigue sin servirnos.

Problemas con la estimación de referencia

Veo las siguientes restricciones que deben cumplirse para esta estimación:

  • Debe existir un sistema de rangos de desarrollo
  • Dos personas en el mismo rango deben tener la misma productividad

Primero, no todas las organizaciones distinguen entre rangos de desarrollador. Normalmente los rangos son del estilo: programador, analista, jefe de proyecto. Pero para poder aplicar esto necesito distinguir entre programadores de nivel 1, 2, 3, …

Y segundo, lo normal es que los rangos estén ligados al salario, por lo que son un reflejo del salario y no de la productividad. No todos en el mismo rango tendrán la misma productividad.

Los puntos de historia

La conclusión a la que se llega es a que no existe una unidad de medida válida. Asumámoslo. Uses la que uses, le encontrarás problemas, y eso si estimas bien, que a veces es misión imposible.

En el mundo del desarrollo, llegar a esta conclusión es romper moldes, ¿Y quienes rompen moldes en TI? Los del desarrollo ágil. Así que no es raro que desde la cultura ágil, principalmente SCRUM, se crease una nueva unidad de medida: los puntos de historia.

Antes de nada, explicar por qué se llaman puntos de historia. En SCRUM a los requisitos que plantean los usuarios se les llama “historias de usuario”, con lo que puntos de historia hace referencia al coste de ese requisito o historia de usuario. Así, los puntos de historia son una medida de coste asociada al requisito.

La gran novedad es que un punto de historia no representa nada. No es una hora, no son 100€ de coste, no es nada. Es una medida que sólo tiene sentido cuando la comparas con otras. Es decir, a priori decir que desarrollar la pantalla de login son 75 puntos, no dice nada. Sí que dice algo cuando ves que hacerla multiidoma son 10 puntos más. O cuando hablamos que hacer el menú de la aplicación son 35 puntos.

Como dicen en AgileFAQ

En términos sencillos, es un número que indica al equipo como de dura es una historia. Esa dureza puede estar relacionada con la complejidad, desconocimiento o esfuerzo.

La clave a la hora de determinar puntos de historia a los requisitos está en tener una referencia. Es decir, una serie de tareas con un valor de puntos de historia con los que comparar. Así usando esas tareas como referencia, el equipo es capaz de estimar el coste.

El ejemplo que se suele utilizar en las sesiones de formación es el de estimar el esfuerzo de preparar una fruta para ser consumida, como se ven en esta wiki de pinkbird. El ejemplo es sencillo:

Supongamos que preparar un plátano cuesta 4 puntos, ¿Cuanto cuesta preparar una piña? Probablemente la gente dirá medidas desde 15 a 40 puntos, pensando en una equivalencia con plátanos.

Bueno, en este momento hemos creado una medida que podemos utilizar para estimar, pero con la que seguimos teniendo los mismos problemas ¿Cuanto se tardará en desarrollar una historia de 10 puntos? Para ello hay que introducir un nuevo concepto, la velocidad:

La velocidad

La velocidad es la cantidad de puntos de historia que puede desarrollar un equipo o persona en una unidad de tiempo (como por ejemplo una semana). Es una medida que se va ajustando con el tiempo. Cada cierto tiempo, evaluamos cuanto trabajo ha sacado la persona o el equipo y obtenemos su velocidad.

El concepto de velocidad normalmente se aplica a equipos de trabajo, de forma que no nos fijamos en la velocidad de cada miembro, sino la de todo el equipo. Pero cuando no tenemos equipos definidos, sino que tenemos un pool de desarrolladores que van entrando y saliendo de los proyectos, la velocidad se debe medir por cada persona.

La medición de la velocidad es muy sencilla: ¿Cuantos puntos de historia ha desarrollado por periodo? Se calcula y se saca el promedio. Es simplemente voluntad de medirlo. Además no necesitamos que el técnico asigne horas o similar. Simplemente mirar cuantas tareas ha finalizado y cuantos puntos de historia tenían estimadas estas tareas.

Ventajas de los puntos de historia

Las ventajas son múltiples:

  • Al no asociar la productividad con salarios o rangos en la empresa, es más fácil tener claro el plazo que tendrá una tarea según el recurso asignado.
  • La estimación, al hacerse por comparación, es más sencilla y fiable.
  • El propio sistema se auto-ajusta, recalculando las velocidades constantemente.

Aunque el sistema se suele usar en entornos ágiles, nada evita que se haga en gestión de proyectos clásica. Además desde mi punto de vista no nos salimos del PMBOK, ya que seguimos haciendo una estimación de los recursos necesarios, asignamos personas y luego entregamos plazos.

Comenzar con los puntos de historia

El problema principal de comenzar con los puntos de historia es que es un sistema que necesita referencias. Necesitamos conocer la velocidad inicial y necesitamos conocer tareas de referencia con sus puntos de historia. Pero no lo tenemos. Por lo tanto mi recomendación es hacer una analogía para “arrancar” el sistema, y luego romper con la analogía.

La analogía que yo uso es: “Un punto es una hora de un programador senior a pleno rendimiento sin que nadie le moleste”. Con esto en la mano ya es posible hacer estimaciones fiables de hasta 15 puntos de historia. Y por comparación, de duraciones superiores. Para la velocidad asumo que los programadores rendirán un 75% e intento evaluar el rendimiento comparativo de los miembros según su experiencia o dedicación. Así por ejemplo en un equipo de 5 miembros en el que tenemos 3 programadores senior, uno junior y uno senior que suele dedicar el 50% de su tiempo a correctivo de otros proyectos me saldrán:

  • 6 puntos/día para los senior.
  • 3 puntos/día para el junior.
  • 3 puntos/día para el que hace tareas de soporte.

En total me salen 24 puntos/día para el equipo. Ya no me preocuparé en quién hace la tarea, la hará el equipo (esto es muy de filosofía agíl, pero también encaja en un planteamiento PMBOK si el recurso no es la persona, sino el equipo). Así, si al equipo les pongo un paquete de trabajo con la pantalla de login, la gestión de usuarios, los menús y unos módulos de la aplicación con 240 puntos de historia, podré decir que espero tenerlo en dos semanas. Encargo la tarea y veo que en 8 días han acabado, pues reajustamos su velocidad a 30 puntos (240 puntos en 8 días), y así iré mejorando en mi estimación.

De la misma manera en sucesivas estimaciones, los técnicos ya no irán pensando en horas de trabajo a full, sino comparando las tareas con la base de datos de estimaciones que tienen en el pasado. El concepto de hora “a full” se usa para iniciar el sistema, pero la base es que luego sea libre de este concepto.

About author

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert y va en camino de certificarse como PMP. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en Idiso, empresa de servicios de distribución hotelera, como responsable del equipo de desarrollo web.

No comments

Te puede interesar...

Diseñando el WBS

Uno de los grandes conceptos que aprendí de leer la guía del PMBOK® es el WBS, o Estructura de Descomposición de Trabajo. Pasé de una ...