Un modelo conceptual para la gestión ágil del trabajo

El enfoque ágil tiene dos objetivos esenciales: mejorar la dinámica de trabajo del equipo favoreciendo su motivación y compromiso, y al mismo tiempo, aumentar la rentabilidad del esfuerzo invertido por el equipo, dirigiéndolo a maximizar la satisfacción del cliente. Todo esto está muy bien, pero ¿cómo llevarlo a la práctica?¿cómo comenzar?. Podríamos pensar que la respuesta es sencilla ya que disponemos de varios métodos ágiles (Kanban, Scrum, Lean Development, Extreme Programming, etc.) y de decenas de herramientas que ofrecen apoyo a dichos métodos. Sin embargo, la implantación del enfoque ágil no es fácil, encierra muchos desafíos, es un proyecto de cambio organizacional. Además, aunque existen métodos ágiles y muchísima literatura al respecto, para bien y para mal no existe una interpretación unificada del enfoque ágil. Por un lado, el enfoque ha tenido libertad para evolucionar rápidamente por no estar regulado por ningún organismo, pero al mismo tiempo la etiqueta "ágil", en muchas implantaciones del enfoque, se ha auto-otorgado muy alegremente :-). Muchas empresas que se han lanzado a implementar el enfoque ágil se han dado cuenta que no basta con asistir a formaciones o certificaciones en agilidad, ni tampoco es suficiente con adquirir una herramienta para conseguir una mejora significativa en el trabajo (incluso es contraproducente comenzar con esto). Si no se dispone de una metodología adaptada al contexto de trabajo las expectativas de mejora no se cumplirán.

Por nuestra parte, durante muchos años trabajando con el enfoque ágil hemos ido refinando TUNE-UP Process, una propuesta metodológica que integra las prácticas ágiles de los principales métodos ágiles en un modelo conceptual unificado. TUNE-UP Process es nuestra interpretación de qué es el enfoque ágil, y tiene a su favor la experiencia conseguida trabajando en diversos contextos de empresa, con un enriquecimiento continuo al utilizarse como base para cursos de formación, y con el alineamiento con Worki, su herramienta de apoyo, con lo que hemos llegado a reunir todas las piezas: modelo, metodología y herramienta.

En este post presento lo esencial del modelo conceptual de TUNE-UP Process. Este modelo contribuye a establecer una buena infraestructura para organización ágil del trabajo, lo cual favorece la implantación del enfoque ágil y permite ir adaptándolo a las necesidades del contexto de trabajo.

Modelo conceptual de TUNE-UP Process

La siguiente imagen muestra los principales conceptos incluidos en nuestra propuesta metodológica. Durante el resto del post describiré en detalle cada uno de ellos.

La Unidad de Trabajo (UT) representa a un ítem de trabajo a un cierto nivel de granularidad (también podría llamarse Historia de Usuario o simplemente Ítem). Por ejemplo, en desarrollo de software una UT podría ser un nuevo requisito, una mejora de un requisito ya implementado o una corrección de un fallo.

Cada UT desde su creación hasta su término sigue un flujo de trabajo (workflow), que corresponde a una secuencia de Actividades (pudiendo existir actividades realizadas de forma alternativa o en paralelo). Los workflows determinan los Tableros kanban que se utilizarán, en los cuales las actividades de un workflow corresponden de izquierda a derecha con las actividades de un Tablero kanban. Cada Tablero kanban muestra en qué actividad (o estado) están las UT que siguen ese flujo de trabajo. Para el diseño de workflows y tableros kanban recomiendo leer: "Workflows flexibles. Parte I y Parte II" y "Tableros kanban. Parte I y Parte II".

Una Línea de Trabajo es el contenedor global de UT. Podríamos NO reconocer Líneas de Trabajo (es decir, tener solo un contenedor para todo el trabajo) pero hay varios factores que hacen conveniente agrupar el trabajo en diferentes Líneas de Trabajo, entre ellos:

• Planificación y seguimiento del trabajo. Trabajos que normalmente tienen distintos calendarios de compromisos o acuerdos de ritmos de entrega.
• Equipos de trabajo. Trabajos asignados a diferentes equipos de trabajo.
• Distribución de capacidad de los equipos. Trabajos que en un período de tiempo compiten por asignación de Capacidad del equipo. Así, según prioridades, se puede distribuir explícitamente la Capacidad del equipo en sus diferentes Líneas de Trabajo.

Así pues, una Línea de Trabajo normalmente está asociada a un producto/servicio y a un equipo de trabajo (pudiendo un equipo ser responsable de varias Líneas de Trabajo). Además, si la naturaleza del trabajo en una Línea de Trabajo es diversa, la Línea de Trabajo puede tener varios Workflows (Tableros kanban), para que a cada UT se le aplique el proceso que le sea más adecuado.

Toda Línea de Trabajo tiene un Backlog. El Backlog es el contenedor de las UT que NO se están contenidas en un Sprint, es decir, las UT estarán en el Backlog o en algún Sprint. Cuando se decide NO trabajar con Sprints conceptualmente todas las UT están en el Backlog, allí se priorizarían e irían terminándose. Cuando se trabaja con Sprints, normalmente mientras están en el Backlog a las UT se les aplica un trabajo de "preparación", y al pasar a un Sprint se les aplica el trabajo asociado a su "ejecución". Por ejemplo, actividades típicas de "preparación" en el Backlog son: Priorizar, Definir/Analizar/Especificar, Validar, Estimar, etc. Actividades típicas de "ejecución" en un Sprint son: Programar/Implementar, Probar, Integrar, Desplegar, etc.  Así pues, el Backlog y los Sprints en un Tablero kanban se corresponden con grupos de columnas; las del Backlog en la parte izquierda del tablero y las de Sprint en la parte derecha. Si se decide NO trabajar con Sprints en una Línea de Trabajo todas las actividades, tanto de preparación como de ejecución se realizan en el Backlog (todas las columnas del Tablero kanban se realizan estando las UT en el Backlog).

Cuando se adquiere un compromiso de entrega (fechas de inicio y fin) es recomendable enmarcar todas las UT de dicho compromiso (el alcance) en un Proyecto asociado a la Línea de Trabajo. Este compromiso requiere tener establecido un alcance y costos, es decir, estamos en una situación de trabajo "planificable". Usualmente el desarrollo de la primera entrega de un producto/servicio es por definición un Proyecto. Sin embargo, después de la primera entrega, si no vuelven a existir compromisos alcance-plazos-costos, podría continuarse el trabajo asociado al producto/servicio sin tener asociado un Proyecto.

A continuación se responden varias cuestiones claves respecto de la combinación de los elementos del modelo conceptual propuesto. Es importante destacar que estas cuestiones deben evaluarse para cada Línea de Trabajo; uno de los errores más frecuentes es ignorar la diversidad del trabajo e imponer la misma estrategia para todo el trabajo y/o no reconocer diferentes Líneas de Trabajo, cada una con sus necesidades.

¿Tiene sentido usar un Tablero kanban si también se usan Sprints?

Se usen o no Sprints, siempre es necesario utilizar un Tablero kanban para visualizar el estado de preparación y ejecución de las UT. 

¿Cuándo conviene usar Sprints en una Línea de Trabajo?

Los Sprints son importantes para ayudar a gestionar el desarrollo incremental a corto plazo. Sin embargo, en situaciones NO planificables (cuando el alcance no se conoce totalmente de antemano o suele variar significativamente) no es sensato imponer una disciplina de Sprint "rígidos" en contenido y/o duración, dado que cualquier previsión probablemente se verá muy afectada por cambios durante  el Sprint. En el caso extremo, si gran parte del esfuerzo de planificar Sprints se pierde por los continuos cambios durante el Sprint, podría prescindirse de usar Sprints y trabajar solo con un Backlog priorizado. Sin embargo, los Sprint podrían ser "flexibles" para acomodarse a un cierto nivel de cambios durante el Sprint (ver "Sprints, welcome to the real world ..."), asumiendo cambios en cuanto a contenido y en duración de los Sprints, o que puedan comenzar aún sin tener todas sus UT preparadas, o que puedan existir a la vez más de un Sprint abierto. En su forma "más flexible" y solo con el propósito de consultar trabajo realizado, el contenido de un Sprint podría establecerse a posteriori (sí, después de terminar un conjunto de UT), es decir, aprovechar los Sprint solo como agrupador de trabajo ya terminado, e incluso poniéndole nombres asociados al calendario. Por ejemplo, en un Sprint llamado "2019 Abril", en el cual se ha incluido todo el trabajo terminado durante el mes de abril de dicho año. 

