sábado, 14 de diciembre de 2013

"Bueno, bonito y barato", ¿puede conseguirse esto con un método ágil?

Si bien el "Bueno, bonito y barato" para un consumidor podría tener su implementación real en la temporada de rebajas :-), llevado al terreno de gestión de proyectos se plantearía como en la imagen adjunta, reflejando un imposible o muy difícil desafío: "Bueno, rápido y barato", y si además solo pudieras elegir 2 aspectos para ser completamente satisfechos, el tercero se vería perjudicado y no se conseguiría completamente. Esta imagen corresponde a una lectura alternativa del conocido Triángulo de Gestión de Proyectos o Triángulo de Hierro, según el cual para lograr el éxito del proyecto deben cumplirse el alcance (requisitos implementados), costos (recursos invertidos) y plazos (duración prevista del proyecto). Alcance-costos-plazos corresponden a Good-cheap-fast en su lectura positiva.

Una reflexión recurrente en la literatura ágil se refiere a que en un enfoque tradicional se fija el alcance y según esto se determinan los plazos y costos, mientras que en un enfoque ágil se fijan los plazos y costes y según esto se implementa el máximo alcance posible. Esto se ilustra en la siguiente figura (una adaptación de una imagen atribuida al método ágil DSDM).


Inmediatamente pensaríamos: ¿qué contrato se adapta mejor cada situación?. Si bien hay variadas alternativas (ver "Contratos Ágiles": Parte 1 y Parte 2), el caso tradicional suele coincidir más con contratos de tipo "Precio Fijo /Alcance Fijo" y el caso ágil, a priori, podría ser más cercano al contrato de tipo "Tiempo y Materiales", aunque en ambos tipos de contratos se presentan ventajas e inconvenientes para el proveedor y para el cliente.

A partir de este punto presentaré mi visión ágil y pragmática respecto de cómo conseguir el éxito en un proyecto gestionando Alcance, Tiempo y Costo. Con "pragmática" me refiero a que siendo realista, en muchas situaciones será muy difícil cambiar el tipo de contrato, es decir, no convenceremos al cliente para establecer un contrato que se acerque hacia alguna variación de tipo "Tiempo y Materiales". ¿Puede entonces un contrato no ideal para el agilismo hacernos renunciar a la aplicación de prácticas ágiles? ¿se puede trabajar de forma ágil en un contexto de Alcance, Tiempo y Costo prefijados? Mi respuesta es sí, pero requiere una explicación.

Un contrato puede obligarnos a identificar los requisitos y estimarlos para establecer un compromiso coherente en cuanto a alcance-plazos-costo. Sin embargo, dicha identificación no tiene por qué implicar una definición detallada (y temprana) de todos los requisitos. Hay requisitos que sólo con un nombre pueden ser estimados, para otros quizás sea necesario hacer algún boceto o prototipo, y para algunos pocos quizás sería conveniente dedicar más esfuerzo para conseguir una definición y validación detallada. Además, normalmente dicha necesidad de especificación detallada está correlacionada directamente con el valor del requisito en el contexto global del producto, es decir, los requisitos de mayor valor son los que incuestionablemente estarán en el producto resultante, y además, deberían ser abordados cuanto antes (implementar lo más importante primero, así cuánto antes podremos confirmar que el producto está bien encaminado). 

Con lo anterior estamos haciendo una discriminación entre los requisitos respecto de su nivel de especificación y validación. Obviamente, un factor importante asociado a la necesidad de especificar en detalle (para conseguir una estimación razonablemente certera) depende de la experiencia del equipo de desarrollo en el ámbito tecnológico y del dominio del problema. Pero de todas formas, siempre será posible en cierta medida conseguir la deseada estimación temprana, necesaria para el compromiso contractual, y al mismo tiempo no caer en una "fase de análisis" que nos obligue a hacer una inversión muy significativa al comienzo del proyecto (incluso antes de cerrar el contrato) y que luego, veamos con frustración que no se ha rentabilizado a lo largo del proyecto. 

Lean Development menciona en uno de sus Mudas (fuentes de desperdicio) la sobreproducción o producción con demasiada anticipación. Especificar tempranamente y en detalle los requisitos puede derivar en este Muda cuando las especificaciones de requisitos quedan obsoletas antes de su implementación o incluso cuando, por cambios en la orientación del proyecto, ciertos requisitos ni siquiera llegan a implementarse. De esta forma, por ejemplo, si se añade un nuevo requisito podríamos intercambiarlo por requisitos previstos y no implementados (que supongan un esfuerzo de implementación equivalente), sin que esto tenga que suponer siempre un desperdicio de esfuerzo en especificación y validación de los requisitos descartados. Lectura recomendada: "Gestión ágil de requisitos o ¿cuál y cuánta documentación/especificación es suficiente?".

En un contexto ágil, la planificación (y re-planificación) y el seguimiento continuo son actividades muy presentes en el día a día del equipo. Esto se ve apoyado/alineado con el hábito de generar versiones frecuentes con nuevos requisitos implementados. El contrato asociado al proyecto puede tener una duración de, por ejemplo, 6 meses, pero la dinámica interna del proyecto puede estar basada en sprints de, por ejemplo, un mes cada uno. Aunque en el contrato se haya establecido un Alcance, Plazo y Costo fijo, soportados por estimaciones de esfuerzo, basta con disponer con un margen de flexibilidad y capacidad de respuesta ante cambios, especialmente respecto de requisitos que aún no han sido implementados (y en los cuales aún no se ha invertido ni siquiera en su especificación y validación detallada). 

Alguien podría mirar estos planteamientos con escepticismo desde una perspectiva de Gestión del Alcance de un proyecto. El éxito de un proyecto se basa en que se satisfagan las expectativas del cliente, pero esto se puede conseguir incluso si dichas expectativas no son las mismas que en el comienzo del proyecto. La clave es que dichas expectativas estén siempre actualizadas. Lecturas recomendadas: "Gestión del alcance en un proyecto ágil" y "7 diferencia entre una planificación tradicional y una ágil". Así pues, aunque se introduzcan cambios en los requisitos, si dichos cambios no generan "desperdicios" significativos de esfuerzo (porque no se ha invertido tiempo su definición ni implementación) no deberían afectar negativamente al proyecto. Solo en el caso que los cambios conlleven desperdicio significativo de esfuerzo habría que evaluar con el cliente el alcance, costo y plazos para mantener actualizadas las expectativas. 

Por otra parte, un requisito siempre ofrece un rango bastante amplio de alternativas en su implementación, todas ellas cumpliendo con su definición y aceptación del cliente. No me refiero solo a alternativas de tecnología, diseño y/o arquitectura interna del producto, sino a las alternativas negociables con el cliente, aquellas que se refieren al diseño de interfaz y experiencia de usuario, al nivel de automatización de ciertas funcionalidades, a la posible opcionalidad de ciertas operaciones complementarias a la funcionalidad esencial. Me gusta referirme a esto como "Sofisticación" (de la implementación de cada requisito) como otro aspecto que en un contexto ágil puede ayudar a resolver el desafío Alcance-Tiempo-Costo. Sí, esto podría verse como una rebaja en la calidad del producto, pero de aquella calidad "prescindible", la cual es necesario detectarla y negociarla abiertamente con el cliente. Debería ser un acuerdo Win-Win entre cliente y desarrolladores que establezca dicho nivel de sofisticación para cada requisito, sin renunciar a la esencia del requisito, y obviamente, dejando abierta la posibilidad para que en una futura entrega (por ejemplo en otro contrato) pueda elevarse el nivel de sofisticación de un requisito. De esta forma, tal como se ilustra en la siguiente figura, cada requisito incluido en el alcance puede además evaluarse en cuanto a su sofisticación, para así ayudar a lograr un equilibrio y consistencia con el tiempo y recursos del proyecto.
   

