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 ("el 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!
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 resistirse a las definiciones, 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 común.
Mucha gente cree que "ágil" equivale a scrum y DevOps equivale a entrega continua. Esta simplificación excesiva genera una tensión innecesaria entre las metodologías ágil y DevOps, ¡pero te sorprendería saber que se llevan superbién!
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ó el vínculo con DevOps. Aunque Patrick acuñó el término “DevOps” más adelante, la conferencia sobre metodología ágil sigue rindiendo homenaje a 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 del 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 admiten que scrum es útil para hacer un 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, como los picos de rendimiento, las interrupciones del sistema y los fallos de seguridad. Estas situaciones exigen una respuesta inmediata. No se puede esperar a priorizar los elementos en un backlog o a la siguiente sesión de planificación de sprints. Por este motivo, muchos equipos que han adoptado la filosofía de DevOps no siguen scrum, sino 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 fuentes, 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 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 organizativas distintas para los productos que trabajamos. A nuestros propietarios de productos se les da bien comprender las funciones que necesitan los usuarios, pero no tanto valorar esas funciones con respecto a capacidades no funcionales como el rendimiento, la fiabilidad y la seguridad. Así pues, algunos productos de SaaS de Atlassian también tienen 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 las tareas las pueden realizar 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 funciones 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 "funciones" 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
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 EC 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 commit 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 funciones. 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 tardar años en llevarse a cabo. 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 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 | Hacer hincapié en el rendimiento del sistema completo, en lugar del rendimiento de un compartimento aislado del trabajo o un departamento en concreto (tan grande como una división o tan pequeño como un colaborador individual). |
| 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 excelencia. |
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.
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 pruebas graduales en el sistema en general, no solo cambios en la aplicación que avanza a lo largo de la canalización. 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 transferencias 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 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
Por último, ni la metodología ágil ni la DevOps son objetivos empresariales por sí mismos. Ambos constituyen movimientos culturales que pueden inspirar a tu organización a usar mejores métodos para lograr los objetivos. Las metodologías ágil y DevOps funcionan mejor en combinación que como enemigos. El truco para evitar el enfrentamiento entre estas dos ideas está en comprender los valores y principios más profundos sobre los que se erigen. Las definiciones breves pero estrechas conducen al pensamiento cuadriculado. Ahora que sabes que la metodología ágil es algo más que scrum, y que DevOps es algo más que la CD, lo tienes todo a punto para probar la potente combinación de las metodologías ágil y DevOps.
Conecta tus herramientas con Automation
Quizá el mayor desafío de trabajar con varias herramientas es el constante cambio de contexto y las interrupciones que esto supone. Cuando se está programando y hay que pasar a una tarea que no es de código, puede llevar horas recuperar el ritmo de trabajo. Por esta razón, cada vez más personas optan por la automatización a través de sus proveedores de Git y herramientas de gestión del trabajo. Estas son tres de las reglas de automatización más habituales.
- Cuando se crea una confirmación y el estado es “Por hacer”, pasa la incidencia a “En curso”. Ir a la regla
- Pasa el estado a “Hecho” cuando se fusione la solicitud de incorporación de cambios. Ir a la regla
- Si una compilación falla en Jenkins, añade un comentario en Jira y envía un mensaje al equipo en Slack. Ir a la regla
Consulta estas reglas de automatización y centenares más en la Biblioteca de plantillas de Jira Automation.
Empieza gratis con la plantilla de plan de proyectos de DevOps
Desarrolla, implementa y gestiona aplicaciones con un enfoque de herramientas abierto.
