Las mejores prácticas de gestión de liberaciones de ITSM explicadas aquí están basadas en el caso de uso de una compañía de telecomunicaciones de mediano tamaño. La compañía enfrenta múltiples problemas que le cuestan alrededor del 25% de sus clientes, y una disminución en su productividad. La razón principal era la falta de procesos eficientes en gestión de liberaciones y procedimientos. Descubra cómo esta compañía mitigó las fallas de liberaciones y aumentó sus liberaciones durante tres meses.
"La gestión de liberaciones es el proceso de administrar, planear, programar y controlar un software diseñado desde diferentes etapas y entornos". - Wikipedia
"La gestión de liberaciones se trata de compilar, probar e implementar, mientras la entrega continua se trata de compilar, probar e implementar usando automatización." - Charles Betz, analista de investigación Forrester
"Para mí, la pieza número uno de automatización a buscar es un software de prueba" -Jayne Groll CEO Instituto DevOps.
Visión general
Una compañía mediana de telecomunicaciones perdió cerca de un 25% de sus clientes en un periodo de tres meses debido a múltiples retrasos en liberaciones críticas de software. Claramente, los procesos de gestión de liberaciones existentes no fueron efectivos, y la compañía tuvo de hacer una resolución de problemas y llegar con un proceso concreto para arreglar las cosas.
La compañía formó un nuevo equipo de gestión de liberaciones para evaluar y simplificar el flujo existente en sus procesos de gestión de liberaciones. En los siguientes 3 meses, un nuevo equipo fue capaz de publicar las versiones pendientes y dos versiones programadas de aplicaciones rediseñadas. Debajo podrá ver cómo el equipo simplificó el proceso de liberaciones de ITSM. Los pasos que el equipo tomó reflejan las buenas prácticas que pueden ser empleadas por cualquier organización de TI, incluyendo la suya.
El nuevo equipo quería una imagen detallada del flujo actual del proceso de gestión de liberaciones. Iniciaron con un número de sesiones tutoriales con individuos clave involucrados en procesos de software. En estas sesiones, el equipo aprendió que un software de CRM estuvo en espera de ser liberado por 2 meses antes de completarse.
Basado en las solicitudes de los clientes, el software CRM incluyó la liquidación de reclamos. También incluyó los créditos de servicio y penalidades para clientes de telecomunicaciones, quienes enfrentaron problemas en el tiempo de inactividad, degradación de servicio y transferencia a un nuevo plan de facturación. El retraso en el despliegue del software CRM significó que muchos de los clientes no tuvieron sus créditos de servicios o reembolsos a tiempo, y que no hubo un sistema de rastreo para solicitudes de estados actualizados. Cerca de un 25% de los clientes minoristas perdieron su paciencia en el sistema y se retiraron.
En el proceso existente, los puntos a tocar, procesos de validación y verificación no fueron perfectos debido a la adquisición de hardware, entorno de prueba y la ausencia de un ciclo de liberaciones acordado.
En orden de lidiar con esta situación, el nuevo equipo de gestión de liberaciones siguió una serie de indicadores de corrección, como lo enumeramos a continuación:
Una vez el equipo tiene una imagen del estado actual de los procesos de gestión de liberación, ellos deciden enfocarse en definir y establecer un ciclo de liberación acordado. Para entender la frecuencia de una liberación en producción, el equipo tiene que entender la frecuencia de una prueba no funcional.
TEl ciclo de la liberación fue desarrollado para lograr lo siguiente:
El equipo de gestión de liberaciones inició experimentando en un ciclo semanal, pero el plan resultó ser inviable. El entorno de la base de datos de los clientes no pudo refrescarse rápidamente. El equipo luego intentó ciclos de dos semanas. No hubo objeción inmediata de los participantes, pero el ciclo de dos semanas falló las dos primeras veces. Una vez ellos se repusieron de algunos cuellos de botella de cambios de entorno y automatizaron algunas pruebas, el equipo decidió que el ciclo de dos semanas era algo que se podía lograr.
Finalmente, el equipo estableció un ciclo, por lo cual, cada dos semanas el código listo para producción del equipo de ingeniería fue puesto en prueba de sistema. Dos semanas después, ellos lanzaron ese código a producción.
El ciclo de liberación no se trataba de cuando el cliente quisiera la liberación. Se trataba de cuando el equipo pudiera entregarlo al mercado con el nivel de calidad deseado. Sin embargo, cuando enganchó a los clientes, y los puso a cargo de tomar decisiones, los clientes empezaron a apoyarlo.
Los procesos livianos son aquellos que no requieren aprobaciones burocráticas largas o reuniones infinitas para lograr un acuerdo. Usualmente requieren sólo un nivel mínimo aceptable de entradas y salidas. Lo que les falta a granel y burocracia, lo compensan en respuesta al cambio y la adopción popular.
Sin embargo, apuntalar este acercamiento fue un asunto espinoso de documentación. El equipo necesitó grabar lo que se había hecho y cómo se había hecho. De otra manera, hubiera sido imposible revisar o mejorar la situación.
La compañía decidió moverse directo a una documentación estándar que le permitiría a la gente (técnicos y otros) leer y actuar sobre los documentos, en lugar de dejar los documentos echados en un estante.
El equipo de ingeniería escogió Confluence, una herramienta comercial, para documentar de forma colaborativa su trabajo. Ellos usaron el software para crear mínima pero efectiva documentación en lo que acordaron construir cada ciclo de trabajo. Ellos grabaron lo que construyeron, cómo lo construyeron, y qué se requería para hacerlo funcionar. El nuevo equipo vio el valor de este acercamiento y lo extendieron (tanto acercamiento como la herramienta) para cualquier persona involucrada en el proceso.
Una secuencia de tareas fue creada en ese entonces para liberar el software de los equipos de ingeniería. La lista de tareas incluye:
Una infraestructura de liberación asegura que todo esté en su lugar para implementar un software y habilitar su uso. Al equipo de gestión de liberaciones le tomó tiempo desarrollar un sistema de gestión de configuraciones (CMS), e inició diseñando una jerarquía de estructura de árbol e ítem de configuración (CI).
El equipo condujo los talleres con la infraestructura, desarrollo de aplicaciones y equipos de gestión para decidir la configuración, cambio y procesos de liberación. El flujo conceptual acordado, desde una perspectiva de la herramienta es representado a continuación.
La infraestructura de liberación cubrió el hardware, almacenamiento, conexiones de red, banda ancha, licencias de software, perfiles de usuario y permisos de acceso. Los servicios humanos y habilidades también fueron parte de la infraestructura de liberación. Por ejemplo, si un software especializado necesitaba ser instalado y configurado, no podían excluir la disponibilidad o costo de obtener tales habilidades en el plan de infraestructura.
Es crítico el descubrir cualquier cuello de botella escondido en procedimientos que requerían hardware o habilidades ausentes (ej. configuración de redes seguras). El equipo tenía que resolver estos problemas antes de la entrega.
Sin embargo, el estándar no era fácil de mantenerse. El equipo se esforzó en obtener una infraestructura de liberación en lugar tan pronto empezaron el proyecto. Sin embargo, incluso después de seis semanas como tiempo de espera, todavía estaban esperando una memoria especializada y los discos duros para los servidores de prueba.
El equipo identificó las tareas de compilación y prueba que podían ser automatizadas, y propusieron los criterios para las definiciones de normal, estándar, y cambios de emergencia. La automatización los habilitó para desempeñar tareas repetitivas sin tener que desaprovechar recursos humanos valiosos. También calificaron un número de cambios estándar basados en riesgos, repetitividad y tiempo involucrado en ejecución.
Los cambios fueron incluidos para alinearse con el ciclo de liberación de dos semanas. Los equipos de cambios trabajaron con los equipos de liberación e implementación para sincronizarse con el calendario y tipos liberación; y soporte de ciclo de vida temprana.
Anterior a que se involucraran en el proyecto, los equipos de ingeniería elaboraron de forma manual paquetes desplegables. Debido a esto, cada nuevo paquete no estaba garantizado en ser igual al anterior. De hecho, ni siquiera estaba garantizado que iba a ser el software que venían elaborando, y mucho menos se garantizaba que iba a funcionar. Frecuentemente, al equipo de personal le tomaba días el crear un paquete con las características, en una estructura que pudiera ser implementada.
EL equipo de gestión de liberaciones inmediatamente dibujó una estructura y criterio de aceptación del servicio para el paquete desplegable que el equipo de ingeniería estaba entregando, y los ayudó a a estandarizar el paquete. Esto disparó la implementación de procesos automatizados para construir el software en esta estructura consistente para cada punto de liberación.
El nuevo ciclo de liberación establecido debía ser probado para regresión, rendimiento e integración en sólo dos semanas, para que el equipo fuera capaz de liberarlo en producción. El equipo fue capaz de sobreponerse a diferentes tipos de pruebas (integración y rendimiento) teniendo entornos separados para cada tipo. No obstante, el reto de acomodar dos meses de pruebas de regresión en una ventana de dos semanas parecía imposible. Aquí explicamos cómo lo hicieron.
Mientras la combinación de gestión de configuraciones, procesos de control de cambio y los procesos de gestión de lanzamientos e implementaciones fueron integrados perfectamente, el proceso completo requirió el vértice de todas las personas en orden de ser posible.
El equipo de gestión de liberaciones respaldó esta importancia estableciendo que el gerente de liberación designado podría esperar que el software estuviera listo en los tiempos que los equipos acordaron. El equipo hizo un acuerdo, que el gerente del programa (en este caso el usuario final) tendría que explicar a los equipos por qué la liberación era importante.
Los integrantes solicitaron que los equipos de ingeniería aseguraran que el software que entregaron se ajustara a un estándar (versionado, probado, documentado y en paquete). El equipo también estableció que debían solicitar este paquete estándar para cada ciclo de liberación. Esto hizo que el proceso de automatización fuera más fácil y más consistente, y lo permitieron para una integración de retroalimentación.
Las siguientes métricas de gestión de liberaciones fueron medidas para sintonizar el proceso de gestión de liberaciones.
Durante el curso de la transformación entera, el activo más grande fue la gente. El equipo de gestión de liberaciones tomó sus perspectivas, problemas y retos en una conducta transparente, e informó a la administración de lo mismo.Incluso mencionaron a algunos de los primeros usuarios como agentes de cambio. Invirtieron considerablemente en entrenamiento, concienciación, y comunicación, de este modo establecer un mecanismo de recompensas por reconocer comportamientos positivos y compartir conocimiento.
Los siguientes talleres fueron conducidos por los equipos de configuración, cambios, y gestión de liberaciones, sin excepción. Los gerentes de línea también estuvieron disponibles para validar la efectividad de los talleres.
El resultado del taller de cinco días fue una mayor claridad para los equipo involucrados en varios puntos de contacto, entregables, y sobre todo impacto empresarial. Se distribuyó una hoja de trucos rápida para resumir los puntos de aprendizaje clave del entrenamiento.
Lecciones aprendidas
Balance final
Basados en la experiencia que tuvo el equipo de gestión de liberaciones al trabajar con otros en el proyecto, se dieron cuenta que una buena gestión de liberación toma trabajo duro, resolver, y una buena comunicación. Por lo tanto, la destreza más grande es la habilidad de revisar, aprender y adaptar las mejoras con una colaboración efectiva de personas en conjunto con el triángulo mágico (configuración, cambio y procesos de gestión de liberación e implementación).