¿Tiene sentido usar Proyecto y Sprints en una Línea de Trabajo? 

Tanto Proyecto como Sprint son contenedores temporales de trabajo, y lo usual es que el alcance de dicho trabajo esté previsto antes de comenzar a trabajar en ello (y que la estimación de esfuerzo sea coherente con la Capacidad del equipo encargado). Por otra parte, se recomienda que los Sprints NO tengan una duración de más de 4 semanas pues su objetivo es darnos una retroalimentación a corto plazo del avance del trabajo. Sin embargo, un Proyecto no tiene dicha restricción de duración. Así pues, sí que puede ser útil combinar los conceptos de Proyecto y Sprints. Por ejemplo, para un Proyecto de 6 meses se podrían establecer 8 Sprints de 3 semanas cada uno. Las UT del Proyecto estarán priorizadas en el Backlog y se irán incluyendo en los sucesivos Sprints hasta finalizar el Proyecto. Al finalizar el Proyecto podrían quedar algunas UT en el Backlog (ya quitadas del alcance del Proyecto), podría tratarse de algunas UT originales, o de nuevas UT que se hayan generado durante el Proyecto. Esta es otra de las razones del por qué es importante separar el concepto de Proyecto del concepto de Línea de Trabajo; aunque el Proyecto finalice, la Línea de Trabajo asociada al producto/servicio seguirá existiendo y tendrá trabajo asociado que habrá que abordar posteriormente (dentro o fuera del marco de otros Proyectos).

No tiene sentido usar Sprints si la duración del Sprint es igual a la del Proyecto. Por ejemplo, si el Proyecto es de 2 semanas y se establece que se hará solo un Sprint de dos semanas, en este caso el Sprint no aportaría nada respecto de la planificación y seguimiento del trabajo. Puede que tampoco tenga mucho sentido tener Sprints muy pequeños, cuando el Proyecto sea de muy corta duración. Por ejemplo, un Proyecto de 3 semanas dividido en 3 Sprints de una semana. Hay que evaluar los "costos de transacción", es decir, el esfuerzo asociado a arrancar un Sprint y a terminarlo (siguiendo todos los protocolos asociados).

Conclusiones

El modelo conceptual propuesto sirve de infraestructura para organizar el trabajo de forma ágil. Sin embargo, hay que destacar que un enfoque ágil no consiste solo en utilizar conceptos ágiles. El mayor desafío es aplicar prácticas ágiles (hábitos de trabajo), y para esto es fundamental establecer un roadmap para ir incorporando dichos hábitos ágiles en el trabajo diario del equipo. Ver nuestra colección de prácticas ágiles en Agile Roadmap.

La libertad que ha tenido el enfoque ágil en cuanto a propuestas e interpretaciones en muchos casos se ha vuelto en su contra. Por ejemplo, el abuso del término Proyecto; si a todo se le llama Proyecto, cuando un proyecto termina ¿hay que crear otro proyecto con el trabajo restante o con el nuevo trabajo que va surgiendo y que está asociado al mismo producto/servicio? ¿hay que cambiarle nombre y fechas al Proyecto una vez terminado terminado para reutilizarlo?. Cuando se solapa para un mismo producto el desarrollo de nuevas funcionalidades con el mantenimiento continuo (de respuesta rápida y con urgencias) ¿se enmarca todo este trabajo en un mismo Proyecto?. Estas confusiones respecto del término Proyectos o la confusa combinación de Tableros kanban con Sprints se ven fomentadas por herramientas como en JIRA o Target Process, donde queda en evidencia la falta de un buen modelo conceptual. En esta temática, recomiendo leer:

"El concepto "Línea de trabajo": más allá de Proyectos, Productos o Servicios"
"Gestión ágil de productos. Líneas de trabajo en un producto a partir de su primera entrega"
"Organización ágil del trabajo"



Patricio Letelier

twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com

www.tuneupprocess.com 

Retrabajo, Refactoring y Fallos ... ¿cuál es su relación?

Retrabajo es el esfuerzo adicional necesario para corregir defectos en un producto. El Retrabajo tiene connotación negativa pues si se evitasen los defectos no se tendría que hacer dicho esfuerzo adicional, pero como veremos no todo el Retrabajo debería considerarse negativo.

Antes de seguir quiero indicar la terminología que usaré en cuanto a defectos, fallos y errores. En el post "Fallos - Defectos - Errores y su gestión en un contexto ágil" se ofrecen unas definiciones al respecto, que resumen en lo siguiente: los errores son cometidos por las personas participantes en el desarrollo de un producto, estos errores generan defectos que quedan incluidos en el producto (especificaciones o código), estos defectos en algún momento se manifestarán, cuando se detecte el fallo provocado por el defecto, y finalmente, la corrección del fallo es la eliminación del defecto. Los defectos pueden generarse en cualquier actividad (por ejemplo, al especificar requisitos, diseñar, programar, probar, etc.). Es muy difícil conseguir productos con cero defectos, pero es posible evitar en gran medida los defectos si se dispone de los mecanismos preventivos adecuados.

El Retrabajo conlleva la repetición parcial o total de algún trabajo que se suponía estaba finalizado. Pero hay que destacar que las mejoras en requisitos ya implementados y/o el desarrollo incremental NO deberían considerarse Retrabajo. Aunque se trata de trabajo asociado a resultados ya obtenidos de un trabajo previo y finalizado, se están añadiendo aspectos no existentes en los requisitos ya implementados. Lectura recomendada: "Flecos" de implementación y gestión ágil de proyectos.

El Refactoring sí que es una forma de Retrabajo, pero ojo!, también es considerada una buena práctica en el enfoque ágil. Hay que aclarar que el Refactoring "bueno", el planteado por Extreme Programming (XP), implica intentar mejorar de la organización del código continuamente. Cada vez que se va a cambiar alguna pieza de código existe la oportunidad para mejorarlo. Sin embargo, muchos equipos interpretan el Refactoring como concentrarse puntualmente en hacer mejoras de arquitectura del código puntualmente, especialmente cuando una parte del código está teniendo serios problemas de mantenimiento. Para este Refactoring "bueno" no deberían crearse ítems específicos, sino que este trabajo debería abordarse como parte del trabajo de programación de cualquier cambio en el producto. En un enfoque ágil el Refactoring es muy importante ya que este enfoque apuesta radicalmente por el desarrollo incremental, es decir, una misma pieza de código tiene alta probabilidad de ser cambiada una y otra vez durante el desarrollo del producto. El Refactoring continuo contribuye a evitar que la arquitectura del código se degrade con los cambios. Así pues, este Refactoring "bueno" y su Retrabajo asociado deberían ser asumibles en un enfoque ágil, pues favorecen la estrategia global de desarrollo de este enfoque.

Por otra parte, hay trabajos que tienden a considerarse como Refactoring, tales como una mejora del rendimiento de la aplicación o una remodelación de la interfaz de usuario. La definición estándar de Rafactoring es "cambiar el código sin que esto conlleve cambios en los requisitos ya implementados", es decir, es un trabajo cuyo resultado no es visible para el usuario. Según esto, los dos ejemplos anteriores (mejora de rendimiento y remodelación de la interfaz) son cambios constatables por el usuario, con lo cual no deberían considerarse Refactoring.

Volviendo al tema del Retrabajo, ¿cuál es el Retrabajo verdaderamente negativo y qué supervisión deberíamos hacer sobre él?. Existen dos situaciones de Retrabajo que deberían ser vigiladas:

