miércoles, 27 de diciembre de 2017

Un modelo conceptual básico para apoyar la implantación de métodos ágiles

Antes de presentar nuestro modelo conceptual comentaré lo que en mayor medida me ha motivado a escribir este post: el uso indiscriminado del término "Proyecto" :-).

En el PMBOK un proyecto se define como: “A project is a temporary endeavor undertaken to create a unique product, service, or result. The temporary nature of projects indicates that a project has a definite beginning and end. ...". Sin embargo, en la mayoría de empresas (y herramientas) se usa el término "Proyecto" casi como sinónimo de "Trabajo", incluso sin existir un inicio y fin predeterminados, o cuando el resultado no es algo claramente nuevo (como es el caso de trabajos de mejora y mantenimiento en general). Más allá de cuestiones de terminología, lo realmente importante es que muchas veces esta denominación marca la estrategia con la que se aborda el trabajo. Por ejemplo, y siendo exagerado, poco sentido tiene el imponer una planificación con Sprints rígidos, entregas pre-establecidas, cálculos de esfuerzo y de capacidad requerida, etc., solo porque el trabajo que se realizará se denomina "Proyecto de mantenimiento de 2018", y siendo que se trata solo de un acuerdo de mantenimiento para un producto software que acabamos de entregar a un cliente. Obviamente dicha estrategia es errónea básicamente porque al alcance a priori es desconocido, no se sabe qué mejoras o correcciones se solicitarán durante el período de realización del trabajo.

Este uso indiscriminado del término Proyecto probablemente está detrás de la confusión que delatan afirmaciones tales como; "para algunos proyectos usamos Kanban y para otros Scrum", "usábamos Scrum pero hemos decidido pasarnos a Kanban". Probablemente la cuestión de fondo es que en ciertos contextos no es conveniente usar Sprints (una de las prácticas de Scrum), o al menos no usarlos con una interpretación rígida (ignorando que los Sprint podrían ser "flexibles" en contenido y/o en duración). Lo lamentable son las decisiones tomadas a nivel de método, es decir, cuando se usa uno u otro de forma exclusiva. La mejor opción es usar las prácticas sugeridas por los métodos, no necesariamente todas, combinándolas, adaptando su intensidad, teniendo cuidado de no hacer interpretaciones radicales. Para no extenderme en esto recomiendo echar un vistazo a los siguientes posts:
Obviamente, no se trata de prescindir del concepto y término "Proyecto", sino de usarlo como un elemento más de la estrategia establecida para abordar un determinado contexto de trabajo. Es decir, asociarlo a trabajos que tienen comprometidas fechas de inicio y fin, donde el alcance está previsto (aunque luego pueda haber ciertos cambios), ya que en esta situación es útil incluir mecanismos de planificación y seguimientos acordes con la rigidez de dicho compromiso.

Cuando me refiero a "trabajo" puede tratarse de un esfuerzo no solo asociado a un producto, podría ser de un servicio prestado. En el resto de este post usaré el término "producto" pero lo comentado también sería aplicable a "servicio".

Una de las características del enfoque ágil es destacar el valor del resultado del trabajo y cómo es percibido por el cliente/usuario. Esto ha cambiado el foco hacia el producto, el éxito ya no es solo una cuestión de cumplir con alcance-plazos-costos (Proyecto). Un producto exitoso se continuará desarrollando y mejorando siempre y cuando se vea reforzado por el valor que aporta a sus cliente/usuarios.

Así pues, un producto podría tener asociados varios proyectos a lo largo de su existencia. Por ejemplo: el proyecto que desarrolla el producto, un proyecto que mejora sustancialmente el producto original, un proyecto de integración con otros productos, etc. Sin embargo, en paralelo a dichos posibles proyectos, un producto podría requerir cierto trabajo de soporte y mantenimiento más continuo (que también hay que gestionar), no enmarcado en esos proyectos.

Además, el contexto de un producto puede cambiar a lo largo de su existencia. Un producto software antes de su primera entrega genera trabajo relativo a su desarrollo, lanzamiento y puesta en marcha, pero a partir de su primera entrega requiera además de mantenimiento y soporte para los usuarios.

Un modelo conceptual para organizar y abordar el trabajo con un enfoque ágil


He tenido la oportunidad de conocer el contexto de trabajo de muchas empresas. Gracias a esta experiencia y con el afán de establecer unas pautas de implantación y metodológicas asociadas a métodos ágiles hemos ido refinando un modelo conceptual, asociado a nuestro enfoque metodológico TUNE-UP Process.


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