Finalmente, volviendo al título de este post, ¿es posible conseguir un "Bueno, bonito y barato" aplicando un enfoque ágil?. Según lo ya comentado mi respuesta es "sí, se puede", pero como habréis visto, requiere de un cambio de chip importante en el desarrollo del proyecto. No se trata de trabajar más por menos como sostienen algunos "genios" de la competividad, se trata de hacer lo que estratégicamente es más apreciado por el cliente (lo que más valor le aportará), de dosificar y negociar el nivel de sofisticación en la implementación de cada requisito, y de gestionar los cambios, manteniendo siempre actualizadas las expectativas del cliente.


Patricio Letelier





   

viernes, 15 de noviembre de 2013

Gestión ágil de productos que tienen varias líneas de trabajo

Cuando trabajamos con un producto nuevo y de gran envergadura o con un producto que tiene un intenso mantenimiento, y se dispone quizás de un equipo numeroso, puede ser conveniente organizar el trabajo sobre el producto en diferentes líneas, y para cada una de ellas realizar una gestión adaptada a sus necesidades. Si bien esto podría considerarse un tema "avanzado", o "raro" :-) para la literatura ágil habitual, es una situación bastante frecuente: un producto que está ya en producción y a la vez tiene mantenimiento muy activo. Esto es usual en empresas que comercializan un producto o unos pocos. Si el producto es de gran envergadura puede incluso ser conveniente formar sub-equipos por áreas del producto constituyendo cada una de esas áreas una línea de trabajo. Otros tipos usuales de líneas de trabajo sobre un mismo producto son: trabajo de desarrollo planificado (nuevos módulos o grandes remodelaciones o cambios no urgentes), trabajo de desarrollo urgente (correcciones de fallos o pequeñas mejoras), soporte (instalación y actualizaciones, atención al cliente, etc). Cada línea de trabajo puede tener sus particularidades en cuando a gestión del trabajo, acuerdos de servicio con el cliente, desarrolladores involucrados, etc. Por esto es conveniente reconocer estas líneas de trabajo y abordarlas con una estrategia adaptada a sus necesidades.

Esta situación multi-línea de trabajo en un mismo producto tiene similitudes con una situación multi-proyecto (o mejor dicho "multi-producto"), ambas comparten desafíos en lo que respecta a gestión y visualización integrada de la información. Recomiendo ver "Agilismo en contextos multiproyecto": Parte I y Parte II,  Multi-kanban, y "Patrones para planificación y seguimiento ágil").

Sea cual sea la estrategia para abordar una situación de producto con varias líneas de trabajo, la clave en esta situación es que se trata del mismo producto, con lo cual es normal que existan dependencias e incluso conflictos entre los cambios que pueda estar sufriendo el producto en cada línea de trabajo. Todos los participantes deberían poder fácilmente visualizar un Backlog global del producto y a la vez distinguir el Bakclog del trabajo correspondiente a cada línea de trabajo. Así, los participantes en cada línea de trabajo del producto podrán anticipar dichas interferencias y coordinar su trabajo. Veamos un ejemplo del desafío de gestión que presenta una situación multi-línea de trabajo sobre un mismo producto. Supongamos que tenemos al producto ACME con tres líneas de trabajo: Desarrollo Planificado, Desarrollo Urgente y Proyecto Nuevo Módulo. Además, cada línea está encargada a un equipo diferente. La siguiente figura ilusta la situación planteada.


En nuestro enfoque para la gestión ágil de proyectos, llamado TUNE-UP Process, la clave es tener una Estructura del Producto (y para ello usamos un grafo representado en un treeview) que sirva de marco para contextualizar todos los cambios del producto, provenientes de todas las líneas de trabajo. Así, cuando en una línea de trabajo se pretende realizar un cambio en un elemento del producto, se puede observar fácilmente qué cambios se han realizado, se están realizando y están pendientes de realizar por todas las líneas de trabajo en dicho elemento. Esto se ilustra en la siguiente figura, en la cual se observa cómo el nodo X está afectado por ítems de trabajo de Desarrollo Urgente y de Desarrollo Planificado, así como el nodo Y está afectado por ítems de trabajo de las tres líneas de trabajo.


Además de contar con la Estructura del Producto como mecanismo para ayudar a coordinar diferentes líneas de trabajo en un mismo producto, hay que decidir la estrategia de planificación y seguimiento para cada una de ellas (ver Patrones de planificación y seguimiento ágil) . Siguiendo con el ejemplo planteado, supongamos que para Desarrollo Urgente no se trabajará con sprints (puesto que la demanda no es planificable y se quiere simplemente generar un buen flujo de trabajo terminado). En cambio en Desarrollo Planificado y en el Proyecto Nuevo Módulo se trabajará con sprints. Cada línea de trabajo contaría con su propio tablero kanban y su backlog (podría, con algunos inconveniente, ser el mismo backlog y tablero kanban pero diferenciando de alguna forma los ítems de cada línea de trabajo). Esto se ilustra en la siguiente figura:


Llegado a este punto resulta evidente que las decisiones que se tomen deben ser soportadas con una correspondiente política para control de versiones, usando ramas, etiquetado u otros mecanismos que se acuerden.

En cuanto a la generación de versiones y planificación con sprints, la alternativa más sencilla sería que todas las líneas de trabajo coincidan en inicio y fin de cada sprint. Desafortunadamente, es difícil conseguir este grado de sincronización. Además, no sería recomendable (o posible) obligar a una línea que no debería trabajar con sprints (como en nuestro ejemplo Desarrollo Urgente) a postergar la generación de una versión para coincidir con el la fecha de término acordada para todas las líneas de trabajo.

Otra alternativa es que cuando se genere una nueva versión (por necesidad de cualquiera de las líneas), se decida qué trabajo de cada línea se quiere aprovechar de sacar en dicha versión. En esta alternativa el trabajo en marcha de las otras líneas que no se incluya en la versión se pasaría como trabajo candidato en la siguiente versión del producto (o siguiente sprint en el caso de que la línea de trabajo utilice sprints). Es decir, en esta alternativa las versiones pueden incluir trabajo de varias líneas de trabajo, pero los sprints se van modificando continuamente. Este es precisamente el inconveniente en esta alternativa para las líneas que trabajan con sprints, pues deberían redefinir su sprint actual cada vez que otra línea saca una versión o bien deberían llevar un versionado en paralelo aislándose de las versiones generadas mientras no interese incluir cambios. En la siguiente figura se ilustra esta alternativa, en cada versión se puede incluir trabajo terminado de varias líneas de trabajo y la frecuencia de generación de versiones no tiende a regularizarse:


Otra alternativa sería que cada línea de trabajo tenga su versionado, fechas de inicio y de fin de sprint, todo de forma independiente para cada línea. Así sería posible que las líneas que trabajan con sprints puedan mantener su duración constante.