1. Fallos detectados en el uso del producto (en una versión ya publicada). Se deben crear ítems para corregir estos fallos, y estos ítems competirán con los otros ítems del Backlog hasta que alcancen la prioridad para ser implementados (un fallo podría no ser severo y tener menos prioridad que otros ítems). Además de la imagen negativa para los usuarios en cuanto a calidad del producto y sus consecuencias, el esfuerzo dedicado a estos ítems de corrección de fallo restará capacidad al equipo para desarrollar mejoras o nuevos requisitos.
2. Fallos detectados durante el proceso de desarrollo de una entrega. Cada vez que en el flujo de trabajo se debe volver a realizar a una actividad supuestamente finalizada se incurre en Retrabajo. Por ejemplo, cuando el programador demanda una corrección dirigida a la actividad (previa) de "Especificar Requisitos" porque algún ítem tiene defectos en su especificación, o cuando el tester al probar un cambio en el producto detecta algún fallo en la implementación de dicho cambio y solicita a programador que vuelva a programar para corregirlo. Sin embargo, no debería considerarse Retrabajo que el mismo programador detecte algún fallo en su trabajo mientras lo está realizando ya que esa detección ocurre en el ámbito de su actividad no finalizada (además, sería difícil  distinguir en una misma actividad cual parte del esfuerzo se refiere a defectos detectados y corregidos dentro de la misma actividad). Así pues, una forma sencilla de identificar Retrabajo dentro del proceso de desarrollo es observando cuándo en un ítem se vuelve a repetir una actividad ya finalizada. Por ejemplo, si un ítem está en la actividad "Pruebas de Aceptación" y debido a fallos detectados vuelve abrirse la actividad "Programar". De esta forma, podemos decir que el esfuerzo invertido en la actividad "Programar", después de la primera vez que se dio por finalizada, es tiempo de Retrabajo en dicha actividad. Pero nuevamente, hay tener en cuenta una situación en la que este Retrabajo no tendría un sentido negativo, es más, podría ser algo positivo. Supongamos que se está implementando un ítem ítem grande, complejo y/o con mucha incertidumbre asociada a su "qué y cómo", y que se descartaron las alternativas asociadas a particionarlo (convertirlo en ítems más pequeños) o desarrollarlo incrementalmente (desarrollar primero una pequeña parte y mantener el resto del ítem pendiente en el Backlog), es decir, el ítem se va a implementar como un todo, y se decide iterar Análisis-Diseño-Implementación-Pruebas para ir intencionalmente desarrollándolo en refinamientos sucesivos y asumiendo posibles "pasos en falso". En este caso es probable que se realicen dichas actividades con bastante paralelismo y/o vuelta atrás, con lo cual no deberíamos penalizar esta estrategia, puntual para un ítem, por el Retrabajo natural que se registrará. 

Según lo anterior, ¿qué métricas deberíamos manejar para poder evaluar el rendimiento de nuestro proceso de desarrollo respecto del Retrabajo?. El esfuerzo invertido en la corrección de defectos sería la métricas esencial, y en segunda instancia, el número de correcciones de defectos (teniendo en cuenta que la diversidad de los defectos y de su corrección hacen que sean muy dispares en esfuerzo uno de otros).

A continuación ilustraré cómo en nuestra metodología y herramienta TUNE-UP Process ofrecemos  información para la supervisión del Retrabajo. Comenzaremos con lo relativo a fallos detectados en el uso del producto.

Capacidad invertida por tipo de ítem (Nuevos requisitos, Mejoras en requisitos ya implementados y Correcciones de fallos). Esta información se muestra por cada Sprint.

En la gráfica anterior cada barra representa el esfuerzo invertido en un Sprint. Los colores corresponden a la proporción del esfuerzo del Sprint invertido en cada tipos de ítem (verde: Nuevos requisitos, amarillo; Mejoras y rojo: correcciones de fallos). 

Número de ítems por tipo en cada Sprint. En esta gráfica se representa también como una barra cada Sprint, pero los colores ahora corresponden a la proporción del número de ítems de cada tipo respecto del total de ítems en el Sprint (usando el mismo código de colores de la gráfica anterior).

Para apoyar la interpretación de estas gráficas también es conveniente conocer la duración de cada Sprint (si el equipo y su disponibilidad se mantiene, a mayor duración del Sprint, mayor capacidad de trabajo). La siguiente gráfica muestra la duración de los Sprints asociados a las anteriores gráficas. Como se observa, en este caso los Sprints son "flexibles" en cuando a duración (en general, lo recomendable es mantener cierta regularidad en la duración de los Sprints, pero puede que en un contexto determinado sea más conveniente usar Sprints flexibles. Ver "Sprints, "welcome to the real world" ...").

Algunos otros datos que podrían ser interesantes para un estudio más profundo, especialmente desde una perspectiva de calidad son:

• Distinguir los fallos según su severidad. 
• Conocer las áreas del producto en las cuáles se están generando más fallos y retrabajo.
• Poder identificar el ítem previo o el Sprint donde se introduce cada defecto.
• Conocer el tiempo transcurrido desde que se detecta un fallo hasta que se publica una versión donde ese fallo está corregido.

Ahora veremos cómo podemos supervisar el Retrabajo asociado a fallos detectados dentro del proceso de desarrollo.

Retrabajo registrado en cada ítem de trabajo. En la siguiente gráfica se muestra el tiempo invertido en la actividad "Programar" para cada uno de los ítems de un Sprint. Además, para cada ítem se destaca en color rojo la proporción de esfuerzo que corresponde a Retrabajo.

¿Cuánto debería ser la proporción admisible de Retrabajo en un ítem?. Dependerá del contexto y también como indiqué antes hay que tener cuidado al evaluar el Retrabajo, pues puede ser intencional, es decir, cuando la estrategia que elegimos para abordar un ítem genera de forma natural cierto Retrabajo. Sin embargo, lo importante de la gráfica anterior y de su interpretación es poder identificar comparativamente que ítems han generado más Retrabajo y estudiarlos para concluir si es justificable o si deben/pueden tomarse medidas preventivas para reducirlo.

Seguimiento de un ítem con indicación de vueltas atrás. Si accedemos a cualquiera de los ítems con Retrabajo podremos ver en su seguimiento (la historia del ítem) información adicional asociada a dicho Retrabajo. Por ejemplo, en la siguiente imagen podemos ver que hay dos vueltas atrás (marcadas con la flecha roja), es decir, se repitieron dichas dos actividades y los tiempos invertidos de esas repeticiones has sido contabilizados como tiempo de Retrabajo.

Finalmente, es muy importante tener presente que la interpretación de esta información y las posibles acciones que se puedan derivar deben tomarse con prudencia. No es recomendable correlacionar  penalizaciones/premios para el equipo basándose directamente en estadísticas de Retrabajo o Fallos. Como he señalado existen bastantes situaciones particulares en las cuales el Retrabajo no debería considerarse negativo. Además, los fallos exigen mayor discriminación en cuanto a severidad, tiempo que se requiere para corregirlos, etc. Acciones mal orientadas podrían perjudicar el espíritu de equipo cuando conllevan la culpabilización de las personas involucradas. Por contraparte, y como sabemos, las estadísticas se pueden manipular :-), sería fácil mejorar los datos, por ejemplo, no registrando esfuerzo en las actividades que se están supervisando, registrando esfuerzo de forma que no figure como Retrabajo, clasificando incorrectamente los fallos, o no poniendo la severidad que les corresponde.



Patricio Letelier

twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com

www.tuneupprocess.com 

¿Desarrollo Incremental implica Especificación Incremental? ¿debería implicarlo?

Muchas veces he visto cómo se plantea el modelo de proceso (la estrategia global de desarrollo) como el principal elemento que diferencia a un enfoque tradicional de uno ágil, diciendo que el  tradicional usa un modelo de proceso Waterfall (en cascada) mientras que el ágil usa un modelo iterativo e incremental. Puede que esto valga como comparación muy simplificada de ambos enfoques, pero al hacerlo se incurre en varios errores. Primero, si bien el modelo de proceso es importante, no lo es todo, hay muchos otros aspectos diferenciadores entre ambos enfoques. Segundo, todos los métodos ágiles proponen un modelo de proceso incremental, pero no todos requieren que también sea iterativo. Scrum y Extreme Programming son claramente iterativos (utilizan Sprints) e incrementales, sin embargo, Kanban, por ejemplo, es solo incremental. Y en tercer lugar, y a propósito de lo que comentaré en este post, un proceso incremental NO solo lo es respecto de la construcción del producto, sino que también puede/debe serlo en su especificación.
En la figura A se observa una representación temporal de esfuerzo dedicado a especificación de requisitos (R) y a construcción (C) en lo que sería un modelo de proceso secuencial. En este modelo de proceso todo se especifica en detalle antes de comenzar la construcción, y no se pretende hacer ninguna entrega parcial hasta que no esté todo construido.

Rational Unified Process (RUP) es, en desarrollo de software, la metodología tradicional de referencia. RUP utiliza un modelo de proceso iterativo e incremental pero no por eso es una metodología ágil. En gran medida la clasificación de "Tradicional" para RUP se le otorga porque la mayor parte de la especificación se hace de forma anticipada (con o sin iteraciones), durante la llamada Fase de Elaboración, en la cual se realiza en detalle la especificación de requisitos, análisis y diseño del sistema para, posteriormente, en la Fase de Construcción, abordar iterativamente la construcción del producto. Como se muestra en la figura B lo que hace RUP diferente respecto de un enfoque secuencial es realizar la construcción de forma iterativa. Esto permite detectar posibles defectos de especificación u otros cambios necesarios al evaluar el resultado de cada iteración, sin embargo, la mayor parte del esfuerzo de especificación se concentra en la Fase de Elaboración. En la estrategia mostrada en la figura B no se considera explícitamente la posibilidad de cambios en los requisitos durante la construcción.

