Opiniones | Opinions | Editoriales | Editorials

¿Cuándo entran en conflicto los métodos ágil y DevOps?

 
Picture of System Administrator
¿Cuándo entran en conflicto los métodos ágil y DevOps?
by System Administrator - Wednesday, 12 October 2016, 10:32 PM
Group Colaboradores y Partners

¿Cuándo entran en conflicto los métodos ágil y DevOps?

por Christopher Ward

El experto Chris Ward explica por qué usar ágil y DevOps juntos puede parecer ideal, pero el conflicto surge en la práctica.

Mucho se ha escrito sobre las metodologías ágil y DevOps. En concreto, hablamos mucho sobre el valor de combinar ambos enfoques para fortalecer un proceso de desarrollo de productos. Sin embargo, hay ocasiones en que estas dos teorías entran en conflicto en la práctica, sobre todo cuando las ganancias a corto plazo de lo ágil entran en conflicto con los objetivos a largo plazo de DevOps.

Comparando lo ágil y DevOps

Los equipos ágiles tienen como objetivo el despliegue rápido y continuo para maximizar el beneficio para el cliente a corto plazo. Las carreras cortas de lo ágil se mueven en un ciclo de "construcción-medición-aprendizaje", donde nuevas funciones se ponen en marcha continuamente, se miden por su éxito en el mercado, son iteradas y luego relanzadas lo más rápido posible. Los ciclos ágiles, sin duda, requieren el despliegue de nuevas características al final de cada carrera para ser más eficaces.

Mientras que un enfoque DevOps también tendría como objetivo maximizar el beneficio para el cliente, podría apuntar a tratar de lograr esto mediante la priorización de la fiabilidad del sistema y la mínima interrupción. En lugar de un despliegue rápido, un enfoque centrado en DevOps quizá tendría como objetivo minimizar el tiempo de inactividad, los errores y los problemas en el sistema mediante la combinación del despliegue del trabajo de múltiples equipos para asegurar menos interrupciones al sistema mayor.Fundamentalmente, DevOps se preocupa por el sistema más grande y por garantizar que la tecnología funciona sin interrupción o perturbación. Ciertamente, la entrega de funciones a corto plazo de los equipos de producto debe ser equilibrada con la salud a largo plazo del sistema de tecnología más grande.

Qué es más eficiente: ¿Construir más o documentar más?

Siguiendo uno de los principios fundamentales del manifiesto ágil, los equipos ágiles siguen la práctica de "trabajar el software sobre una amplia documentación". Los equipos ágiles siguen la filosofía de que cualquier tipo de gastos que les impide entregar código de calidad a los clientes son gastos que se deben reducir a toda costa.

Una organización DevOps exigiría la documentación para asegurar la eficiencia a largo plazo del desarrollo del producto. Para los equipos ágiles, un enfoque DevOps puede sentirse como más trabajo y menos tiempo para hacer código. Ciertamente, la cuestión de cómo, cuándo y qué documentar es algo así como una espada de doble filo: Nadie quiere que equipos que proporcionan valor al cliente se vuelvan ineficientes y sobrecargados de trabajo adicional. Sin embargo, los equipos de desarrollo web ágiles constantemente toman tiempo de sus carreras para rastrear y comprender los problemas, y los cambios de código anteriores se vuelven ineficiencia estratégica a largo plazo.

Qué es más prudente: ¿Pagar la deuda de tecnología ahora o más tarde?

En el núcleo de muchos productos de tecnología hay un conjunto de decisiones históricas sobre la manera de hacer frente a la "deuda tecnológica", una metáfora para el trabajo de desarrollo, refactorización y optimizaciones que a menudo se dejan de lado por otros objetivos de la empresa. Los principales objetivos de prácticamente cada startup son crecer los ingresos, aumentar las ganancias, crecer la base de clientes y retener a los usuarios. El desarrollo web durante este tiempo es, a menudo, un asunto rápido y sucio, centrado en lanzar lo más rápido y a menudo posible, y estar bien con los cabos sueltos en la tecnología que todo el mundo sabe que tendrá que ser reparado más adelante. Esta estrategia tiene mucho sentido, ya que las startups no tienen garantía de existir lo suficiente para arreglar su deuda tecnológica si no pueden volverse rentables. Como tal, la mayoría de las empresas se forjan inicialmente en este enfoque profundamente ágil de desarrollo.

Así, mientras que no es de extrañar que las empresas opten por cortar las esquinas, ignorar algunos principios DevOps y retrasar la salud de los sistemas más grandes durante su crecimiento inicial, a menudo incluso las empresas más grandes tienen problemas para moverse hacia sistemas holísticos cuando son estables y están mucho más allá de la fase de arranque. En algún momento, una organización centrada en DevOps exigirá que los problemas anteriores en el código (que no son necesariamente de cara al cliente) sean abordados, así como la creciente complejidad del código conforme la empresa crece.

Cualquier decisión de pagar tal deuda tecnológica se convierte en una carga para los equipos ágiles, ya que los distrae de la entrega de valor al cliente. Sin mencionar, que la decisión de pagar la deuda de tecnología, en lugar de lanzar más características, es un argumento que a menudo no sienta bien con los líderes de la compañía que se centran en el precio de las acciones y los ingresos anuales. Debido a que una empresa de éxito y sus líderes pueden enorgullecerse del valor del producto, la proposición de invertir tiempo y recursos para pagar la deuda de tecnología puede no ser aceptada. Cuando un modo de pensar DevOps no tiene un punto de apoyo en la cultura de la empresa, la deuda de tecnología puede no convertirse en una prioridad de la compañía y puede fácilmente convertirse en una carga para el equipo de operaciones separado, que, a su vez, lo dejará sentir en el desarrollo de productos estratégicos a largo plazo, ya que el sistema se vuelve espinoso, inestable y poco fiable.

De la misma manera que tiene sentido para todas las empresas pedir dinero prestado para empezar, es razonable que las empresas de tecnología aplacen el trabajo en sus sistemas. Sin embargo, en ambos casos, la deuda debe ser pagada por la empresa para mantener su viabilidad en el largo plazo. Como programador, Ward Cunningham lo describió: "Saltarse el diseño es como pedir dinero prestado. Refactorizar es como amortizar lo invertido. Un desarrollo más lento debido a la complejidad es como pagar intereses".

El tema de la deuda de tecnología, tal vez más que cualquier otro tema, da voces sobre el conflicto fundamental del corto plazo frente al largo plazo entre las filosofías ágil y DevOps. El enfoque ágil claro y directo que trae a una compañía de tecnología rápidamente a una posición de éxito es muy poco probable que no sea el mismo enfoque que le va a permitir que sea un líder exitoso en tecnología.

Próximos pasos

Quizás quiera leer también:

Profundice más 

Link: http://searchdatacenter.techtarget.com

1153 words