lunes, 24 de abril de 2017

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).
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 horas ideales de programación y va a abordar un proyecto cuyo esfuerzo total está estimado en 800 horas ideales de programación. Podríamos afirmar que a día de hoy (y respecto de las horas de programación) 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 horas ideales de programación. Si la Capacidad del equipo sigue siendo 200 horas ideales de programación 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 que puede estudiarse junto con la anterior es que en los requisitos más "grandes" se pueda 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 condsiderados 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 horas ideales de programación, con lo cual tendríamos un margen de 200 horas ideales de programación. Es decir, un proyecto que teóricamente podríamos terminar en 4 menos lo hemos planificado para 5 meses.

La siguiente figura ilustra la reducción ideal del esfuerzo restante durante un proyecto, la cual convergería a 0 al obtener la versión resultante del quinto Sprint. Como se observa en la figura más abajo (en la línea amarilla) si abordamos un alcance de proyecto equivalente a 800 horas ideales de programación con nuestra de 200 horas ideales de programación deberíamos terminar al final del cuarto Sprint.


Sin embargo, lo normal es que después de cada Sprint los cambios que surjan provocarán un repunte del esfuerzo restante. Si disponemos de un buffer de un tamaño adecuado podríamos asumir dichos cambios sin tener que cambiar los plazos ni renunciar a requisitos o cambios imprescindibles. La siguiente figura ilustra cómo con el buffer, y abordando los cambios que se detectan al final de cada Sprint, aun el proyecto llegaría a completarse en el tiempo previsto.

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, 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:




Patricio Letelier

viernes, 21 de abril de 2017

Gestión ágil de productos. Líneas de trabajo en un producto a partir de su primera entrega

Un tema escasamente tratado en la literatura ágil es cómo abordar adecuadamente la gestión del trabajo de un equipo en contextos "multi-proyecto". Desde el punto de vista ágil, no es una situación ideal pues implica distribuir la capacidad del equipo y asumir una degradación del desempeño por los posibles cambios de contexto que deberá hacer el equipo para enfrentar varias líneas de trabajo simultáneamente. Desgraciadamente en muchas empresas esta situación existe y es difícil de cambiar, no todas las empresas pueden permitirse tener equipos exclusivamente dedicados a una línea de trabajo.

En un par de posts anteriores comenté respecto del "Agilismo en un contexto multi-proyecto" (Parte I y Parte II). En este post veremos otra forma de "multi-proyecto" que ocurre cuando en el marco de un mismo producto se presentan varias líneas de trabajo con diferentes necesidades de gestión. El reconocimiento y gestión diferenciada de estas líneas de trabajo es clave para el buen funcionamiento de los equipos encargados. En el post "Gestión ágil de productos que tienen varias líneas de trabajo" ya comenté unos aspectos generales respecto de tener varias líneas de trabajo sobre un mismo producto. Ahora veremos una cuestión específica y natural que lleva a una línea de trabajo de desarrollo a transformarse en tres líneas de trabajo sobre el mismo producto.

Mientras un producto/servicio se está desarrollando tiene una una sola línea de trabajo, la línea de Desarrollo, pero a partir de la primera entrega (paso a producción) tendremos que tomar decisiones respecto de cómo abordar las tres líneas de trabajo que existirán a partir de ese momento: Desarrollo, Mantenimiento y Soporte, tal como se ilustra en la siguiente figura.


La situación planteada conlleva tomar decisiones en dos aspectos: qué equipo(s) se encargará(n) de cada línea de trabajo a partir de la primera entrega y qué configuración de gestión se utilizará en cada una de las líneas de trabajo. Comentemos primero respecto de la configuración de gestión.

La línea de trabajo de Desarrollo normalmente es "planificable", es decir, puede definirse a priori lo que se va a desarrollar y acordar con el cliente el alcance, plazos y costo (es decir, estamos en un escenario de proyecto), y opcionalmente (pero deseable) el trabajo se puede organizar en Sprints que agrupan los cambios para producir versiones con una regularidad de un cierto número de semanas (Sprints de no más de 4 semanas). Aún siendo planificable otra opción sería trabajar sin el marco de proyecto, solo definiendo Sprints mientras el cliente estime conveniente que vale la pena continuar. Incluso podría trabajarse sin Sprints ni proyecto, simplemente estableciendo priorización del trabajo, abordándolo según dicha priorización y consiguiendo nuevas versiones al implementar cada nueva característica. Por otra parte, la línea de trabajo de Desarrollo, a partir de la primera entrega tiene una exigencia mayor respecto de pruebas de regresión y no interferencia con el uso que ya están haciendo del producto los usuarios. Además, si ya se tiene una versión en producción las siguientes versiones son en mayor medida potenciales entregas.

