jueves, 30 de octubre de 2014

Modelos de proceso para desarrollo ágil

Un modelo de proceso determina una estrategia global respecto de cómo se desarrollará un producto o servicio. El modelo de proceso ilustra qué actividades se realizarán a lo largo del tiempo. Existen diferentes modelos de proceso, desafortunadamente no hay uno que sea el mejor para todas las situaciones. En este post me centraré en tres modelos de proceso: Cascada, Incremental, e Iterativo-Incremental.

Dependiendo del dominio del proyecto (y del producto o servicio resultante) las actividades necesarias para desarrollarlo pueden ser muy diferentes. Sin embargo, podremos coincidir en que en términos generales al menos se realizarán tres actividades: Definición, Ejecución y Pruebas. La Definición se refiere al establecimiento de qué se quiere conseguir, corresponde a actividades de especificación de requisitos, análisis, etc. La Ejecución se refiere a la construcción de lo que se ha acordado en la Definición. Finalmente las Pruebas incluirían todas las actividades asociadas a la conformidad del resultado respecto de lo definido. Así pues, como sugiere la siguiente figura, explicaré los 3 modelos de proceso señalados centrándome en cómo se distribuirían en ellos estas tres actividades.


Proceso en Cascada

El proceso en cascada (Waterfall) es el modelo clásico por excelencia. En un proceso en cascada las actividades se secuencian en su orden lógico (Definición, Ejecución y Pruebas), intentando además, y si se dispone de capacidad, hacer cierto solape entre ellas. La siguiente figura muestra cómo sería un proceso en cascada.


Ventajas
  • Es un modelo sencillo de entender por el cliente, aunque él suele estar más interesado en los plazos, costos y alcance del proyecto que en el proceso de desarrollo :-).
  • Es cómodo para el cliente pues su participación tiende a concentrarse al principio y al final del proyecto.
  • Tempranamente se puede acordar el alcance, costo y plazos del proyecto, (al finalizar la actividad de Definición). Esto está alineado con relaciones cliente-proveedor en las cuales se requiere fijar dichos elementos antes de comenzar la ejecución del proyecto.

Desventajas
  • Se asume que no habrá re-trabajo ni cambios. Una vez que una actividad se termina no volvería a realizarse, ni para abordar nuevos requisitos ni para realizar correcciones de fallos.
  • Las pruebas se concentran al final. En las actividades de pruebas es natural que se detecten fallos y que esto genere re-trabajo para corregirlos. Si el re-trabajo es significativo puede que no quede margen para que el proyecto termine dentro de los plazos o costos estimados. 
  • Si se desempeñan roles únicos y fijos, es difícil organizar al equipo. Por ejemplo, si se termina la definición y quienes trabajaron en ella no realizan otro tipo de actividades, deberían ser asignados a otro proyecto. Pero si se genera re-trabajo o aparecen nuevos requisitos tendrían que volver al proyecto.
Cuando se planifica un proyecto siguiendo un proceso en cascada usualmente se utiliza un diagrama Gantt, en el estilo del que se muestra en la siguiente figura:


Este diagrama Gantt delata claramente un proceso en cascada por la forma escalonada en la cual se distribuyen en el tiempo las actividades. Además, en general es muy difícil acertar quién y cuando iniciará y terminará de realizar una tarea (en un diagrama Gantt todas las tareas tienen un inicio y fin que se asocian con precisión a fechas del calendario).

Una crítica adicional que le haría al proceso en cascada, y en particular a la planificación que él condiciona, es que se puede perder fácilmente el foco respecto del producto o servicio que se espera como resultado del proyecto. Al intentar cuadrar las actividades que deben realizarse, dentro de las restricciones de plazos y costos, es fácil despistarse respecto de lo que debería ser mucho más importante: que el resultado conseguido sea satisfactorio para el cliente. Terminar actividades no es una buena medida del progreso del proyecto, especialmente cuando ello no conlleva una validación con el cliente respecto del resultado que se espera del proyecto. Terminar parte del resultado y validarlo con el cliente nos puede ofrecer más garantías respecto al adecuado progreso del proyecto. 

Un proceso en cascada NO es adecuado para desarrollo ágil, pues además de todas las debilidades mencionadas, es contrario a dos valores esenciales que destaca el agilismo: responder a los cambios y medir el progreso con el producto funcionando (aunque aunque no esté terminado) en lugar de hacerlo con la documentación resultante de actividades. 

Proceso Incremental