Existen otras alternativas que mezclan los criterios antes señalados y detalles de versionado que harían demasiado extenso este post. Pienso que con lo expuesto el lector ya puede hacerse una idea de las variantes que deberían considerarse para conseguir una estrategia ajustada a las necesidades de cada línea se trabajo en el producto.

Otro aspecto a tener en cuenta pero que también excede el alcance de este post es la organización de los equipos, particularmente los roles de Product Owner y de Scrum Master (usando por ejemplo los roles de Scrum). Lo ideal es que pudiésemos abordar todo el trabajo con solo un PO y un SM para reducir los esfuerzos de coordinación, de no ser así, no queda más remedio que coordinar POs y SMs en caso de tener varios. Esto en en ámbito de Scrum se conoce como "Scrum de Scrums" y se refiere a los mecanismos para escalar Scrums en equipos grandes (más de 10 personas). Este post se ha centrado más en la importancia que tiene el establecer una planificación y seguimiento ajustada a las necesidades de cada línea de trabajo, aún tratándose del mismo producto, e independientemente de si son equipos diferentes en cada línea de trabajo o es mismo equipo para todas ellas.

En la herramienta que apoya nuestro enfoque TUNE-UP Process se ofrecen funcionalidades específicas para soportar las alternativas comentadas en este post, permitiendo a la vez tener una visión integrada del trabajo asociado a un producto con varias líneas de trabajo, junto también con la información de otros productos que también deban gestionarse en el mismo ámbito de trabajo.

Finalmente, en el post "Gestión ágil de productos. Líneas de trabajo en un producto a partir de su primera entrega" comento respecto del caso particular en el cual para un mismo producto, a partir de su primera entrega surgen tres líneas de trabajo: Desarrollo, Mantenimiento y Soporte.


Patricio Letelier




Patrones para planificación y seguimiento ágil

Una cuestión muy importante para el éxito de una implantación de prácticas ágiles es la configuración de prácticas de planificación y seguimiento para cada uno de los productos o servicios con los que se trabaja. Esto es especialmente más desafiante en contextos multiproyecto en los cuales el o los equipos están encargados de varios productos y/o servicios a la vez (ver Agilismo en contextos multiproyecto; Parte I y Parte II, y Multi-kanban). En este post recomendaré algunas alternativas para llevar a cabo la planificación y seguimiento de proyectos adaptadas a las necesidades específicas del producto o servicio. Nuestro enfoque en cuanto a prácticas es integrador en el sentido que incluye prácticas de los métodos ágiles más populares (Kanban, Lean Software Development, Scrum y Extreme Programming) y nuestra propuesta de patrones para planificación y seguimiento está refinada en base a experimentación y aplicación en proyectos industriales, contando además con un soporte explícito en nuestra herramienta Tune-up.

La configuración de planificación y seguimiento debe considerar la situación actual del producto o servicio, para conseguir un balance entre lo que sería el ideal y los desafíos que podría plantear el cambio hacia ese ideal. En muchas ocasiones lo más recomendable es iniciar una evolución más que un cambio radical que pueda crear ruido e incluso rechazo, particularmente para productos o servicios que son claves para el negocio.

Una práctica básica indiscutible en cualquier implantación ágil es la visualización de todo el trabajo no terminado mediante un tablero kanban. Así pues, un tablero kanban es el mecanismo básico para el seguimiento del trabajo. Ojo que con esto no estoy refiriéndome a usar el Método Kanban, sino solo el tablero que ofrece una mecánica para el flujo y visibilidad del trabajo. Existe bastante confusión respecto del uso de un tablero kanban, el cual no es exclusivo del Método Kanban, y además, es necesario en Scrum o XP porque en estos métodos no se ofrece un equivalente para visualizar el trabajo del equipo (ver ¿Kanban o Scrum?: that is not the question).

Una vez explicado el papel del tablero kanban, el resto de aspectos que podemos considerar para la configuración de planificación y seguimiento de cada producto/servicio son los siguientes:
  1. Agrupación (o no) del trabajo en sprints
  2. Gestión del esfuerzo
  3. Proceso centrado en Pruebas de Aceptación
  4. Líneas de trabajo en un mismo producto/servicio
Agrupación (o no) del trabajo en sprints
  • No usar sprints. Si la demanda del trabajo no es planificable (no sabemos qué trabajo ni cuando nos va a llegar) y/o no tenemos compromisos estrictos de plazos o alcance con el cliente, esta podría ser la mejor opción. Esta alternativa está cercana a la propuesta del Método Kanban, según la cual debemos centrarnos en generar un buen flujo de trabajo terminado, haciendo entregas muy frecuentes. Esta alternativa es particularmente adecuada para trabajo de mantenimiento continuo o solución de incidencias.
  • Sprints flexibles. Si no se tienen compomisos estrictos con el cliente pero sí que se tiene la posibilidad de acordar paquetes de trabajo para ser entregados en una cierta fecha, puede ser interesante utilizar sprints para evitar repetir muy continuamente las actividades de arranque y cierre de versión (que por ejemplo, incluyen en el cierre el pasar pruebas de regresión, despliegue, actualización de ayuda, etc.). El "Continuous Delivery" tiene ese desafío, es decir, contar con una buena infraestructura que evite una penalización en esfuerzo en dichas actividades de arranque y cierre de versión. Los ítems incluidos en el sprint, por no existir un compromiso estricto de alcance y plazo con el cliente, podrían no estar estimados y en caso de no poder terminarse en la fecha de fin del sprint simplemente se pasarían al siguiente sprint (reevaluando su prioridad respecto de los ítems contenidos en el Backlog en ese momento).
  • Sprints rígidos. Si la demanda es planificable y además el compromiso con el cliente en cuanto alcance y plazo del sprint es más bien rígido, lo recomendable es tener una noción de la capacidad del equipo y realizar estimaciones del trabajo que se incluye en el sprint para asegurar que sea consistente el esfuerzo asociado respecto de dicha capacidad. 

Gestión del esfuerzo
En este aspecto me refiero a cómo medir el esfuerzo estimado, invertido y restante en realizar un ítem de trabajo.
  • Esfuerzo estimado. Primero hay que insistir en que si no hay un compromiso estricto con el cliente en cuanto a alcance y plazos la estimación puede ser opcional. El esfuerzo estimado puede medirse en Horas Ideales o en Puntos (o cualquier otra medida de tamaño). Las Horas Ideales (horas de trabajo sin interrupciones) miden el esfuerzo asociado a actividades específicas, por ejemplo, horas ideales de programación. Los Puntos en cambio miden el esfuerzo global asociado al tamaño de un ítem de trabajo. Ver "Estimación en un proyecto ágil": Parte I y Parte II.
  • Esfuerzo invertido. Son las horas reales invertidas en actividades asociadas a un ítem de trabajo, por ejemplo, cuántas horas de programación o testeo llevamos invertidas en un ítem. No tiene mucho sentido plantearse el registrar Puntos invertidos en un ítem, pues no es una medida asociada a una actividad y estaríamos forzándo a darles una interpretación de unidad de tiempo, lo cual justamente es lo que los Puntos no son.
  • Esfuerzo restante. Se puede medir como la diferencia entre horas estimadas (y actualizadas cuando corresponda) y horas invertidas. En el caso de Puntos son los punto correspondientes a ítems de trabajo no terminados, es decir, no se haría un cálculo parcial del trabajo que esté comenzado pero no terminado.También es una alternativa el registrar directamente el esfuerzo restante, es decir, para cada ítem iniciado registrar períódicamente cuántas horas ideales restan en una actividad para finalizarla.