¿Pero es esta estrategia de desarrollo a su vez incremental? Scrum define que el resultado de un Sprint (iteración) debería ser una versión potencialmente entregable de un producto, debería ser un incremento del producto tal que en algún momento puede llegar a ser una entrega parcial que se pase al cliente para que la utilice. El solo hecho de realizar iteraciones no garantiza que se consigan incrementos del producto al finalizar cada iteración. Por ejemplo, en la Fase de Elaboración de RUP aunque se pueda realizar con iteraciones, éstas no darán como resultado un incremento del producto. Solo durante la Fase de Construcción de RUP se tendría la posibilidad de conseguir incrementos del producto puesto que en cada iteración se obtendrían requisitos implementados. Sin embargo, el planteamiento de RUP contempla solo una entrega al finalizar la Fase de Transición (después de la Fase de Construcción). 

Concentrar la mayor parte de la especificación del sistema al inicio está alineado con el establecimiento de un contrato a Precio-Fijo, ya que así, antes de comenzar la construcción, se puede conseguir un presupuesto que fije alcance, plazo y precio. Sin embargo, como ocurre en muchos proyectos, cuando el grado de incertidumbre es alto, por mucho tiempo que se le dedique a una especificación anticipada, esta no será eficaz pues probablemente habrá cambios durante el proyecto. Los cambios obligarán a rehacer especificaciones, descartar especificaciones por estar obsoletas, o que incluso requisitos ya especificados no alcancen a ser implementados (puede que simplemente pierdan prioridad respecto a otros nuevos no identificados inicialmente).

Mi impresión, por lo que he observado en empresas que dicen usar un Enfoque Ágil, es que su proceso se parece bastante al de RUP, ilustrado en la figura B. La especificación detallada mayoritariamente la hacen anticipadamente, junto a la firma del contrato. Es decir, al menos en este aspecto siguen siendo tradicionales :-).

¿Pero es factible que la especificación también se realice de forma incremental? ¿Es posible realizar un desarrollo incremental que incluya también una especificación incremental? ¿Sería esto compatible con una adecuada gestión de alcance y/o un contrato del tipo precio-fijo?

La respuesta es sí, es factible hacer una especificación incremental y alinearla con un proceso de construcción incremental. Para esto debemos diferenciar entre "identificar" requisitos y "especificarlos en detalle". Si queremos gestionar el alcance de de un proyecto es vital que tengamos identificados los requisitos involucrados en dicho alcance (al menos la mayoría y entre ellos los más importantes). Pero identificar un requisito es ponerle un nombre y poco más. Lo que sucede es que tenemos la natural tendencia a especificar anticipadamente un requisito porque queremos tener estimaciones que nos permita establecer el alcance y acordar un compromiso, no es porque lo necesitamos ya para implementar cada requisito. Pero la especificación detallada de un requisito se podría postergar en extremo hasta el instante justo antes de comenzar a implementarlo.

Veamos dos alternativas factibles de desarrollo incremental que incluye también especificación incremental. En la Figura C se presenta un proceso en el cual al comienzo y por un breve período se realiza una identificación de los requisitos (sus nombres y poco más), por eso este bloque inicial R tiene un color menos intenso. Después de esta breve identificación de requisitos se hace un ordenamiento estratégico de ellos, el cual corresponderá con su orden de implementación. A continuación, los requisitos que se implementarán primero se especifican en detalle y luego se implementan. Si además, este primer conjunto de requisitos tiene una orientación MVP (Mínimo Producto Viable) con su implementación podríamos ya tener una primera entrega parcial (primera realease). A partir de ahí, y posiblemente con ciertos espacios entre nuevos desarrollos de incrementos, se continuaría con el desarrollo del resto de requisitos en ciclos cortos de especificación detallada y construcción.

Pero ¿cómo podríamos firmar un contrato y gestionar el alcance durante el desarrollo si no tenemos una especificación detallada de los requisitos al inicio?. Si el equipo ejecutor tiene experiencia en cuanto a la solución que debe implementar no debería tener inconvenientes en realizar buenas estimaciones contando solo con requisitos identificados (sin mayor especificación). Pero si en el equipo no tiene dicha experiencia, lo cual incrementa la incertidumbre, aún así tendremos siempre tres apoyos respecto de las estimaciones. Primero, si hemos hecho un ordenamiento estratégico de los requisitos, probablemente los de mayor valor y/o riesgo serán los primeros en implementarse, pues entonces éstos serán inmediatamente especificados en detalle y se podrá tener un estimación más argumentada para ellos al inicio del desarrollo. Segundo, en situaciones de incertidumbre respecto de la estimación si se realizan estimaciones normales (ni pesimistas ni optimistas), probablemente las sub-estimaciones se compensarán globalmente con las sobre-estimaciones. Habría que tener demasiada mala suerte para que todas la estimaciones resulten estar por debajo de lo real :-). Tercero, en un caso puntual de imposibilidad para poder asignar una estimación a un requisito por inexperiencia técnica para implementarlo o poca claridad respecto a su definición, se puede hacer algún prototipo que ayude a reducir esa incertidumbre y poder dar una estimación, o incluso para ese requisito puntualmente hacer una especificación más detallada, lo suficiente para atrevernos a argumentar una estimación.

Una variación del modelo de proceso mostrado en la Figura C, más extrema en cuanto a la especificación incremental, se muestra en la Figura D. En este caso, con o sin una estrategia MVP, se realizan Sprints más cortos y se solapa la construcción del Sprint actual con la especificación detallada de lo que se implementará en el siguiente Sprint. Esto se hace hasta conseguir una primera release. A partir de allí se podría seguir con dicho solapamiento, o realizar Sprints no continuos según el ritmo posterior de desarrollo o mantenimiento que requiera el producto. 

Lo importante es tener en cuenta que existen alternativas y variantes sobre ellas. La elección del modelo de proceso debe estar basada en el contexto de desarrollo de cada producto. Las ventajas de los modelos iterativos e incrementales (y que además incluyen especificación incremental) son mucho mayores cuando el contexto nos hace prever cambios durante el desarrollo. 

Lecturas recomendadas: 

Modelos de proceso para desarrollo ágil.

Desarrollo Iterativo versus Incremental ... o ¿cuál es la mejor estrategia para pintar la Mona Lisa?.

Patricio Letelier

twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com 

Tableros kanban en dos niveles: desde pedidos de una pizzería a gestión de portafolio

Advierto que este post no va de cómo se cocinan los proyectos :-), sino de unas interesantes analogías entre la gestión de pedidos en una pizzería y un portafolio de proyectos respecto de trabajar con tableros kanban sincronizados, en este caso tableros en dos niveles, un kanban general (pedidos de pizzas o portafolio de proyectos) y otro kanban detallado (pizzas y trabajo dentro de un proyecto).

Arranquemos con el ejemplo de la pizzería donde se reciben pedidos de pizzas. Un pedido puede incluir una o más pizzas de diferente tipo y tamaño (por ejemplo, pedido del Sr. Pérez: 2 margaritas medianas y una cuatro estaciones grande). Supongamos que en el trabajo de la pizzería para atención de sus clientes se identifican las siguientes actividades: Tomar Pedido, Preparar Masa, Añadir Ingredientes, Hornear, Armar Pedido y Entregar. El siguiente tablero kanban podría servir para visualizar el estado del trabajo.

Pero la pregunta clave es ¿qué ítems son los que aparecen en el kanban? ¿Representan los pedidos de pizzas o cada una de las pizzas de los pedidos?. Hay algunas columnas que delatan que el trabajo se hace a nivel de pedido (por ejemplo: Tomar "Pedido" o Entregar "Pedido") y otras en las que el trabajo se hace a nivel de pizzas (por ejemplo, Añadir Ingredientes). Claramente hay dos perspectivas del proceso, de cara al cliente es importante saber cómo va la elaboración de su pedido como un todo, y desde el punto de vista del trabajo interno de la pizzería lo que se manejan son pizzas. Entonces las alternativas de ítems a utilizar en nuestro tablero kanban serían: Pedidos, Pizzas (de un pedido) o incluso Pedidos y Pizzas (ambos tipos de ítems). Veamos las ventajas e inconvenientes de cada alternativa:

