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.
