DevOps y Agile : de la mano por favor!

En una organización de tecnología , el equipo de operaciones proporciona la interfaz directa entre tecnología,  negocio y usuario final (cliente). A menudo, operaciones es el primer punto de contacto para la comunidad de usuarios finales. El equipo DevOps:

Una organización de operaciones generalmente incluiría al grupo que se hace cargo de los "incrementos a implantar" completados del equipo de desarrollo  y los pone en producción, así como también al equipo que brinda soporte de "Nivel 1" para el negocio.

El equipo de operaciones tiene que ser eficiente y estar bien informado para poder brindar un servicio de calidad al negocio, eficiente desde el punto de vista de lanzar los ejecutables completados a producción rápidamente, y conocedores en términos de poder entender las consultas de los usuarios y proporcionar la respuesta correcta.

A menudo, cuando el equipo de desarrollo crea la solución, los requisitos funcionales reciben toda la atención, pero los requisitos de despliegue y soporte por el contrario, no.

Esto genera sorpresas durante la implementación de la aplicación, el soporte de producción y la recuperación ante problemas que surjan. Si tales casos se repiten, las empresas perciben que tecnología es menos receptivo e impredecible, y que no aporta el valor que debería aportar.

En un escenario Agile, el equipo de desarrollo produce funcionalidad de trabajo al final de cada sprint. Sin embargo, la funcionalidad completa tendrá que esperar hasta que llegue la fecha de lanzamiento (release) en muchas ocasiones.

Incluso en la fecha de lanzamiento, si el equipo de operaciones no está preparado para la integración y la implementación o si el negocio no está listo para entrar en funcionamiento con las pruebas y validaciones de la nueva funcionalidad, habrá retrasos en el lanzamiento. Menor tiempo de lanzamiento al mercado, un beneficio clave de Agile.

Este escenario se ilustra a continuación:

Los colores rojos significan desperdicio (waste), pérdida de oportunidad, y retraso.

DevOps es una filosofía en la que los equipos de negocio, desarrollo y operaciones colaboran de forma continua para garantizar que las soluciones de Tecnología estén disponibles para el negocio a tiempo y que se ejecuten sin interrupciones.

Requiere automatización, colaboración, cambio cultural y una estructura organizativa que es menos compleja y fácil de gestionar y "navegar" por ella. Aborda a las personas, el proceso y las herramientas, así como las dimensiones tecnológicas necesarias para asegurar esta colaboración y sincronizar a los diferentes interesados ​​para pasar la funcionalidad a producción más rápidamente.

DevOps permite la realización de los beneficios de una entrega más rápida de la funcionalidad lograda a través de Agile.

Un requisito fundamental de DevOps es que el equipo de operaciones esté continuamente involucrado con el equipo de desarrollo durante todo el ciclo de vida del desarrollo de la solución.

La parte de operaciones debe participar desde la etapa de visión para comprender la visión del negocio, las épicas y las líneas de tiempo de lanzamiento. También debe contribuir a determinar la viabilidad técnica y de programación de la solución. TIENE QUE SER GLOBAL a la organización.

Desde la etapa de visión hasta la etapa de desarrollo, el equipo de operaciones debe proporcionar las aportaciones necesarias al equipo de desarrollo para que puedan construir y validar los requisitos relacionados con las operaciones.

La filosofía DevOps es mejora en las herramientas, mejora del rendimiento, mejora de la organización, mejora de los procesos y cambio de cultura:

Debe participar en la visión inicial, en el inicio del product backlog, durante la sprint planning, en el desarrollo del sprint con la construcción y testing y finalmente en la puesta en producción del incremento realizado.

El equipo de tecnología junto con los líderes de la organización deberían equipar al PO con la apreciación básica de los requisitos no funcionales (NFR), junto con los requisitos relacionados con aspectos técnicos, como los siguientes:

- Plataformas de implementación y soporte

- Su disponibilidad y limitaciones

- Dependencia de los proveedores en el mantenimiento de la infraestructura

- Interfaces / aplicaciones de terceros necesarias para las soluciones finales

No se espera que el PO sea un experto en estas áreas, pero debería ser capaz de prever tales requisitos y comunicarlos a las partes interesadas apropiadas en tecnología  y en negocio; y eso se consigue con la implicación de DevOps desde la concepción del producto inicial. El PO debe rodearse de un staff entre los que se encuentra DevOps.

Normalmente, el Product Backlog se centra en historias épicas e historias relacionadas con los requisitos funcionales. El PO y el equipo de desarrollo están bien capacitados para intercambiar ideas, analizar épicas y documentar los requisitos funcionales.

Sin embargo, a menudo los NFR no están bien especificados ni identificados correctamente. Además de los requisitos funcionales, la acumulación de trabajo debe describir elementos como los siguientes:

- Requisitos de desempeño

- Requisitos técnicos relacionados con la implementación y el soporte

- Requisitos para desarrollar las pautas para una rápida reversión y avance

- Requisitos de seguridad / firewall