Según lo anterior, algunas alternativas para gestión de esfuerzo serían:
  • No gestionar esfuerzo.
  • Usar Puntos solo como esfuerzo estimado y calcular los puntos restantes como puntos de ítems no terminados.
  • Registrar solo el esfuerzo invertido.
  • Registrar solo el esfuerzo restante en horas ideales.
  • Registrar el esfuerzo estimado y el esfuerzo invertido. El esfuerzo restante puede calcularse como la diferencia entre el esfuerzo estimado y el invertido.  
Proceso centrado en pruebas de aceptación
Esta es una práctica que me llamó la atención cuando dí mis primeros pasos en el agilismo con Extreme programming. Si bien no se trata de una exclusividad del enfoque ágil, pues las pruebas de aceptación están presente también en las metodologías tradicionales, es indudable que el protagonismo es mucho más marcado en el contexto ágil. Además, la diferencia fundamental es que en el ámbito ágil el proceso debería estar dirigido por las pruebas de aceptación. Ojo!, no estoy hablando de TDD, el cual está orientado a pruebas unitarias. En un enfoque ágil, las pruebas de aceptación se escriben en el momento de definir o redefinir el ítem de trabajo, es decir, son en sí mismas la especificación detallada del ítem, son el criterio de éxito establecido para la implementación. Desgraciadamente, esta práctica no es sencilla de implantar, requiere formación y experiencia, además de cambios en la forma de trabajo pues o bien el tester (de testeo de aceptación) trabaja codo a codo con el que establece los requisitos (quien define/analiza el ítem de trabajo) o es este último quien directamente especifica las pruebas de aceptación del ítem (tarea que tradicionalmente realiza el encargado de testeo).

Pues bien, de cara a la planificación y seguimiento ágil, el tener un proceso centrado en pruebas de aceptación ofrece las siguientes ventajas:
  • Para la planificación las pruebas de aceptación son una excelente forma de negociar y establecer desarrollo incremental de ítems de trabajo "grandes". Así, en lugar de particionarlos, se pueden desarrollar en ítems sucesivos que incrementan la funcionalidad dando soporte a más pruebas de aceptación.
  • Para el seguimiento las pruebas de aceptación de un ítem de trabajo y su estado nos ofrecen un detalle adicional del estado de avance del trabajo en un ítem. Por ejemplo, podríamos saber del total de pruebas identificadas cuantas están ya definidas (condiciones, pasos y resultado) y cuántas estan ya diseñadas (instanciaciones concretas de datos para las condiciones, pasos y  resultado), o por otra parte, podríamos saber cuántas pruebas están implementadas OK y cuántas tienen detectado algún fallo y están KO.   
También hay que destacar que para conseguir estas ventajas no se requiere que las pruebas de aceptación estén automatizadas. La automatización o no de las pruebas de aceptación ofrece ventajas, desafíos y consideraciones de rentabilidad adicionales a lo que es el tema de este post :-).

Líneas de trabajo en un mismo producto
Una situación bastante habitual en productos grandes y/o con un mantenimiento continuo es tener varias líneas de trabajo en paralelo sobre el mismo producto. Por ejemplo, trabajo asociado a módulos específicos del producto los cuales llevan probablemente su propio versionado, o trabajo de grandes cambios o nuevos módulos, o trabajo de mantenimiento asociados a corrección de fallos o pequeñas mejoras que debe entregarse a muy corto plazo. De cara a la planificación y seguimiento esta situación incluye varios desafíos. Si lo tratamos como un solo producto, podríamos caer en hecho de someter a una única configuración de planificación y seguimiento a todas las líneas de trabajo, por ejemplo, trabajando con sprints, cada sprint contendría trabajo de las diferentes líneas y se tendría que sincronizar de alguna forma al cierre del sprint. Si gestionáramos cada línea de trabajo como un producto separado tendríamos la libertad para definir la configuración de planificación y seguimiento para cada línea de trabajo, por ejemplo, si se trabaja con sprints, cada línea de trabajo tendría sus propios sprints. En cualquiera de los casos deberíamos asegurar que los cambios se gestionen y visualicen en conjunto para detectar conflictos o dependencias entre las diferentes líneas pues de todas formas estaríamos trabajando sobre el mismo producto. Para conocer más detalles respecto de esta situación y alternativas asociadas a cómo abordarla ver "Gestión ágil de productos que tienen varias líneas de trabajo".

Conclusiones
Los patrones de planificación y seguimiento ágil surgen de la elección de estrategias en cada uno de los 4 aspectos planteados. A continuación se muestran algunos patrones de ejemplo:

Producto A: Usar sprints flexibles, registrar en horas esfuerzo invertido (sin hacer estimaciones), no trabajar centrado en pruebas de aceptación, y tratar el desarrollo y el mantenimiento urgente dentro del mismo producto y sprint pero pasando a producción versiones asociadas a mantenimientos urgentes.

Producto B: No usar sprints, registrar el esfuerzo en Puntos (no registrar el esfuerzo invertido) y usarlo solo como un dato descriptivo para reconocer en el Backlog ítems pequeños o grandes, trabajar centrado en las pruebas de aceptación, el producto ya está en producción y mientras no aparecen grandes cambios, todo el mantenimiento se hace de forma contínua en la medida que va recibiéndose y priorizándose.

Producto C: Un producto grande con diferentes módulos abordados por diferentes equipos. Cada equipo-módulo ajusta su configuración de planificación y seguimiento, pero todos los equipos comparten la información de la estructura del producto para poder detectar conflictos y dependencias respecto del trabajo que realiza otro equipo en otro módulo. Por ejemplo el equipo E1 trabaja en el módulo M1 con sprints, registrando tiempo estimado e invertido en horas (y disponiendo del tiempo restante también en horas), y trabaja centrado en pruebas de aceptación. El Equipo E2 trabaja en el módulo M2 (un nuevo módulo para el cual hay que desarrollar inicialmente un prototipo), no utiliza sprints, no hace estimaciones ni registros de tiempo invertido, y no trabaja centrado en pruebas de aceptación.

Obviamente de acuerdo al patrón seleccionado, la planificación y las formas de seguimiento serán diferentes. Por ejemplo, si no se tienen sprints no tiene sentido preguntarse si vamos a cumplir con una fecha de entrega de un paquete de trabajo, sin embargo, esto no debería ser un problema puesto que justamente lo que quieres darle al cliente es una solución lo más inmediata posible del problema que te está reportando en el momento. Si no se estima, no se podrá disponer de una gráfica Burndown o de trabajo Finalizado versus No Finalizado. Si se utilizan Puntos podrás tener una gráfica Burndown y una gráfica de relación entre ítems Finalizados/No Finalizados, pero en ambos casos solo se contabilizará un cambio cuando el ítem esté terminado, mientras los ítems siguen sin finalizarse ambas gráficas no muestran cambios. Si se registran estimaciones en horas y esfuerzo invertido también en horas, automáticamente puede calcularse el trabajo restante de la gráfica Burndown y las proporciones de trabajo finalizado y no finalizado. Si se trabaja centrado en pruebas de aceptación podrá adicionalmente conocerse el estado de especificación de las pruebas (identificadas, definidas o diseñadas) y su estado de ejecución (OK o KO).