Por otra parte, la línea de trabajo de Soporte es claramente "no planificable", no podemos saber qué dudas, mejoras, o fallos nos reportarán los usuarios (llamémoslos tickets). Aunque puede que tengamos alguna acumulación de tickets pasados pendientes de resolver, los cuales podrían en alguna medida planificarse, el Soporte es un servicio, y como tal es muy importante la velocidad de respuesta, con lo cual la idea es priorizar, ejecutar y resolver lo más rápido posible los tickets. Además, las acumulaciones de tickets no resueltos se producirán probablemente por escalamiento a otro nivel de servicio, en particular las mejoras y fallos se suelen derivar a la línea de trabajo de Mantenimiento o de Desarrollo. Cuando dichas mejoras o fallos se implementan en una nueva entrega del producto los correspondientes tickets puedes darse por cerrados.

Finalmente, la línea de trabajo Mantenimiento podría no reconocerse como línea independiente y considerarse incluida en la línea de Desarrollo ya que en ambos casos se trata de cambios de producto y el equipo realiza básicamente el mismo trabajo técnico. Sin embargo, conviene que el Mantenimiento esté diferenciado, especialmente si tenemos una demanda importante de trabajo urgente/pequeño que debe/puede hacerse de inmediato para ofrecer respuesta rápida. El Mantenimiento está a medio camino entre trabajo planificable y no planificable, ya que no todos los cambios son urgentes o pequeños. Todo lo no urgente o de mayor envergadura podría planificarse en Mantenimiento, o incluso pasarse para ser abordado por la línea de trabajo de Desarrollo. Para una línea de Mantenimiento es usualmente recomendable trabajar con Sprints flexibles en cuanto a contenido y duración, es decir, los Sprints podrían contener desde solo un cambio, implementado y entregado inmediatamente, hasta acumular varios cambios que se implementan en unos pocos días y luego se entregan. Esta flexibilidad también podría darse respecto a no llegar a terminar todo lo que se pretendía, porque podrían incorporarse otros ítems durante el Sprint.

El flujo de trabajo de una línea de Soporte (en la cual se gestionan tickets) difiere significativamente del flujo de trabajo de las líneas de trabajo de Desarrollo y de Mantenimiento (en las cuales se gestionan cambios en el producto). De todas formas, en cada línea debería poder visualizarse el estado del trabajo no terminado asociado a la línea (lectura recomendada: Multi-kanban, un tablero kanban para contextos multi-proyecto).

Respecto al equipo encargado de las líneas de trabajo, si es el mismo equipo el que va asumir todo el trabajo habrá que establecer ciertas directrices para la distribución de su capacidad en cada línea de trabajo, asignando cierta capacidad a la línea de Desarrollo y reservando un porcentaje de capacidad para abordar las otras dos líneas. La línea de Soporte es buena candidata para ser encargada a un equipo independiente, que incluso pueda encargarse del servicio de Soporte para varios productos ofrecidos por la empresa. Sin embargo, como comenté antes, los tickets que requieran cambios en producto deben sincronizarse con ítems en líneas de trabajo de Mantenimiento o Desarrollo. Las líneas de Mantenimiento y Desarrollo podrían encargarse a un mismo equipo pero aún así conviene gestionarlas como dos líneas en las cuales el equipo debe distribuir su capacidad. Si el Desarrollo y el Mantenimiento están encargados a equipos diferentes es muy importante su coordinación pues ambos equipos estarán generando versiones del mismo producto, es decir, cada uno tendrá su ritmo de generación de versiones y pueden coincidir en las partes del producto sobre las cuales están trabajando o que los cambios que realiza un equipo tengan impacto en el trabajo del otro equipo.

