Las metodologías ágiles y DevOps: ¿amigos o enemigos?

DevOps es una metodología ágil aplicada más allá del equipo de software. Pero la verdadera cuestión es: en un combate, ¿cuál vencería?

Ian Buchanan Ian Buchanan
Buscar temas

A un lado, tenemos al experto certificado en scrum, conocido entre sus amigos como el programador extremo, y entre sus hijos como el LeSS SAFe DAD ("padre menos seguro")... ¡la metodología ágil!

Y al otro lado tenemos a la máquina de la cultura lean, que entrega continuamente infraestructura como código. Su brazo izquierdo se llama Dev, y el derecho se llama Ops... ¡DevOps!

Aunque he llevado el bombo publicitario al extremo, las declaraciones sobre la metodología ágil y DevOps pueden hacer que suenen muy distintos. Para agravar la confusión, ambos conceptos parecen desafiar la definición, aun cuando tienen su propia jerga y consignas. Por ser la más antigua, la metodología ágil suena menos imprecisa, pero es muy frecuente que la gente se frustre con la infinidad de definiciones que tiene DevOps. La falta de una definición ha provocado cierta amalgama habitual.

Mucha gente piensa que "metodología ágil" es sinónimo de scrum y que DevOps significa "entrega continua". Esta simplificación excesiva genera una tensión innecesaria entre la metodología ágil y DevOps, pero te sorprendería saber que se llevan estupendamente.

No se puede negar el vínculo histórico que hay entre DevOps y la metodología ágil. Cuando Patrick DuBois y Andrew Clay Schafer compartieron conceptos sobre la "infraestructura ágil" en la conferencia de 2008 sobre metodología ágil, nació la conexión con DevOps. Aunque Patrick acuñó el término "DevOps" más adelante, la conferencia sobre metodología ágil sigue rindiendo homenaje esta conexión con DevOps. Pero vayamos más allá de la historia y pensemos en los vínculos prácticos entre la metodología ágil y DevOps, cuando miramos bajo la superficie de scrum y la entrega continua.

La metodología ágil es algo más que scrum

Para algunos equipos, scrum marca la diferencia entre una lucha constante y frustrante y un trabajo en equipo productivo y gratificante. Para otros, scrum sustituye las políticas y los compromisos excesivos por la objetividad y la orientación. También se puede entender como si fuera un dogma. Cuando las limitaciones del negocio o el propio trabajo exigen algo distinto, un equipo ágil aprovechará los principios básicos de scrum, examinará sus prácticas y se adaptará para ser más eficiente. Esto tiene especial importancia cuando scrum se aplica fuera del contexto del desarrollo de software.

Planear el trabajo imprevisto

En la comunidad de DevOps, los que tienen experiencia con la metodología ágil reconocen que scrum es útil para realizar el seguimiento del trabajo planificado. Se pueden planificar algunas tareas de operaciones: publicar un gran cambio del sistema, desplazarse entre centros de datos o llevar a cabo actualizaciones del sistema. Pero gran parte del trabajo de operaciones no se planifica: alcanzar el máximo rendimiento, interrupciones del sistema y fallos de seguridad. Estas situaciones exigen una respuesta inmediata. No hay tiempo que perder para dar prioridad a los elementos en un backlog o en la siguiente sesión de planificación de sprints. Por este motivo, muchos equipos que han llegado a adoptar la filosofía de DevOps, van más allá de scrum hacia kanban. Así pueden realizar el seguimiento de ambos tipos de trabajo y comprender su interacción. O bien adoptan una estrategia híbrida, a menudo llamada scrumban o kanplan (kanban con backlog).

En muchos sentidos, la clave de la amplia adopción de scrum puede ser que no establece prácticas técnicas. Las sencillas prácticas de gestión de scrum suelen marcar una gran diferencia para los equipos. Donde una vez hubo prioridades en conflicto de varias maestras, ahora hay un solo conjunto de prioridades en el backlog. Y donde una vez hubo demasiado trabajo en curso, ahora hay un plan delimitado por lo que el tiempo ha demostrado que es posible. En conjunto, esto puede ofrecer nuevos niveles de productividad a los equipos. Sin embargo, los equipos se pueden ver limitados por la falta de prácticas técnicas, como las revisiones del código, las pruebas de aceptación automatizadas y la integración continua.

Otros procesos ágiles como la programación extrema tienen opiniones firmes sobre cómo las prácticas técnicas aumentan la capacidad del equipo para mantener un ritmo sostenible y ofrecen transparencia y visibilidad a la dirección y las partes interesadas. Algunos equipos de scrum recurren a colocar las tareas técnicas en el backlog. Aunque encaja con las directrices de scrum, rápidamente se topan con el problema práctico de los prejuicios sobre las funcionalidades que tienen los propietarios de productos. A no ser que el propietario del producto sea muy técnico, puede que no tenga los conocimientos para evaluar la rentabilidad de las prácticas técnicas. La cosa se pone más difícil aún para el propietario del producto a medida que las tareas técnicas se extienden a las operaciones para garantizar fiabilidad, rendimiento y seguridad.