Cada UT desde su creación hasta su término sigue un Workflow, que corresponde a una secuencia de Actividades (pudiendo existir actividades realizadas de forma alternativa o en paralelo). Los workflows determinan los tableros kanban que se utilizarán, en los cuales las actividades del workflow corresponden de izquierda a derecha con las actividades del tablero kanban. En principio cada tablero kanban mostrará las UT que siguen ese workflow, pero podrían mezclarse (integrarse) varios workflows en un mismo tablero kanban, especialmente si comparten actividades. Para el diseño de workflows y tableros kanban recomiendo leer: "Workflows flexibles. Parte I y Parte II" y "Tableros kanban. Parte I y Parte II".

Una Línea de Trabajo es el contenedor más global de UT. Podríamos NO reconocer Líneas de Trabajo (es decir, tener solo un contenedor para todo el trabajo) pero hay varios factores que hacen conveniente establecer diferentes Líneas de Trabajo, entre ellos:
  • Planificación y seguimiento del trabajo. Trabajos que normalmente tienen distintos calendarios de compromisos o acuerdos de ritmos de entrega.
  • Equipos de trabajo. Trabajos asignados diferentes equipos de trabajo.
  • Distribución de capacidad de los equipos. Trabajos que en un período de tiempo compiten por asignación de capacidad.
Así pues, una Línea de Trabajo normalmente tiende a estar asociada a un producto o servicio y a un equipo de trabajo (pudiendo un equipo ser responsable de varias Líneas de Trabajo). Además, si la naturaleza del trabajo asociado a una Línea de Trabajo es diversa, la Línea de Trabajo puede tener asociados varios Workflows, para que a cada UT se le aplique un workflow con las actividades que le sean más adecuadas.

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

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

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

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

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

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

Los Sprints son importantes para ayudar a gestionar el desarrollo incremental a corto plazo. Sin embargo, en situaciones NO planificables (cuando el alcance no se conoce totalmente de antemano o suele variar significativamente) no es sensato imponer una disciplina de Sprint rígidos en contenido y/o duración, dado que cualquier previsión probablemente se verá muy afectada por cambios durante  el Sprint. En el caso extremo, cuando gran parte del esfuerzo de planificar Sprints se pierde por los continuos cambios, podría prescindirse de usar Sprints y trabajar solo con un Backlog priorizado.

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

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

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

¿Cómo empezar a organizar el trabajo de forma ágil?

Recorriendo los elementos del modelo conceptual propuesto debería hacerse las siguientes actividadess (no necesariamente en el orden presentado):

  • Identificar las Líneas de Trabajo. Para comenzar se podría considerar que cada producto o servicio es una Línea de Trabajo, cada una de ellas con el nombre de dicho producto o servicio, por ejemplo, si tenemos el producto ACME, establecemos la Línea de Trabajo ACME. Si se diera el caso (ahora o más adelante) que el producto ACME tuviese trabajo de desarrollo, mantenimiento y soporte, podría ser conveniente tener más de una Línea de Trabajo asociada al mismo producto, en este ejemplo, las Líneas de Trabajo: ACME Desarrollo, ACME Mantenimiento, y ACME Soporte. La división o agrupación de Líneas de Trabajo puede variar de acuerdo con las necesidades, lo importante es que en un momento dado las Líneas de Trabajo sean cómodas y efectivas para la gestión del trabajo asociado.
  • Asignar los colaboradores (el equipos) responsables de cada Línea de Trabajo.
  • Definir los Workflows que necesita cada Línea de Trabajo según la actividades que se deben realizar sobre sus UT. Los Workflows podrían reutilizarse entre diferentes Líneas de Trabajo. Además, una Línea de Trabajo puede utilizar varios Workflows, según lo requieran sus UT.
  • Para cada Línea de Trabajo decidir si se trabajará con Sprints y cuáles serán sus características. Esto lo comento en detalle en el post  Sprints, "welcome to the real world"
  • Establecer Proyectos cuando sea necesario. Normalmente un Proyecto se asocia a una Línea de Trabajo, pero podría darse el caso que en un mismo Proyecto se vean involucradas varias Líneas de Trabajo.

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

Para finalizar, y volviendo a la motivación original de este post; el abuso del término Proyecto, en mi opinión este abuso se ve fomentado además por herramientas (como en JIRA o Target Process) con deficiencias conceptuales importantes. Si a todo se le llama Proyecto, cuando un proyecto termina ¿te ves obligado a crear otro proyecto con el trabajo restante o nuevo que surge y que está asociado al mismo producto? ¿le cambias nombre y fechas al proyecto terminado?. Cuando se solapa para un mismo producto el desarrollo de nuevas funcionalidades con el mantenimiento continuo (de respuesta rápida y con urgencias) ¿se enmarca todo este trabajo en un mismo proyecto?. En esta temática, te recomiendo leer: Gestión ágil de productos. Líneas de trabajo en un producto a partir de su primera entrega.



Patricio Letelier

www.tuneupprocess.com 

No hay comentarios:

Publicar un comentario