Close

Marco CALMS

Evalúa tu capacidad y mide cómo avanza tu proceso de transformación al modelo DevOps.

Foto de Ian
Ian Buchanan

Ingeniero principal de soluciones


CALMS es un marco de trabajo que evalúa la capacidad de una compañía de adoptar los procesos de DevOps, además de una forma de medir el éxito mientras tiene lugar la transformación a este modelo. El acrónimo fue acuñado por Jez Humble, coautor de "The DevOps Handbook", y significa cultura (Culture), automatización (Automation), metodología lean (Lean), medición (Measurement) y compartir (Sharing).

Cultura


Icono de trofeo
Material relacionado

Descubre las ventajas de DevOps

Icono de equipo
Material relacionado

Crear una cultura de DevOps

Los desafíos e, incluso, las emergencias constituyen una prueba efectiva de la cultura de DevOps. ¿Se vuelcan los profesionales de desarrollo, operaciones y atención al cliente en el problema y lo resuelven como equipo? ¿Los análisis retrospectivos de incidentes se centran en mejorar los resultados para el próximo incidente en lugar de buscar culpables? Si la respuesta es "sí", es un buen indicio de que tu organización está adoptando una cultura de DevOps.

Las empresas de mayor éxito aprueban la cultura de DevOps en todos los departamentos y a todos los niveles del organigrama. A una escala tan amplia, el término "DevOps" suele quedarse corto y acabar por no ser necesario. Esas empresas cuentan con canales de comunicación abiertos y los emplean habitualmente. Asumen que mantener al cliente satisfecho es tanto responsabilidad de la gestión de productos como del equipo de desarrollo. Entienden que DevOps no es el trabajo de un solo equipo. Es el trabajo de todos.

Automatización


La automatización contribuye a suprimir el trabajo manual repetitivo, genera procesos reproducibles y crea sistemas fiables.

Compilar, probar, desplegar y automatizar son los puntos de partida típicos de los equipos que aún no la han puesto en práctica. Oye, ¿y qué mejor motivo para que Desarrollo, Pruebas y Operaciones trabajen juntos que construir sistemas que los beneficien a todos?

Los equipos con escasa experiencia en automatización suelen empezar con la entrega continua: la práctica de ejecutar cada cambio en el código mediante un puñado de pruebas automatizadas, a menudo facilitadas por una infraestructura basada en la nube, para luego empaquetar compilaciones satisfactorias y promoverlas hasta producción con implementaciones automatizadas.

¿El motivo? Los ordenadores ejecutan las pruebas con mayor rigor y exactitud que los seres humanos. Estas pruebas detectan antes los errores y los fallos de seguridad. Además, las implementaciones automatizadas alertan a los equipos de TI y operaciones de los "desajustes" entre entornos, lo que reduce las sorpresas cuando llega la hora de publicar.

Otra de las contribuciones principales de DevOps es la idea de “configuración como código”. Los desarrolladores procuran crear aplicaciones modulares que admitan composición porque son más fiables y fáciles de mantener. La misma filosofía se puede aplicar a la infraestructura que las aloja, ya esté en la nube o en la red de la propia compañía.

La “configuración como código” y la “entrega continua” no son los únicos tipos de procesos automatizados que se observan en el mundo de DevOps, pero merecen una mención especial porque ayudan a derribar la barrera que hay entre el desarrollo y las operaciones. Y cuando DevOps utiliza implementaciones automatizadas para enviar código probado a conciencia a entornos de idéntica provisión, el “¡A mí me funciona!” deja de ser un mantra.

Infalible


Cuando se habla de "lean" en un contexto de software, solemos pensar en suprimir actividades de escaso valor y avanzar rápido: ser enérgico, ser ágil. Más oportunos aún para DevOps son los conceptos de mejora continua y aceptación de los errores, que sientan las bases de una mentalidad experimental.

Una mentalidad de DevOps ve oportunidades de mejora continua en todas partes. Algunas resultan obvias, como mantener retrospectivas periódicas para mejorar los procesos del equipo. Otras son más sutiles, como las pruebas A/B en distintos métodos de incorporación para nuevos usuarios del producto.

Al desarrollo ágil le agradecemos el haber convertido la mejora continua en una idea corriente. Los primeros en adoptar la metodología ágil demostraron que un producto sencillo en manos de los clientes hoy tiene más valor que un producto perfecto en manos de los clientes dentro de seis meses. Si el producto se mejora continuamente, los clientes no se marcharán.

¿Y sabes qué? Cometer errores es inevitable. Así que es como si prepararas al equipo para asumirlos, recuperarse y aprender de ellos (algunos lo llaman “ser antifrágil”). En Atlassian pensamos que, si no te equivocas de vez en cuando, es que no te estás esforzando lo suficiente.

En el contexto de DevOps, equivocarse no es un delito punible. Los equipos tienen asumido que las cosas están destinadas a torcerse en algún momento, así que trabajan para conseguir detecciones y recuperaciones rápidas. Los análisis retrospectivos se centran en descubrir en qué fallaron los procesos y cómo reforzarlos, no en qué miembro del equipo se cargó el código. ¿Por qué? Porque la mejora continua y el fracaso van de la mano.

Medición


Sin datos, es difícil demostrar que tu esfuerzo continuo por mejorar esté en realidad mejorando algo. Por suerte, hay un montón de herramientas y tecnologías para medir el rendimiento: cuánto tiempo pasan los usuarios con tu producto, si esa entrada del blog ha generado alguna venta o con cuánta frecuencia aparecen alertas críticas en tus registros.