Un incremento en un producto o servicio es una nueva versión generada por la terminación de un conjunto de ítems de trabajo. Un ítem puede ser un nuevo requisito, una mejora en un requisitos ya incluido, o puede ser la corrección de un fallo detectado en un versión previa.

En un proceso incremental es clave contar con una lista ordenada del trabajo pendiente dado que desde allí y siguiendo el orden establecido iremos cogiendo trabajo para llevarlo a cabo. Dicha lista ordenada se denomina Backlog. Cada vez que se identifique un nuevo ítem (de cualquier tipo) debe incluirse en el Backlog en la posición que le corresponda según los criterios aplicados (Lectura recomendada: Gestión eficaz del Backlog). Así, el Backlog es el sitio donde se gestionarán los cambios, representados por nuevos ítems, modificaciones de ítems, eliminaciones de ítems o modificación de posición de ítems en la lista. Esto se ilustra en la siguiente figura: 


La siguiente figura ilustra un proceso incremental. Los ítems se cogen del Backlog según orden y dependiendo de la capacidad del equipo podrían abordarse a la vez más de un ítem. Cada vez que se termina un ítem se tiene la posibilidad de generar una nueva versión e incluso entregarla al cliente (Continuous Delirvery), sin embargo, habría que evaluar si conviene en ese momento hacer una entrega al cliente ya que el costo asociado a pruebas y despliegue y/o la molestia que puede ocasionar al cliente pueden hacer recomendable NO hacer entregas tan frecuentes.  


Ventajas
  • Las entregas al cliente pueden ser todo lo frecuente que se desee, llegando al punto de hacerlas cada vez que se termina un ítem. Esto permite hacer validaciones más frecuentes con el cliente. Además se evita acumulación de defectos entre cada versión debido a diferentes ítems y a su interferencia. Así también es más fácil detectar defectos.
  • La definición de un ítem se puede postergar hasta en momento en el cual se decide abordar el ítem. Esto favorece la resistencia al cambio, pues no se necesita hacer inversión de esfuerzo con anticipación. Mientras más tiempo hay entre la definición y la ejecución de un ítem, más riesgo existe que dicha definición caduque o que el ítem pierda prioridad.
  • Si el ordenamiento del Backlog es el adecuado (lo mas importante y de mayor riesgo primero, entre otros criterios disponibles), tempranamente podremos darnos cuenta cómo progresa el desarrollo, y en caso extremo podremos cancelarlo también tempranamente. 
  • Durante todo el proyecto se realizan todas las actividades, con lo cual aunque los participantes sean especialistas en ciertas actividades y no realicen otras, tendrán trabajo a lo largo de todo el proyecto (pero quizás con menor intensidad por no estar concentrado).

Desventajas
  • El cliente debe participar activamente a lo largo del proyecto, definiendo los ítems que se cogen desde el Backlog y probando las nuevas versiones. Esto más que una desventaja es usualmente visto como una incomodidad por el cliente, especialmente si no tiene conciencia del impacto que puede suponer su NO protagonismo en la rentabilización de su inversión en el desarrollo.

En un proceso incremental, lo ideal sería NO preestablecer el alcance y plazos, y fijar un costo por esfuerzo invertido. Es más, en determinados contextos NO es posible saber qué ítems serán abordados porque la demanda no está preestablecida. Esto ocurre en contextos de operaciones (no suele pasar en contextos de desarrollo), por ejemplo, mantenimiento cuando el producto ya está en producción, incidencias o tickets, etc. En estos casos simplemente no podemos hacer gestión de alcance, a lo más podemos tener límites para el esfuerzo invertido que de superarse lleven a renegociar o firmar un nuevo contrato.

Aún teniendo una demanda preestablecida de ítems podríamos ahorrarnos gestionar el alcance. Esto es posible si existe una relación de confianza entre el cliente y el proveedor, y se espera que a partir de una determinada versión el producto tenga madurez suficiente para entregarlo, y allí decidir si continuar o no trabajando de la misma forma, es decir, de ítem en ítem, de versión en versión. Si el cliente obliga al proveedor a comprometerse en alcance, plazos y/o costo, éste se vería  obligado a disponer de una definición y estimación para al menos los ítems más protagonistas, con lo cual perdemos en parte dicha ventaja de definición postergada. Además, en este caso, durante el proyecto también nos veríamos obligados a realizar una gestión de alcance continuamente, cada vez que se produzcan cambios en el Backlog. Lectura recomendada: Gestión de alcance en un proyecto ágil.

