Metodologías ágiles y gestión del cambio: valor y estimación de las historias de usuario (2 de 3)

Asignar valor a una historia de usuario

Es muy importante que los elementos que apilemos en el Product backlog, se prioricen, es decir, deben tener asignados un valor. Dicho valor es asignado por el Product Owner, y pondera básicamente las siguientes variables:

• Beneficios de implementar una funcionalidad
• Pérdida o coste que demande posponer la implementación de una funcionalidad
• Riesgos de implementarla
• Coherencia con los intereses del negocio
• Valor diferencial con respecto a productos de la competencia

Uno de los aspectos más importantes aquí es que la definición de "valor" para cada cliente puede variar. Por lo tanto es muy recomendable incluir algún tipo de escala cualitativa. Como por ejemplo se podría aplicar la técnica MoSCoW. Su fin es obtener el entendimiento común entre cliente y el equipo del proyecto sobre la importancia de cada requisito o historia de usuario. La clasificación es la siguiente:

• M - MUST. Se debe tener la funcionalidad. En caso de que no exista la solución a construir fallará.
• S - SHOULD Se debería tener la funcionalidad. La funcionalidad es importante pero la solución no fallará si no existe.
• C - COULD Sería conveniente tener esta funcionalidad. Es en realidad un deseo.
• W - WON'T No está en los planes tener esta funcionalidad en este momento. Posteriomente puede pasar a alguno de los estados anteriores. En cada iteración (en cada análisis) todas las historias de usuario se deben de priorizar y se comenzará a desarrollar por la que más valor aporte al cliente.

La idea sería encontrar un rol tanto en la parte del cliente como en la nuestra que priorice el trabajo del desarrollo. Los métodos ágiles suelen proponer al cliente o representante del cliente (product owner) que priorice el trabajo del equipo software.

Para un menor número de cambios, una buena estimación. La estimación ágil

En la actualidad el desarrollo software sigue afectado por graves problemas:

• los proyectos no se ajustan al presupuesto inicial
• son entregados fuera de plazo
• existe una baja calidad del software generado
• el software no cumple las especificaciones
• y el código muchas veces es inmantenible,...

...lo cual dificulta la gestión y evolución del proyecto. Si vamos a aplicar prácticas ágiles, éstas no escapan a este problema y de hecho, por estar asociadas a requisitos cambiantes el desafío es mayor.

La mayoría de los errores que se producen con más frecuencia en los proyectos software están relacionados con aspectos de estimación. Entre estos errores se pueden destacar:

• Calendario optimista: la tendencia al estimar es hacerlo de manera optimista. Esta tendencia es general y se va disminuyendo con la experiencia. Aún así en un histórico de estimaciones estimar por encima es mucho menos frecuente que estimar por debajo.
• Expectativas no realistas: muchas veces las tareas sobre las que se ha estimado son ambiguas. Posteriormente el equipo seguramente se llega a un consenso común pero el cliente puede mantener otra expectativa. Y presionará para obtener el resultado que él cree es el correcto.
• Confundir estimaciones con objetivos: al estimar tenemos que tener en cuenta nuestra capacidad actual real y el histórico de productividad de la empresa. Es decir, si queremos terminar en 3 meses (un objetivo) puede que lo consigamos o no sabiendo que contamos con 2 programadores y que el 20% del tiempo estamos respondiendo incidencias de otros proyectos.
• Omisión de estimar tareas necesarias: las pruebas, la documentación, las tareas relacionadas con la gestión de configuración o la calidad puede que no se planifiquen. Pero muchas veces consumen tiempo.

La unidad de estimación: puntos historia

Históricamente, la unidad clásica de estimación del “tamaño” de un requisito ha sido el Punto Función. Pero, en los últimos años, los puntos historia se han convertido en una unidad de tamaño muy usada, principalmente en proyectos ágiles. Por ejemplo, la técnica de estimación Planning Poker, que explicaremos más adelante, emplea los Puntos Historia.

A la hora de asignar puntos historia a cada historia de usuario lo que importa son los valores relativos de una historia frente al resto: una historia a la que se le asignan dos puntos historia debe requerir el doble de esfuerzo, complejidad o tamaño que una historia a la que se le asigna un único punto.

Y normalmente hay dos formas de hacer esta asignación:

• Seleccionar una historia de las más pequeñas y asignarle 1 punto historia. Esta historia de usuario con 1  punto historia hará de unidad, y al resto se le asignarán puntos historia en función de su complejidad respecto a ésta.
• Seleccionar una historia de tamaño medio y asignarle un número en la mitad del rango de puntos historia a utilizar. Normalmente, se usan rangos de puntos historia entre 1-10. Según esto, buscaríamos una historia de tamaño medio y le asignaríamos cinco puntos historia. Cada historia adicional se calcula comparándola con la primera historia.

Peligros al estimar

Al realizar estimaciones teniendo en cuenta jornadas de trabajo es necesario recordar lo siguiente: los días son "ideales". Éstos son aquellos en los que se cumplen las horas de trabajo definidas sin interrupciones, interferencias o distracciones de ningún tipo.

