[E-book gratis] La matriz de excelencia en la prestación de servicios para equipos de TI y empresariales. Descargar ahora
Las mejores prácticas de gestión de liberaciones de TI que se explican aquí se basan en el caso práctico de una mediana empresa de telecomunicaciones. La empresa se enfrentaba a múltiples problemas que le costaron alrededor del 25% de sus clientes y un descenso de su productividad. La razón principal era la falta de un proceso y unos procedimientos eficaces de gestión de liberaciones. Descubra cómo esta empresa mitigó los fallos en las liberaciones y agilizó las liberaciones de software en tres meses.
"La gestión de liberaciones consiste en compilar, probar e implementar, mientras que la liberación continua consiste en compilar, probar e implementar utilizando la automatización." - Charles Betz, analista de investigación, Forrester
"Para mí, el elemento de automatización número uno que se debe buscar son las pruebas de software." - Jayne Groll CEO, DevOps Institute
Una mediana empresa de telecomunicaciones perdió alrededor del 25 por ciento de sus clientes en un periodo de tres meses debido a múltiples retrasos en la liberación de software crítico. Estaba claro que el proceso de gestión de liberaciones existente no era eficaz, y la empresa tuvo que solucionar el problema y llegar a un proceso concreto para enmendar las cosas.
La empresa formó un nuevo equipo de gestión de liberaciones para evaluar y optimizar su actual flujo de procesos de gestión de liberaciones. En los tres meses siguientes, el nuevo equipo pudo entregar las versiones pendientes y dos versiones programadas de aplicaciones rediseñadas. A continuación, verá cómo el equipo agilizó su proceso de gestión de liberaciones. Los pasos que siguió el equipo reflejan las mejores prácticas que puede emplear cualquier organización de TI, incluida la suya.
El nuevo equipo quería tener una visión detallada del flujo actual del proceso de gestión de liberaciones. Empezaron con varias sesiones de orientación con personas clave implicadas en el proceso del software. En estas sesiones, el equipo se enteró de que la liberación del software de CRM estaba pendiente desde hacía dos meses tras su finalización.
Según los requisitos del cliente, el software CRM incluía la liquidación de reclamaciones. También incluía créditos de servicio y penalizaciones para los clientes de telecomunicaciones que enfrentaban problemas de inactividad, degradación del servicio y transferencia de un nuevo plan de facturación. El retraso en la implementación del software de CRM hizo que varios de los clientes no pudieran obtener sus créditos de servicio o reembolsos a tiempo, y que no hubiera un sistema de seguimiento para conocer el estado de las solicitudes. Alrededor del 25 por ciento de los clientes minoristas perdieron la paciencia con el sistema y se marcharon.
En el proceso existente, los puntos de contacto, la validación y el proceso de verificación no eran fluidos debido a la adquisición de hardware, el entorno de pruebas y la falta de un ciclo de liberación acordado.
Para abordar esta situación, el nuevo equipo de gestión de liberaciones siguió los siguientes consejos
para corregir el rumbo:
Una vez que el equipo se hizo una idea del estado actual del proceso de gestión de liberaciones, decidió centrarse en definir y establecer un ciclo de liberaciones acordado. Para conocer la frecuencia de liberación en producción, el equipo tuvo que determinar la frecuencia de las pruebas no funcionales. Después de consultar con los equipos de ingeniería, se llegó a la conclusión de que el proyecto requería pruebas de regresión, rendimiento e integración.
Se desarrolló el ciclo de liberación para lograr lo siguiente:
El equipo de gestión de liberaciones empezó experimentando con un ciclo semanal, pero el plan resultó inviable. El entorno de bases de datos del cliente no podía actualizarse rápidamente. Entonces, el equipo probó con ciclos de dos semanas. No hubo objeciones inmediatas por parte de los participantes, pero el ciclo de dos semanas fracasó las dos primeras veces. Una vez se superaron algunos cuellos de botella en el entorno y automatizaron algunas de las pruebas, el equipo decidió que el ciclo de dos semanas era factible.
Por último, el equipo estableció un ciclo según el que, cada dos semanas, el código "listo para producción" del equipo de ingeniería se puso a prueba en el sistema. Dos semanas después, el código se puso en producción.
El ciclo de liberación no tenía que ver con el momento en que el cliente quería la liberación. Se trataba de cuándo el equipo podía lanzarlo al mercado con el nivel de calidad deseado. Sin embargo, cuando el equipo involucró a los clientes y los convirtió en los responsables de la toma de decisiones, ¡los clientes empezaron a apoyarlo!
Los procesos ligeros son aquellos que no requieren largas aprobaciones burocráticas ni reuniones interminables para llegar a un acuerdo. Normalmente, sólo requieren el nivel mínimo aceptable de entrada y salida. Lo que les falta de volumen y burocracia lo compensan con su capacidad de respuesta al cambio y su adopción popular.
Sin embargo, la base de este planteamiento era la compleja documentación. El equipo necesitaba registrar lo que se hacía y cómo se hacía. De lo contrario, sería imposible revisar o mejorar la situación.
La empresa decidió adoptar una norma de documentación que permitiera a las personas (técnicos y otros) leer los documentos y actuar respectivamente, en lugar de dejar que los documentos permanecieran guardados.
El equipo de ingenieros eligió Confluence, una herramienta comercial, para documentar su trabajo de forma colaborativa. Utilizaron el software para crear una documentación mínima pero eficaz de lo que acordaron hacer en cada ciclo de trabajo. Registraban lo que hacían, cómo lo hacían y qué se necesitaba para que funcionara. El nuevo equipo vio el valor de este enfoque y lo extendió (tanto el enfoque como la herramienta) a todos los demás implicados en el proceso.
A continuación se creó una secuencia de tareas para entregar el software de los equipos de ingeniería. La lista de tareas incluía:
Una infraestructura de liberación garantiza que todo esté listo para implementar el software y permitir su uso. El equipo de gestión de liberaciones se tomó su tiempo para desarrollar un sistema de gestión de configuraciones (CMS) y empezó por crear la estructura de árbol y la jerarquía de los elementos de configuración (CI).
El equipo organizó talleres con los equipos de infraestructura, desarrollo de software de aplicación y gestión para decidir los procesos de configuración, cambio y liberación. A continuación se muestra el flujo conceptual acordado, desde la perspectiva de la herramienta.
La infraestructura de liberación abarcaba el hardware, el almacenamiento, las conexiones de red, el ancho de banda, las licencias de software, los perfiles de usuario y los permisos de acceso. Las competencias y los servicios humanos también formaban parte de la infraestructura de liberación. Por ejemplo, si había que instalar y configurar un software especializado, debían incluir la disponibilidad o el costo de conseguir esas competencias en el plan de infraestructura.
Es fundamental descubrir cualquier cuello de botella oculto en la adquisición del hardware necesario o las competencias que faltan (por ejemplo, configuración de redes seguras). El equipo tenía que resolver estos problemas antes de la entrega.
Sin embargo, no fue fácil lograrlo. El equipo se esforzó por disponer de la infraestructura de liberación nada más empezó el proyecto. Sin embargo, incluso después de seis semanas de anticipo, seguían esperando la memoria y los discos duros especializados para los servidores de prueba.
El equipo identificó las tareas de creación y prueba que se podían automatizar, y estableció los criterios y definiciones de cambios normales, estándar y de emergencia. La automatización les permitió realizar tareas repetitivas sin consumir valiosos recursos humanos. También clasificaron una serie de cambios estándar en función del riesgo, la repetibilidad y el tiempo de ejecución.
Los cambios se agruparon para ajustarlos al ciclo de liberación de dos semanas. Los equipos de cambios trabajaron con los equipos de liberación e implementación para sincronizar con el calendario de liberación, los tipos de liberación y el apoyo al inicio del ciclo de vida.
Antes de participar en el proyecto, los equipos de ingeniería elaboraban manualmente los paquetes implementables. Por ello, no se garantizaba que cada nuevo paquete fuera igual que el anterior. De hecho, ni siquiera se garantizaba que fuera el software que habían estado creando, ¡y mucho menos que funcionara! A menudo, el personal técnico tardaba días en crear un paquete con las características requeridas, en una estructura que pudiera implementarse.
El equipo de gestión de liberaciones elaboró inmediatamente una estructura y unos criterios de aceptación del servicio para el paquete implementable que el equipo de ingeniería estaba entregando, y les ayudó a estandarizar el paquete. Esto desencadenó la implementación de procesos automatizados para construir el software en esa estructura coherente para cada punto de liberación.
Como el equipo había automatizado el proceso de verificación de los criterios de aceptación, la ejecución estaba garantizada. Por ejemplo, el código debía someterse a pruebas unitarias antes de la entrega y a pruebas de implementación para garantizar que así fuera. Como resultado, el equipo de gestión de liberaciones pudo empaquetar, versionar, probar e implementar el código terminado con un solo comando, en muy poco tiempo.
El ciclo de liberación recién establecido obligaba a probar la regresión, el rendimiento y la integración de una liberación en sólo dos semanas, para que el equipo pudiera ponerla en producción. El equipo pudo superar los distintos tipos de pruebas (integración y rendimiento) disponiendo de entornos separados para cada tipo. Sin embargo, el reto de acomodar dos meses de pruebas de regresión en un plazo de dos semanas parecía imposible. Así es cómo lo hicieron.
Aunque la gestión de configuraciones, el proceso de control de cambios y los procesos de gestión de liberaciones e implementaciones se integraron a la perfección, todo el proceso requirió el vértice de las personas para que fuera posible.
El equipo de gestión de liberaciones respaldó esta importancia estableciendo que el gestor de liberaciones designado esperaría que el software estuviera listo en el momento acordado por los equipos. El equipo acordó que el gestor del programa (en este caso, el cliente usuario final) explicaría a los equipos por qué era importante la liberación.
El equipo pidió a los equipos de ingeniería que se aseguraran de que el software que entregaban se ajustara al estándar (versionado, probado, documentado y empaquetado). El equipo también estableció que solicitarían este paquete estándar para cada ciclo de liberación. De este modo, el proceso automatizado resultaba más sencillo y coherente, y permitía integrar la retroalimentación.
Las siguientes métricas de gestión de liberaciones se midieron continuamente para ajustar el proceso de gestión de liberaciones.
Durante toda la transformación, el mayor activo fueron las personas. El equipo de gestión de liberaciones asumió sus perspectivas, problemas y retos de forma justa y transparente, e informó a la dirección al respecto. Incluso incluyeron a algunos de los primeros en adoptar el cambio como agentes de cambio. Invirtieron mucho en formación, concienciación y comunicación, e instituyeron un mecanismo de recompensa para reconocer el comportamiento positivo y el intercambio de conocimientos.
Los siguientes talleres se impartieron a los equipos de gestión de liberaciones, configuraciones y cambios, sin excepción. Los directores de línea también estuvieron disponibles para validar la eficacia de los talleres.
El resultado del taller de cinco días fue una mayor claridad para los equipos implicados sobre los distintos puntos de contacto, los entregables y el impacto general en la empresa. Se distribuyó una hoja de consejos rápidos para resumir los puntos clave de la capacitación.
Lecciones aprendidas
Con base en la experiencia que tuvo el equipo de gestión de liberaciones al trabajar con otras personas en el proyecto, se dieron cuenta de que una buena gestión de liberaciones requiere trabajo duro, determinación y una gran comunicación. Sin embargo, la principal habilidad adquirida es la capacidad de revisar, aprender y adaptar mejoras con la colaboración eficaz de las personas junto con los procesos de gestión de configuraciones, cambios e implementaciones del triángulo mágico.