El agilismo está volcado en la satisfacción del cliente, para esto
debemos mantener siempre alineando el trabajo del equipo con los intereses del
cliente, aún a costa de asumir cambios respecto de lo que inicialmente se
acordó. Este planteamiento genera inmediatamente inquietud en quien te escucha
y aparece la típica pregunta ¿y cómo se gestiona el alcance? ¿si permites
que el cliente cambie lo que se acordó, cómo podremos llegar a buen término sin
modificar los plazos y/o los recursos?
Obviamente, si el
cliente introduce nuevos requisitos o modifica los ya considerados
probablemente se estará modificando el esfuerzo requerido para completar la
entrega del producto, lo cual si es asumido sin más pondría en riesgo el
cumplimiento del plazo de entrega o incluso directamente podría hacer inviable
dicha entrega. Por contraparte, si el equipo se niega a hacer cambios respecto de lo pactado inicialmente, puede que se consiga un producto técnicamente
correcto y acorde a lo inicialmente acordado, pero que podría ser inútil
respecto de las expectativas finales del cliente. Para resolver este
dilema lo que debemos hacer es permitir cambios pero evaluando su impacto
respecto del esfuerzo, junto con negociar con el cliente la posible exclusión
en la entrega de otros elementos menos prioritarios.
A partir de la
versión de 2011 de la Scrum Guide, se ha pasado a proponer que el equipo
trabaje con un solo sprint abierto y que el resto del trabajo pendiente esté en
el Backlog, se ha quitado el concepto de Release (entrega) y la correspondiente Release Planning Meeting. Recordad que además los sprints no deberían tener una duración
mayor a un mes. Sin embargo, si se está desarrollando un nuevo producto o se
está abordando una remodelación de gran envergadura en un producto existente,
probablemente necesitemos varios sprints para poder conseguir un producto
preparado para ser puesto en producción. En este caso, cuando el cliente
introduce cambios durante el desarrollo, éstos se harían en el sprint actual
(si es estrictamente necesario) o se llevarían al Product Backlog.
Esta forma de trabajo dificulta la gestión del alcance puesto que el limite de
trabajo que se incluirá en la entrega debe establecerse en el Product Backlog
(a menos que estemos en el último sprint antes de la entrega, caso en el cual
el alcance final lo determinaría el propio sprint).
Para realizar una
eficaz gestión de alcance, aceptando cambios en el trabajo pendiente, es
imprescindible distinguir claramente durante todo el desarrollo cuál es el trabajo
pendiente acordado para el entrega y cuál es el que NO será incluido en la
entrega. El esfuerzo asociado al trabajo de la entrega debe ser ser factible de
abordar con la capacidad del equipo y el tiempo disponible hasta el plazo de
entrega. Para esto el equipo debe tener una noción de su Capacidad, por ejemplo
en horas ideales por semana o puntos, y correspondientemente cada ítem de trabajo
debería estar estimado en una unidad coherente con la usada para medir la
capacidad. Así pues, la gestión del alcance conlleva la estimación del trabajo
que se realizará y el registro de la Capacidad del equipo. Mientras más
inflexible sea el compromiso de la entrega, más frecuente y preciso debería
hacerse dicha gestión de alcance. Trabajando con sprints, el seguimiento no
solo debe centrarse en el alcance del sprint sino también en el alcance de la
entrega de la cual el sprint es una parte.
El alcance de la
entrega se mantiene coherente con los plazos y la capacidad del equipo
negociando con el cliente. Se negociará la introducción de ítems nuevos (o
modificaciones en ítems existentes) o su intercambio por otros ítems considerados hasta ese momento parte de la entrega, es decir, la idea es añadir, quitar, modificar y/o intercambiar los ítems.
De cara a
conseguir una buena "cadencia" (ritmo de trabajo terminado que puede
entregar un equipo en regimen normal normal de trabajo) es preferible negociar el alcance de la entrega prescindiendo de ítems menos prioritarios, en lugar de modificar los plazos o
introducir cambios en el equipo para conseguir más Capacidad (a menos que el
equipo no tenga dedicación completa a la entrega, caso en el cual sí que sería
interesante contar con más dedicación a ello, para intentar conseguir su dedicación
completa).
Aceptar el cambio
conlleva estar vigilantes del alcance y negociar oportunamente cada vez que se
produzcan cambios en el esfuerzo que puedan afectar el compromiso al
momento de la entrega. Por lo tanto la gestión del alcance en un contexto ágil
existe y es protagonista.
Hay que destacar que la gestión del alcance sólo tiene sentido cuando existe planificación, estimación y el compromiso de entrega. Puede darse que el compromiso con el cliente esté basado en un Acuerdo de Nivel de Servicio o simplemente en indicadores de flujo, tales como ítems terminados por unidad de tiempo, tiempo de servicio de los ítem desde que se reciben hasta que se implementan, etc. Esto sucede por ejemplo en equipos que realizan mantenimiento continuo de un producto resolviendo lo antes posible fallos o pequeñas mejoras, o equipos fuera del contexto de desarrollo, tales como un help desk o un equipo de infraestructuras encargado de resolver incidencias. En estos casos el foco se cambia hacia mejorar el flujo de trabajo terminado más que en gestionar el alcance ya que la demanda suele no ser planificable. Así pues, para estos casos la gestión del alcance no es protagonista pero se mantiene la priorización del trabajo, posiblemente también su estimación y quizás el registro de esfuerzo invertido. .
Hay que destacar que la gestión del alcance sólo tiene sentido cuando existe planificación, estimación y el compromiso de entrega. Puede darse que el compromiso con el cliente esté basado en un Acuerdo de Nivel de Servicio o simplemente en indicadores de flujo, tales como ítems terminados por unidad de tiempo, tiempo de servicio de los ítem desde que se reciben hasta que se implementan, etc. Esto sucede por ejemplo en equipos que realizan mantenimiento continuo de un producto resolviendo lo antes posible fallos o pequeñas mejoras, o equipos fuera del contexto de desarrollo, tales como un help desk o un equipo de infraestructuras encargado de resolver incidencias. En estos casos el foco se cambia hacia mejorar el flujo de trabajo terminado más que en gestionar el alcance ya que la demanda suele no ser planificable. Así pues, para estos casos la gestión del alcance no es protagonista pero se mantiene la priorización del trabajo, posiblemente también su estimación y quizás el registro de esfuerzo invertido. .
En el
contexto ágil, cuando se requiere un seguimiento continuo y preciso se utiliza
la Gráfica Burndown, en la cual podemos observar tanto la tendencia del trabajo
restante como las perturbaciones que puedan afectar los compromisos. La
siguiente figura muestra una gráfica Burndown para el segundo sprint de
desarrollo de un producto.
En la figura, la
línea roja muestra día a día el esfuerzo restante del sprint. La línea morada
es la referencia. Si el esfuerzo restante tiende a ir por bajo la línea morada
puede que se cumplan con la entrega antes de plazo. Correspondientemente, si el
esfuerzo restante tiende a ir por sobre línea de referencia nos advertiría que
puede que no se llegue a cumplir en el plazo establecido. Así, la gestión de
alcance durante un sprint se apoyará en la
Gráfica Burndown para determinar la factibilidad de incorporar cambios en lo acordado al inicio del sprint.
Si a la vez,
además de supervisar el sprint abierto de un producto, estamos en el marco de una release o entrega (un compromiso a más largo
plazo), mantendremos en paralelo una gráfica Burndown similar a la anterior pero para el seguimiento de
todo el trabajo de la entrega (todos los sprints). Así pues, una gráfica
Burdown de la entrega ilustraría el progreso y estado actual del proyecto como un
todo, es decir, de todas las unidades de trabajo incluidas en la entrega (release).
El enfoque
descrito lo tenemos implementado en nuestra herramienta TUNE-UP Process. Cada producto que lo necesite puede ser planificado
y supervisado usando Sprints. Además, cuando se requiere una planificación y
seguimiento a más largo plazo se pueden establecer Proyectos los cuales
utilizan gráficas similares a las que se utilizan para el seguimiento de un
Sprint.
Patricio Letelier
Patricio Letelier
No hay comentarios:
Publicar un comentario