En un enfoque tradicional puede que esta situación se postergue hasta el final del proyecto de desarrollo, es decir, que se haga una sola entrega al final. Pero si seguimos un enfoque ágil se intentará realizar entregas frecuentes durante el desarrollo (aunque acotadas en cierta medida). Las entregas frecuentes permiten hacer una validación más certera para confirmar que el desarrollo está bien encaminado, pero además, contribuyen a no acumular "tensión" respecto a aspectos que suelen provocar retrasos y problemas cuando se dejan todos para ser resueltos al momento de la entrega final, tales como: formación de usuarios, integración con otros sistemas, migraciones de datos, infraestructuras necesarias para que opere el sistema, etc. Así, todos estos aspectos se van abordando incrementalmente según lo requieran las entregas parciales.  

En cualquier caso siempre llegará el momento en que una línea "pura" de Desarrollo genere las tres líneas que hemos indicado y con ello nos enfrentemos a las cuestiones antes comentadas.


Patricio Letelier


miércoles, 19 de abril de 2017

Design Thinking, Lean Startup y Métodos Ágiles

Design Thinking es un proceso para la generación de ideas innovadoras de productos/servicios, se basa en la comprensión de necesidades de los usuarios potenciales y en una estrecha validación con ellos. El proceso consta de 5 actividades: Empatizar (ponerse en la piel del usuario y comprender sus necesidades), Definir (establecer el problema que se quiere resolver), Idear (determinar posibles soluciones), Prototipar (construir un prototipo, una solución tangible) y Probar (validar el prototipo con el usuario). Estas actividades se realizan una tras de otra pero volviendo a cualquiera de las actividades previas cuantas veces sea necesario. El proceso de Design Thinking se potencia con la participación de equipos multidisciplinares.

Lean Startup es un proceso iterativo para desarrollar una idea de negocio hasta convertirla en un producto con garantías de éxito. El método asume un contexto de emprendimiento caracterizado por una alta incertidumbre y limitaciones de recursos y/o tiempo para validar dicha idea de negocio (contexto natural de una empresa Startup). La validación se basa en la experimentación con versiones preliminares del producto con early adopters (clientes dispuestos a usar el producto aunque no está del todo terminado, y antes de un lanzamiento masivo).  Lean Startup se basa en un ciclo Built-Measure-Learn que se repite en cada iteración. Con "Built" se obtiene un MVP (Minimun Viable Product), con "Measure" se realizan experimentos con early adopters para recolectar datos y con "Learn" se aprende de dichos datos para reforzar la idea original o para pivotar sobre ella re-definiéndola para que ofrezca mejores expectativas de éxito. El MVP es una versión del producto que nos permite llevar a cabo dichos experimentos de validación con early adopters.

Los Métodos Ágiles, representados por Scrum, Kanban, Lean Development y Extreme Programming entre otros, ofrecen un conjunto de prácticas que ayudan a la gestión de proyectos y equipos de trabajo, favoreciendo la satisfacción del cliente, la productividad, la calidad, y la motivación y compromiso del equipo de trabajo. Los Métodos Ágiles promueven un proceso incremental e iterativo (esto último solo en el caso de Scrum y Extreme Programming). Los Métodos Ágiles han demostrado ser especialmente más eficaces (que los Métodos Tradicionales) en contextos donde se esperan cambios durante el desarrollo del producto/servicio.

Una razonable integración de estos tres enfoques sería aplicarlos de forma secuencial de acuerdo con la fase en la cual se encuentra el producto/servicio. Es decir, usar Design Thinking durante la generación de la idea de producto/servicio, usar Lean Startup para validar el producto/servicio construyendo un MVP, y usar Métodos Ágiles para desarrollar el producto/servicio en su versión comercial. Esto se ilustra en la siguiente figura.
Lean Product Management for Enterprises The Art of Known Unknowns, Natalie Hollier


Puede que en productos manufacturados o servicios donde el software no sea protagonista tenga sentido una marcada diferenciación entre la generación de la idea, validación con MVPs y su desarrollo ágil. Pero esta integración no es la más adecuada cuando el software es lo principal del producto/servicio.

