Ágil vs DevOps: ¿Cuál deberías elegir y por qué?
¿Alguna vez te has preguntado qué buenas prácticas siguen las organizaciones de alto rendimiento que les permite alcanzar ese nivel? ¿Se inclinan hacia enfoques ágiles o DevOps?
Para alcanzar sus objetivos, estas organizaciones a menudo recurren a una combinación de herramientas ágiles para gestionar el desarrollo iterativo y la planificación adaptativa, junto con herramientas DevOps que optimizan la automatización, la integración continua y el despliegue.
El objetivo de un proceso de desarrollo y operaciones es ayudar a la empresa a cumplir con sus requerimientos, facilitar la colaboración entre los miembros del equipo y romper los silos para desbloquear problemas y, finalmente, completar los proyectos o funcionalidades en los que están trabajando. De esta manera, pueden incrementar el número de usuarios activos diarios o mensuales, o en el caso de aplicaciones empresariales, aumentar las funcionalidades de sus aplicaciones.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Cuando los equipos trabajan en silos, surgen brechas de comunicación que resultan en caos. En cambio, cuando los equipos trabajan en conjunto, son más efectivos.
En el alcance de este artículo, cubriré los enfoques ágiles y de DevOps, ejemplos de cuándo adoptar metodologías específicas y cómo se ve afectado el testing en cada uno de estos escenarios.
Prácticas de desarrollo de software ágil
En comparación con el proceso de desarrollo en cascada, ágil se centra en uno de sus principios clave, que consiste en satisfacer a los clientes desde el inicio del proceso y a través de la entrega continua. La entrega continua solo es posible cuando involucramos al equipo de calidad desde el principio y colaboramos con ellos frecuentemente.
Actualmente, algunas empresas pequeñas y medianas se encuentran en una situación en la que no siguen completamente un enfoque ágil ni de cascada, sino una mezcla de ambos. Estos llamados equipos ágiles enfocan tanta energía en procesos granulares como reuniones diarias de 30 minutos y retrospectivas de 60 minutos, que se olvidan del retorno sobre la inversión que aportan, lo que termina generando una situación donde se encuentran muchos bugs en producción.
¿Realmente la industria ha migrado del enfoque en cascada?
¿Alguna vez has formado parte de una organización (que pensabas que seguía procesos ágiles de desarrollo de software) solo para darte cuenta de que el equipo de calidad solo se involucra en el testing después de que el desarrollo ya ha finalizado?
En este ejemplo, aún lo llamaban ágil porque los miembros del equipo de desarrollo trabajaban en múltiples ramas (o funcionalidades) de forma iterativa. Pero al momento de requerir la validación de sus funcionalidades, esperaban hasta que todo el desarrollo estuviera terminado, lo cual es la esencia de la metodología en cascada. Sin embargo, como las empresas quieren avanzar más rápido para ampliar su base de clientes, la mayoría de las veces los equipos terminan acumulando deuda técnica.
La mejor manera de solucionar este problema es transformar la organización para que sea completamente ágil y trabaje de la mano con el equipo de calidad de forma iterativa. Esto implica colaborar con todos los involucrados para garantizar que entiendan las consecuencias de no hacer el cambio y cómo puede afectar la experiencia del usuario final.
Marcos ágiles y sus variantes
En el alcance de este artículo, hablaré de dos de los marcos ágiles más populares:
- Scrum
- Kanban
Scrum es una metodología ágil utilizada en el desarrollo de software basada en procesos iterativos e incrementales. Consiste en adherirse a desarrollos con límite de tiempo llamados sprints. La duración de los sprints varía según la organización, pudiendo ser semanal, mensual o trimestral.
Hay una sesión de planificación del sprint, seguida de la ejecución del sprint donde ocurre la implementación y las pruebas, incluyendo reuniones diarias, y finalmente finaliza con una sesión de retrospectiva.
Scrum suele implementarse en equipos de desarrollo de productos donde los miembros deben limitar su trabajo en el tiempo para cumplir con los plazos de los clientes. Se aplica principalmente a aplicaciones B2C porque, si esperas demasiado, tu funcionalidad ya no será nueva, ¡ya que alguien más podría haberla implementado!
En aplicaciones B2B, que generalmente corresponden a empresas, se utiliza comúnmente una versión modificada de la metodología ágil llamada SaFe - Scaled Agile Framework.
La mayoría de los proyectos en empresas suelen clasificarse en una de las siguientes categorías:
- Nivel de equipo
- Nivel de programa
- Nivel de portafolio
Los proyectos a nivel de equipo son desarrollos basados en características que implican que cada miembro del equipo sea responsable de su propio proyecto y procesos. Estos equipos suelen utilizar Scrum o Kanban dependiendo de la naturaleza de su trabajo.
Si los equipos pertenecen a organizaciones de investigación y desarrollo o automatización de pruebas, entonces es imperativo que sigan Kanban, que es menos rígido, y el objetivo es centrarse en finalizar la tarea actual en vez de saltar al siguiente "objeto brillante" a la vista. Si los equipos forman parte de la organización de desarrollo de producto, entonces tienden a usar procesos Scrum.
Los proyectos a nivel de programa implican que varios equipos trabajen hacia un objetivo específico, como la migración a AWS. Aunque este proyecto podría caer en la categoría de proyectos a nivel de portafolio, argumentaría que no necesariamente impacta a equipos como recursos humanos o contabilidad.
En este caso, el proyecto de migración a AWS podría durar meses debido a problemas imprevistos, por lo que el enfoque está en culminar la migración a AWS con éxito mientras se divide en sprints justificados.
Los proyectos a nivel de portafolio involucran diferentes organizaciones dentro de la empresa; un ejemplo sería la implementación de JIRA. Cada organización necesitaría que los flujos de trabajo de JIRA se implementaran de manera distinta según sus necesidades. Los equipos de recursos humanos no requieren pruebas; su enfoque se centra principalmente en atender solicitudes específicas de los empleados, y una vez que los asisten, la tarea se marca como "completa".
Las metodologías ágiles deben ser adoptadas por organizaciones conocidas por someterse a cambios constantes. Pero estos cambios aún deben pasar por una fase de pruebas y corrección de errores, y las pruebas no son necesariamente automatizadas, lo que resulta en un aumento del tiempo de los procesos.
Finalmente, cuando las funcionalidades están listas para ser desplegadas, se entregan al equipo de build/ops. Por lo tanto, las pruebas ocurren de forma iterativa en comparación con el enfoque en cascada (waterfall), pero no se desplazan tanto hacia el inicio como para centrarse en pruebas y entrega continuas. ¡De ahí la necesidad del enfoque DevOps!
-
Testiny
Visit WebsiteThis is an aggregated rating for this tool including ratings from Crozdesk users and ratings from other sites.4.9 -
Testpad
Visit WebsiteThis is an aggregated rating for this tool including ratings from Crozdesk users and ratings from other sites.4.1 -
TestMonitor
Visit WebsiteThis is an aggregated rating for this tool including ratings from Crozdesk users and ratings from other sites.4.6
Enfoque DevOps
El enfoque DevOps se centra en aspectos que van más allá del desarrollo y las pruebas, y promueve una canalización CI/CD completamente automatizada junto con capacidades de monitoreo. Mientras Agile abraza los cambios, el enfoque DevOps se enfoca en pruebas y entrega continuas para asegurar liberaciones frecuentes y exitosas para los usuarios finales.
El objetivo del equipo de Operaciones de TI es escalar el proceso de desarrollo de software para acelerar la escritura y actualización del código responsable de crear nuevas aplicaciones y servicios y actualizar funciones dentro del equipo de TI.
Incluso en términos de la estructura de los equipos, hoy en día los equipos de calidad y operaciones de TI forman parte de la misma organización para poder trabajar de la mano. De hecho, se ha incorporado un nuevo rol llamado TestOps que se enfoca específicamente en configurar las canalizaciones CI/CD, donde se ejecutan pruebas automáticas sobre las pull requests, entregando retroalimentación inmediata a los equipos de desarrollo.
Las pruebas automatizadas son esenciales para escalar los esfuerzos de pruebas y su valor se pierde si no forman parte de un sistema de pruebas y ciclo de despliegue continuo. Por ello, el personal de TestOps siempre se mantiene ocupado con el mantenimiento de la infraestructura de pruebas automáticas.
Esto asegura que los miembros del equipo de operaciones se centren en ofrecer una infraestructura de clase mundial para el desarrollo de software sin distraerse con la infraestructura de pruebas.
Hoy en día existen muchas herramientas y prácticas DevOps para agilizar el proceso general.
- Un archivo de estado de Terraform hace referencia a un conjunto de infraestructuras que se definen y gestionan como una sola unidad; así es como se definen y gestionan los distintos entornos de desarrollo y pruebas. Terraform ayuda a configurar servidores, pero necesitamos una infraestructura para ejecutar estos servidores.
- AWS proporciona la infraestructura mediante instancias EC2, que actualmente son la manera más rentable de configurar y ejecutar estos servidores. Para dar un paso más, si tu stack tecnológico cuenta con muchos microservicios, con docker compose puedes definir y ejecutar múltiples entornos docker de contenedores.
- Ansible automatiza el proceso de configuración de las máquinas para que ejecuten cualquier proceso o servidor.
- Kubernetes ayuda a gestionar un clúster de estas instancias EC2 como un pod y programa la ejecución de contenedores en este clúster según los recursos de cómputo disponibles.
¿Deberías usar Agile o DevOps?
Si bien el debate entre el desarrollo de software Agile y el enfoque DevOps es constante dentro de las organizaciones, la mejor manera de abordarlo es haciéndonos las siguientes preguntas:
- ¿Cuál es la adaptabilidad de nuestra organización frente a nuevas tecnologías?
- ¿Somos capaces de oponernos a nuestros competidores en cuanto a la calidad de nuestros productos?
- ¿Es probable que los clientes utilicen nuestros productos porque cumplen con sus expectativas?
Si las respuestas a las preguntas anteriores implican algún tipo de negación, entonces es momento de centrarnos más en una combinación de ambos enfoques y personalizarlo para satisfacer nuestras necesidades.
La Metodología Ideal de Desarrollo de Software
La diferencia clave entre los procesos de desarrollo de software basados en agile y DevOps es que el primero se centra más en adaptarse a cambios constantes, mientras que el segundo pone énfasis en pruebas continuas, entrega y despliegue continuos. La colaboración entre los equipos de desarrollo y operaciones es crucial para que el equipo de desarrollo no se vea bloqueado.
Así que, en mi opinión, un proceso ideal de desarrollo de software debería implicar lo siguiente:
- Manejo de diferentes perfiles de cliente/usuario e incorporación de retroalimentación de los clientes
- Enfocarse en las mejores prácticas para evitar la acumulación de deuda técnica
- Mejora continua, pruebas continuas, integración continua, entrega continua, despliegue continuo y monitoreo
Así es como se vería el proceso:
Gestionar diferentes perfiles de cliente no es algo restringido a los equipos de gestión de producto. Al final del día, ¿por qué desarrollamos estos productos? ¿Cuál es el propósito de estos productos si no los llegan a utilizar los clientes?
Toma el ejemplo clásico de Nokia: acumularon deuda técnica por no mantenerse al día con las tendencias del mercado, en particular la innovación de su competidor Apple. Se enfocaron en seguir ciclos de sprint rigurosos ¡solo para ser olvidados eventualmente!
Todas las empresas deben entender por qué se desarrollan sus características y qué tipo de clientes atienden. Esto garantizará que estemos desarrollando funcionalidades centradas en el usuario.
Cuando se lanza un producto nuevo, ya sea una aplicación móvil o una aplicación web, siempre hay que garantizar que exista una vía para que los clientes dejen sus comentarios. No todas las empresas siguen un proceso estricto de colaborar estrechamente con soporte al cliente.
CI/CD
Finalmente, aboga por la integración continua y la entrega continua basadas en IA/ML. Cuando un proyecto falla, esto no necesariamente denota una carencia de habilidades del equipo, sino más bien la falta de pruebas suficientes y la imposibilidad de detectar problemas antes durante el desarrollo.
Pero a veces, incluso con pruebas adecuadas y automatización, pueden ocurrir problemas—si existiera un sistema de recomendaciones para identificar cuándo lanzar y cuándo no, quizás podrían evitarse fracasos catastróficos.
Las iteraciones frecuentes ayudan al equipo de desarrollo a entender qué funciona y qué no, y apoyan el pensamiento sobre la escalabilidad. ¡La advertencia es que consume tiempo! Si otro sistema de recomendaciones/predicción pudiera recopilar datos sobre los clientes y predecir si una funcionalidad específica ayudará a ganar tracción o a fracasar incluso antes de comenzar el desarrollo, facilitaría el proceso de crear un producto de alta calidad desde el primer día.
El objetivo general es asegurar que el impacto para el negocio se multiplique más rápido al adoptar estas mejores prácticas como parte del proceso de desarrollo.
Reflexiones Finales
Al final, tanto Agile como DevOps desempeñan un papel crucial en el desarrollo moderno de software, pero la elección adecuada depende de los objetivos de tu organización, la estructura del equipo, las opciones de precios y las necesidades del proyecto.
Agile se centra en el desarrollo iterativo y la flexibilidad, mientras que DevOps enfatiza la entrega continua, la automatización y la colaboración entre el desarrollo y las operaciones. Muchas organizaciones logran el éxito al combinar ambos enfoques para maximizar la eficiencia y la calidad. No importa el camino que elijas, es fundamental alinear tus herramientas y procesos para impulsar la innovación y entregar valor más rápido.
Para obtener más información sobre cómo optimizar tus flujos de trabajo de desarrollo y mantenerte al día con las tendencias de la industria, suscríbete al boletín de The CTO Club.