• Ítems=Pedidos: Es más sencillo conocer el estado del pedido. Es más fácil la gestión de información pues siempre habrá menos pedidos que pizzas con lo cual el tablero tendrá menos ítems. Sin embargo, físicamente todas las pizzas del pedido deberían estar en la misma actividad a la vez (en la actividad que esté su Pedido) o tener algún truco para indicar que un pedido está en más de una actividad.
• Ítems=Pizzas: Puede ser más difícil de gestionar el pedido pues las pizzas como ítems podrían estar en diferentes actividades, pero deben entregarse todas en conjunto (y calientes :-) ). Además, podemos llegar a tener muchos ítems en el tablero.
• Ítems=Pedidos y Pizzas: Podría pensarse como una solución más detallada que combina algunas ventajas de las dos anteriores y aparentemenre reduciría sus inconvenientes, pero puede ser peor esta alternativa porque hay que gestionar dos típos de ítems a la vez y conjuntamente (el ítem Pedido y sus ítems Pizzas).

Probablemente ninguna de las alternativas anteriores resultará del todo cómoda pues lo que hay detrás de esta situación es que estamos mezclando dos niveles de trabajo (Pedidos y Pizzas incluidas en los pedidos). El trabajo y la gestión de ambos debe estar coordinado pero probablemente es más sencillo y fácil de gestionar si se representan estos dos niveles como dos tableros kanban coordinados. La siguiente figura muestra un ejemplo de lo que podrían ser estos dos tableros kanban.

Como en el kanban detallado tendremos pizzas de diferentes pedidos, deberíamos contar con un mecanismo para diferenciar los ítems e identificar fácilmente cuáles son de un mismo pedido (por ejemplo, con colores o etiquetas). En cualquier caso, y ya poniéndonos en terreno, sea cual sean los tableros e ítems utilizados, las pizzas en la cadena de producción normalmente se acompañan del ticket del pedido durante todo el proceso, y son los encargados quienes van verificando el avance en conjunto de todas las pizzas del pedido.

Una vez explicada la situación de la pizzería, llevémoslo al contexto de un portafolio de proyectos. En organizaciones con un cierto grado de madurez en la gestión de sus proyectos es normal que tengan definido un flujo de trabajo para sus proyectos, que incluya estados tales como: Propuesto, En Evaluación, En Ejecución, Cerrado, etc.. Los nombres y el detalle de estado pueden obviamente ser diferentes. Sin embargo, estos estados corresponderían con las columnas del tablero kanban que ilustraría el estado de los proyectos (el estado del portafolio de proyectos), es decir, sería un equivalente a los pedidos de la pizzería. Y además, la columna "En Ejecución" estaría detallada en otro(s) tablero(s) kanban que representarían el estado de ejecución de cada uno de los ítems en los proyectos. Por ejemplo, si fuera un proyecto de desarrollo de software el tablero kanban detallado (el equivalente al de las pizzas) contendría ítems del tipo Nuevo Requisito, Mejora o Corrección de fallo, y las actividades serían del tipo Especificación, Programación, Pruebas, etc. Así, en algún momento los ítems de un proyecto se terminan y el proyecto como un todo (en el kanban de proyectos) saldría del estado "En ejecución" pasando al siguiente estado en el kanban de portafolio. Tal como en el caso de las pizzas, los ítems de cada proyecto deberían poder distinguirse o filtrarse fácilmente (para evitar tener un kanban para cada proyecto).



Patricio Letelier

twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com

www.tuneupprocess.com 

Sprints, "welcome to the real world" ...

Un Sprint es un contenedor/agrupador de ítems de trabajo que se implementan en un período de tiempo. El uso de Sprints se ha convertido casi en sinónimo de estar aplicando Scrum. Pero Scrum es bastante más que el solo concepto de Sprint. Además, el modelo de proceso iterativo e incremental no es una exclusividad de Scrum, también está presente en otros métodos ágiles, aunque en lugar de Sprint se utilizan el término Iteración. Incluso RUP, una metodología tradicional, sigue un proceso iterativo e incremental claramente basado en iteraciones. También se suele contraponer Scrum y Kanban en cuanto a usar o no usar Sprints. Vistos como métodos, Kanban no cuenta con el concepto de Sprint, y Scrum en su propuesta original no dispone de un tablero para visualizar el estado del trabajo (tablero kanban). Sin embargo, desde la perspectiva de prácticas ágiles, el uso de dicho tablero es fundamental siempre, y el uso (opcional) de Sprints es un excelente complemento para la organización del trabajo (lecturas recomendadas: ¿Kanban o Scrum?: that is not the question y Tableros kanban. Parte II: Diseño de tablero kanban para aplicarlo con Scrum).

En este post me centraré en ilustrar algunas variantes del concepto de Sprint en su aplicación en diferentes contextos de trabajo. Tener presente estas variantes es muy importante para hacer una buena adaptación metodológica al contexto de trabajo. Sin embargo, tampoco habría que desestimar la opción "cero", que sería simplemente NO usar Sprints :-). Pero de aquí en adelante en este post asumo que estamos en un contexto donde sí que es conveniente usar Sprints.  

En Scrum el concepto de Sprint es protagonista, aunque si no usáramos Sprints todavía tendríamos de Scrum otras prácticas ágiles que son muy interesantes, tales como: equipo auto-gestionado, equipo crosss-functional, los roles de Scrum, etc. Aunque básicamente un Sprint es una iteración, en Scrum establecen las siguientes características específicas:

• Debe dar como resultado un incremento potencialmente entregable del producto.
• No debería durar más de 4 semanas.
• Debería comenzar apenas se termine el Sprint anterior.
• Contiene ítems cuya suma de esfuerzo estimado debe ser coherente con la Capacidad del equipo. 

Estas características son sencillas y sensatas, pero al usar Sprints en un contexto específico suelen aparecer dudas, algunas de las cuales comento a continuación:

Contenido de los Sprints

• A priori, se esperaría que al usar Sprints los ítems que se van a implementar en un Sprint estén predeterminados, ya que asumimos que el contexto de un Sprint es el de trabajo planificable (se conoce anticipadamente qué se hará en el Sprint). Además, durante el Sprint no debería haber demasiada presión por añadir ítems adicionales, considerando que su duración es de unas pocas semanas. El cliente puede que no vería resuelto su nuevo ítem al finalizar el Sprint actual, pero si dicho ítem tiene suficiente prioridad podrá incluirse en el siguiente Sprint. Sin embargo, si hay cierta urgencia se podría añadir el nuevo ítem al Sprint quitando otro equivalente en esfuerzo y que aún no haya sido implementado. 
• Por otra parte, los Sprints pueden ser útiles en contextos NO planificables, es decir, donde no se conoce con exactitud qué trabajo se realizará en las próximas semanas. En estos casos el Sprint permite agrupar ítems de trabajo, aunque el contenido no será definitivo hasta que no se dé por terminado el Sprint. Por ejemplo, en un contexto de mantenimiento de un producto, al comenzar un Sprint se podría en extremo iniciarlo vacío, y en la medida que se van terminando ítems se van incluyendo (ya terminados) en el Sprint. Luego, en algún momento se decide cerrar el Sprint con el contenido de ítems terminados en ese instante. Otro escenario posible sería incluir en el Sprint un conjunto de ítems candidatos y que luego, cuando se considere conveniente, se terminaría el Sprint solo con los ítems terminados, y el resto de ítems se devolverían al Backlog para competir con otros ítems candidatos para el siguiente Sprint.

Regularidad de los Sprints