Ignorar la configuración de la planificación y seguimiento de cada producto (o de sus líneas de trabajo) puede conllevar situaciones de proceso en las cuales se hace más trabajo o menos trabajo del que realmente se requiere para ser eficaz en cuanto al éxito del equipo en el producto, o simplemente incomodidades para abordar el trabajo pues no se ajusta a las necesidades del contexto del producto.  

Las variantes para establecer los patrones de planificación y seguimiento ágil los hemos ido refinando con nuestra experiencia en múltiples proyectos de implantación de nuestro enfoque Tune-up, y se ofrecen en nuestra herramienta como sencillas opciones de configuración de cada producto/servicio, incluso es posible cambiar en cualquier momento de una configuración a otra si se considera conveniente.


Patricio Letelier


sábado, 15 de junio de 2013

Multikanban, un tablero kanban para contextos multiproyecto

Antes de empezar, es importante puntualizar que con "multiproyecto" me refiero a la situación en la cual un equipo ágil está encargado de varios (muchos) proyectos. NO me refiero a "escalar la agilidad", o cómo varios equipos pueden participar de forma coordinada en un trabajo de mayor envergadura abordado por varios equipos de trabajo. En este último caso ya hay bastante información bajo la etiqueta "Scrum de Scrums", es decir, dividir un proyecto de gran tamaño (y con muchas personas involucradas) en áreas y equipos, de forma que cada equipo esté dedicado un área diferente pero coordinados respecto del trabajo global. Recomiendo la lectura de un caso real descrito en Scaling Agile @ Spotify with Tribes,Squads, Chapters & Guilds.

Para una introducción al enfoque ágil en contextos multiproyecto recomiendo mis posts "Agilidad en un contexto multiproyecto" Parte I y Parte II.

No existe un planteamiento consensuado respecto del enfoque ágil en una situación en la cual un equipo está encargado de varios (muchos) proyectos. Acerca de esta situación sugiero echar un vistazo a los siguientes debates
Un escenario multiproyecto no es un tema usualmente abordado en la bibliografía ágil. Si bien no se menciona explícitamente que un equipo debe dedicar toda su capacidad de manera exclusiva a un solo producto/servicio, cuando se describen los métodos ágiles se pasa por alto la existencia de esta situación multiproyecto. Correspondientemente, en general las herramientas tampoco ofrecen mecanismos específicos para dicha situación, parece que se asume como normal que un equipo en un contexto multiproyecto, tenga que por ejemplo, trabajar con varios tableros kanban a la vez, o que de manera artificial se tienda a incluir en un Backlog o sprint ítems que corresponden a diferentes productos/servicios.

¿Por qué un contexto multiproyecto es una realidad difícil de cambiar?
  • Porque existen oportunidades de negocio y no se cuenta con suficiente personal para abordarlas cada una de forma exclusiva. ¿Qué empresa estaría dispuesta a perder un proyecto porque el cliente no quiere esperar un aplazamiento para el comienzo del proyecto?. Además, si se trata de una empresa pequeña el aumento de proyectos conlleva directamente que equipos y/o personas NO estén con dedicación exclusiva a un proyecto. 
  • Porque los productos/servicios resultantes de un proyecto requieren mantenimiento. Los productos/servicios no tienen necesariamente una continuidad de esfuerzo dedicado a ellos por parte del equipo, ni tampoco requieren la misma intensidad en cuanto a cantidad de esfuerzo dedicado a ellos. Probablemente, se necesitará mayor capacidad del equipo dedicada cuando se desarrolla la primera entrega del producto o cuando se lleva a cabo el desarrollo de un nuevo módulo de tamaño considerable. Sin embargo, el Backlog del producto/servicio sigue vivo mientras el producto/servicio está siendo utilizado, es decir, seguirá existiendo una demanda en términos de nuevos ítems añadidos al Backlog. Probablemente mientras no se tengan ítems urgentes que obliguen a realizar una asignación de capacidad del equipo, o en general hasta que la demanda acumulada no alcance ciertas prioridades del negocio, el producto/servicio, aunque esté en producción, podría pasar un período sin capacidad asignada para trabajar en él pero contando como un producto/servicio encargado al equipo. Así pues, como contrapartida, debido a estas posibles fluctuaciones de capacidad y sin abusar de ello, un equipo podría estar encargado de varios productos/servicios sin que llegue necesariamente a un estado de saturación o degradación de desempeño.
  • Porque en niveles superiores de supervisión (unidades, departamento, etc.) la perspectiva es siempre multiproyecto. La dirección de la empresa puede apostar por el enfoque ágil y proporcionar el apoyo y confianza necesarias para el funcionamiento de los equipos, pero NO creo que renuncie a supervisar :-), al menos en cierta medida. Así pues, los niveles superiores deben contar con mecanismos para poder supervisar el conjunto de proyectos. 
Un contexto "demasiado" multiproyecto NO es una situación positiva para el equipo. La degradación del desempeño de un equipo puede ser similar a la ocasionada cuando a nivel de ítems en una actividad tenemos un WIP elevado. La recomendación general también sería similar, es decir, limitar la cantidad de proyectos entre los cuales el equipo debe distribuir su capacidad (y consecuentemente intercalar su dedicación), privilegiando terminar proyectos en lugar de abrir nuevos. Pero esto a nivel de negocio son cuestiones difíciles de evitar, y no suele ser la primera opción el incremento de personal :-).

Cuando la la empresa opta por asumir un contexto multiproyecto a nivel de equipos, no hay fórmulas mágicas para que pueda funcionar adecuadamente, la clave es que la dirección provea pautas respecto de la distribución de la capacidad de cada equipo, y que éstas estén alineadas con las prioridades del negocio. Cada equipo seguirá dichas pautas de distribución adaptándolas a períodos de tiempo. La siguiente figura ilustra una distribución de capacidad prevista y real para un equipo. En la figura se distingue entre asignación de capacidad (para trabajos en los cuales se realiza una planificación) y reserva de capacidad (para los trabajos que responden a demanda no planificable). Naturalmente, la demanda no planificada puede provocar cambios en la distribución real porque puede fluctuar requiriendo más o menos capacidad que la reserva prevista, y en ocasiones puede tener carácter urgente siendo ineludible su atención, cueste lo que cueste.


Llegando a este punto, podríamos optar por renunciar al agilismo en un contexto multi-proyecto :-), sin embargo, mi opinión es que es preferible considerarlo un obstáculo y enfrentarlo, sin dejar de acceder a los beneficios de las prácticas ágiles.

Nuestro Enfoque

Anecdóticamente, ya en 2005 cuando nos propusimos desarrollar una herramienta para apoyar la gestión ágil de nuestros proyectos, estábamos ya abordando una situación multi-proyecto, y en la primera versión ya intentamos integrar de forma homogénea todo el trabajo que tiene asignado un equipo. Incluso en esa época, sin aún conocer el método Kanban ni los tableros kanban, apostamos de forma natural por un multikanban, es decir, un tipo de tablero kanban que sintetizara todo el trabajo de un equipo, proporcionando filtros para conseguir una vista a nivel de miembro, producto/servicio, sprint y de proyecto.

