Por muy favorables que sean las condiciones para aplicar un enfoque ágil en la gestión del trabajo probablemente no podremos escapar de estas preguntas que nos hará el Product Owner: ¿Cuánto costará? o ¿Lo tendremos todo para la fecha X?. Si alguien cree que en el enfoque ágil no corresponde hacer estas preguntas o no es posible responderlas, o si piensa que no se puede realizar gestión del alcance, está muy equivocado :- ), se puede y se debe.


La gestión de alcance de un proyecto básicamente consiste en contrastar el esfuerzo asociado al trabajo que se solicita respecto de la Capacidad del equipo de desarrollo para realizarlo en una duración determinada. Tenemos al menos tres alternativas para hacer este cálculo:


  • "A ojo". Por conocimiento del ritmo de trabajo de nuestro equipo, claridad del trabajo y/o experiencia en trabajos similares podríamos animarnos a hacer una previsión totalmente informal y contestar directamente las preguntas antes señaladas, y aun así, ser bastante certeros (por ejemplo, estar en alrededor de un más-menos 10% de acierto).
  • Usando Puntos. Hacer una estimación en Puntos (medida relativa de tamaño de cada UT) y contrastarla con la Capacidad del equipo, medida también en Puntos por unidad de tiempo (por ejemplo, Puntos por mes de trabajo). Así, si nos pidiesen un trabajo que se ha medido en 200 puntos y la capacidad del equipo es de 50 Puntos por mes, podríamos prever un plazo de 4 meses.
  • Usando Horas Ideales. Hacer estimaciones en Horas Ideales (horas netas de trabajo, sin contar interrupciones) para una o varias actividades que deben realizarse sobre las UT, por ejemplo, Horas Ideales de Programación (HIP), que sería el tiempo efectivo dedicado a programar una UT. La Capacidad del equipo se mediría también en HIP. Así, si nos piden un esfuerzo de 500 HIP, y nuestro equipo tiene una Capacidad de 100 HIP por mes, podríamos prever un plazo 5 meses.  


Las dos últimas alternativas implican que el equipo tenga medida su Capacidad y que se realicen estimaciones para las UT que se quieren abordar en el proyecto. Una de las prácticas ágiles esenciales es no adelantar trabajo cuando su entrega no está próxima, pues mientras más tiempo nos adelantemos más probable es que ese esfuerzo se pierda si van surgiendo cambios o si finalmente el trabajo preparado no llega ni siquiera a ejecutarse. Pero antes de empezar la ejecución del trabajo de un Proyecto existe una natural presión por definir tempranamente el trabajo en detalle para así poder tener una estimación más argumentada. ¿Cómo se resuelve esta situación sin entrar en conflicto con dicha práctica del enfoque ágil? La clave es la priorización del trabajo. El Product Owner debe establecer una estrategia de desarrollo que se plasme en un ordenamiento del Backlog. Normalmente el factor más determinante en ese ordenamiento es el valor que le aportarán las UT una vez terminadas y la mitigación de riesgos del proyecto, es decir, enfrentar cuanto antes los trabajos que podrían hacer fracasar el proyecto (aunque también pueden tomarse en cuenta otros factores, en "Gestión eficaz del Product Backlog" se indican 14 factores). De esta forma, dado que las UT se ejecutarán en dicho Orden, no hay ningún inconveniente en especificar detalladamente las primeras (por ejemplo, un 10% de las UT). El resto de las UT podrían especificar de forma menos detallada o incluso aceptar que de momento solo cuentan con un nombre. Además, no olvidar que las estimaciones son solo eso, estimaciones, es decir, siempre conllevan un grado de error e incertidumbre. La estimación también está muy ligada a la experiencia del equipo en el trabajo que se le solicita. Finalmente, habría que ser muy malo en las estimaciones, o tener muy mala suerte para subestimar (o sobreestimar) todas las UT. Normalmente en algunas se tiene un grado de sobreestimación y en otras de subestimación, es decir, las diferencias en la estimación normalmente se contrarrestan y así el acierto global de la estimación del proyecto puede ser relativamente bueno.


