{"id":1851,"date":"2021-06-14T05:37:00","date_gmt":"2021-06-14T05:37:00","guid":{"rendered":"https:\/\/www.capgemini.com\/mx-es\/?post_type=research-and-insight&p=1851"},"modified":"2025-04-05T13:27:00","modified_gmt":"2025-04-05T13:27:00","slug":"los-beneficios-de-devops-como-moldear-a-su-equipo-para-que-tenga-exito","status":"publish","type":"research-and-insight","link":"https:\/\/www.capgemini.com\/mx-es\/insights\/biblioteca-de-investigacion\/los-beneficios-de-devops-como-moldear-a-su-equipo-para-que-tenga-exito\/","title":{"rendered":"Los beneficios de DevOps: c\u00f3mo moldear a su equipo para que tenga \u00e9xito"},"content":{"rendered":"\n
\"Web-Banner-The-benefits-if-DevOps-How-to-shape-your-team-to-succeed-1\"\/\"\"\/<\/div>

Los beneficios de DevOps: c\u00f3mo moldear a su equipo para que tenga \u00e9xito<\/h1><\/div>
<\/div><\/div><\/div><\/div><\/div><\/header>\n\n\n\n
\n

En la parte 1 , exploramos la definici\u00f3n de DevOps y abordamos algunos de los desaf\u00edos que existen al implementar DevOps en organizaciones de TI. En la parte 2, veremos los beneficios de usar el modelo DevOps dentro de sus equipos.<\/p>\n\n\n\n

Volviendo a la definici\u00f3n de DevOps de la Parte 1, DevOps se puede definir simplemente como: las personas que crean la aplicaci\u00f3n, ejecutan la aplicaci\u00f3n. Entonces, \u00bfpor qu\u00e9 DevOps? \u00bfPor qu\u00e9 adoptar este enfoque? \u00bfC\u00f3mo es mejor que el modelo tradicional de funci\u00f3n dedicada Build \/ Run que se implementa com\u00fanmente en las organizaciones de TI? \u00bfQu\u00e9 problemas resuelve? Repasemos algunas de las fallas clave del enfoque tradicional de compilaci\u00f3n o ejecuci\u00f3n. Estas deficiencias dar\u00e1n una idea de c\u00f3mo DevOps puede ser m\u00e1s beneficioso para las organizaciones.<\/p>\n\n\n\n

En el modelo tradicional de funci\u00f3n dedicada Build \/ Run, cada funci\u00f3n tiene prioridades en competencia de manera efectiva. \u201cBuild\u201d quiere moverse lo m\u00e1s r\u00e1pido posible, implementando funciones en Producci\u00f3n en el ciclo m\u00e1s corto posible. \u201cRun\u201d quiere estabilidad por encima de todo. Si alguna vez ha sido el t\u00e9cnico responsable durante un P1, sabe lo intensa que es esta situaci\u00f3n. Y har\u00e1 todo lo que est\u00e9 a su alcance para evitar que esto ocurra. A menudo, esto significar\u00e1 minimizar la tasa de cambio en el sistema de producci\u00f3n. Los profesionales de TI son conscientes de la naturaleza fr\u00e1gil de muchas soluciones de TI. El adagio \u201cSi no est\u00e1 roto, no lo arregles\u201d se modifica para que los profesionales de TI digan \u201cno lo toques para que no se rompa\u201d. Por lo tanto, \u201cEjecutar\u201d a menudo quiere ralentizar el ciclo de Cambio tanto como sea posible. La tasa de cambio deseada es una prioridad conflictiva en este modelo,<\/p>\n\n\n\n

El modelo funcional genera externalidades en la forma en que trabajan: el lenguaje elegante de su trabajo empuja los problemas que crean a los dem\u00e1s. Como \u201cBuild\u201d a menudo se ejecuta en la ejecuci\u00f3n del proyecto (Waterfall, Agile o algo intermedio, no importa), la mayor\u00eda se establece utilizando el modelo de caso de negocios com\u00fan que dice efectivamente \u201cSi invertimos X, obtendremos Y\u201d. Una vez aprobado, el \u00e9xito del proyecto es a menudo una medida de la parte \u201cInvertir X\u201d del caso de negocio, es decir, medidas de \u00e9xito puntuales, presupuestarias o centradas en hitos. Y asegurarse de que la \u201cInversi\u00f3n X\u201d parezca exitosa a menudo puede ocurrir a expensas del lado \u201centonces obtendremos Y\u201d de la ecuaci\u00f3n, que es la parte m\u00e1s importante de la ecuaci\u00f3n, es el rendimiento. Para que un proyecto reclame el \u00e9xito al cumplir con sus medidas de \u00e9xito a tiempo \/ dentro del presupuesto \/ centradas en los hitos, los problemas conocidos en un proyecto de construcci\u00f3n a menudo quedan sin resolver. Son \u201carrojados por encima de la valla\u201d para que \u201cRun\u201d se ocupe de ellos despu\u00e9s de que el proyecto haya terminado.<\/p>\n\n\n\n

Cada desarrollador de cada proyecto ha escrito una funci\u00f3n que tiene una probabilidad razonable de causar problemas importantes una vez implementada. Entonces, \u00bfpor qu\u00e9 ocurre esto y por qu\u00e9 no lo corrigen? \u00bfSon malos en su trabajo? \u00bfEscriben el c\u00f3digo con flojera? Si haces esta pregunta, probablemente no seas un programador. Siempre puede distinguir a los codificadores de los no codificadores, es decir, las personas que han escrito incluso aplicaciones b\u00e1sicas frente a las que nunca han escrito una l\u00ednea de c\u00f3digo. Los no codificadores no pueden comprender que los errores est\u00e1n 100% seguros en las soluciones de TI. En su propia experiencia, un \u201cerror\u201d son los errores ortogr\u00e1ficos en un correo electr\u00f3nico o documento de Word, con su error claramente resaltado<\/em> (incluso corregido) por la propia aplicaci\u00f3n antes de que se env\u00ede a su destinatario. sus errores son claros y f\u00e1ciles de corregir e imaginan que debe ser el mismo al escribir software. Ir\u00f3nicamente, incluso existen errores en este contexto<\/em>, ya que los creadores de contenido no se molestan con la revisi\u00f3n b\u00e1sica y emiten contenido con errores ortogr\u00e1ficos. Pero este punto escapa a los no codificadores. Los errores son ciertos en TI y ocurren con mayor frecuencia en casos excepcionales, que son dif\u00edciles de prever para los desarrolladores.<\/p>\n\n\n\n

\u201c\u00bfFunciona en mi m\u00e1quina\u2026?\u201d A menudo se presenta como una defensa combinada, una declaraci\u00f3n f\u00e1ctica y una pregunta cuando un profesional de TI le informa al desarrollador un error de producci\u00f3n. El probablemente at\u00f3nito IT Pro murmurar\u00e1 en respuesta \u201cbueno, no se est\u00e1 ejecutando en su m\u00e1quina\u2026\u201d. El problema es que, como la m\u00e1quina de los desarrolladores, es un entorno de circuito cerrado. Los casos de excepci\u00f3n generalmente no se experimentar\u00e1n en este entorno. Incluso los intentos de imitar entornos de producci\u00f3n en un entorno de desarrollador individual se quedan muy cortos, espere, no entornos de producci\u00f3n. Por lo tanto, incluso cuando el desarrollador tiene la sospecha de que una funci\u00f3n est\u00e1 mal escrita, puede cumplir con su objetivo funcional, pasar rondas de prueba y ser liberado. Esto crea un error de bomba de tiempo, esperando que ocurra ese caso de excepci\u00f3n,<\/p>\n\n\n\n

Parece que los desarrolladores, \u00bfverdad? Equivocado. Aqu\u00ed est\u00e1 la cuesti\u00f3n: los desarrolladores son la parte superior de la cadena alimentaria de TI. Es el peque\u00f1o y sucio secreto de TI. Los desarrolladores pueden realizar literalmente todas las dem\u00e1s funciones de TI (probador, profesional de TI, administrador de red), pero no funciona al rev\u00e9s. Los probadores, los profesionales de TI, los administradores de red NO PUEDEN codificar como los desarrolladores, aunque a menudo act\u00faan con la actitud que pueden. Su secuencia de comandos no es un c\u00f3digo de aplicaci\u00f3n. Por lo tanto, no se equivoque, los desarrolladores son las estrellas del rock, est\u00e1n tratando de construir el futuro para sus clientes.<\/h3>\n\n\n\n

En el lado Run de la valla, los equipos \u201cRun\u201d generan sus propias externalidades. A menudo, esto es un subproducto de las circunstancias en las que operan. La financiaci\u00f3n de la \u201cejecuci\u00f3n\u201d de TI a menudo se considera un costo puro en el caso de negocio, no una inversi\u00f3n. En lugar de objetivos puntuales o dentro del presupuesto, los objetivos del equipo de Run son a menudo una visi\u00f3n poco realista de \u201chacer m\u00e1s con menos\u201d constantemente. En la pr\u00e1ctica, esto generalmente se convierte en \u201chacer menos con menos\u201d. Las actividades importantes se descartan a medida que los recursos se dispersan. De hecho, estas pueden ser las actividades exactas que habr\u00edan evitado que ocurriera un caso excepcional, como ayudar a los Desarrolladores a establecer un entorno de desarrollo similar o habilitar herramientas que minimicen el riesgo de cambios de producci\u00f3n, como la alternancia azul \/ verde. Al igual que los desarrolladores, es un error pensar que los profesionales de TI son malos en su trabajo.<\/p>\n\n\n\n

Prioridades en conflicto. Se crean externalidades. Salida lenta y de baja calidad. Hay m\u00e1s: herramientas y procesos separados. Bombas de tiempo de producci\u00f3n. Enfoque en silos. Estos son solo ALGUNOS de los problemas con el modelo funcional tradicional Build \/ Run.<\/p>\n\n\n\n

Entonces, \u00bfcu\u00e1l es el mejor enfoque? \u00a1DevOps por supuesto! DevOps tiene como objetivo garantizar que se logre el equilibrio adecuado entre el progreso de las caracter\u00edsticas de la aplicaci\u00f3n (la \u201ccompilaci\u00f3n\u201d tradicional) y la estabilidad de la aplicaci\u00f3n (la \u201cejecuci\u00f3n\u201d tradicional), ya que la propiedad de DevOps existe en AMBOS el c\u00f3digo (donde se construir\u00e1n nuevas caracter\u00edsticas) la aplicaci\u00f3n Productionised (el tradicional \u201cRun\u201d).<\/p>\n\n\n\n

Los beneficios de DevOps<\/h2>\n\n\n\n

Al ver c\u00f3mo se desempe\u00f1a DevOps en el contexto de los problemas descritos, resulta f\u00e1cil ver por qu\u00e9 DevOps funciona y, en la mayor\u00eda de los casos, es un modelo operativo superior:<\/p>\n\n\n\n