Todas las organizaciones de TI que quieran seguir siendo relevantes en la era digital probablemente hayan analizado detenidamente cómo empresas como Facebook, Twitter y Amazon han aprovechado DevOps para moverse a la velocidad del rayo.
Los directores ven a estas empresas como una inspiración, y la presión es cada vez mayor para parecerse a ellas. Entonces, ¿por qué, después de aproximadamente una década, el cambio a DevOps sigue siendo un desafío importante en las empresas?
Porque hay una falla importante en el modelo actual. Las referencias populares a las transformaciones de DevOps son aplicables únicamente a organizaciones nacidas en la era digital. Las personas en esas organizaciones van desde millennials hasta personas de la generación Z, sus procesos son ágiles y sus tecnologías son nativas de la nube, con un enfoque en aplicaciones web y móviles.
Eso es muy diferente de las organizaciones de TI en, digamos, servicios financieros, gobierno o manufactura de automóviles. Si el enfoque de su empresa es tradicional, tendrá seguramente más personas de la Generación X, y procesos orientados en cascada con tecnologías que van desde el mainframe hasta el cliente / servidor y la nube.
En la empresa tradicional, sus desafíos, incluso su definición de “más rápido”, son diferentes de los que están experimentando los nativos digitales. Su organización tiene un ADN diferente. Y si bien es posible que se sienta inspirado por los Facebook y Google del mundo, las hojas de ruta que siguieron esas organizaciones no son del todo relevantes para lo que su organización necesita hacer para transformarse.
Una forma de avanzar es crear o contratar una fábrica de software, como la de BLMovil. Este es cómo lo hicimos nosotros en nuestra Software Factory.
El enfoque de la fábrica de software para la transformación
En BLMovil necesitábamos transformarnos a través de DevOps para poder continuar capacitando a nuestros clientes con sus propias transformaciones digitales, así como para continuar haciendo crecer nuestro negocio.
Para impulsar esta transformación, lanzamos un programa de fábrica de software (SW Factory), un conjunto integrado de herramientas, servicios, datos y procesos que ayudan a nuestros ingenieros a planificar, construir, probar, lanzar y / o operar y administrar el software que entregamos. a nuestros clientes.
Comenzamos con una declaración de misión y definimos el valor que queríamos obtener del programa. Queríamos integrar nuestros grupos de productos y facilitar una transformación de DevOps proporcionando un conjunto rentable y común de herramientas y servicios de ingeniería que pudieran entregarse a mayor velocidad, alta calidad y escala.
Si bien necesitábamos controlar los costos, teníamos que entregar más rápido, sin comprometer la calidad, y pensamos que podríamos lograrlo proporcionando las personas, los procesos y las herramientas necesarias, y mejorando continuamente.
Cuidado con los desafíos y las brechas
Después de analizar nuestro punto de partida para identificar nuestros desafíos y brechas. Esto es lo que encontramos:
Redundancia de herramientas
Esto había resultado en costosos y complejos grupos de desarrollo. Teníamos varios equipos de desarrollo y casi todos los equipos tenían sus propias herramientas. Por ejemplo, teníamos más de un sistema de gestión de defectos, de gestión de código fuente (SCM) y repositorios de artefactos. Esta complejidad había evolucionado a lo largo del tiempo, porque cada equipo elegía sus propias herramientas.
Falta de visibilidad de los datos necesarios para impulsar los flujos de valor de un extremo a otro
Sin procesos e integraciones estándar en todo el ecosistema empresarial, como entre el sistema de soporte y SW Factory, la experiencia del cliente podría verse significativamente afectada.
Productividad y calidad subóptimas
La falta de alineación o colaboración entre los grupos de productos puede generar una productividad y una calidad por debajo de lo que necesitamos aportar a nuestros clientes. Eso lo solucionamos mediante la generación de una metodología y un marco para gestionar una gran cartera de desarrollos tanto de producto propio como para terceros de forma ágil y coordinada.
Establecimos nuestros principios rectores
Para abordar estos desafíos y transformarnos, llegamos a los siguientes principios rectores.
Nos esfrozamos por lograr una entrega ágil desde el principio
- Entregamos un producto mínimo viable (MVP), comenzando con un conjunto básico de servicios que hayan demostrado internamente que generan valor y con un riesgo mínimo para el negocio.
- Exponemos gradualmente los servicios, comenzando con pilotos locales de algunos clientes. Luego, escalamos gradualmente a la cartera completa de clientes.
- Colaboramos continuamente con los clientes para obtener sus comentarios y alinear la demanda y las prioridades en consecuencia.
Establecimos un modelo operativo de intermediario de servicios
Esto requiere roles y responsabilidades claros para el propietario del servicio y para la prestación del servicio. Para cada servicio hay un rol de propietario del servicio que actúa como gerente de producto para el servicio y es responsable de impulsar el valor y la satisfacción del cliente. También existe una función de prestación de servicios, responsable de la disponibilidad y el soporte continuos del servicio.
Entregamos flujos de valor de extremo a extremo
Basados en el marco IT4IT, con procesos e integraciones estándar entre SW Factory y el ecosistema empresarial.
Aprovechamos el marco SAFe
Este marco nos ayuda a alinear nuestro portafolio, entregar más rápido a escala, brindar la capacitación requerida y capacitar a nuestra gente para que evolucione.
Otros principios incluyeron:
- Somos los primeros en implementar nuestras propias herramientas y soluciones.
- Nos hemos convertido en una implementación de referencia para la transformación de DevOps empresarial.
- El utilizar nuestras propias soluciones desde el principio nos permite compartir nuestras experiencias y proporcionar comentarios a nuestros clientes.
Resultados y siguientes pasos
Hemos podido hacer la transición de la organización en solo 12 meses. Esto creó una interrupción mínima para los equipos, y ya estamos viendo mejoras sustanciales en la velocidad y la calidad de la entrega.
Para contratar una fábrica de software, comience por alinear sus expectativas con las de la organización. “DevOps” es un término con muchas interpretaciones, por lo que hay que ser concreto en lo que se busca dentro de la organización.
Tiene que Identificar el valor que espera obtener, sus desafíos y brechas, y luego identificar qué es lo que realmente busca y qué busca lograr en la práctica, y estará listo para una transformación DevOps.