Propietarios de producto y propietarios de servicio

En Atlassian, reconocemos que nos ayuda tener dos funciones distintas para los productos que trabajamos. A nuestros propietarios de productos se les da bien comprender las funcionalidades que necesitan los usuarios, pero no tanto valorar esas funcionalidades con respecto a capacidades no funcionales como el rendimiento, la fiabilidad y la seguridad. Así pues, algunos productos de SaaS de Atlassian también cuentan con propietarios de servicio, responsables de priorizar esas capacidades no funcionales. De vez en cuando, puede que los dos propietarios tengan que lidiar con el "tira y afloja", pero la mayor parte del tiempo lo pueden hacer equipos independientes. Esta no tiene por qué ser la única forma de aumentar el feedback de las operaciones, pero ayuda a superar los típicos prejuicios sobre las funcionalidades que tienen los propietarios de los productos. Esta estrategia de "dos propietarios" no es la única vía hacia DevOps. Lo importante es ver esos aspectos no funcionales como "funcionalidades" y ser capaz de planificarlos y priorizarlos como cualquier otra historia de usuario funcional.

En última instancia, ninguna de estas críticas de scrum son del todo inherentes a scrum. Como en todos los métodos ágiles, scrum tiene un mecanismo incorporado de "mejora del proceso" llamado "retrospectivas". Por lo tanto, es razonable creer que algunos equipos de scrum recurrirán a DevOps como fuente de inspiración y utilizarán las retrospectivas de scrum para poder adaptarse a DevOps. Sin embargo, es práctico darse cuenta de que la mayoría de equipos necesitan una inyección de ideas externas. Hasta que DevOps no sea algo habitual (quizá incluso se enseñe en las escuelas), no será un resultado orgánico de scrum. Resulta irrelevante que el equipo recurra a un orientador ágil o de DevOps, siempre que esa persona aporte experiencia en la automatización de compilaciones, pruebas e implementaciones de software.

DevOps no es solo entrega continua

Cuando se hace bien, la disciplina de entrega continua (CD) ayuda a limitar el trabajo en curso, al tiempo que la automatización de la implementación ayuda a erigir restricciones. Con ello, la CD ayuda al equipo de software a entregar con mayor frecuencia y calidad, en lugar de tener que elegir una de las dos cosas. Sin embargo, de igual modo que los equipos que solo se centran en scrum se pueden perder la amplitud del contexto ágil, los que se centran en la entrega continua se pueden perder la amplitud del contexto de DevOps.

Practicar la CD no sirve para abordar directamente los problemas de comunicación que hay entre el negocio y el equipo de software. Si el negocio tiene un ciclo de un año de planificación regido por el presupuesto, un equipo que entregue cada confirmación a producción aún puede tener que esperar meses para que el negocio reaccione. En demasiadas ocasiones, esas reacciones llegan como funciones escalonadas, como cancelar el proyecto o, aún peor, duplicar el equipo del proyecto (porque una gran afluencia de personas nuevas resulta perjudicial).

El modelo Agile Fluency señala el primer nivel de fluidez como "Atención al valor", en el que el equipo se centra en la transparencia y la coherencia. Sin esta fluidez, la CD puede caer fácilmente en un ciclo infinito de mejoras técnicas que no aporta ningún valor sustancial al negocio. El equipo podría ser bueno en entregar con rapidez y calidad, pero serían productos de poco valor para los usuarios finales o para el negocio. Aunque haya muchos comentarios positivos de usuarios, esa valoración del poco valor solo sería posible en un nivel superior de la cartera del negocio. Sin esta fluidez esencial, es difícil comparar las prácticas técnicas con las funcionalidades. Esto tiene especial importancia en equipos con código base antiguo, que quizá no tengan pruebas automatizadas o un diseño adecuado para las implementaciones frecuentes. En un contexto antiguo, la transformación a CD podría llevar años. Así pues, es mucho más importante ser capaz de demostrar las ventajas para el negocio.

Los tres modos

DevOps consiste en algo más que automatizar el canal de implementación. En palabras de John Allspaw, DevOps consiste en "Operaciones que piensan como Desarrollo y Desarrollo que piensa como Operaciones". Analizando esa premisa, Gene Kim explica los tres modos como principios de DevOps:

