Uso de workflows por diversión y sus beneficios

Todo el mundo odia los "procesos", pero hay que asumirlo: sin un workflow establecido, no se va a ningún lado.

Dan Radigan Dan Radigan
Buscar temas

Todos los equipos de software tienen un proceso para llevar a cabo el trabajo. Normalizar el proceso (es decir, establecerlo como workflow) lo convierte en algo estructurado y repetible, lo cual lo convierte en escalable. En Atlassian tenemos un enfoque iterativo de la gestión del workflow porque nos ayuda a alcanzar nuestros objetivos más rápidamente y ejemplifica nuestra cultura de equipo. Somos expertos en la gestión de workflows ágiles (sin falsa modestia) y queremos ayudaros a que vosotros también lo seáis.

Empieza por lo fácil, empieza ahora

Al implementar un workflow para un equipo, siempre hay que empezar por lo fácil. Resiste la tentación de dedicar semanas de ingeniería (en exceso). Los workflows demasiado complejos son difíciles de entender y de adoptar, por no hablar de su adaptabilidad. Para los equipos de software, recomendamos estos estados de workflow básicos:

Por hacer

Trabajo que no se ha empezado

En curso

Trabajo en el que el equipo está trabajando activamente.

Revisión del código

Trabajo que está finalizado y en espera de revisión.

Finalizado

Trabajo completamente terminado y que cumple con la definición que tenga el equipo de finalizado.

En un gestor de incidencias, estos estados fluyen de uno al siguiente mediante transiciones que estructuran el flujo de trabajo.

Flujo de trabajo ágil | Orientador ágil de Atlassian

Algunos equipos de software incluyen estados adicionales en su workflow para ayudarles a realizar el seguimiento de los estados del trabajo con mayor precisión.

Esperando el control de calidad

Trabajo que se ha implementado, pero que está esperando la revisión de un encargado de pruebas (consulta nuestro artículo sobre pruebas ágiles para obtener más información).

Listo para hacer un merge

Código que se ha revisado y está listo para hacer un merge con el master o rama de versiones

Cada estado del workflow no necesita un control por parte de distintas personas. A medida que el equipo ágil madura, los desarrolladores pueden asumir más parte del trabajo, desde el diseño hasta la entrega. Después de todo, un equipo autónomo que pueda controlar trabajo heterogéneo es uno de los distintivos de la agilidad.

Habla de cada punto problemático en la retrospectiva del equipo y recuerda que cada equipo tendrá valores ligeramente diferentes en función de su proyecto, recursos tecnológicos y método preferido para trabajar. Por eso es tan importante elegir un gestor de incidencias que tenga una configuración de flujo de trabajo flexible. Demasiados equipos sacrifican su estilo de trabajo para adaptarse a un conjunto de herramientas concreto, lo cual es frustrante para todos. Los miembros del equipo empiezan a evitar esa herramienta, extendiendo la frustración por todo el equipo y creando caos en general. Y cuando falla la motivación, la productividad se resiente. Son dos contratiempos que todos queremos evitar.

Los equipos que acaban de adoptar metodologías ágiles o que no tienen habilidades interdisciplinares a menudo terminan con "minicascadas" en su flujo de trabajo. Por ejemplo, el equipo de diseño inicia un elemento de trabajo con un modelo. El equipo de desarrollo realiza la implementación. El equipo de pruebas confirma la calidad. Cada estado está bloqueado hasta que se complete el anterior. ¿Te suena? Eso es una cascada. No obstante, se puede hacer mucho mejor con flujos de trabajo ágiles que desbloqueen el equipo y simplifiquen el desarrollo.

Optimiza el workflow

Cuando te sientas cómodo con el flujo de trabajo básico y estés listo para personalizarlo, crea estados para cada tipo de trabajo del proceso del equipo. La idea, el diseño, el desarrollo, la revisión del código y las pruebas son funcionalmente diferentes y pueden ser estados individuales. Intenta lograr un conjunto lean de estados que comuniquen claramente la fase en la que se encuentra un elemento de trabajo.

Los estados de proyecto también se pueden compartir con el resto de la organización. Al crear un flujo de trabajo, piensa sobre qué métricas es importante informar y qué podrían aprender los miembros que no sean del equipo. Por ejemplo, un flujo de trabajo bien diseñado responde a las siguientes preguntas:

  • ¿Qué trabajo ha finalizado el equipo?
  • ¿El backlog de trabajo está aumentando o sigue el ritmo del equipo?
  • ¿Cuántos elementos hay en cada estado?
  • ¿Hay cuellos de botella que estén ralentizando al equipo?
  • ¿Cuánto tarda una tarea media en completarse?
  • ¿Cuantos elementos de trabajo no han pasado nuestros estándares de calidad a la primera?

El siguiente paso para optimizar el flujo de trabajo es garantizar un flujo constante de trabajo. Los límites del trabajo en curso (WIP) imponen un número máximo y mínimo de incidencias en un estado concreto del flujo de trabajo, asegurando que cada estado tenga trabajo suficiente para involucrar a todo el equipo, pero no demasiado para evitar que dejen de estar centrados en las prioridades. La aplicación de límites en el trabajo en curso mostrará rápidamente los procesos que ralentizan el trabajo general a lo largo del canal. A medida que el equipo aprenda a optimizar teniendo en cuenta los límites WIP, aumentará el rendimiento. (Consulta el artículo sobre límites WIP para obtener más información).

Los retos de escalar un workflow

Las organizaciones que cuentan con varios equipos ágiles se enfrentan a retos especiales con los flujos de trabajo. A menudo, los equipos desean optimizar su propio flujo de trabajo para reflejar su cultura y sus procesos únicos. Es algo perfectamente comprensible. Sin embargo, puede suponer un problema cuando distintos equipos usan procesos diferentes en el mismo proyecto.

Los equipos ágiles que trabajan juntos se benefician al compartir el mismo flujo de trabajo. Usar el mismo flujo de trabajo hace que realizar transiciones de trabajo entre equipos ágiles sea más fácil, dado que usan las mismas convenciones para definir y entregar los trabajos. Crear un proceso común normalmente implica concesiones por parte de ambos equipos. Eso está bien: así los equipos aprenden los unos de los otros y al final, el resultado será un flujo de trabajo mejor.

Consejo de experto

Con Jira Software, el gestor de incidencias de Atlassian, los equipos pueden compartir flujos de trabajo, pero tienen representaciones distintas del proceso en su tablero ágil. Esta capacidad da lugar a opciones de visualización flexibles sin sacrificar el activo compartido de flujo de trabajo.

Independientemente de tu workflow, el proceso para desarrollarlo también debería ser ágil. Habla sobre ello en las retrospectivas de vez en cuando y adáptalo a medida que cambie la cultura y la composición de los equipos.

A continuación
Epics, stories, themes