La configuración de planificación y seguimiento debe considerar la situación actual del producto o servicio, para conseguir un balance entre lo que sería el ideal y los desafíos que podría plantear el cambio hacia ese ideal. En muchas ocasiones lo más recomendable es iniciar una evolución más que un cambio radical que pueda crear ruido e incluso rechazo, particularmente para productos o servicios que son claves para el negocio.
Una práctica básica indiscutible en cualquier implantación ágil es la visualización de todo el trabajo no terminado mediante un tablero kanban. Así pues, un tablero kanban es el mecanismo básico para el seguimiento del trabajo. Ojo que con esto no estoy refiriéndome a usar el Método Kanban, sino solo el tablero que ofrece una mecánica para el flujo y visibilidad del trabajo. Existe bastante confusión respecto del uso de un tablero kanban, el cual no es exclusivo del Método Kanban, y además, es necesario en Scrum o XP porque en estos métodos no se ofrece un equivalente para visualizar el trabajo del equipo (ver ¿Kanban o Scrum?: that is not the question).
Una vez explicado el papel del tablero kanban, el resto de aspectos que podemos considerar para la configuración de planificación y seguimiento de cada producto/servicio son los siguientes:
- Agrupación (o no) del trabajo en sprints
- Gestión del esfuerzo
- Proceso centrado en Pruebas de Aceptación
- Líneas de trabajo en un mismo producto/servicio
- No usar sprints. Si la demanda del trabajo no es planificable (no sabemos qué trabajo ni cuando nos va a llegar) y/o no tenemos compromisos estrictos de plazos o alcance con el cliente, esta podría ser la mejor opción. Esta alternativa está cercana a la propuesta del Método Kanban, según la cual debemos centrarnos en generar un buen flujo de trabajo terminado, haciendo entregas muy frecuentes. Esta alternativa es particularmente adecuada para trabajo de mantenimiento continuo o solución de incidencias.
- Sprints flexibles. Si no se tienen compomisos estrictos con el cliente pero sí que se tiene la posibilidad de acordar paquetes de trabajo para ser entregados en una cierta fecha, puede ser interesante utilizar sprints para evitar repetir muy continuamente las actividades de arranque y cierre de versión (que por ejemplo, incluyen en el cierre el pasar pruebas de regresión, despliegue, actualización de ayuda, etc.). El "Continuous Delivery" tiene ese desafío, es decir, contar con una buena infraestructura que evite una penalización en esfuerzo en dichas actividades de arranque y cierre de versión. Los ítems incluidos en el sprint, por no existir un compromiso estricto de alcance y plazo con el cliente, podrían no estar estimados y en caso de no poder terminarse en la fecha de fin del sprint simplemente se pasarían al siguiente sprint (reevaluando su prioridad respecto de los ítems contenidos en el Backlog en ese momento).
- Sprints rígidos. Si la demanda es planificable y además el compromiso con el cliente en cuanto alcance y plazo del sprint es más bien rígido, lo recomendable es tener una noción de la capacidad del equipo y realizar estimaciones del trabajo que se incluye en el sprint para asegurar que sea consistente el esfuerzo asociado respecto de dicha capacidad.
Gestión del esfuerzo
En este aspecto me refiero a cómo medir el esfuerzo estimado, invertido y restante en realizar un ítem de trabajo.
- Esfuerzo estimado. Primero hay que insistir en que si no hay un compromiso estricto con el cliente en cuanto a alcance y plazos la estimación puede ser opcional. El esfuerzo estimado puede medirse en Horas Ideales o en Puntos (o cualquier otra medida de tamaño). Las Horas Ideales (horas de trabajo sin interrupciones) miden el esfuerzo asociado a actividades específicas, por ejemplo, horas ideales de programación. Los Puntos en cambio miden el esfuerzo global asociado al tamaño de un ítem de trabajo. Ver "Estimación en un proyecto ágil": Parte I y Parte II.
- Esfuerzo invertido. Son las horas reales invertidas en actividades asociadas a un ítem de trabajo, por ejemplo, cuántas horas de programación o testeo llevamos invertidas en un ítem. No tiene mucho sentido plantearse el registrar Puntos invertidos en un ítem, pues no es una medida asociada a una actividad y estaríamos forzándo a darles una interpretación de unidad de tiempo, lo cual justamente es lo que los Puntos no son.
- Esfuerzo restante. Se puede medir como la diferencia entre horas estimadas (y actualizadas cuando corresponda) y horas invertidas. En el caso de Puntos son los punto correspondientes a ítems de trabajo no terminados, es decir, no se haría un cálculo parcial del trabajo que esté comenzado pero no terminado.También es una alternativa el registrar directamente el esfuerzo restante, es decir, para cada ítem iniciado registrar períódicamente cuántas horas ideales restan en una actividad para finalizarla.
- No gestionar esfuerzo.
- Usar Puntos solo como esfuerzo estimado y calcular los puntos restantes como puntos de ítems no terminados.
- Registrar solo el esfuerzo invertido.
- Registrar solo el esfuerzo restante en horas ideales.
- Registrar el esfuerzo estimado y el esfuerzo invertido. El esfuerzo restante puede calcularse como la diferencia entre el esfuerzo estimado y el invertido.
Esta es una práctica que me llamó la atención cuando dí mis primeros pasos en el agilismo con Extreme programming. Si bien no se trata de una exclusividad del enfoque ágil, pues las pruebas de aceptación están presente también en las metodologías tradicionales, es indudable que el protagonismo es mucho más marcado en el contexto ágil. Además, la diferencia fundamental es que en el ámbito ágil el proceso debería estar dirigido por las pruebas de aceptación. Ojo!, no estoy hablando de TDD, el cual está orientado a pruebas unitarias. En un enfoque ágil, las pruebas de aceptación se escriben en el momento de definir o redefinir el ítem de trabajo, es decir, son en sí mismas la especificación detallada del ítem, son el criterio de éxito establecido para la implementación. Desgraciadamente, esta práctica no es sencilla de implantar, requiere formación y experiencia, además de cambios en la forma de trabajo pues o bien el tester (de testeo de aceptación) trabaja codo a codo con el que establece los requisitos (quien define/analiza el ítem de trabajo) o es este último quien directamente especifica las pruebas de aceptación del ítem (tarea que tradicionalmente realiza el encargado de testeo).
Pues bien, de cara a la planificación y seguimiento ágil, el tener un proceso centrado en pruebas de aceptación ofrece las siguientes ventajas:
- Para la planificación las pruebas de aceptación son una excelente forma de negociar y establecer desarrollo incremental de ítems de trabajo "grandes". Así, en lugar de particionarlos, se pueden desarrollar en ítems sucesivos que incrementan la funcionalidad dando soporte a más pruebas de aceptación.
- Para el seguimiento las pruebas de aceptación de un ítem de trabajo y su estado nos ofrecen un detalle adicional del estado de avance del trabajo en un ítem. Por ejemplo, podríamos saber del total de pruebas identificadas cuantas están ya definidas (condiciones, pasos y resultado) y cuántas estan ya diseñadas (instanciaciones concretas de datos para las condiciones, pasos y resultado), o por otra parte, podríamos saber cuántas pruebas están implementadas OK y cuántas tienen detectado algún fallo y están KO.
Líneas de trabajo en un mismo producto
Una situación bastante habitual en productos grandes y/o con un mantenimiento continuo es tener varias líneas de trabajo en paralelo sobre el mismo producto. Por ejemplo, trabajo asociado a módulos específicos del producto los cuales llevan probablemente su propio versionado, o trabajo de grandes cambios o nuevos módulos, o trabajo de mantenimiento asociados a corrección de fallos o pequeñas mejoras que debe entregarse a muy corto plazo. De cara a la planificación y seguimiento esta situación incluye varios desafíos. Si lo tratamos como un solo producto, podríamos caer en hecho de someter a una única configuración de planificación y seguimiento a todas las líneas de trabajo, por ejemplo, trabajando con sprints, cada sprint contendría trabajo de las diferentes líneas y se tendría que sincronizar de alguna forma al cierre del sprint. Si gestionáramos cada línea de trabajo como un producto separado tendríamos la libertad para definir la configuración de planificación y seguimiento para cada línea de trabajo, por ejemplo, si se trabaja con sprints, cada línea de trabajo tendría sus propios sprints. En cualquiera de los casos deberíamos asegurar que los cambios se gestionen y visualicen en conjunto para detectar conflictos o dependencias entre las diferentes líneas pues de todas formas estaríamos trabajando sobre el mismo producto. Para conocer más detalles respecto de esta situación y alternativas asociadas a cómo abordarla ver "Gestión ágil de productos que tienen varias líneas de trabajo".
Conclusiones
Los patrones de planificación y seguimiento ágil surgen de la elección de estrategias en cada uno de los 4 aspectos planteados. A continuación se muestran algunos patrones de ejemplo:
Producto A: Usar sprints flexibles, registrar en horas esfuerzo invertido (sin hacer estimaciones), no trabajar centrado en pruebas de aceptación, y tratar el desarrollo y el mantenimiento urgente dentro del mismo producto y sprint pero pasando a producción versiones asociadas a mantenimientos urgentes.
Producto B: No usar sprints, registrar el esfuerzo en Puntos (no registrar el esfuerzo invertido) y usarlo solo como un dato descriptivo para reconocer en el Backlog ítems pequeños o grandes, trabajar centrado en las pruebas de aceptación, el producto ya está en producción y mientras no aparecen grandes cambios, todo el mantenimiento se hace de forma contínua en la medida que va recibiéndose y priorizándose.
Producto C: Un producto grande con diferentes módulos abordados por diferentes equipos. Cada equipo-módulo ajusta su configuración de planificación y seguimiento, pero todos los equipos comparten la información de la estructura del producto para poder detectar conflictos y dependencias respecto del trabajo que realiza otro equipo en otro módulo. Por ejemplo el equipo E1 trabaja en el módulo M1 con sprints, registrando tiempo estimado e invertido en horas (y disponiendo del tiempo restante también en horas), y trabaja centrado en pruebas de aceptación. El Equipo E2 trabaja en el módulo M2 (un nuevo módulo para el cual hay que desarrollar inicialmente un prototipo), no utiliza sprints, no hace estimaciones ni registros de tiempo invertido, y no trabaja centrado en pruebas de aceptación.
Obviamente de acuerdo al patrón seleccionado, la planificación y las formas de seguimiento serán diferentes. Por ejemplo, si no se tienen sprints no tiene sentido preguntarse si vamos a cumplir con una fecha de entrega de un paquete de trabajo, sin embargo, esto no debería ser un problema puesto que justamente lo que quieres darle al cliente es una solución lo más inmediata posible del problema que te está reportando en el momento. Si no se estima, no se podrá disponer de una gráfica Burndown o de trabajo Finalizado versus No Finalizado. Si se utilizan Puntos podrás tener una gráfica Burndown y una gráfica de relación entre ítems Finalizados/No Finalizados, pero en ambos casos solo se contabilizará un cambio cuando el ítem esté terminado, mientras los ítems siguen sin finalizarse ambas gráficas no muestran cambios. Si se registran estimaciones en horas y esfuerzo invertido también en horas, automáticamente puede calcularse el trabajo restante de la gráfica Burndown y las proporciones de trabajo finalizado y no finalizado. Si se trabaja centrado en pruebas de aceptación podrá adicionalmente conocerse el estado de especificación de las pruebas (identificadas, definidas o diseñadas) y su estado de ejecución (OK o KO).
Ignorar la configuración de la planificación y seguimiento de cada producto (o de sus líneas de trabajo) puede conllevar situaciones de proceso en las cuales se hace más trabajo o menos trabajo del que realmente se requiere para ser eficaz en cuanto al éxito del equipo en el producto, o simplemente incomodidades para abordar el trabajo pues no se ajusta a las necesidades del contexto del producto.
Las variantes para establecer los patrones de planificación y seguimiento ágil los hemos ido refinando con nuestra experiencia en múltiples proyectos de implantación de nuestro enfoque Tune-up, y se ofrecen en nuestra herramienta como sencillas opciones de configuración de cada producto/servicio, incluso es posible cambiar en cualquier momento de una configuración a otra si se considera conveniente.
Patricio Letelier
No hay comentarios:
Publicar un comentario