Primer modo Pensamiento sistémico Destaca el rendimiento de todo el sistema, en lugar del rendimiento de una unidad aislada concreta de una tarea o departamento, que puede ser tan grande como una división o tan pequeña como un contribuyente individual.
Segundo modo Aumento de los ciclos de feedback Se crean ciclos de feedback de derecha a izquierda. El objetivo de la mayoría de las iniciativas de mejora de procesos es recortar y ampliar los ciclos de feedback, de forma que se puedan aplicar continuamente las correcciones necesarias.
Tercer modo Cultura de experimentación y aprendizaje continuos Creación de una cultura que cultive dos elementos: la experimentación continua, en la que se afrontan riesgos y se aprende de los errores, y la comprensión de que la repetición y la práctica es un requisito previo de la maestría.

La entrega continua (CD) se centra en el primer modo: automatizar el flujo de desarrollo a operaciones. La automatización desempeña una función obvia en ayudar a acelerar el sistema de implementación. Pero hay más pensamientos sistémicos aparte de la automatización.

El segundo modo se caracteriza por la práctica: "Devs también lleva localizadores". Aunque no es necesario el uso literal de localizadores, significa conducir a los desarrolladores a incidencias funcionales. De esta manera comprenden las consecuencias de sus elecciones de desarrollo. Por ejemplo, pueden motivarlos a poner los mensajes de registro en lugares mejores y a que esos mensajes tengan más sentido. No es solo la concienciación. Los desarrolladores también aportan su entendimiento interno del sistema al trabajo de resolución de problemas, para que las resoluciones se encuentren antes y se implementen mejor.

Este tercer método consiste en realizar experimentos graduales en el sistema en general, no solo cambios en la aplicación a lo largo del canal. Dicho de otro modo, es relativamente fácil ver cuánto tiempo lleva la automatización y utilizar una infraestructura cada vez más potente para seguir mejorándola. Cuesta más entender cómo las entregas entre funciones u organizaciones provocan retrasos. Esto quiere decir que los equipos "inspeccionan y adaptan" todo el flujo de trabajo de entrega en busca de oportunidades para mejorar la colaboración humana. De hecho, la CD requiere tener la costumbre de adaptar y mejorar. Si el equipo no reflexiona acerca de cómo ser más eficiente y, a continuación, revisa y ajusta su comportamiento en lo demás, la CD no crecerá ni progresará. El equipo necesita sentir que tiene el poder de resolver sus propios problemas.

En scrum, cada retrospectiva es una oportunidad para mejorar las prácticas y las herramientas. Pero si el equipo no aprovecha esas oportunidades para solucionar problemas técnicos tanto a corto como a largo plazo, simplemente esperarán a que el propietario del producto mande tareas de CD al backlog, cosa que nunca ocurrirá.

DevOps es una metodología ágil aplicada más allá del equipo de software

Scrum se aplica fundamentalmente al principio de la metodología ágil "Aceptar la variación de los requisitos, aunque sea tarde, en desarrollo. Los procesos ágiles aprovechan los cambios para lograr la ventaja competitiva del cliente".

La entrega continua se aplica fundamentalmente al principio ágil "Nuestra máxima prioridad es la satisfacción del cliente mediante la entrega temprana y continua de software de gran valor."

Esto significa que la metodología ágil trata más de acoger cambios entrantes y salientes que de llevar a cabo ritos como reuniones rápidas y planificación de sprints. De hecho, el manifiesto ágil cuenta con otros 10 principios. En lugar de tratar de elegir entre esos principios, se deben considerar un todo. Todos juntos, esos principios representan una postura hacia los cambios compartida por la metodología ágil y DevOps.

Este personal se ha quedado bloqueado intentando ejecutar sistemas frágiles que, además, son los más importantes para las empresas. Por ello, también son los que necesitan los cambios más urgentes. Por ello, esta idea ágil de adoptar el cambio no consiste en aplicarlo "porque sí". Se trata de responsabilizar al desarrollo de la calidad de sus cambios, al mismo tiempo que se mejora la capacidad general para entregar valor empresarial. Este enfoque sobre el valor empresarial es otro aspecto que comparten la metodología ágil y DevOps.

Por último, ni la metodología ágil ni las DevOps son objetivos empresariales por sí mismas. Ambas constituyen movimientos culturales que pueden inspirar a tu organización a usar mejores métodos para lograr los objetivos. La metodología ágil y las DevOps funcionan mejor en combinación que como enemigas. El truco para evitar el enfrentamiento entre estas dos ideas consiste en comprender los valores y principios más profundos sobre los que se erigen. Las definiciones, breves pero delimitadas, conducen al pensamiento aislado. Ahora que sabes que la metodología ágil es algo más que scrum, y que las DevOps son algo más que la CD, estás preparado para probar la potente combinación de metodología ágil y DevOps.

A continuación
Agile Teams