El método ágil Kanban propone un proceso de desarrollo incremental, y sin gestión de alcance.

Proceso Iterativo e Incremental

El proceso iterativo e incremental es un proceso incremental que tiene como complemento iteraciones (Sprints). La siguiente figura ilustra este proceso:




Ventajas
  • Tiene todas las ventajas del proceso incremental.
  • Usando Sprints se puede conseguir un equilibrio entre tener versiones frecuentes y no invertir demasiado esfuerzo en las actividades necesarias para generar, probar y revisar con el cliente cada versión. Así, en cada Sprint en general se incluirá un conjunto de ítems, es decir, cada nueva versión no es el resultado de un solo ítem.
  • Cuando los compromisos con el cliente son poco flexibles la gestión de alcance tiende a ser obligatoria. Trabajar con Sprint permite hacer una gestión de alcance más sostenible (a ritmo constante) pues aunque el período del Sprint sea breve, ofrece cierta calma respecto de los cambios que suelen aparecer al revisar una versión. Se realizaría gestión de alcance tanto a nivel de proyecto (o entrega) como a nivel de Sprint. Para la gestión a nivel de entrega, tal como vimos en el proceso incremental, se requeriría una definición y estimación para todos los ítems, con diferente nivel de detalle, discriminando entre los más ítems más protagonistas (los primeros en cogerse desde el Backlog) y los menos. En cambio para la gestión de alcance del Sprint, idealmente éste, al arrancar, debería tener definidas en detalle los ítems que se incluyen en él.
Para potenciar estas ventajas se recomienda que los Sprints sean de la misma duración para así conseguir una cadencia, un ritmo sostenible de trabajo. Scrum sugiere que los Sprints sean de a lo más 4 semanas de duración.

Desventajas
  • Al igual que en proceso incremental, el cliente tiene que participar activamente durante todo el proyecto (aunque como indiqué antes esto no debería ser una desventaja). Al usar Sprints el cliente tiene un cierto "respiro" en cuanto a la frecuencia de las revisiones de versiones, pues no se realizaría al terminar cada ítem sino que al terminar cada Sprint.  

Los métodos ágiles Scrum y Extreme Programming utilizan iteraciones (Sprints).

Conclusiones

  • No existe un modelo de proceso que sea el mejor para todas las situaciones, sin embargo, en contextos donde se esperan cambios un proceso incremental es más apropiado que uno en cascada. 
  • Si disfrutamos de una relación de confianza entre el cliente y el proveedor deberíamos intentar acercarnos a un proceso incremental (no iterativo), pues así no tenemos que "distraernos" en gestión de alcance, definiciones anticipadas y cálculos de estimación. 
  • Cuando los compromisos con el cliente son poco flexibles un proceso iterativo e incremental es lo recomendable pues en él la gestión de alcance es protagonista, tanto a nivel de cada Sprint como del proyecto completo.
  • Finalmente, es importante destacar que un mismo equipo puede ser responsable de varias líneas de trabajo, es decir, puede estar trabajando en diferentes proyectos, productos o servicios. El modelo de proceso más eficaz debe evaluarse en cada una de dichas líneas de trabajo.


Patricio Letelier

miércoles, 29 de octubre de 2014

¿Qué es ser ágil? ¿por qué debería interesar ser ágil?

¿Qué es ser ágil?
Un primer intento por responder esta pregunta ya lo hice en un post hace unos años: Agilismo en pocas palabras. Pero viendo que el sesgo mediático hacia Scrum sigue campando a sus anchas me he animado a dedicar la primera parte de este post a reivindicar que Scrum es solo una parte del agilismo :-), y la otra parte a argumentar por qué vale la pena ser ágil.

Ser ágil conlleva el comulgar y aplicar los valores y principios del Manifiesto Ágil. Lo claro y sencillo es la comprensión de dichos valores y principios generales, lo más complicado y menos evidente es cómo constatar en acciones concretas del día a día que efectivamente se están aplicando dichos valores y principios.

Podríamos suponer que si usamos un método ágil estaremos siendo ágil. Pero, ¿qué método deberíamos usar?, podríamos elegir entre los más populares: Kanban, Lean Development, Scrum o Extreme Programming. Pero, no son todos iguales, ¿en qué se diferencian? ¿cuál es el mejor?. Tengo la impresión que estas dudas están bastante extendidas, pues recurrentemente me encuentro con la necesidad de responder a esta cuestiones :-).