En un ámbito de producto software los tres enfoques: Design Thinking, Lean Development y Métodos Ágiles podrían aplicarse de forma conjunta y solapados. Si bien Design Thinking podría ser aplicado de forma más anticipada que los otros dos, incluso podría ser prescindible en caso que la idea de producto esté clara, pues el principal aporte de Design Thinking está en el descubrimiento de ideas.

Design Thinking y Lean Startup coinciden en la construcción de un producto tangible (prototipo en Design Thinking y MVP en Lean Startup) para poder hacer experimentos de validación con early adopters, sin embargo, Lean Startup conlleva ya un camino hacia la construcción del producto comercial, es decir, no se trata de prototipo no operacional o con la intención que sea desechable.

Los Métodos Ágiles no incluyen prácticas asociadas al descubrimiento de ideas de producto, con lo cual Design Thinking puede ofrecer este complemento. Lean Startup y los Métodos Ágiles (particularmente Scrum y Extreme Programming) coinciden en usar un proceso iterativo e incremental. En el caso de Lean Startup el concepto de incremento es el MVP y en los Métodos Ágiles este concepto puede corresponder con la versión resultante de un Sprint, o la versión que se pasa a producción (Entrega o Release). En cualquier caso se trata de una versión del producto, pero una diferencia importante es que el MVP no responde a la regularidad de un Sprint. Los Sprint tienen una duración no mayor de un mes y conllevan una periodicidad, los MVPs no tiene esa regularidad. Con lo cual un MVP se acerca más a lo que representa una primera Entrega (conseguida después de un cierto número de Sprints), lo cual marca un hito en cuanto a incrementos del producto. Sin embargo, el MVP tiene una orientación más experimental y su validación podría dar un giro al posterior desarrollo del producto, pivotando el producto hacia otra dirección. Si bien los Métodos Ágiles asumen esa posibilidad de cambios, Lean Startup va más allá considerando que que los cambios podrían ser más radicales. El aprendizaje ("Learn") de MVP en un ciclo Lean Startup puede producir un pivote radical de la idea de producto/servicio. Por otro lado, los Métodos Ágiles hacen énfasis en la arquitectura y pruebas del producto desde el inicio del desarrollo, en Lean Startup mientras estemos validando con early adopters el foco está en la validación del producto, sin prestar especial atención a la arquitectura y pruebas del producto.

En mi opinión, lo fundamental que hay que tener presente al mezclar Lean Startup y Métodos Ágiles es el contexto de negocio, es decir si se trata de un producto que tiene asegurado su mercado o si se trata de un producto innovador que deberá crearse/ganarse su mercado. Ese último caso se presenta claramente en un marco de emprendimiento (por ejemplo en una empresa Startup). En esta situación pueden aplicarse casi todas las prácticas ágiles, tales como: desarrollo incremental (el MVP ya lo conlleva), priorización del trabajo, tener un tablero kanban para visualizar el trabajo pendiente, todas las asociadas a dinámica de equipo (auto-organización, equipo cross-functional, reuniones y roles de Scrum), minimalismo en la especificación, etc. Probablemente unas pocas prácticas no serían tan recomendables, tales como: desarrollo iterativo, planificación mediante estimación del esfuerzo y contrastada con la capacidad del equipo, refactoring, pruebas automatizadas o uso de estándares. En el otro caso, cuando el producto tiene en cierto grado asegurado su mercado (puede ser un producto interno para una empresa o encargado a medida por una empresa cliente), podríamos pensar que bastaría con aplicar solo Métodos Ágiles pues nos facilitan la gestión de los posibles cambios, siendo estos no tan radicales como se esperaría en un marco de emprendimiento. Sin embargo, pienso que la estratégica del concepto de MVP debería siempre estar presente y alineado con los hitos que representan las Entregas. Es decir, el MVP ayuda a exigirnos una estrategia que busque siempre acotar el alcance de las entregas del producto para así poder en relativamente poco tiempo validar con la parte cliente, poniendo en producción (o pre-producción) una versión parcial del producto. Así pues, el concepto de MVP debe estar asimilado por el Product Owner como mecanismo para reducir la ambición de las entregas del producto/servicio, en favor de hacer evaluaciones tempranas de lo más esencial del producto/servicio, aunque esto postergue la incorporación de otras características menos esenciales.      


Patricio Letelier


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