{"id":4345,"date":"2023-02-16T23:06:24","date_gmt":"2023-02-16T23:06:24","guid":{"rendered":"https:\/\/radiobiz.com.ar\/?p=4345"},"modified":"2023-02-17T00:11:37","modified_gmt":"2023-02-17T00:11:37","slug":"7-signos-reveladores-de-devops-falsos","status":"publish","type":"post","link":"https:\/\/radiobiz.com.ar\/en\/7-signos-reveladores-de-devops-falsos\/","title":{"rendered":"7 signos reveladores de DevOps falsos"},"content":{"rendered":"

\u00bfSus equipos de desarrollo realmente adoptan DevOps o simplemente siguen la corriente? Aprenda a detectar las se\u00f1ales de advertencia de ‘DevOps Kabuki’.<\/h2>\n\n\n\n\n\n\n\n

No hay duda de que DevOps ha ayudado a muchas organizaciones de TI a lograr su objetivo de entregar aplicaciones y servicios m\u00e1s r\u00e1pido y mejor que los procesos tradicionales de desarrollo de software. Desafortunadamente, mientras que algunos l\u00edderes de TI hacen un buen trabajo pregonando los beneficios de DevOps, sus equipos van en la direcci\u00f3n equivocada, adoptando herramientas y pr\u00e1cticas a medias o completamente equivocadas.<\/p>\n\n\n\n

Es responsabilidad del CIO asegurarse de que los equipos de desarrollo no se desv\u00eden intencionalmente -o sin intenci\u00f3n- del camino de DevOps. Estas son las siete se\u00f1ales de advertencia que le alertar\u00e1n sobre la posible presencia de DevOps falsos en su organizaci\u00f3n.<\/p>\n\n\n\n

    \n
  1. Colocar DevOps en un silo
    La primera se\u00f1al de una implementaci\u00f3n falsa de DevOps se puede detectar f\u00e1cilmente, simplemente viendo un organigrama. \u00abSi encuentra DevOps en su propio silo, separado de Ingenier\u00eda y Operaciones, es una se\u00f1al inicial de que su responsabilidad de DevOps no est\u00e1 all\u00ed\u201d, afirma Fernando Cuadra, consultor principal de la firma de asesor\u00eda e investigaci\u00f3n tecnol\u00f3gica, ISG. \u00abAl crear un equipo de DevOps separado, el CIO esencialmente ha agregado otra capa de complejidad, otro silo y otro paso que administrar\u201d.<\/li>\n<\/ol>\n\n\n\n

    El organigrama debe reflejar un dise\u00f1o que permita a los equipos resolver problemas de manera integral en todas las \u00e1reas relevantes. \u00abOpte por crear equipos multifuncionales de principio a fin, desde Dise\u00f1o hasta Operaciones\u201d, aconseja Cuadra. \u00abDevOps no se trata de pipelines y CI\/CD; se trata de ser due\u00f1o de su entrega de valor con una fricci\u00f3n m\u00ednima en toda la empresa\u201d.<\/p>\n\n\n\n

    DevOps es solo una herramienta en lo que deber\u00eda ser una conversaci\u00f3n mucho m\u00e1s amplia sobre el lado humano de la tecnolog\u00eda, observa Cuadra. \u00abRequiere una comprensi\u00f3n profunda de los componentes b\u00e1sicos de los equipos de alto rendimiento, y c\u00f3mo los CIO pueden refrescar su percepci\u00f3n de c\u00f3mo se ven los equipos muy funcionales\u201d.<\/p>\n\n\n\n

      \n
    1. Centrarse en las herramientas por encima de las personas
      Una organizaci\u00f3n que se enfoca en una cultura DevOps centrada en herramientas y tecnolog\u00eda, en lugar de personas y procesos, est\u00e1 180 grados fuera de sincron\u00eda. \u00abEs crucial evaluar las pr\u00e1cticas y necesidades de negocio actuales\u201d, afirma Mohan Kumar, arquitecto senior de TEKsystems, una empresa de administraci\u00f3n de servicios de TI.<\/li>\n<\/ol>\n\n\n\n

      Kumar recomienda priorizar los equipos. \u00abInculque la cultura DevOps en la comunicaci\u00f3n, la colaboraci\u00f3n, la recopilaci\u00f3n de comentarios y el an\u00e1lisis\u201d, sugiere Kumar. \u00abUn ambiente amigable con los experimentos, que permite a los desarrolladores fallar r\u00e1pido, recuperarse r\u00e1pido y aprender m\u00e1s r\u00e1pido, crea una cultura libre de culpas dentro de la organizaci\u00f3n\u201d. Kumar tambi\u00e9n sugiere fomentar un flujo de ideas creativas aprovechando la inteligencia colectiva de los equipos.<\/p>\n\n\n\n

      La adopci\u00f3n de DevOps es un proceso iterativo, por lo que el CIO debe comenzar evaluando el estado actual del equipo de desarrollo y luego construir gradualmente una estrategia de mejora continua que involucre personas, procesos y herramientas que puedan evolucionar junto con las necesidades y desarrollos futuros. \u00abEn \u00faltima instancia, la creatividad es un m\u00fasculo que debe ejercitarse continuamente para crecer\u201d, observa Kumar.<\/p>\n\n\n\n

        \n
      1. Muy poca automatizaci\u00f3n
        Las DevOps falsas pueden ocurrir cuando los l\u00edderes de los equipos carecen de una mentalidad de automatizaci\u00f3n, particularmente la capacidad de invertir el tiempo y los recursos necesarios para construir una arquitectura s\u00f3lida con entrega de c\u00f3digo automatizada.<\/li>\n<\/ol>\n\n\n\n

        Antes de seguir adelante con una iniciativa de automatizaci\u00f3n, considere cuidadosamente las necesidades de desarrollo, los contratos existentes y los equipos de proyecto actuales. \u00abVea si las habilidades de la organizaci\u00f3n est\u00e1n al nivel en el que puede automatizar la infraestructura\u201d, afirma Ian Fogarty, director general de tecnolog\u00eda y operaciones de la consultora Accenture Federal Services.<\/p>\n\n\n\n

        \"\"<\/a><\/figure>\n\n\n\n

        Sin embargo, la automatizaci\u00f3n puede ser un arma de doble filo. Kumar observa que es muy f\u00e1cil cambiar involuntariamente de procesos manuales defectuosos a procesos automatizados defectuosos. Aconseja resistirse la tentaci\u00f3n de automatizar tanto como sea posible. En su lugar, automatice tanto como sea razonable. El objetivo final, se\u00f1ala Kumar, deber\u00eda ser convertir las versiones de software en un proceso de implementaci\u00f3n automatizado, confiable y repetible.<\/p>\n\n\n\n

          \n
        1. Automatizaci\u00f3n al azar
          Aunque la automatizaci\u00f3n es muy beneficiosa, muchas organizaciones se lanzan a la automatizaci\u00f3n de DevOps sin suficiente an\u00e1lisis y planificaci\u00f3n. \u00abHemos visto organizaciones que dan prioridad a la automatizaci\u00f3n sin tener en cuenta otros aspectos, como la gobernanza, las personas, los procesos y la tecnolog\u00eda\u201d, afirma Aaron Oh, director general de DevSecOps en Deloitte Risk & Financial Advisory. Estas organizaciones generalmente terminan perdiendo una cantidad significativa de tiempo revisando y arreglando el trabajo de automatizaci\u00f3n.<\/li>\n<\/ol>\n\n\n\n

          Antes de pasar directamente a la automatizaci\u00f3n, Oh sugiere establecer una gobernanza s\u00f3lida y estandarizar los requisitos y procesos. \u00abLa colaboraci\u00f3n entre las unidades de negocio es una parte esencial de DevOps\u201d, se\u00f1ala Oh. Aborde cualquier barrera organizativa que pueda existir. \u00abLa orientaci\u00f3n del liderazgo va a ser importante para establecer el tono\u201d, afirma Oh. \u00abAdem\u00e1s, aproveche las herramientas de orquestaci\u00f3n inteligente para ayudar a eliminar a\u00fan m\u00e1s los silos y lograr eficiencia en la comunicaci\u00f3n\u201d.<\/p>\n\n\n\n

            \n
          1. Tener expectativas poco realistas
            Los l\u00edderes tecnol\u00f3gicos senior deben centrarse en un compromiso que se extienda m\u00e1s all\u00e1 de la simple introducci\u00f3n de nuevas herramientas y pr\u00e1cticas tecnol\u00f3gicas. \u00abNecesitan priorizar una cultura cambiante y la mentalidad de los empleados\u201d, afirma Tim Potter, director de Deloitte Consulting. \u00abTambi\u00e9n deben establecer plazos realistas para que la transformaci\u00f3n arraigue en la organizaci\u00f3n\u201d.<\/li>\n<\/ol>\n\n\n\n

            Una organizaci\u00f3n que simplemente implementa m\u00e1s herramientas automatizadas y cambia el nombre de los equipos de Aplicaciones existentes a \u00abequipos DevOps\u201d, comprometidos con los problemas de producci\u00f3n de principio a fin, probablemente se sentir\u00e1 decepcionada con los resultados, explica Potter.<\/p>\n\n\n\n

            Los l\u00edderes tecnol\u00f3gicos tambi\u00e9n deber\u00edan estar dispuestos a aceptar el hecho de que, despu\u00e9s de comprometerse con DevOps, la producci\u00f3n puede disminuir inicialmente antes de mejorar. \u00abDeben estar preparados para brindar ‘cobertura a\u00e9rea’ a sus equipos de Aplicaciones, permiti\u00e9ndoles probar y aprender y sentirse c\u00f3modos operando en un nuevo modelo\u201d, aconseja Potter. \u00abEstablecer expectativas inapropiadas y no proporcionar suficiente tiempo para la transformaci\u00f3n puede llevar a las organizaciones a adoptar DevOps solo en nombre\u201d.<\/p>\n\n\n\n

              \n
            1. Equipos estancados en el pasado
              Los viejos h\u00e1bitos tardan en morir. Durante d\u00e9cadas, el desarrollo de software sigui\u00f3 la metodolog\u00eda tradicional en cascada, un proceso que exig\u00eda recopilar requerimientos con anticipaci\u00f3n, crear funciones y, finalmente, enviar los resultados al control de calidad y otros equipos para su lanzamiento, afirma Ashish Kakran, director de la firma de capital de riesgo de TI Thomvest Ventures. \u00abSol\u00eda pasar meses antes de que los clientes vieran las funciones nuevas\u201d, se\u00f1ala.<\/li>\n<\/ol>\n\n\n\n

              Cuando los equipos de desarrollo no logran salir por completo de la cascada, terminan con extra\u00f1as combinaciones de procesos que pueden describirse como \u00abcataratas \u00e1giles\u201d, afirma Kakran. \u00abIndica que no se ha realizado un movimiento completo para aprovechar los \u00faltimos avances en el desarrollo de software\u201d.<\/p>\n\n\n\n

              Kakran sugiere que una manera r\u00e1pida y f\u00e1cil de detectar un equipo con dificultades es examinar sus \u00abEpics\u201d y \u00abStories\u201d de DevOps.<\/p>\n\n\n\n

              \u00abEl contexto completo de un proyecto en curso a menudo se captura en estas tareas\u201d, explica. \u00abSi siente que el proyecto de un mes ya est\u00e1 dividido en tareas con poca o ninguna retroalimentaci\u00f3n continua de los clientes, es una se\u00f1al de que el equipo se est\u00e1 preparando para el fracaso, ya sea por no cumplir con los plazos del proyecto o por no brindar experiencias de usuario \u00fatiles\u201d.<\/p>\n\n\n\n

                \n
              1. Inflexibilidad
                DevOps no es una metodolog\u00eda \u00fanica para todos. Para obtener la m\u00e1xima eficacia, los flujos y las herramientas de DevOps deben ajustarse a las necesidades espec\u00edficas de la organizaci\u00f3n, que pueden variar ampliamente seg\u00fan su tama\u00f1o, tipos de aplicaciones y experiencia en desarrollo.<\/li>\n<\/ol>\n\n\n\n

                DevOps nunca debe ser est\u00e1tico. Los procesos y las herramientas deben adaptarse a medida que la organizaci\u00f3n crece y sigue su b\u00fasqueda de mejora continua. Estos objetivos requieren herramientas flexibles, as\u00ed como la capacidad de analizar los KPI para revelar oportunidades de mejora, afirma Wing To, vicepresidente de Ingenier\u00eda de Digitial.ai, que comercializa una plataforma DevOps basada en inteligencia artificial. Los l\u00edderes de TI tambi\u00e9n deben tener en cuenta el cambio cultural necesario para unir a los equipos de Desarrollo y Operaciones. En lugar de crear un departamento de DevOps separado, que solo crea m\u00e1s silos y cuellos de botella en los procesos, la metodolog\u00eda debe integrarse en cada \u00e1rea comercial.<\/p>\n\n\n\n

                DevOps se trata b\u00e1sicamente de personas y procesos. Los l\u00edderes de TI deben comprender que estos recursos deben ser espec\u00edficos de acuerdo al contexto. \u00abLa forma \u00f3ptima de usar las herramientas y los procesos cambia con el tiempo, es din\u00e1mica, no est\u00e1tica, y las herramientas y los procesos necesitan un entrenamiento cuidadoso para usarlos correctamente\u201d, se\u00f1ala To.<\/p>\n\n\n\n

                Llegar a un equilibrio
                Hay un equilibrio entre empujar y jalar que se debe lograr cuando se lanza una transformaci\u00f3n DevOps exitosa. \u00abSi tiene suerte, los equipos entusiastas se ofrecer\u00e1n como voluntarios para estar entre los primeros en realizar la adopci\u00f3n\u201d, afirma Potter. \u00abEs importante apoyar a estos equipos –recompensarlos por su coraje y celebrar su \u00e9xito, mientras que al mismo tiempo se mantiene el enfoque en la hoja de ruta de transformaci\u00f3n de toda la organizaci\u00f3n\u201d.<\/p>\n\n\n\n

                Recuerde, sin embargo, que los beneficios ser\u00e1n limitados y tardar\u00e1n si toda la organizaci\u00f3n no acepta la transformaci\u00f3n. \u00abInevitablemente, habr\u00e1 interdependencias que reducir\u00e1n la velocidad de un equipo de Aplicaciones si la organizaci\u00f3n en general no ha hecho el cambio\u201d, afirma Potter.<\/p>\n\n\n\n

                Basado en el art\u00edculo de John Edwards (CIO)<\/p>","protected":false},"excerpt":{"rendered":"

                \u00bfSus equipos de desarrollo realmente adoptan DevOps o simplemente siguen la corriente? Aprenda a detectar las se\u00f1ales de advertencia de ‘DevOps Kabuki’. No hay duda de que DevOps ha ayudado a muchas organizaciones de TI a lograr su objetivo de entregar aplicaciones y servicios m\u00e1s r\u00e1pido y mejor que los procesos tradicionales de desarrollo de …<\/p>","protected":false},"author":2,"featured_media":4347,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20],"tags":[77],"class_list":["post-4345","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tecnologia","tag-devops"],"jetpack_featured_media_url":"https:\/\/radiobiz.com.ar\/wp-content\/uploads\/2023\/02\/202230216-DevOps.jpg","_links":{"self":[{"href":"https:\/\/radiobiz.com.ar\/en\/wp-json\/wp\/v2\/posts\/4345","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/radiobiz.com.ar\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/radiobiz.com.ar\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/radiobiz.com.ar\/en\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/radiobiz.com.ar\/en\/wp-json\/wp\/v2\/comments?post=4345"}],"version-history":[{"count":2,"href":"https:\/\/radiobiz.com.ar\/en\/wp-json\/wp\/v2\/posts\/4345\/revisions"}],"predecessor-version":[{"id":4351,"href":"https:\/\/radiobiz.com.ar\/en\/wp-json\/wp\/v2\/posts\/4345\/revisions\/4351"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/radiobiz.com.ar\/en\/wp-json\/wp\/v2\/media\/4347"}],"wp:attachment":[{"href":"https:\/\/radiobiz.com.ar\/en\/wp-json\/wp\/v2\/media?parent=4345"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/radiobiz.com.ar\/en\/wp-json\/wp\/v2\/categories?post=4345"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/radiobiz.com.ar\/en\/wp-json\/wp\/v2\/tags?post=4345"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}