• Tener Sprints de la misma duración genera una sana rutina de trabajo para el equipo. Esto además facilita el cálculo de la Capacidad del equipo, es decir, facilita el conocer cuántos Puntos u Horas Ideales (o cualquier otra unidad de medida que se utilice) podría abordar con éxito el equipo en un Sprint. 
• Por otra parte, si durante el Sprint se detecta que no será posible terminar todos los ítems podría optarse por alargar el Sprint. Si esto se hace de forma habitual puede llevar a una relajación o falta de compromiso del equipo. Suele ser más recomendable terminar el Sprint en la fecha prevista y tomar oportunamente las acciones necesarias respecto a decidir qué ítems no se llegarán a terminar, o incluso para aquellos ítems ya comenzados crear un nuevo ítem que incluya el trabajo no realizado permitiendo así terminar el ítem original solo con la parte del trabajo ya hecha.
• Hay situaciones en las cuales la demanda de trabajo no es previsible y fluctúa de forma importante. Por ejemplo, en un contexto de mantenimiento podemos pasar por períodos de mucho trabajo (después de una entrega de una versión con cambios importantes), y otros en los cuales hay poca demanda. En esta situación aún podría ser útil usar Sprints como agrupador, pero en este caso los Sprints podrían no ser ni continuos ni de la misma duración.
• En cuanto al tamaño de los Sprints, ¿cuál es el tamaño aconsejable (considerando que no deben ser de más de 4 semanas)?. Mientras menos duración tengan los Sprints más frecuentemente podremos evaluar la buena marcha del trabajo. Sin embargo, el arranque y cierre de cada Sprint conlleva un esfuerzo (costes de transacción), y debe evaluarse hasta qué punto compensa realizarlo tan frecuentemente. Me refiero a actividades tales como las reuniones de planificación y de revisión del Sprint, el posible despliegue de la versión, pruebas (y especialmente pruebas de regresión), formación de usuarios, actualización de manuales, etc. Para un contexto nuevo de trabajo (nuevo en cuanto a los miembros del equipo, la tecnología utilizada, el dominio de aplicación, etc.) mi recomendación es comenzar con Sprints más bien pequeños, de 1 a 2 semanas, con el propósito de que el equipo aprenda y se adapte rápidamente. Luego, en un régimen de trabajo más estable recomendaría pasar a Sprints de 3 semanas. No me gustan los Sprint de 4 semanas y menos cuando se corresponden con meses de calendario pues prefiero que exista mayor atención (o inquietud) respecto a qué semana se termina un Sprint :-). 

Preparación de los ítems de cada Sprint

• Para poder tener cierta garantía de cumplir con la implementación de los ítems incluidos en el Sprint debería existir coherencia entre la Capacidad del equipo y el esfuerzo requerido. Pero para hacer estimaciones de dicho esfuerzo con cierta precisión es necesario definir qué involucra cada ítem, es decir, saber cuáles son los requisitos asociados al ítem. Cada ítem necesita una "preparación", es decir, tareas relacionadas con la definición, especificación, validación, diseño y estimación (entre otras). Así pues, cada ítem del Sprint debería estar preparado antes de comenzar el Sprint. De esta forma, durante el periodo del Sprint el trabajo consistiría básicamente en implementar y probar cada ítem. La preparación de ítems de un próximo Sprint se debería hacer en paralelo a la implementación del Sprint actual. Particularmente, podría dejarse dicha preparación hacia el final del Sprint actual, cuando se va extinguiemdo el trabajo del Sprint actual y los miembros del equipo que vayan quedando sin trabajo en el Sprint actual puedan dedicarse a la preparación de ítems del Sprint siguiente. El caso extremo sería esperar a realizar toda la preparación en la Reunión de Planificación del Sprint, para la cual Scrum propone una duración de 8 horas (para un Sprint de 4 semanas). La razón de dichas 8 horas es precisamente porque se asume que los ítems que se incluirán en el Sprint podrían aún no estar preparados.
• Si hay ítems incluidos en el Sprint y que no están preparados al comenzar el Sprint puede deberse a que simplemente no alcanzaron a ser preparados, y se tendrán que ir preparando durante el Sprint con el ruido que esto conlleve en la marcha del Sprint. También esa situación podría corresponder a una decisión estratégica para abordar un ítem de cierta complejidad, entremezclando su preparación e implementación, llevando al extremo el desarrollo incremental de dicho ítem. Obviamente, cuando no todos los ítems del Sprint están preparados y estimados hay más incertidumbre respecto a si se terminarán todos los ítems en la fecha de fin del Sprint.

Número de Sprints abiertos simultáneamente

• En ediciones anteriores de la Guía de Scrum (scrumguide.org) se hablaba de la Release Planning Meeting, la cual consistía en establecer previamente cuáles serían los Sprints que conformarían una Release (Entrega). Por ejemplo, si teníamos una Release comprometida en 6 meses, podríamos planificar el contenido de 8 Sprints de 3 semanas cada uno hasta conseguir dicha Release. Sin embargo, muchas veces la dinámica del contexto de trabajo usualmente tira por tierra cualquier intento de planificación detallada a mediano o largo plazo. Por esto es más eficaz trabajar con un Backlog bien gestionado y ordenado, y luego a partir de él ir estableciendo solo el Sprint siguiente. Sin embargo, en la medida que se va extinguiendo el trabajo del Sprint actual podría abrirse ya el nuevo Sprint, aunque no necesariamente para comenzar a implementar sus ítems, sino solo como contenedor de los ítems candidatos que se están preparando para ese próximo Sprint. 
• Otra situación en la cual puede ser útil tener varios Sprints abiertos, e incluso implementándose en paralelo, es cuando tenemos equipos diferentes trabajando sobre el mismo producto. Podría tratarse que equipos trabajando en diferentes áreas o subsistemas, equipos trabajando en mantenimiento o en desarrollo, etc. En esas situaciones puede que además sea conveniente que cada línea de trabajo tenga su propio Backlog y planificación de Sprints (aunque se trate del mismo producto). Indudablemente en estos casos se requiere una buena coordinación del entre los equipos involucrados.

Como hemos visto, el término Sprint da para mucho más de lo que plantea Scrum. En las implantaciones del enfoque ágil en las cuales he participado me ha resultado útil referirme a "Sprints" (a secas) cuando hablo de Sprints tal como los plantea Scrum, y usar el término "Sprints Flexibles" cuando hablo de Sprints que tienen alguna consideración especial de entre las comentadas antes. Los Sprints Flexibles son un aspecto clave para conseguir una conveniente adaptación de un proceso iterativo e incremental al contexto de trabajo de un equipo. No es necesario renunciar al uso de Sprints cuando no es posible aplicarlos tal como los plantea Scrum. Eso sí, un Sprint no es tal si no da como resultado un incremento del producto o si dura demasiado (orientativamente, más de cuatro semanas), estos dos aspecto son esenciales. Por otra parte, cuando existe una demanda constante de trabajo sobre un producto no hay excusas para no mantener una sana regularidad de duración (la misma duración) y continuidad (uno tras otro) de los Sprints.

Finalmente, y muy importante que cualquier decisión asociada a los Sprints (y otros aspectos de organización del trabajo) debe tomarse considerando las características de cada línea de trabajo, pues puede haber diferencias significativas entre una y otra. Aplicar de forma uniforme una decisión siempre es lo más sencillo, pero suele ser muy ineficaz cuando hay diferencias importantes entre las líneas de trabajo. Cuando digo "línea de trabajo" me refiero al desarrollo, mantenimiento o soporte, de un producto o de un servicio. No es lo mismo un contexto de desarrollo planificado respecto de uno de mantenimiento continuo, o de uno de soporte (donde no podemos prever el trabajo que llegará en las próximas semanas), incluso tratándose del mismo producto o servicio sus líneas de trabajo en general requieren un tratamiento particular. Lectura recomendada: Gestión ágil de productos. Líneas de trabajo en un producto a partir de su primera entrega.



Patricio Letelier

twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com

www.tuneupprocess.com 

"Flecos" de implementación y gestión ágil de proyectos

Para implantar métodos que resulten eficaces hay que entender la naturaleza de la construcción de software. Teóricamente, desde el punto de vista técnico, si disponemos de cierto tiempo podremos preparar (definir, diseñar y estimar) adecuadamente el trabajo que se va a implementar (programar y probar), de tal forma que una vez hecha dicha implementación ésta sea totalmente satisfactoria, que no se requiera trabajar más en ella. Sin embargo, por una parte, la certeza en cuanto a corrección y completitud de dicha preparación no suele ser muy alta, y por otra, cuando el cliente ya puede interactuar con algo tangible suele desear mejoras :-). Esto hace que desde unos requisitos ya implementados aparezcan "Flecos"; mejoras (o incluso fallos) que corresponden a una continuación del trabajo iniciado por un ítem (Historia de Usuario) que ya dábamos por terminado. Aunque los flecos incomoden, es más importante saber gestionarlos que conseguir que no aparezcan (objetivo difícil de conseguir en desarrollo de software). Además, una estrategia puramente ágil, centrada en el desarrollo incremental, promueve los flecos y su gestión. Esta inconveniencia se amortiza con creces en comparación con una estrategia tradicional. Solo desde el punto de vista de la especificación ya estamos evitando el "Análisis-Parálisis", un problema mucho más grave (lectura recomendada: ¿Análisis-Parálisis o No Análisis?. MVP la respuesta razonable).