El desafío de dicha visualización sintetizada tiene dos aspectos, por una parte los elementos involucrados, y por otra, las actividades del los diferentes workflows (representadas como columnas de los tableros kanban). La siguiente figura muestra los elementos que consideramos y que corresponden a opciones de filtrado en el Multikanban.


Un agente (miembro) participa en equipos. Un equipo tiene agentes. Un equipo está encargado de productos o servicios. Un producto o servicio tiene un Backlog (que contiene el trabajo pendiente priorizado y no incluido aun en sprints). Un producto o servicio tiene definidos sprints con trabajo que se ha movido desde el Backlog. En caso que un producto o servicio no trabaje con sprints (por ejemplo, porque su demanda no es planificable), todo el trabajo estará en el Backlog y directamente allí se abordará.

Pero ¿qué entendemos por Proyecto?. Las metodologías ágiles se enfocan en el producto o servicio que se ofrece como resultado al cliente. Por esto, es el producto o servicio el que tiene un Backlog y opcionalmente se desarrolla o atiende en sprints. Sin embargo, para nosotros el concepto de proyecto sigue siendo válido para representar un esfuerzo invertido durante un tiempo relativamente largo (varios meses), necesario por ejemplo, para desarrollar la primera entrega de un producto o la entrega de un nuevo módulo de gran envergadura. Así, mediante el concepto de proyecto podemos gestionar el alcance global de una entrega, aunque trabajemos con sprints de pocas semanas. Además, el concepto de proyecto nos ha permitido gestionar cambios simultáneos en varios productos, cada uno con su trabajo independiente, pero llevando una planificación y seguimiento global a nivel de proyecto.

La siguiente figura muestra una parte del formulario de inicio de Worki, la interfaz en la cual cada colaborador del equipo puede visualizar todo el trabajo no terminado en el cual participa.



En Worki pueden definirse diferentes workflows y luego asociarse a productos/servicios según sus necesidades. Es decir, en un mismo producto podemos tener ítems que pasan por diferentes actividades, algo que en un tablero kanban tradicional sería dificil de gestionar pues implicaría llevar en cuenta qué columnas son aplicables a cada ítem. En Worki, al crear un ítem se le asigna un workflow y el sistema se encarga de hacerlo pasar por las actividades que le corresponden (permitiendo decisiones de saltos atrás o hacia adelante cuando el agente lo estime conveniente). El tablero multikanban de Worki reúne todas las actividades de los ítems en los cuales un colaborador o equipo participa y no están terminados, es decir, no solo muestra el trabajo que en un momento determinado podría ser realizado por un agente sino que también le muestra el trabajo que está por llegarle, o que ya realizó y está ahora en manos de otros colaboradores. Esto elegantemente se diría como: "disponer de un buen Shared Situational Awareness" :-). Cuando una celda del multikanban tiene fondo azul, todo el contenido de dicha celda es trabajo asignado al colaborador seleccionado y ese trabajo ya está disponible para realizarse. Cuando la celda tiene fondo celeste, allí hay trabajo listo para realizar por el agente conectado o por otros agentes. Cuando la celda está en fondo blanco, todo el trabajo allí contenido está en manos de otros agentes. Además, cuando una actividad de un ítem no tiene preasignado un encargado, será vista como lista para realizar por todos los colaboradores que compartan el rol de la actividad, así cualquiera de ellos podrá acceder a ella y autoasignársela

Con los mecanismos descritos, con Worki podemos, de forma eficiente y sencilla, visualizar todo el trabajo en un contexto multiproyecto. Más aún, vemos de forma integrada el trabajo en productos o servicios que tienen distintas estrategias respecto de usar o no usar sprints, con situaciones diversas en cuanto a preasignación de agentes, o que requieren workflows específicos para cada tipo de ítem. Lectura recomendada respecto de workflows y su relación con tableros kanban: Workflows Flexibles Parte I y Parte II.

Patricio Letelier

viernes, 7 de junio de 2013

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

Este post viene motivado por el debate iniciado por Agustín Villena en chileagil@googlegroups.com a fines de mayo de 2013. El debate se titula "Incremental versus Iterativo" y pone como referencia los siguientes posts: Don’t know what I want, but I know how to get it, por Jeff Patton (2008), y Revisiting the Iterative Incremental Mona Lisapor Steven Thomas (2012). En estos posts, como metáfora del desarrollo de un producto software se utiliza la elaboración del cuadro de la Mona Lisa. Suele ser un tanto engañoso usar metáforas para explicar conceptos de ingeniería de software, pues normalmente encierran siempre algún truco o interpretación forzosa :-). Sin embargo, como la exposición en dichos posts ya estaba dada en términos de dicha metáfora, continuaré con su utilización. A continuación se muestran las ilustraciones de los posts indicados antes. En cada caso la pintura se realiza en varios pasos numerados. Además, en cada ilustración se destaca el nivel de visualización previa del pintor respecto del cuadro que va a pintar.

Figura 1. Proceso Incremental según Jeff Patton 


Figura 2. Proceso Iterativo según Jeff Patton


Figura 3. Proceso Iterativo e Incremental  según Steven Thomas

En enero de 2010 Jeff Sutherland escribió un post replicando el post de Jeff Patton, titulado Iterative versus Incremental Development. En dicho post Jeff Sutherland descalifica la clasificación de Jeff Patton, diciendo que la Figura 1 (Proceso Incremental) simplemente muestra un enfoque "out of step" (alejado de la realidad), sin embargo, no juzga si es o no un proceso incremental :-). En el caso de la Figura 2, dice que NO es un proceso iterativo sino incremental. Jeff Sutherland interpreta que en la Figura 2 hay una intención de conseguir una versión potencialmente entregable del producto en cada paso. Como veremos a continuación esta consideración hace que un proceso se clasifique como incremental, es decir, un proceso puede ser iterativo (organizar el trabajo en iteraciones, llámense éstos sprints o pasos) pero, para que además sea incremental, debe existir la intención de producir una versión potencialmente entregable. En el caso de la Figura 3 de Steven Thomas, si bien presenta una mezcla de las estrategias de la Figura 1 y Figura 2, también es una cuestión de interpretación si en cada paso existe o no la intención de que el resultado que se obtenga en cada iteración sea un incremento potencialmente entregable.

Consecuentemente con lo anterior, en Scrum se establece que el resultado de un sprint (una iteración) es un incremento potencialmente entregable del producto ("potentially releasable product increment"), es decir, una versión que potencialmente podría pasarse a producción. El incremento es la suma de todos los ítems del Backlog completados durante un sprint y todos los sprints anteriores.

Por otra parte, Alistair Cockburn en el apartado de su web titulado Incremental versus Iterative Development proporciona otra perspectiva en cuanto a la definición de Iterativo y de Incremental. Incremental lo plantea como la estrategia que permite mejorar el proceso (desarrollar partes y luego integrarlas) e Iterativo lo plantea como el re-trabajo para mejorar el producto.

