Close

Marco CALMS

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

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

DevOps no es solo un proceso o un enfoque diferente del desarrollo, sino que constituye un cambio de cultura. Y una parte muy importante de la cultura de DevOps es la colaboración.

Todas las herramientas y automatizaciones del mundo no sirven para nada si los profesionales de desarrollo y de TI o de operaciones no trabajan juntos, porque DevOps no soluciona los problemas relacionados con herramientas, sino los problemas humanos.

Piensa en DevOps como la evolución de los equipos de metodología ágil, pero con la diferencia de que las operaciones están ahora incluidas de forma predeterminada. Formar equipos con una orientación hacia los productos que sustituyan los equipos basados en funciones es dar un paso en la dirección correcta. Incluye desarrollo, control de calidad, gestión de productos, diseño, operaciones, gestión de proyectos y cualquier otro conjunto de aptitudes que requiera un producto de larga duración. En lugar de tener un equipo que se encargue de todo o de contratar a "profesionales de DevOps", es más importante contar con equipos basados en los productos que puedan trabajar juntos en perfecta armonía.

Pocas cosas fomentan tanto la colaboración como compartir un objetivo común y tener un plan para alcanzarlo juntos. En algunas compañías, cambiar de repente a equipos basados en proyectos resulta algo excesivo y precipitado, por lo que es mejor ir a paso lento. Los equipos de desarrollo pueden (y deben) invitar a los miembros adecuados del equipo de operaciones a unirse a las sesiones de planificación de sprints, las reuniones rápidas diarias y las demostraciones de sprints. Y, del mismo modo, los equipos de operaciones también pueden invitar a desarrolladores clave a sus reuniones, ya que esta es una forma ágil y orgánica de estar al tanto del trabajo, las ideas y las dificultades de los demás.

Material relacionado

Descubre las ventajas de DevOps

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

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.

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.

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.

Ian Buchanan
Ian Buchanan

Ian Buchanan is a Principal Solutions Engineer for DevOps at Atlassian where he focuses on the emerging DevOps community and the application of Jira, Bitbucket, and Bamboo for better continuous integration and continuous delivery. While Ian Buchanan has broad and deep experience with both Java and .NET, he is best known as a champion of lean and agile practices in large enterprises.

During his career, he has successfully managed enterprise software development tools in all phases of their lifecycle, from cradle to grave. He has driven organization-wide process improvement with results of greater productivity, higher quality, and improved customer satisfaction. He has built multi-national agile teams that value self-direction and self-organization. When not speaking or coding, you are likely to find Ian indulging his passions in parsers, meta-programming, and domain-specific languages.


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

Taller de simulación

Ilustración de un mapa

Pruébalo gratis

Suscríbete para recibir el boletín de DevOps

Thank you for signing up