Para gestionar dichos flecos una opción sería continuar (o reabrir) el mismo ítem original para extenderlo con los flecos que se van detectando. Esta alternativa no es recomendable porque no permite fácilmente distinguir entre lo ya realizado y lo pendiente (asociado a los flecos). Además, psicológicamente no es bueno que se trabaje en algo de forma muy prolongada sin terminarlo (o reabriéndolo una y otra vez). Así pues, recomiendo que los flecos siempre se representen con nuevos ítems dando por terminado el ítem original o los flecos ya abordados. Además, si los flecos están representados como ítems por separado pueden competir individualmente por prioridad con otros ítems, es decir, los flecos puede que ya no sean prioritarios cuando los contrastamos con todo el trabajo pendiente. Así pues, los flecos deberían tener una trazabilidad del tipo "es continuación de" o similar con respecto al ítem original.

Esta naturaleza imperfecta pone en jaque a una mentalidad tradicional para construir software, en la cual, un ítem se prepara y se implementa con la idea de ser terminado al primer intento, sin flecos :-). Si desde una perspectiva ágil además añadimos mucha interacción con el cliente, entregas frecuentes, reuniones de revisión, desarrollo incremental, etc., se desata tempranamente la identificación de flecos, especialmente cuando se trata de requisitos implementados y ya entregados, y más aún si esos requisitos tienen cierto éxito entre los usuarios (por ser muy apreciados y/o porque se utilizan con mucha frecuencia).

En la siguiente figura se ilustra cómo en un proceso iterativo e incremental el trabajo se va preparando e implementando incrementalmente. Obviamente en un desarrollo de un nuevo producto hay un breve período inicial de establecimiento del Backlog con la identificación de ítems y la preparación de los que se implementarán en el primer Sprint. A partir de allí la preparación se repite para cada siguiente Sprint, pero a partir del término del primer Sprint ya podríamos estar detectando flecos. Estos flecos aparecerán como ítems en el Backlog y según su prioridad se irán incorporando en los siguientes Sprints como ítems de mejora o de corrección de fallo. Así pues, la implementación de nuevos requisitos no se concentra toda en una fase inicial, ni tampoco la implementación de los flecos tiene que ser relegada a una fase más hacia el final.

Un enfoque ágil promueve la aparición temprana de flecos y su gestión como nuevos ítems que deben ser priorizados. Esto que parecería algo negativo (y lo es en un sentido tradicional) pues representa cambios no previstos, pero resulta ser una gran ventaja ya que los flecos se detectan y gestionan tempranamente.

Cuando afirmamos que con un enfoque ágil se gestionan mejor los cambios, en gran medida nos referimos a dicha identificación y gestión de los flecos de implementación (lectura recomendada: ¿Por qué un enfoque ágil permite gestionar mejor los cambios en un proyecto?). Obviamente los flecos y cambios en general nos incomodan, pero esto hay que valorarlo con una visión global del proyecto, ya que su detección y gestión tardía probablemente comprometería el éxito del proyecto. Más aún, el hecho que los flecos compitan con otros ítems pendientes ofrece la oportunidad para que el cliente discrimine entre lo esencial y lo prescindible de cada uno de los requisitos. El cliente podría ir interactuando con versiones parciales/incompletas pero tangibles (implementadas) del requisito, hasta el punto que considere que se ha alcanzado "un MVP" del requisito, lo cual dejaría espacio para la implementación de otros requisitos que de otra forma se habrían descartado por falta de capacidad o tiempo para implementarlos.

Asumir que existirán cambios y gestionarlos conlleva prestar atención continuamente al alcance del proyecto  (lectura recomendada: Gestión del Alcance en un Proyecto Ágil ) y correspondientemente negociar con el cliente. Una medida preventiva para abordar un margen de cambios imprevistos es considerar un Buffer de Capacidad para proyectos ágiles.



Patricio Letelier

twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com 

Una estrategia MVP para abordar Épicas

Una Épica es un ítem "grande" (y/o complejo) que supone un importante esfuerzo para terminarlo. Pero ¿de qué  tamaño de esfuerzo estamos hablando? y ¿por qué tenemos que prestar atención especial a las Épicas?. En cuanto a tamaño me refiero a un ítem que, una vez definido y estimado, en su ejecución (básicamente su implementación y pruebas) se necesitaría más de una semana de trabajo. Uso este tamaño orientativo para una Épica porque un período de una semana, desde que se encarga la ejecución de un ítem al equipo hasta cuando lo termina, es un período "saludable", así no se arrastra trabajo sin terminar de una semana a otra. Además, si trabajamos con Sprints de 2 o tres semanas de duración es razonable que un ítem no cope gran parte de dicha duración, dejando espacio para otros ítems y haciendo más visible el progreso del trabajo medido en ítems terminados.

Las Épicas son más usuales cuando se comienza a construir un producto o cuando se hace una extensión importante de un producto existente. Esto es así porque con los nuevos requisitos tenemos una tendencia natural a ser ambiciosos en cuanto a funcionalidad, y más aún, para conseguirla toda a la vez :-). Las mejoras (de requisitos ya implementados) y correcciones de fallos no suelen caer en categoría de Épicas.

En la siguiente figura se presentan 4 alternativas para enfrentar Épicas, haciendo analogía (un poco forzada) con lo que sería enfrentarnos zanparnos mucha comida.

En la imagen superior izquierda se ilustra la opción por defecto, no hacer nada en especial para abordar una Épica, asumiendo que se tardará un tiempo importante en terminarla y que esto puede conllevar inconvenientes. En la imagen superior derecha, aunque se mantiene la Épica como un solo ítem, éste se aborda colaborativamente, por ejemplo, dos o más desarrolladores trabajando a la vez en en la Épica. Esto haría posible terminar la Épica en un tiempo más corto y evita complicaciones que pueden surgir por dividir la Épica en ítems más pequeños. Esta opción es aconsejable cuando la Épica no es muy grande, es decir, cuando abordada colaborativamente sí que es posible terminarla dentro de una semana de trabajo.

La imagen de abajo a la izquierda ilustra dicha división de la Épica en ítems más pequeños. La división de una Épica en varios ítems es atractiva cuando se pueden abordar en paralelo varios de esos ítems. Pero el hacer trabajo en paralelo se ve obstaculizado cuando los ítems no son bastante independiente debido a las dificultades de coordinación e integración que puede conllevar la terminación dichos ítems.  Otro importante inconvenientes es que al dividir la Épica podemos estar perdiendo la oportunidad de identificar lo esencial respecto de lo secundario, es decir, no cuestionar si es imprescindible implementar toda la Épica.

La opción de abajo a la derecha, intenta ilustrar que en lugar de zamparnos gran cantidad de comida a la vez, que lo mejor es hacerlo de forma progresiva y estratégicamente organizado para una dieta equilibrada. Esta es la opción más alineada con un enfoque ágil auténtico, pero siempre que se lleve a cabo con una orientación de MVP (Minimun Viable Product). Desarrollar una Épica con orientación MVP significa desarrollarla incrementalmente, paso a paso, poniendo el primer objetivo en una implementación mínima pero satisfactoria para una determinada versión del producto. Es decir, tal como se aplica MVP a nivel de producto como un todo, aplicarlo a nivel de una Épica. En la práctica esto conlleva discriminar entre lo esencial y lo secundario de la Épica. En términos de división de la Épica, solo necesitamos establecer dos ítems; uno como primera versión de la Épica y otro representando el "resto" de la Épica. Si trabajamos con Sprints el ítem primera versión se incluye en el Sprint y el "resto" se mantiene en el Backlog. Una vez terminado el ítem correspondiente a la primera versión MVP de la Épica el proceso puede repetirse con el ítem "resto" de la Épica. Esto continuaría hasta que se consuma y termine todo el trabajo restante de la Épica o hasta que el "resto" ya no sea tan prioritario en comparación con otros ítems pendientes. Es precisamente esta última situación la gran diferencia respecto de una división temprana del una Épica en varios ítems. Cuando se desarrolla incrementalmente una Épica, todo su desarrollo puede ser incremental, es decir, no es necesario definir en detalle toda la Épica, sino solo el MVP que se va a implementar inmediatamente (lectura recomendada: ¿Análisis-Parálisis o No Análisis?. MVP la respuesta razonable).  


Patricio Letelier

twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com 

Buffer de Capacidad para proyectos ágiles