El equipo de desarrollo  es multifuncional y autoorganizado. ¿Debería este equipo incluir a una persona operaciones también? Si, pero  esto depende de la habilidad de los miembros del equipo de operaciones y la permeación cross que tengan en la organización.

Por lo general, en una organización de tecnología de nueva creación, algunos de los desarrolladores o testers también serían responsables del despliegue y del soporte de Nivel 3 (corrección de errores). En tales casos, los requisitos relacionados con el despliegue y el apoyo se debatirán ampliamente en las reuniones de planificación y revisión.

Sin embargo, en las organizaciones grandes, las operaciones necesitarían un gran equipo dedicado a asumir el código completo de múltiples equipos de desarrollo y desplegarlos. En tales casos, la rotación laboral podría ser una propuesta útil.

 Es decir, algunos de los desarrolladores podrían desempeñar el rol de operaciones durante cierto período de tiempo, y algunos de los miembros del equipo de operaciones con la aptitud adecuada podrían formar parte del equipo de desarrollo durante un período de tiempo determinado.

De esta forma, el lado de operaciones estaría bien representado durante el ciclo de desarrollo. Se polinizaría el conocimiento cruzado y la creación de perfiles cross.

Otra palanca clave para involucrar  a operaciones en el ciclo de desarrollo es crear una relación de transparencia basada en la participación de operaciones en la Definición de Hecho. Junto con los elementos estándar de codificación, pruebas y documentación, la validación del código en la plataforma de implementación (por ejemplo, una caja de producción simulada), instrucciones de soporte específicas como parte de la documentación y una ejecución de estas instrucciones también deben incluirse en la definición de hecho. Aquí nuevamente, las aportaciones del equipo operaciones son cruciales.

Es una gran idea incluir al equipo de operaciones durante la planificación de sprints y en las reuniones diarias seleccionadas en las que el equipo debata los aspectos de operaciones, realizadas y notificadas a dicho equipo de operaciones bajo demanda, puesto que bajo su participación en las planificaciones de los sprints estas reuniones se pueden anticipar. Cualquier dependencia de los proveedores de infraestructura y los integradores de sistemas debe considerarse en esta etapa utilizando las aportaciones del equipo de operaciones.

Cuando el equipo de operaciones está continuamente involucrado en el ciclo de desarrollo, no hace falta decir que también deberían ser parte de la revisión del sprint. El equipo de desarrollo debe demostrar las características relacionadas con las operaciones de la solución.

Claramente, todas las revisiones de sprint pueden no incluir características relacionadas con operaciones. Sin embargo, si el equipo de operaciones es parte de las revisiones, tienen la oportunidad de ver lo que está por venir y proporcionar entradas para los siguientes sprints para mejorar el producto e incluir los requisitos de operaciones también.

Aquí nuevamente, si uno o más de los miembros del equipo de desarrollo representan a operaciones, es más fácil obtener esta alineación. Si operaciones es un equipo separado, el equipo de desarrollo debe asegurarse de obtener feedback el equipo de operaciones para revisiones de sprints.

Cuando varios equipos de Scrum trabajan en una solución, la integración de la salida de cada equipo debe planificarse y ejecutarse cuidadosamente. Cada equipo de Scrum debe tener en cuenta los requisitos de operaciones y las características en consonancia con los requisitos. Los propietarios del producto deben tener una visión del producto final, cómo se desarrollará a través de múltiples equipos de Scrum y dónde y cómo se implementará.

Deben involucrar a los equipos de operaciones para proporcionar entradas específicas para cada equipo de Scrum. En los eventos de Scrum of Scrums, las operaciones deben unirse y validar que los equipos de Scrum los incluyen en sus planes y demos.

DevOps, al igual que Agile está en continua evolución, adaptación y mejora:

DevOps y Agile se complementan entre sí y ayudan a la empresa y a los equipos de lanzamiento a planificar el calendario anual. Con el compromiso continuo y la colaboración con el equipo de desarrollo, el equipo de operaciones sabe qué funcionalidad aparecerá y cuando.

Con esa idea, y utilizando el patrón de finalización de sprints, los equipos de desarrollo y operaciones deberían ser capaces de predecir con razonable precisión las posibles fechas de lanzamiento. Finalmente, deberían esforzarse por alinear el plan de lanzamiento con los planes de sprints. Y cuando se produzca esta alineación, el equipo de soporte podrá trasladar la funcionalidad completa a producción más rápidamente y en intervalos más cortos, ¡y se estará llegando a los beneficios claves de Agile! Reducción del time to market, calidad y retroalimentación rápida.

Un modo rápido de medir dicha colaboración, involucración y alineamiento es con KPIs como estos:

- Porcentaje de cumplimiento de las fechas de pasos a producción planificadas.

- Porcentaje de incremento en el número de lanzamientos realizados.

- Tiempos de lanzamientos a producción.

- Defectos atribuibles a los requisitos de plataforma y soporte.

- Porcentaje de NFRs cumplidos.

- Porcentaje de Rollbacks realizados.