Formación escrita en DevOps

¿Cómo facilitar el flujo de trabajo con DevOps?

En DevOps, el flujo es la cadena completa de producción de software, desde la idea hasta el código que se ejecuta en producción. Usted y sus equipos se encargan de crear y mantener un flujo fiable, coherente y rápido para cumplir y superar los objetivos de la organización y aventajar a otros productos y servicios de su mercado.

Defina una misión para su transformación DevOps

Una vez formado el equipo de DevOps, el siguiente paso es definir una misión. El equipo necesita una misión común para funcionar correctamente. Sin ella no podrá priorizar el trabajo crítico ni distinguir los impedimentos graves de las tareas secundarias. La misión debe ser ambiciosa e inspiradora y, al mismo tiempo, alcanzable en el plazo establecido.

La misión debe adaptarse a su equipo de DevOps. Se basa en las características, retos y objetivos de la organización al atender a los clientes internos y externos que interactúan con el equipo.

Algunos ejemplos de misiones para iniciar la transformación DevOps son:

• Reducir en un 75 % el tiempo medio desde el registro del código hasta su entrada en producción en 3 meses.
• Reducir en un 33 % el tiempo medio desde la solicitud hasta la entrada en producción en 6 meses.
• Reducir en un 50 % el número de incidentes de producción en 12 meses.

¿Qué es un flujo de valor y quién participa en él?

Para mejorar su trabajo, necesita conocer su flujo de valor. En los sistemas de TI, es la secuencia de actividades necesarias para diseñar, construir y operar un producto y servicio de software concreto. También identifica el personal, los conocimientos, los servicios auxiliares y los materiales que permiten que fluya el valor.

En una estructura organizativa compleja, nadie puede identificar por sí solo todo el flujo de valor. Por eso deben participar todos los integrantes del equipo de DevOps, las partes interesadas, los proveedores, los representantes de clientes y, si es posible, los propios clientes.

Elabore un mapa del flujo de valor para encontrar oportunidades de mejora

Un mapa del flujo de valor permite a usted y a su equipo de DevOps visualizar cómo se realiza un trabajo típico en su organización de desarrollo y entrega de software. El objetivo no es documentar exhaustivamente todos los pasos. Es comprender el flujo de trabajo habitual lo suficiente para identificar las principales ineficiencias, restricciones, problemas y pérdidas de tiempo y recursos.

Cuando los ingenieros de desarrollo y operaciones se sientan juntos por primera vez a trazar un mapa del flujo de valor, suele ser la primera vez que operaciones comprende cómo afectan a desarrollo los servidores de bases de datos mal configurados y sin espacios de tablas. Del mismo modo, suele ser la primera vez que un ingeniero de desarrollo ve las consecuencias de entregar software sin funciones integradas de monitorización, disponibilidad, capacidad de prueba y configuración.

Elimine tantos traspasos, restricciones y desperdicios como pueda

Algunos de los factores de eficiencia más importantes, pero que suelen pasarse por alto, son los traspasos, el desperdicio y las restricciones. Cuando se transfiere una actividad de un equipo a otro hay que avisar, hacer solicitudes, programar, priorizar o reducir la prioridad y resolver conflictos.

Cada vez que el trabajo pasa de un equipo a otro se pierde información y aumenta el tiempo total de entrega del flujo de valor.

Para superar estos problemas:

• Cuestione el tiempo necesario para cada traspaso. Por ejemplo, según el mapa anterior, pasan 80 horas hasta que el equipo de despliegue recoge código que ya ha superado las pruebas. ¿Por qué? ¿No podemos automatizar ese proceso? Claro que podemos.
• Elimine el desperdicio que generan los traspasos repetitivos. Según el mapa anterior, el equipo de pruebas devuelve el 65 % de las funcionalidades a desarrollo. Las correcciones de algunos defectos se entregan hasta 3 veces antes de que las apruebe el equipo de pruebas. ¿Podríamos acelerar las iteraciones integrando mejor a desarrollo y pruebas? El gran número de defectos también indica que algo no funciona bien en desarrollo. Hay que identificar y resolver las causas de esos problemas de calidad.
• Cuestione los traspasos y elimine todos los que pueda. Según el mapa, una vez refinada una solicitud pasan 320 horas hasta que la tramita el responsable de aprobarla. ¿Por qué hace falta ese responsable? ¿Qué valor aporta al flujo? ¿Tiene suficiente información y perspectiva para decidir bien? Si se incorporara al equipo que refina las solicitudes, conocería mucho mejor lo que aprueba y se eliminaría un traspaso de 320 horas. Mientras sigan existiendo restricciones y obstáculos que ralenticen el flujo, es difícil esperar mucho de DevOps.

DevOps exige hacer estas preguntas para cambiar la forma de trabajar. No todos en su organización se alegrarán de oírlas. Pero usted ya está preparado.

Haga visible el flujo para todos

Para que el trabajo avance de izquierda a derecha y su organización DevOps cumpla sus objetivos, necesita herramientas y mecanismos que hagan visible el flujo. En TI, basta un clic para transferir trabajo de un equipo a otro en su flujo de valor. Pero, con tareas incompletas, dependencias incoherentes y malentendidos, es habitual que el trabajo rebote entre equipos, con «un paso adelante y dos atrás», y avance demasiado despacio o ni siquiera avance.

Es importante que todo el mundo pueda ver el flujo, dentro y fuera del equipo. DevOps utiliza la lista de trabajo pendiente del producto, la lista de planificación del sprint y los tableros Kanban para visualizarlo. Estos tableros deben incluir tanto las tareas del equipo como todo el flujo, desde la idea inicial de los productos y servicios hasta su mantenimiento operativo y su fin de vida. Así, cuando se estanque el trabajo, todos lo verán rápidamente y compartirán la responsabilidad de eliminar los obstáculos para que vuelva a fluir de manera continua.

Limite el tamaño de los lotes y el trabajo en curso

Una investigación realizada en Stanford University descubrió que hacer varias cosas a la vez es menos productivo que hacer una sola cada vez. También observó que quienes se ven bombardeados habitualmente por varios flujos de información electrónica prestan menos atención, recuerdan peor y cambian de una tarea a otra con menos facilidad que quienes completan una tarea cada vez.

Para su equipo de DevOps, esto significa reducir el trabajo en curso y limitar el tamaño de los lotes de código que entrega. Por ejemplo, puede permitir un máximo de 6 tareas de desarrollo en curso para evitar cambios continuos de contexto y concentrarse en el trabajo. También puede estimar cada tarea en puntos de historia con números de Fibonacci (0, 1, 2, 3, 5, 8, 13, 21, 34, ..) y dejar que el equipo procese hasta un total determinado de puntos (velocidad) en un periodo dado (sprint).

Además de mejorar la calidad y la productividad, limitar el tamaño de los lotes ayuda a identificar y resolver antes las causas raíz de los problemas. Al terminar una tarea, registre el código en el repositorio común, valídelo en la plataforma de integración continua y despliéguelo en producción. Un lote pequeño facilita identificar problemas en producción debidos a la entrega y simplifica cualquier reversión necesaria. Además, al entregar continuamente en producción, el equipo sentirá el orgullo constante de contribuir a la misión de la organización. Compare esta forma de trabajar con la moral, la motivación y los retos técnicos de equipos que programan durante 8 meses sin entregar una sola línea de código a producción.

Dedique el 20 % de su tiempo a reducir la deuda técnica

Si su organización no reserva tiempo para reducir la deuda técnica y sigue acumulando soluciones provisionales sobre soluciones provisionales, llegará un punto en que todos los ingenieros dedicarán todo su tiempo a resolver problemas. En términos financieros, su organización solo estará pagando los intereses de la deuda.

CONCLUSIÓN

En este capítulo hemos explicado qué son el flujo de valor y el flujo de trabajo en DevOps, por qué importan y cómo conseguir que el trabajo avance por el flujo de valor.