Según todo lo anterior, en mi opinión, queda claro que un Proceso Iterativo, apelando a lo básico, es un proceso donde se trabaja con ventanas temporales (llamadas usualmente iteraciones o sprints) en las cuales se lleva a cabo cierto trabajo sobre el producto. Un Proceso Incremental e Iterativo es un proceso en el cual el resultado de cada iteración es un incremento potencialmente entregable del producto. Pero quedaría por responder la pregunta del millón :-) ¿puede un proceso ser Incremental SIN ser Iterativo?. Mi respuesta es afirmativa, y mi argumento sería el siguiente (en la línea de Alistar Cockburn): si el producto se desarrolla en partes que se van integrando en cierto momento con la intención de hacer una entrega, pero sin utilizar iteraciones (o sprints), estaríamos en el caso de un proceso NO iterativo pero SÍ Incremental. Pondría como ejemplo la estrategia del método Kanban, el cual promueve la generación de un buen flujo de trabajo terminado, con entregas continuas pero sin trabajar con sprints (sin estimar ni planificar, y en su lugar centrarse en la priorización continua del trabajo pendiente). A propósito de este ejemplo, aprovecho para destacar que la decisión de un equipo respecto de usar o no sprints suele tomarse a través de una cuestión mal planteada, puesta en términos de la elección entre usar de forma excluyente Scrum o Kanban (lectura recomendada. ¿Kanban o Scrum? ... that is not the question).

Finalmente, en la metáfora de la Mona Lisa se diferencia entre pintarla teniendo una concepción previa del todo (Figura 1), o comenzar con una idea vaga, e ir definiéndola y ajustándola en cada paso (Figuras 2 y 3). En mi opinión este aspecto (el tener o no una idea preconcebida y detallada del resultado) no es extrapolable tan directamente a desarrollo de software. Es ampliamente reconocido que los requisitos suelen cambiar durante el desarrollo, tanto en términos de añadir o quitar requisitos, como en cuanto a modificar los requisitos originales. Con lo cual aunque se haga un esfuerzo importante por definir anticipadamente todos los requisitos, de todas formas se esperan cambios en ellos. Es por esto que, siguiendo la recomendación de uno de los 7 Mudas de Lean Development en cuanto a "no producir con demasiada antelación", los ítems en el Backlog no deberían ser definidos en mayor detalle hasta que no se acerque su implementación. Es decir, en el Backlog, podemos tener ítems con escasa definición o muy grandes (Épicas) que sabemos que necesitarán un trabajo previo antes de su implementación, pero, como asumimos que habrá cambios, no conviene anticipar su preparación hasta cuando sea inminente que se van a implementar. Una excepción a esto se daría cuando el contexto nos obliga a planificar con mayor antelación (por ejemplo, compromisos contractuales poco flexibles), y esto consecuentemente ejerce presión para anticipar una preparación y estimación más detallada.


Patricio Letelier

lunes, 20 de mayo de 2013

Curso Métodos y Prácticas Ágiles: Material para profesores

El propósito de este post es compartir mi experiencia en enseñanza de métodos ágiles, es lo que he venido aplicando y refinando en la ETSInf (Escuela de Informática) de la Universitat Politècnica de València, en el Grado de Ingeniería Informática. Gran parte de este material también es utilizado en cursos y talleres dirigidos a empresas y en múltiples seminarios en España y Sudamérica. NO se trata de un curso para autoaprendizaje, mi interés es poder establecer contactos y colaboraciones con otros profesores que están enseñando o están interesados en comenzar a enseñar métodos ágiles
Este enfoque de enseñanza de métodos ágiles se viene refinando desde el año 2000, en docencia , investigación y aplicación en proyectos de desarrollo y asesorías en mejora de procesos. En 1998 ya enseñaba RUP, y a partir de 2002 incorporé Extreme Programming, y más tarde Scrum, Kanban y Lean Development. La estrategia docente desarrollada tiene una marcada orientación hacia la implantación de prácticas ágiles. Si bien se hace hace una breve introducción a los métodos ágiles más populares, gran parte de la asignatura está dedicada a explicar prácticas ágiles (independientemente del método del cual provengan) mediante actividades prácticas, y en paralelo ir aplicándolas en un proyecto de trabajo en equipo. 

Si bien existe en internet y en libros mucha información relativa a métodos ágiles, el material que utilizo no es una mera recopilación de esos contenidos. Las características más destacables de mi planteamiento docente son:
  • Se ofrece una visión global del proceso software aunque centrándonos mayoritariamente en métodos ágiles, con un discurso objetivo y crítico respecto de las ventajas, inconvenientes y desafíos del enfoque ágil.  
  • Se presentan los conceptos y prácticas de Kanban, Lean Development, Scrum y Extreme Programming, pero más que enfatizar los métodos resaltamos las prácticas que hay detrás de los métodos, pues considero más importante el conocer el conjunto de prácticas ágiles y aplicarlas que el enseñar un método ágil concreto. (ver Carta de Prácticas Ágiles).
  • Se da mucha importancia a la estrategia de implantación de prácticas ágiles, ofreciendo pautas al respecto. (ver ¿Revolución o evolución hacia el agilismo? y AGILEV Roadmap)
  • Si bien se explican las diferencias del enfoque ágil respecto del tradicional, no se insiste en el enfrentamiento ágil-tradicional, incluso se deja abierta la posibilidad de realizar mezclas de prácticas ágiles con algunas provenientes del enfoque tradicional.   
  • Se incluyen numerosas actividades y ejemplos para ilustrar las prácticas ágiles, las cuales se han integrado con los contenidos teóricos ofrecidos a lo largo de la asignatura.
  • Con mis colaboradores hemos desarrollado Worki, una herramienta para gestión ágil de equipos de trabajo (Ayuda en línea de Worki), que está totalmente alineada con nuestro planteamiento, aunque esto no impide que pueda utilizarse otra herramienta.
Nuestras asignaturas actuales en el Grado en Informática son Proceso del Software (PSW) y Proyecto de Ingeniería de Software (PIN), ambas en la rama de Ingeniería del Software (ver artículo presentado en JENUI 2013 donde se describe nuestra estrategia docente). En PSW proporcionamos los conceptos e ilustramos las prácticas ágiles, además, trabajando en equipos de 4 alumnos se lleva a cabo la exploración y planificación de un producto software, llegando hasta establecer un Backlog y preparar un primer Sprint de desarrollo (solo se llega a definir las unidades de trabajo con sus bocetos y pruebas de aceptación, no se implementan). El profesor desempeña el rol de cliente y de instructor para cada uno de los equipos. La asignatura PIN se imparte en el cuatrimestre inmediatamente siguiente y están matriculados los mismos alumnos de PSW. En PIN se trabaja en equipos de 6-8 alumnos, y se asocia a cada equipo uno de los productos preparados en PSW. Así, en PIN los equipos realizan 3 Sprints para conseguir una primera entrega de su producto, aplicando en un contexto bastante realista las prácticas ágiles aprendidas en PSW. El profesor desempeña el rol de cliente y de instructor, y mantiene un estrecho contacto con los equipos, participando como cliente en la preparación y validación del trabajo, y como instructor proporcionando apoyo respecto de las prácticas ágiles aplicadas.

Si estás interesado en establecer una colaboración docente respecto en una asignatura dedicada desarrollo de software utilizando métodos ágiles ponte en contacto conmigo (letelier@dsic.upv.es), podrás contar con material, con el uso de Worki en tus clases y con mi apoyo para llevar adelante la "Transformación Ágil" de tu asignatura ;-).


Patricio Letelier

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