Detrás de los principios ágiles y de los métodos ágiles lo que debemos identificar y conocer son Prácticas Ágiles. El método Extreme Programming (XP) presenta una lista explícita y concreta de 12 prácticas ágiles, muy estrechamente relacionadas, apoyándose unas con otras y creando sinergia en su aplicación conjunta. Kent Beck el autor de XP explica en su libro que el apelativo "Extreme" del nombre de su método se refiere a aplicar el máximo de prácticas y en la mayor intensidad posible, a ello se refería con "extrema".

Si analizamos los métodos ágiles descubriremos que existen prácticas ágiles comunes entre métodos y otras exclusivas de alguno de ellos. Pero sin lugar a dudas, si optamos por elegir un método, estaremos ignorando prácticas ágiles de otros métodos que podrían sernos útiles. Lectura recomendada: ¿Kanban o Scrum?, that is not the question. Las prácticas ágiles deben verse como oportunidades para mejorar nuestra forma de trabajo, con lo cual NO debemos centrarnos en evaluar un método ágil para aplicarlo sino que debemos evaluar qué prácticas ágiles podemos aplicar, y tal como decíamos antes, mientras más prácticas y en mayor intensidad se apliquen, más significativa será la mejora que consigamos.

Para ayudar en la comprensión de las prácticas ágiles hemos desarrollado el sitio AgileRoadmap+, un servicio gratuito que presenta una lista de 42 prácticas ágiles extraídas de los métodos ágiles más populares, presentadas de una forma genérica (para facilitar su comprensión en contextos que no son de software), y establecidas con mucha granuralidad para facilitar su selección y decisión respecto de su nivel de aplicación.

Así pues, "ser ágil" no es un todo o nada. Probablemente no podrás aplicar todas las prácticas ágiles, ni todas en su mayor intensidad. Tampoco significa que no se apliquen practicas tradicionales. La implantación de prácticas ágiles podría conllevar una evolución que al menos al empezar deba convivir con prácticas más tradicionales. Algunas prácticas tradicionales son complementarias a las prácticas ágiles, es decir, cubren necesidades de proceso no abordadas por las practicas ágiles, por ejemplo, gestión de riesgos, gestión de proveedores, prácticas específicas del contexto (asociadas a aplicación de técnicas específicas para el análisis, diseño o construcción del producto). Todo esto tampoco significa que cualquier aplicación parcial de prácticas ágiles deba considerarse como una implantación ágil. Lo realmente interesante es tener conciencia de qué prácticas ágiles se están aplicando y en qué nivel de intensidad, y qué prácticas ágiles no se están aplicando (y por qué no).

¿Por qué debería interesarnos ser ágil?
Probablemente bastaría solo con la comprensión de las prácticas ágiles para convencernos que nos conviene aplicarlas :-). Sin embargo, podemos ser más exigentes en cuanto a los argumentos que nos animen a embarcarnos en una implantación de prácticas ágiles.

Una forma sencilla y sensata de argumentar la utilidad de las prácticas ágiles es estableciendo su contribución a objetivos del ámbito candidato para la implantación. Según esto, a continuación se presenta un esquema que relaciona objetivos de mejora y prácticas ágiles (del catálogo de prácticas ágiles de AgileRoadMap+).

A nivel global los objetivos se han clasificado en tres dimensiones de mejora (identificados por su letra inicial):


En el siguiente esquema se representan con puntos las prácticas ágiles, como sectores los objetivos y en los círculos concéntricos desde adentro hacia afuera se representa el grado de contribución de los objetivos a la correspondiente práctica, así, una práctica que esté más hacia el interior contribuye de forma mayor que una práctica que se encuentra más hacia el exterior. Además, una práctica puede estar repetida en diferentes sectores cuando contribuye a diferentes objetivos.

Descarga desde este enlace una presentación en la cual poniendo el cursor sobre el punto de la práctica puede leerse su nombre. Además, con la mismos números identificativos, en este enlace está la lista de prácticas ágiles del AgileRoadmap+.




Con esta información, seleccionando los objetivos más importantes en el ámbito en el cual se hará la implantación de prácticas ágiles podemos identificar qué prácticas ágiles pueden contribuir a conseguir dichos objetivos.

El objetivo "OBJ3: Gestionar eficazmente los cambios, tanto en los trabajos como en sus prioridades" está explicado en detalle en el post de este link.

En AgileRoadmap+ encontrarás además información respecto de desafíos de cada práctica y relaciones entre prácticas, lo cual te ayudará a seleccionar las prácticas ágiles con las que sería recomendable comenzar la implantación ágil.


Patricio Letelier


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