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

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")... ¡á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!

Although I've taken the hype to an extreme, the sound bites about Agile and DevOps can make them sound like very different ideas. Compounding the confusion, both concepts seem to defy definition, even as they have their own jargon and slogans. As the elder, Agile may be less vague, but it's certainly common for people to become frustrated with the myriad of definitions for DevOps. The lack of definition has lead to some common conflation. 

Many people think Agile means Scrum and DevOps means Continuous Delivery. This oversimplification creates an unnecessary tension between Agile and DevOps so you may be surprised to find that they are best friends!

There's no denying the historical connection between DevOps and Agile. When Patrick DuBois and Andrew Clay Schafer tried to connect at the Agile 2008 Conference about "Agile Infrastructure", the connection to DevOps was born. Although Patrick later coined the term "DevOps", the Agile Conference continues to honor this connection with a DevOps track. But let's dive deeper than history and consider the practical connections between Agile and DevOps, when we look below the surface of Scrum and Continuous Delivery.

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

In the DevOps community, those with Agile experience acknowledge that scrum is useful for tracking planned work. Some work in operations can be planned: releasing a big system change, moving between data centers, or performing system upgrades. But much of the work of operations is unplanned: performance spikes, system outages, and compromised security. These events demand immediate response. There's no time to wait for the items to be prioritized in a backlog or for the next sprint planning session. For this reason, many teams that have come to embrace DevOps thinking, look beyond Scrum to Kanban. This helps them track both kinds of work, and helps them understand the interplay between them. Or, they adopt a hybrid approach, often called Scrumban or Kanplan (kanban with a backlog).

In many ways, the key to Scrum's wide adoption may be that it prescribes no technical practices. Scrum's lightweight management practices often make a big difference for a team. Where there was once competing priorities from multiple masters, there is now a single set of priorities in the backlog. And where there was once too much work in progress, there is now a plan constrained by what time has shown is really possible. In combination, these can take a team to new levels of productivity. However, the team may find themselves constrained by the lack of technical practices, such as coding reviewsautomated acceptance tests, and continuous integration.

Otros procesos ágiles como la programación extrema tienen sólidas opiniones 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 propietarios de servicio, responsables de priorizar esas capacidades no funcionales. De vez en cuando, puede que los dos propietarios tengan que lidiar con el "toma y daca", pero la mayor parte del tiempo lo pueden hacer equipos independientes. Esta no tiene por qué ser la única forma de "ampliar el feedback" de las operaciones, pero ayuda a superar los típicos prejuicios sobre las funcionalidades que tienen los propietarios de 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 corriente (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, mientras esa persona aporte experiencia en la automatización de compilaciones, pruebas y despliegues de software.

DevOps no es solo entrega continua

When done well, the discipline of Continuous Delivery (CD) helps to limit work in progress, while the automation of deployment helps to elevate constraints. In this way, CD helps a software team deliver more frequently and with higher quality, instead of having to choose between the two. However, just as teams focusing only on Scrum can miss the broader context of Agile, so too can teams focusing on Continuous Delivery miss the broader context of DevOps.

The practice of CD does not directly address problems in communication between the business and a software team. If the business has a year-long, budget-driven planning cycle, then a team delivering every commit into production may still have to wait months before the business can react. All too often those reactions come as step-functions, like canceling the project, or worse doubling the project team (because a large influx of new people is disruptive).

The Agile Fluency Model indicates the first level of fluency as "Focus on Value", where teams focus on transparency and alignment. Without this fluency, CD can easily devolve into an endless cycle of technical improvement that yields no appreciable value to the business. A team might get good at delivering fast with high quality, but for a product that has low value for end-users or the business. Even when there are many users who say good things, that assessment of low value might only be possible at a larger business portfolio level. Without this important fluency, it is hard to weigh technical practices against features. This is particularly important for a team with a legacy codebase, that may not have automated tests or a design suitable for frequent deployment. In a legacy context, a CD transformation may take years. So it's that much more important to be able to demonstrate business benefit.

Los tres modos

DevOps consiste en algo más que automatizar el canal de despliegue. 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 los principios de DevOps:

Primer modo Pensamiento sistémico emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department — this can be as large as a division or as small as an individual contributor.
Segundo modo Aumentar los ciclos de feedback Crear ciclos de feedback de derecha a izquierda. El objetivo de casi cualquier iniciativa de mejora en los procesos es reducir y aumentar los ciclos de feedback para poder realizar las correcciones necesarias de forma continua.
Tercer modo Cultura de la experimentación y el aprendizaje continuos Creación de una cultura que fomente dos cosas: la experimentación continua, asumiendo riesgos y aprendiendo de los errores; y la comprensión de que la repetición y la práctica es el requisito previo de la maestría.

 

La entrega continua (EC) 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 despliegue. Pero hay más pensamientos sistémicos aparte de la automatización.

The Second Way is characterized by the practice, "Devs wear pagers too."  Although the literal use of pagers may not be necessary, it means pulling developers into operational issues. This helps developers understand the consequences of their development choices. For example, that can inspire developers to put log messages in better places and to make those messages more meaningful. It's not just about awareness. Developers also bring their internal understanding of the system to troubleshooting efforts, so a resolution can be found and implemented faster.

The Third Way is about making incremental experiments in the system as a whole, not just as changes to the application moving through the pipeline. In other words, it's relatively easy to see how long automation takes and to use increasingly powerful infrastructure to keep improving it. It's harder to understand how the hand-offs between roles or organizations introduces delays. This means teams "inspect and adapt" across the whole delivery workflow, looking for opportunities to improve human collaboration. For that matter, CD requires a habit of adapting and improving. If the team doesn't reflect on how to become more effective, and then tune and adjust its behavior on anything else, then CD will not grow and thrive either. The team needs to feel empowered to solve their own problems.

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 EC 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 planificaciones 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 las metodologías ágiles y DevOps.

Estos amigos se quedaron atascados al tratar de ejecutar sistemas frágiles que son, además, los más importantes para el negocio. Como son los más importantes para el negocio, también son los que necesitan los cambios más urgentes. Como tal, esta idea ágil de acoger el cambio no es "porque sí". Es por responsabilizar al desarrollo de la calidad de los cambios, al tiempo que se mejora la capacidad general de aportar valor al negocio. Este énfasis en el valor del negocio es otro aspecto que comparten la metodología ágil y DevOps

Finally, neither Agile nor DevOps are business goals in and of themselves. Both are cultural movements that can inspire your organization with better means for achieving your goals. Agile and DevOps work better in combination, than as adversaries. The trick to avoiding confrontation between these two ideas is to understand the deeper values and principles upon which they are formed. Quick, but narrow, definitions lead to siloed thinking. Now that you know there's more to Agile than Scrum, and there's more to DevOps than CD, you're ready to try the powerful Agile + DevOps combination.

Up Next
Tutoriales