martes, 14 de mayo de 2013

Actividad: Ball Point Game. Ilustrando un proceso iterativo y su mejora continua


Esta actividad es una adaptación del juego creado por Boris Gloger  y de la explicación ofrecida por Declan Whelan. Este interesante y entretenido juego ilustra la dinámica de un equipo trabajando de forma iterativa y en mejora continua mediante retrospectivas. Para ilustrar  Scrum y su proceso iterativo prefiero otras actividades (ver Scrum + Kanban + conceptos Equipo Self-organizing y Cross-functional). Mi interés por esta actividad es más por lo que respecta al hábito y conveniencia de realizar mejora continua mediante reuniones de retrospectiva.

Esta actividad tiene una duración aproximada de 30 minutos.

INDICACIONES

El objetivo en el juego es pasar tantas bolas como sea posible a través de cada miembro del equipo en 2 minutos. Se contabilizará cada bola pasa a través de todos los miembros del equipo siempre que la primera persona que toque la bola sea también la última en tocarla. Se realizarán 5 iteraciones. Antes de cada iteración el equipo estimará cuántas bolas piensa que va a conseguir pasar hasta el final. Después de cada iteración se registrará el número de bolas conseguidas.

Material
Boris Gloger recomienda bolas de tenis pero podría hacerse con cualquier objeto que pueda ser lanzado con facilidad. Dependiendo de la cantidad de participantes, prever una cantidad adecuada para que no tengan que esperan demasiado a que les lleguen bolas (considerar que las bolas que llegan al final se contabilizan y se vuelven a poner en el circuito).

Reglas del Juego
- Casa bola debe pasar por todos los integrantes
- La bola debe pasar por el aire
- No pasar la bola al vecino a izquierda o derecha
- Integrante de inicio = Integrante de término
- Iteración = 2 min
- Tiempo entre iteraciones = 1 min
- Haremos 5 iteraciones
- Si la bola cae al suelo o no cumple alguna regla se computará un fallo


Guía de la actividad
- 2 min. para introducción
- 2 min. para comentar de normas
- 2 min. para preparar primer sprint
- Realizar 5 iteraciones:
          - Registrar la estimación del equipo
          - Registrar la mejora que se aplicará en el sprint (a partir del segundo sprint)
          - 2 min. de iteración
          - Registrar bolas conseguidas y fallos
          - Aproximadamente 2 min. de retrospectiva
- 10 minutos comentarios finales
Crear una hoja o transparencia para que las reglas del juego estén siempre visibles. 

Revisando la información en internet, vemos que Ball Point Game es usualmente realizada al principio de un curso o seminario de Scrum, principalmente con el propósito de "romper el hielo" entre los asistentes. Para ello solo se forma un equipo con todos los asistentes, esperando intencionalmente que se cree un cierto caos, lo cual también resulta divertido. En nuestro caso el propósito es diferente, nos centramos en destacar el valor de las retrospectivas (después de explicar métodos y prácticas ágiles, en un apartado de Mejora Continua). Así, para asegurarnos que exista posibilidad de realizar buenas retrospectivas, en las cuales todos tengan la posibilidad de participar, nuestra recomendación es que los equipos no tengan mucho más de 10 personas, así pues, realizamos el proceso en paralelo con varios equipos a la vez, yendo todos a la par en cuanto a tiempos, sprints e indicaciones. 

Preparar (para cada equipo) una tabla como la siguiente donde registrar los resultados de cada iteración.


Sprint
Bolas
Estimadas
Bolas Reales
Fallos
Mejoras
1




2




3




4




5





Asegúrese de disponer de un espacio suficiente para que el equipo pueda experimentar diferentes posiciones de sus integrantes.

Indicaciones adicionales
  • Que el instructor registre los resultados y complete la(s) tabla(s) de datos, así los equipos se concentran en los sprints y en las retrospectivas.
  • Recomendable usar StopWatch como cronómetro para la cuenta regresiva de 2 min. en cada sprint.
  • Cuando pregunten ¿se puede hacer tal cosa?, simplemente remitirlos la las reglas del juego diciendo  "es vuestro proceso”.
  • Recuerde registrar las mejoras que realicen en el proceso inmediatamente después de la retrospectiva.
  • Recuerde solicitar una estimación de bolas antes de comenzar cada sprint.
  • Al terminar el sprint antes de comenzar la retrospectiva dejar todas las bolas preparadas para el siguiente sprint, así el equipo estará centrado en la retrospectiva pensando en mejoras. 

COMENTARIOS FINALES

Algunos temas de debate:
  • ¿Qué iteración funcionó mejor?,  pero ¿qué entendemos por “mejor”?
  • ¿Se consiguió una mejora continua, fueron eficaces las retrospectivas?. Es importante valorar las reuniones de retrospectiva puesto que la mejora en productividad y calidad del trabajo, y compromiso y moral del equipo puede ser muy rentable respecto del tiempo invertido en dichas reuniones.
  • Establecer paralelismos entre Scrum y el Ciclo de Deming (Plan-Do-Check-Act).
  • Pull Systems. La mayoría de los equipos establecen de forma natural un Pull System, es decir, no se produce o avanza la producción si no hay demanda desde la parte que recibe bolas. En nuestro caso existe un límite para el WIP, correspondiente a cuántas bolas puede tener una persona en sus manos. 
  • ¿Qué tipo de liderazgo se generó, se tomaron en cuenta todas las ideas?. La energía o ímpetu por proponer mejorar puede llegar a generar conflictos. En el ámbito laboral intervienes otros factores asociados a las iniciativas de mejora, tales como: el reconocimiento, la recompensa, la autoridad, etc.
  • ¿Es siempre posible mejorar el proceso? ¿Existe un ritmo o velocidad natural en cada proceso?. Manteniendo una misma configuración en iteraciones sucesivas, por simple práctica,  se conseguirá mejorar los resultados y reducir los fallos. Sin embargo, sin hacer cambios, cada vez la mejora será menos significativa. Esto es normal, pues un sistema tiene un cierto rendimiento una vez alcanzado su estado de eficiencia, en el cual a menos que se introduzcan nuevos cambios, permanecerá estable y predecible. Es decir, esta situación de estabilidad en eficiencia no es mala, pero no debería llevarnos al conformismo o descartar la búsqueda de nuevas mejoras. Tampoco debemos estresar el sistema presionando por más velocidad de la que puede dar de forma natural.
  • Puede presentarse el caso en el cual con una nueva configuración se obtenga un resultado peor, incluso llegando a abortar la iteración si está siendo desastrosa. Esto no debería verse como un fracaso, es un aprendizaje :-) , y siempre podría volverse a una situación previa de la cual se conocía su desempeño.
  • Respecto de un trabajo de equipo real, la gran simplificación en este juego es que generalmente los ítems de trabajo (las bolas de este juego) no requieren el mismo esfuerzo para procesarlas. En desarrollo de software si dos o más ítems son exactamente iguales, solo se desarrollaría una vez y luego simplemente se reutilizaría. Sin embargo, en muchos casos el equipo se enfrenta a ítems de diverso tamaño y/o complejidad, es decir, el juego equivalente tendría bolas de distinto tamaño, peso, etc., con lo cual quizás el proceso debería adaptarse a las características de cada tipo de ítem.

INSTANTES DE LA ACTIVIDAD