Aunque se puede medir casi todo, eso no quiere decir que lo tengas que medir todo. Sigue el ejemplo del desarrollo ágil y empieza por lo básico:

¿Cuánto tiempo se tardó en pasar del desarrollo a la implementación?

¿Con qué frecuencia tienen lugar errores o fallos?

¿Cuánto se tarda en recuperarse tras un fallo del sistema?

¿Cuántas personas utilizan su producto en este momento?

¿Cuántos usuarios has ganado o perdido esta semana?

Sobre una base sólida implantada, cuesta menos detectar métricas más sofisticadas del uso de las funciones, el recorrido de los clientes, y los acuerdos de nivel de servicio (SLA). La información que se obtiene viene muy bien a la hora de confeccionar hojas de ruta y especificar el siguiente gran paso.

Con todos estos datos jugosos, tu equipo puede tomar decisiones, pero resultan aún más útiles cuando se comparten con otros equipos, sobre todo si son de otros departamentos. Por ejemplo, el equipo de marketing quiere tener funciones nuevecitas que vender. Mientras tanto, observas una alta rotación de clientes, porque el producto está plagado de deuda técnica. Al aportar datos de los usuarios útiles para la hoja de ruta, aunque no profundicen en funciones y sí en correcciones, es más fácil lograr consenso y obtener la aceptación de las partes interesadas.

Compartir


Por mucho que nos gustaría que existiera una varita mágica para transformar a todos los equipos en equipos de alto rendimiento de DevOps, la realidad es que la transformación a este modelo requiere una mezcla de prácticas, filosofías culturales y herramientas. Pero, como has leído, las ventajas que presenta terminar con la división de los equipos de desarrollo y operaciones merecen mucho la pena: mayor confianza, publicaciones de software más rápidas, implementaciones más fiables y mejor ciclo de feedback entre los equipos y los clientes.

Adoptar el modelo DevOps no es tarea fácil. Sin embargo, si cuenta con las herramientas, la mentalidad y el esfuerzo adecuados, una organización puede llevar a cabo una transformación al modelo DevOps que ofrezca ventajas significativas.

La antigua fricción entre los equipos de desarrollo y operaciones se debe en gran medida a una falta de intereses comunes. Creemos que compartir responsabilidades y logros representará un importante avance para zanjar esa división. Los desarrolladores pueden ganar puntos de buena voluntad de manera instantánea ayudando a soportar una de las cargas más pesadas del equipo de operaciones: el guion (hoy en día, en sentido figurado). En DevOps gusta la idea de que las personas que compilan una aplicación se involucren también en su lanzamiento y ejecución.

En conclusión...


De esta idea surge la frase "tú lo creas, tú lo gestionas", que fomenta un enfoque práctico en todos los equipos. Esto no quiere decir que contrates desarrolladores esperando directamente que también dominen las operaciones. Lo que quiere decir es que los equipos de desarrollo y operaciones trabajan conjuntamente a lo largo de todo el ciclo de vida de una aplicación. Asimismo, los informes han demostrado que la única forma de revisión que mejora la entrega y el rendimiento es que los compañeros se revisen el código y los productos entre ellos. De hecho, apenas había diferencias entre externalizar las revisiones y no revisar.

Los equipos que adoptan DevOps suelen tener una función rotativa en la que los desarrolladores tratan las incidencias detectadas por los usuarios finales, mientras que solucionan problemas de producción al mismo tiempo. Esta persona da respuesta a las incidencias urgentes que los clientes han notificado, creando parches cuando haga falta, y trabaja en el backlog de los defectos notificados por clientes. El “desarrollador de apoyo” aprende así mucho sobre el uso que se le da a la aplicación en la vida real. Y gracias a su gran disponibilidad para con el equipo de operaciones, los equipos de desarrollo fomentan la confianza y el respeto mutuo.

Atlassian ha creado Open DevOps para que los equipos creen la cadena de herramientas de DevOps que quieran con las herramientas que les encantan gracias a las integraciones con los principales proveedores y aplicaciones de Marketplace. Pruébalo gratis ahora.

Ian Buchanan
Ian Buchanan

Ian Buchanan es ingeniero principal de Soluciones de DevOps en Atlassian, donde se centra en la comunidad emergente de DevOps y en la aplicación de Jira, Bitbucket y Bamboo para lograr una integración y una entrega continuas mejoradas. Si bien tiene una amplia y profunda experiencia con Java y .NET, se le conoce más por ser un defensor de las prácticas lean y ágiles en las grandes empresas.

A lo largo de su carrera, ha gestionado con éxito herramientas de desarrollo de software empresarial en todas las fases de su ciclo de vida, desde la adopción hasta la retirada. Ha impulsado la mejora de procesos en toda la organización, que ha dado como resultado una mayor productividad, calidad y satisfacción del cliente. Ha creado equipos ágiles multinacionales que valoran la autonomía en cuanto a dirección y organización. Cuando no está dando charlas o programando, Ian se dedica a otras de sus pasiones: los analizadores, la metaprogramación y los lenguajes específicos de dominio.


Compartir este artículo
Tema siguiente

Lecturas recomendadas

Consulta estos recursos para conocer los tipos de equipos de DevOps o para estar al tanto de las novedades sobre DevOps en Atlassian.

Ilustración de Devops

La comunidad de DevOps

Ilustración de Devops

Ruta de aprendizaje de DevOps

Ilustración de un mapa

Pruébalo gratis

Suscríbete para recibir el boletín de DevOps

Thank you for signing up