En un contexto de proyecto con rigidez en los tres elementos del triángulo de hierro: alcance, plazo y costo, surge la necesidad de una planificación y seguimiento (más) cuantitativo. El enfoque ágil muchas veces es descartado en estos contextos por la creencia errónea que la planificación y el seguimiento ágil no generarán dicha información cuantitativa. Un enfoque ágil, impregnado de la filosofía Lean, evitará todos los elementos prescindibles en el proceso, con lo cual podría prescindirse de la recolección y el procesamiento de información cuantitativa, pero solo cuando ésta no se aproveche adecuadamente. Muchas veces se somete a los equipos a un registro y reporte de datos que no es rentabilizado ni por el equipo ni por los niveles de supervisión.

¿De qué información cuantitativa estamos hablando?. Esencialmente necesitamos tres elementos: la Estimación del Esfuerzo del trabajo, el Esfuerzo ya Invertido y la Capacidad del equipo que ejecuta el trabajo. Un cuarto elemento derivado de lo anterior es el Esfuerzo Restante = Estimación de Esfuerzo - Esfuerzo ya Invertido.

Dependiendo de las necesidades de gestión de una determinada línea de trabajo, desde una perspectiva ágil podría ser válido y eficaz cualquiera de los siguientes niveles de gestión (desde el más simple al más exigente):

1. Centrarse solo en la generación de un buen flujo de trabajo terminado, SIN usar Estimación NI Capacidad. En esta opción probablemente no se utilizarían Sprints pues su uso conlleva de forma natural alguna de las otras opciones que se plantean a continuación.
2. Usar el Esfuerzo Restante establecido directamente (NO como la diferencia entre Estimación y Esfuerzo Invertido) y Capacidad. 
3. Usar Estimación y Capacidad del equipo usando como unidad Puntos (u otra medida similar que represente el tamaño de las unidades de trabajo de forma global).
4. Usar Estimación, Esfuerzo Invertido y Capacidad del equipo usando Horas Ideales (horas de trabajo ininterrumpido, NO horas de contrato). Al trabajar con Horas Ideales debemos indicar de la actividad que se trata, por ejemplo, Horas Ideales de Programación (HIP).

Excepto en la opción 1, en las otras tres sería posible responder cuantitativamente la pregunta ¿llegaremos a cumplir el compromiso de alcance-tiempo-costo? En 2, 3 y 4 el equipo conoce su Capacidad y puede con ello calcular a partir de cualquier día del proyecto cuánto trabajo puede abordar desde ese momento hasta el final del proyecto. Además, el equipo puede también conocer en cualquier día del proyecto cuánto es el esfuerzo necesario para abordar el trabajo restante. Por ejemplo, supongamos un equipo tiene una Capacidad mensual de 200 HIP y va a abordar un proyecto cuyo esfuerzo total está estimado en 800 HIP. Podríamos afirmar que a día de hoy (y respecto de las HIP) parece factible realizar dicho proyecto en 4 meses (4 * 200 = 800). Supongamos que más adelante, finalizando el segundo mes del proyecto comprobamos que el trabajo restante es de 500 HIP. Si la Capacidad del equipo sigue siendo 200 HIP por mes, concluiríamos que en ese momento que con esa Capacidad no podríamos terminar el proyecto en dos meses.

Haríamos un razonamiento similar al usar Puntos en lugar de Horas Ideales, es decir, comparando el Esfuerzo Restante respecto de Capacidad disponible, pero en este caso ambos datos medidos en Puntos (es una medida del tamaño de las unidades de trabajo, medida relativa a una unidad de trabajo usada como referencia).

Hasta aquí todo claro y de muy sencillo cálculo. Pero ¿qué pasa con los cambios que se presenten durante el proyecto y que conlleven un aumento del esfuerzo total asociado al proyecto?. La primera solución sería negociar oportunamente con el cliente una reducción de alcance del proyecto para conseguir una reducción de esfuerzo equivalente a los cambios que han surgido. Como no todos los requisitos son igual de importantes o esenciales, el cliente podría postergar aquellos requisitos relativamente prescindibles (dejándolos fuera del alcance del proyecto). Otra posible opción incluso más recomendable es estudiar si en los requisitos más "grandes" se puede hacer una reducción estableciendo una parte como primera versión (y dentro del alcance del proyecto) y el resto como un trabajo postergado fuera del proyecto. Sin embargo, puede que el cliente llegue a un punto en el cual ya no está dispuesto a reducir más el alcance del proyecto, y que tampoco sea factible aumentar los plazos/costos del proyecto. Para evitar esta situación límite sabemos que en proyectos en los cuales se presentarán cambios es conveniente tener una determinada holgura. A continuación veremos una forma ágil de establecer y gestionar dicha holgura.

En un proyecto gestionado de forma ágil deberían descubrirse tempranamente los cambios especialmente los de gran impacto pues en los primeros Sprints nos preocuparemos de abordar el trabajo más importante y valioso para el cliente, así como aquello que pueda conllevar mayor riesgo. Además, se asume que al revisar cada versión resultante de un Sprint se detectarán cambios, asociados a fallos o mejoras que probablemente deban ser considerados dentro del alcance del proyecto. Así pues, con las reuniones de revisión al final de cada Sprint y con las entregas frecuentes se fuerza desde el comienzo del proyecto la aparición de esos posibles cambios. Pero la solución (fácil) no siempre podrá ser quitar o reducir el alcance del proyecto.

Un buffer nos permitirá abordar los cambios sin que ello suponga reducir el alcance de un proyecto durante su ejecución (y manteniendo su costo y plazo). La idea es sencilla, al planificar el proyecto reservar un porcentaje de la Capacidad del equipo para los eventuales cambios. Por ejemplo, si reservamos un 20% de Capacidad para dicho proyecto de 4 meses lo abordaríamos como si se tratase de un proyecto de 1000 HIP, con lo cual tendríamos un margen de 200 HIP. Es decir, un proyecto que teóricamente podríamos terminar en 4 meses lo planificamos para 5 meses.

La siguiente gráfica Burndown ilustra la reducción ideal del esfuerzo restante (línea naranja) durante un proyecto. Se comienza con el esfuerzo restante total de 800 HIP y a a medida que avanza el tiempo del proyecto se esperaría que el esfuerzo restante converja a 0 al final del cuarto Sprint.

Sin embargo, la línea roja ilustra una evolución más real del esfuerzo restante en un proyecto en el cual surgen cambios, particularmente detectados en las reuniones de revisión al finalizar cada Sprint. Como se observa, al final de cada Sprint es normal que aparezcan "flecos", es decir, nuevas UT que representan pequeñas mejoras e incluso fallos. 

Si no contamos con holgura nos veríamos obligados a negociar constantemente con el Product Owner buscando una reducción de alcance, extensión de plazos y/o aumento de costos. Previendo esos usuales "flecos" podemos establecer un buffer de Capacidad/Tiempo que nos permita abordarlos y reservar las negociaciones para cambios que sean más significativos. Así, volviendo al ejemplo de antes, en la siguiente figura se ilustra el mismo proyecto, pero ahora planificado a 5 meses, con lo cual contamos con un buffer de Capacidad/Tiempo de un 20%, ya que conseguimos una Capacidad disponible de 1000 HIP mientras el esfuerzo inicialmente previsto es de 800 HIP.  

El buffer es del proyecto como un todo, no se debería establecer un buffer para cada unidad de trabajo ya que lo usual es que las diferencias entre los esfuerzos reales invertidos y los estimados de unas y otras unidades de trabajo se anulen entre sí en cierta medida. Es decir, finalmente en algunas unidades de trabajo se requiere más esfuerzo del estimado inicialmente y en otra menos. El buffer global debería cubrir la desviación de forma más eficiente que si cada unidad de trabajo tuviese su propio buffer.

Finalmente, podría pensarse que actuando de esta forma no habría mucha diferencia con respecto a un proyecto gestionado de forma tradicional en el cual también se establezca un buffer. Pero la diferencia existe y es significativa, en un proyecto tradicional se tienen muy pocas o ninguna evidencia del consumo del buffer hasta que el proyecto está muy avanzado pues precisamente los cambios tienden a detectarse al final del proyecto, donde se concentran las actividades de pruebas.

Otras lecturas relacionadas:

• ¿Por qué un enfoque ágil permite gestionar mejor los cambios en un proyecto?
• "Seguimiento ágil: Dashboard global para contextos multi-proyecto".
• "7 diferencias entre una planificación tradicional y una ágil"  
• "Estimación en un proyecto ágil, Parte I: Una estrategia pragmática"
• "Estimación en un proyecto ágil, Parte II: Algunas diferencias respecto de estimación tradicional"

Patricio Letelier

twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com