The DevOps Handbook: Principio de Flow (2/4)

Segunda parte del libro The DevOps Handbook

Una de las claves que veremos en este principio es la reducción del tiempo para desplegar cambios o nuevas funcionalidades, reduciendo la complejidad y el tiempo necesario para disponer de un incremento de valor en producción, el lead time. Pequeños incrementos donde toda la cadena trabaja con un único objetivo global, no en diferentes objetivos aislados según el equipo.

Fuente: cloudbees.com

Las claves de este principio son las siguientes:

Hacer el trabajo visible

Una clara diferencia entre el trabajo de una fábrica y el nuestro es que en la fábrica el flujo trabajo es visible y en cierta manera previsible. Para ver como fluye el trabajo en nuestra value stream debemos conseguir algo similar. Solo así podremos ver qué lleva más tiempo, dónde se bloquea o la cantidad de trabajo pendiente.

Ejemplos pueden ser los tableros kanban o de sprint planning, o las múltiples re-implementaciones de tableros que nos permiten visualizar y medir en qué punto se encuentra el trabajo.

Sólo de esta manera los stakeholders pueden ser capaces de conocer el volumen, las dificultades o priorizar mejor en función del trabajo pendiente. También podremos así proponer mejoras en los puntos más problemáticos, como hacer mejoras en nuestra cadena de trabajo o dar más apoyo donde realmente es necesario.

Limitar el trabajo en curso (WIP)

WIP: Work In Progress

En los equipos de desarrollo es común la llegada urgencias como errores, necesidades imperiosas, ocurrencias. Imaginemos el coste en el caso de una fábrica cuya cadena de producción se interrumpa de esa forma.

En el caso de tecnología el coste de las urgencias suele ser muy poco visible y además por desgracia ya presuponemos los retrasos de los proyectos software. Pero, ¿y si conseguimos eliminar de la ecuación los retrasos por trabajo no planificado?

Debemos evitar la existencia del trabajo en paralelo, cada cambio de contexto supone un esfuerzo y un tiempo perdido, que por desgracia también resta energía porque tenemos que lidiar con el multitasking para volver una y otra vez al trabajo principal.

Reducir el tamaño del trabajo

Otra de las claves para un flujo suave y ágil es reducir el tamaño del bloque de trabajo. En lugar de disponer un gran bloque que lleva meses desarrollar, es mucho más eficiente pequeños bloques de días o pocas semanas hasta ponerlo en producción.

Una de las claves Lean en reducir los tiempos de entrega y el aumento de la calidad, y se consigue disminuyendo el tamaño los bloques de trabajo. Grandes bloques pueden provocar una mayor presión sobre los trabajos en curso (WIP), una pérdida de calidad del resultado y unos tiempos de entrega muy altos.

Un ejemplo para el nuestro caso, trabajar con bloques pequeños donde podremos codificar, testear y desplegar de una forma rápida, y recibir información de su integración en producción de forma rápida. Esto nos permite resolver de forma casi inmediata cualquier incidencia o deuda técnica, ya que tenemos fresco el contexto de trabajo. El incremento de calidad así es más que notable.

Reducir el número de pasos (transferencia entre equipos)

Cada vez que se transfiere trabajo de un equipo a otro se requiere comunicación, reuniones, coordinación, verificaciones, etc., en resumen, se añade tiempo extra y cierta pérdida de información entre las transferencias.

En nuestra cadena de trabajo podemos reducir el número de transferencias automatizando procesos del flujo de trabajo, y reorganizando los equipos para permitir mayor autonomía en la entrega de valor al cliente desde su inicio hasta el final.

Identificar limitaciones de nuestro flujo y resolver de forma continua

Cuando en nuestra cadena de trabajo existe una limitación importante, debemos abordar una solución para resolver esa restricción. Algunos casos de nuestro flujo de trabajo con el desarrollo pueden ser:

• Disponer de un entorno de trabajo automatizado self-service, donde no tendremos que dedicar tiempo para configurarnos uno, o depender de que alguien nos provea de dicho entorno para trabajar, testear, etc.
• Automatizar el despliegue del código, donde están automatizados todos y cada uno de los pasos que hay que seguir para poner nuestro código en producción, en un tiempo mínimo y con una seguridad controlada.
• Automatización de tests, en lugar de tener flujos de tests manuales propios o delegar todo a equipos dedicados, automatizar la gran mayoría de ellos para que puedan ser ejecutados bajo demanda o durante los despliegues.
• Arquitectura desacoplada, proveer de mayor autonomía para completar los cambios, eliminando dependencias que no aportan valor y mejorando también la productividad del desarrollador.

Eliminar dificultades y pérdidas de tiempo de la cadena de valor

Esto es otro de los principios Lean: eliminar actividades que no mejoran el resultado de ninguna manera.

En el caso del desarrollo:

• Trabajo parcialmente acabado, debemos evitar llenar nuestro WIP de tareas inacabadas que solo hacen ruido pero que no aportan nada. Se vuelven obsoletas y pierden valor con el tiempo.
• Extra-procesos, tareas o actividades que no añaden nada al resultado, como pueden ser documentación no necesaria, revisiones o aprobaciones que no aportan nada.
• Extra-funcionalidades, añadir mayor complejidad y esfuerzo en requerimientos no solicitados que luego requerirán de revisiones, testing o mantenimiento.
• Multitasking, añadir varias tareas a una misma persona, que como ya hemos visto antes supone una pérdida de tiempo con los cambios de contexto y de calidad por la pérdida de foco.
• Esperas, evitar retrasos por paradas que impiden un flujo continuo, esto puede incentivar el multitasking.
• Movimiento, trasladar trabajo entre personas o equipos requiere de tiempo de comunicación y esfuerzo de transferencia de información. Evitar el traspaso de tareas hace ganar tiempo y eficacia.
• Información defectuosa, información incorrecta, parcial o compleja genera derroche de tiempo en solucionar posteriormente errores, que cuanto más tarde se detecten más tiempo conlleva.
• Trabajo manual o no habitual, todo proceso que no puede automatizarse o se realiza forma no habitual, suele significar pérdida de tiempo y riesgos.
• Trabajo heroico, cuando un flujo de trabajo está bien establecido no es normal que haya actos de trabajo extraordinarios para llevar adelante una puesta en producción. Esto resta energía y entusiasmo al equipo, especialmente cuando se vuelven habituales.

Ley de Conway

Formulado en 1967 por un programador llamado Melvin Conway:

Las organizaciones dedicadas al diseño de sistemas [...] están abocadas a producir diseños que son copias de las estructuras de comunicación de dichas organizaciones.

Esto nos viene a indicar que según las estructuras de los equipos así podría ser el diseño de nuestras aplicaciones, como ejemplo nos ilustra como un equipo hizo un compilador que se ejecutaba en una fase, mientras otro equipo hizo lo propio en dos fases porque tenían su equipo dividido en dos grupos.

Es posible que si diseñamos un proceso basado en cómo se hace actualmente, por ejemplo si tratamos de automatizar el trabajo manual de un almacén, si trasladamos el conocimiento tal cual, nuestro diseño será tan eficiente o ineficiente como el procedimiento original.