Por otra parte, previendo que surgirán cambios a lo largo del proyecto pero sin saber cuáles serán, es recomendable no planificar igualando el Esfuerzo Estimado con la Capacidad disponible del equipo. La idea es tener un buffer de Capacidad/Tiempo que permita abordar los posibles "flecos" que surjan. Lectura recomendada: "Buffer de Capacidad para proyectos ágiles". Así, en los ejemplos anteriores, si en el primer caso en lugar de 4 meses planificamos 4 meses y 3 semanas, o en el segundo caso en lugar de planificar 5 meses planificamos 6 meses, en ambos casos dispondríamos se un buffer de alrededor de 16% para abordar dichos "flecos" sin vernos obligados a negociar con el Product Owner.


Puntos e HIP son dos medidas de esfuerzo alternativas, es decir, para gestionar el alcance del proyecto (o de un Sprint) bastaría con utilizar una de ellas. Sin embargo, usar ambas a la vez puede ofrecer ciertas ventajas. Al crear una UT se le puede asignar fácilmente un tamaño usando Puntos, una medida global de la UT y comparativa respecto a otra UT usada como referencia. Es decir, los Puntos, siendo a priori menos precisos que las HIP, son muy fáciles de establecer. Los Puntos usados como estimación muy preliminar, ya al registrar la UT, pueden además ayudar en la priorización de las UT. Así UT relativamente pequeñas podrían hacerse en cualquier momento, o otras más grandes habría que ver en más detalle si son prioritarias. Posteriormente, al tener más información de una UT, justo antes de ejecutar el trabajo asociado a ella, se podría trabajar con HIP como medida de estimación para contar con mayor información detallada y cuantitativa del proyecto. A partir de aquí la explicación se hará usando HIP, sin embargo, con Puntos sería muy similar.


Veamos ahora un ejemplo de cómo gestionar el alcance de un proyecto en Worki. A continuación, se muestran los elementos definidos en "Elementos del sitio". Existe una Línea de trabajo llamada TotalCombat. Además, tenemos la Línea de trabajo de Portafolio llamada "Juegos para móviles". En Worki un Portafolio es un contenedor de proyectos (ver Gestión de Portafolio).



Se ha creado el proyecto "Primera entrega TotalCombat". De momento no se han precisado sus fechas de inicio y fin, con lo cual se asignan por defecto la fecha de creación del proyecto.



En Worki un proyecto es también una UT, pero que pertenece a una Línea de trabajo que es un Portafolio. Así, al acceder al proyecto vemos que es un proyecto del portafolio "Juegos para móviles" y que este proyecto está asociado a la Línea de trabajo TotalCombat.



Por otra parte, para el desarrollo de la primera entrega de TotalCombat utilizaremos el workflow "WF Desarrollo usando Sprints" cuya definición se muestra a continuación. La única actividad que se ha marcado como "Estimable" es Programar. Con lo cual, aunque podríamos estimar todas las actividades, Worki considerará solo la actividad Programar para hacer los cálculos de estimaciones y de progreso del trabajo, y solo advertirá cuando esta estimación falte en una UT.



A continuación, en el Tablero multikanban de Worki vemos que en el Backlog de TotalCombat hay 38 UT (en la captura solo salen las filas que caben en el alto de la ventana), ya han sido ordenadas y tienen una estimación preliminar en HIP. Es una estimación preliminar porque se ha hecho sin todavía hacer la especificación detallada de los requisitos de las UT. Cuando se realice dicha especificación detallada se podrían retocar dichas estimaciones ante la evidencia que no corresponden al esfuerzo confirmado en ese momento. Todas las UT están en este momento en la actividad "Esperar prioridad" y ninguna tiene asignado valor en la columna Proyecto.


 


En la figura se ha remarcado la columna "Estimación (horas)". El total de las 38 UT en el Backlog suman 824 HIP. Si nuestro equipo tiene una Capacidad de 100 HIP/Mes parecería sensato prever una duración de 9 meses para toda la implementación del Backlog (considerando un pequeño buffer de poco más de 8%). Si el Product Owner estuviese de acuerdo le asignaríamos el proyecto "Primera entrega TotalCombat" a todas las UT. Los valores de Puntos, HIP y Proyecto asignado pueden modificarse accediendo al Gestor de UT con cada una de las UT y cambiando el valor de los campos tal como se indica en la siguiente figura.



Para modificar el valor de HIP de varias UT a la vez se sugiere acceder a Seguimiento > Tiempos Actividad donde dicho valor se puede editar directamente en la lista, manteniendo el filtro con el check "Mostrar solo actividades estimables" del workflow (en nuestro ejemplo solo "Programar" se ha marcado en el workflow como "estimable"). Esto se muestra en la siguiente figura.