Entre un 25% y 35% del tiempo se invertirán en otras actividades (imprevistos, llamadas, correo) de gestión del proyecto. Asimismo es bueno recordar que el trabajo se expande hasta ocupar todo el tiempo del que se disponía para su realización.

Estos dos aspectos significan que si realizamos una estimación por arriba (es decir que indicamos 3 días a una tarea que se realiza en 2 días) por lo general los equipos van a utilizar todo el tiempo del que disponen. Y si estimamos por debajo (decimos 3 días reales para una tarea de 3 días ideales) tendremos retrasos.

Para seleccionar la duración de una iteración, podemos encontrar recomendaciones de todo tipo. Por ejemplo, metodologías como XP recomiendan iteraciones de un par de semanas, mientras que lo habitual en Scrum es que sean de un mes de duración. Y lo normal que nos solemos encontrar en proyectos son iteraciones que están entre una semana y un mes.

¿Qué debería determinar la duración más recomendable para una iteración? Sin que exista una norma exacta, los siguientes factores pueden servirnos de ayuda:

• La frecuencia con la que hay que mostrar el software a los usuarios. Normalmente, el software se puede mostrar al final de una iteración (demos de prototipos), por lo que a mayor frecuencia requerida para mostrar demos y avance, menor debiera ser la duración de la iteración.
• En línea con el anterior, debiéramos pensar con qué frecuencia hay que medir, o mostrar, el progreso del proyecto. En teoría sólo al final de una iteración podemos medir con precisión la cantidad de trabajo que realmente ha sido completado.
• La frecuencia con la que se pueden re-ajustar objetivos del proyecto. No debiéramos hacer cambios de objetivo, funcionalidad, o alcance, una vez que ha comenzado una iteración. Los ajustes y cambios deben esperar hasta el momento en que una iteración termina. Por ello, si se requiere mayor ratio de cambio de alcance, menor debiera ser la duración de la iteración. Por lo tanto, el tiempo que se puede aguantar sin cambios de prioridad es un factor determinante a la hora de fijar la temporalidad de una iteración.

Con todo, por ejemplo, si tenemos cuatro meses de proyecto, y nuestras iteraciones son de un mes de duración, tendremos tres momentos (al final de la iteración 1, 2 y 3) para tomar “feedback”, medir progreso y re-ajustar prioridades.

Otra consideración clave es el tiempo que tarda una idea (un requisito funcional, una historia de usuario) en transformarse en software. Por ejemplo, consideremos de nuevo iteraciones de cuatro semanas. Suponiendo que una nueva idea aparece en el medio de una iteración, esa idea solo puede introducirse en la próxima versión, que comenzará en dos semanas. Dos semanas que quedan de la iteración en que aparece el nuevo requisito, más cuatro de la siguiente, hacen que la nueva idea esté implementada en 6 semanas, y si 6 semanas es mucho para nuestro negocio... habrá que considerar iteraciones menores.

Una última consideración. No olvides que a menor tiempo de iteración mayor nivel y sofisticación debe tener el equipo de desarrollo, por lo que la madurez, compenetración, experiencia, cualidades técnicas, etc., juegan un papel importante.

Ejemplo: supongamos que tenemos un equipo de desarrollo software. Nuestro rol es de jefe de proyecto y un cliente nos ha pedido que desarrollemos una potente calculadora para móviles.

El cliente nos ha trasladado las historias de usuario. Nuestro equipo ya las ha agrupado por valor (dado por el cliente) y también ha estimado el tiempo que tardaremos, en días, en completarlas. El cliente desea la implementación de:

El primer paso que debemos hacer es dividir las historias de usuario en tareas de un tiempo homogéneo:

Para formar el Sprint Backlog y simplificar el problema, supondremos que las historias de usuario son indivisibles. Además las tareas a implementar en cada historia de usuario tienen que guardar el orden establecido.

Ésto es: si se quiere implementar el requisito 3, ha de realizarse 3.1 y 3.2 en la misma iteración, y en ese orden.

Para el primer Sprint, las historias de usuario que maximizan el valor percibido por el cliente son 1, 3 y 4. Por lo que nuestro muro Kanban inicial quedaría así:

De esta manera podemos ver que es fácil estimar en Kanban. Son tareas más o menos homogéneas en tiempo. Por lo que, realizando unos pequeños cálculos podemos determinar nuestro tiempo estimado. En este caso, como el WIP (Work In Progress) de estado del flujo "En progreso" es 2, el tiempo máximo vendrá determinado por el promedio de tiempo de todas las tareas dividido 2 (ver fórmula).

Por tanto:

3 días (de la tarea 1) + 2 días (de la tarea 3.1) + 3 días (de la tarea 3.2) + 3 días (de la tarea 4)

2 (WIP "En progreso")

El resultado de esta operación es aproximadamente 6 días. Por lo tanto, para terminar las historias de usuario, el equipo tardará aproximadamente 6 días.

 

Bibliografía

Roberto Canales Mora. Informática profesional. Ed. Starbook. Roberto Canales Mora

Agilidad y Lean. Gestionando los proyectos y negocios del s. XXI. Javier Garzás, Miriadax