De forma similar, en lugar de modificar una a una las UT para asignar un valor de Proyecto, tanto en el Tablero multikanban como en la opción Lista de UT se pueden activar acciones para aplicar en todas las filas seleccionadas, como se muestra a continuación. El botón con icono check activa la columna de cheks y habilita el botón con icono de rayo donde se ofrecen acciones para aplicar sobre las filas seleccionadas. En este caso nos interesa "Cambiar Proyecto" asignando el proyecto "Primera entrega TotalCombat" a todas las UT que en este momento consideramos que entran en el alcance del proyecto.



Hasta aquí podría llegar nuestra gestión de alcance en este ejemplo de arranque de un proyecto. Desafortunadamente no suele ser tan fácil, y normalmente hay una negociación entre el Product Owner y el equipo. Para recrear esta otra situación supongamos que para el Product Owner es imprescindible que la primera entrega sea en 4 meses, y se descarta aumentar los costos incrementando el equipo (para aumentar la Capacidad), entonces deberíamos pasar a negociar con el Product Owner. Esto se hace en dos niveles, primero a nivel de UT, intentar acordar que algunas UT no se incluyan en el proyecto. En nuestro ejemplo, para 4 meses el equipo no se debería comprometer a realizar un equivalente de trabajo de mucho más de 360 HIP (considerando una capacidad de 100 HIP/Mes, y un pequeño buffer de 10% de capacidad/tiempo). Según esto lo que haremos, teniendo la lista ordenada por la columna Orden, es ir asignando proyecto a las UT hasta no sobrepasar dicha capacidad. Para verificar los totales de estimación para las UT filtradas se puede usar el filtro Proyecto o el filtrado sobre la columna Proyecto. Esto se muestra en la siguiente figura.



Así, esta figura muestra que el alcance del proyecto incluiría 21 UT que suman 365 HIP. Con esto "en este momento" habría coherencia entre plazos y esfuerzo con respecto de la Capacidad del equipo. Con lo cual si equipo y Product Owner están conformes, nuevamente podríamos pensar que ya está hecha la gestión del alcance del proyecto. Sin embargo, deberíamos repetir el procedimiento cada vez que se detecten cambios significativos (nuevas UT, cambios en las estimaciones de UT), particularmente después de la reunión de revisión de cada Sprint.


Pero, ¿qué pasaría si el Product Owner no se resigna a dicha reducción del alcance?, y por ejemplo, quiere que se incluya también las UT "Guardar partida", "Niveles del juego" y "Configuración del personaje", que se muestran en la siguiente figura. Estas UT no tienen asignado el proyecto y suman 35 HIP. Si el Product Owner no está dispuesto a intercambiarlas por otras UT que están ahora en el proyecto nos queda la posibilidad de negociar en un segundo nivel, el nivel en el cual podríamos intentar reducir el tamaño de algunas UT del proyecto (o bien de las que se quiere añadir).



Por ejemplo, la UT "Amenazas dinámicas" tiene una estimación de 50 HIP. Supongamos que la podemos reconvertir en dos UT: "Amenazas dinámicas básicas" con una estimación de 15 HIP y "Amenazas dinámicas avanzadas" con 35 HIP. La UT "Amenaza dinámicas básicas" la mantenemos en el proyecto, pero "Amenazas dinámicas avanzadas" la dejamos fuera del proyecto. Así conseguiríamos inlcuir las 3 UT que quería el cliente pues hemos intercambiado un equivalente de 35 HIP.


Ya con esta información podemos acordar y registrar (confirmar) las fechas correspondientes, de inicio y fin del proyecto.



Como se comentó antes, durante el proyecto y ante cualquier cambio que implique una modificación del esfuerzo asociado al trabajo restante, o algún imprevisto respecto de la suposición de Capacidad del equipo, se debería inmediatamente re-negociar el alcance (si aún se mantienen rígidos los plazos y la no intención de aumentar la Capacidad con más personas en el equipo), efectuando las mismas operaciones que hemos visto en Worki.


La gestión de alcance del Sprint es muy similar a la del proyecto, y se centra en que el esfuerzo que suman las UT que se incluyen en un Sprint sea coherente con la Capacidad disponible del equipo durante dicho Sprint. Y también del mismo modo, además de la gestión de alcance al iniciar el Sprint, también debería repetirse ante cambios significativos para que oportunamente se negocien las expectativas del resultado del Sprint.