{"id":41818,"date":"2020-02-16T20:46:08","date_gmt":"2020-02-16T17:46:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/sem-arhetipov-prevrashheniya-po-princzipam-devops"},"modified":"2020-02-16T20:46:08","modified_gmt":"2020-02-16T17:46:08","slug":"sem-arhetipov-prevrashheniya-po-princzipam-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/sem-arhetipov-prevrashheniya-po-princzipam-devops","title":{"rendered":"Siete arquetipos de transformaci\u00f3n seg\u00fan los principios de DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La pregunta de \u00abc\u00f3mo implementar DevOps en nuestra empresa\u00bb lleva a\u00f1os en la mente de muchos, pero hay pocos materiales de calidad al respecto. A veces, te conviertes en v\u00edctima de publicidad de consultores poco inteligentes, que solo desean vender su tiempo, sin importar c\u00f3mo. En otras ocasiones, se oyen palabras vagas y generales sobre c\u00f3mo las naves de megacorporaciones surcan los vastos dominios del universo. Surge la pregunta: \u00bfy a nosotros, qu\u00e9? Estimado autor, \u00bfpodr\u00edas formular claramente tus ideas en una lista?<\/p>\n

Todo esto se debe a que no hay mucha pr\u00e1ctica real y comprensi\u00f3n de los resultados de las transformaciones culturales en las empresas. Los cambios culturales son procesos prolongados, cuyos resultados no se ver\u00e1n ni en una semana ni en un mes. Necesitamos a alguien con suficiente experiencia, que haya visto c\u00f3mo se crean y colapsan las empresas a lo largo de los a\u00f1os.<\/p>\n

\"Siete
\n
\nJohn Willis<\/b> es uno de los padres de DevOps. John cuenta con d\u00e9cadas de experiencia trabajando con un gran n\u00famero de empresas. Recientemente, ha comenzado a notar patrones espec\u00edficos que se presentan en el trabajo con cada una de ellas. Utilizando estos arquetipos, John gu\u00eda a las empresas en el verdadero camino de la transformaci\u00f3n DevOps. M\u00e1s sobre estos arquetipos se puede encontrar en la traducci\u00f3n de su presentaci\u00f3n en la conferencia DevOops 2018.
\n<\/a><\/noindex>
\n

\r\n \"Reproducir\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Acerca del ponente:<\/b><\/p>\n

Con m\u00e1s de 35 a\u00f1os en gesti\u00f3n de TI, particip\u00f3 en la creaci\u00f3n del precursor de OpenCloud en Canonical, estuvo involucrado en 10 startups, dos de las cuales fueron vendidas a Dell y Docker. Actualmente es Vicepresidente de DevOps y Pr\u00e1cticas Digitales en SJ Technologies.<\/p>\n

A continuaci\u00f3n, la narraci\u00f3n en voz de John.<\/b><\/p>\n

Me llamo John Willis, y es m\u00e1s f\u00e1cil encontrarme en Twitter, @botchagalupe<\/a><\/noindex>. Ese mismo seud\u00f3nimo tengo en Gmail y GitHub. Y aqu\u00ed est\u00e1 el enlace<\/a><\/noindex> donde podr\u00e1s encontrar grabaciones de mis charlas y presentaciones.<\/p>\n

Tengo muchas reuniones con CIO de diferentes grandes empresas. Frecuentemente se quejan de que no entienden qu\u00e9 es DevOps, y todos los que intentan explic\u00e1rselo hablan de algo diferente. Otra queja com\u00fan es que DevOps no funciona, aunque los directores parecen seguir las instrucciones dadas. Se trata de grandes empresas que tienen m\u00e1s de cien a\u00f1os. Despu\u00e9s de hablar con ellos, llegu\u00e9 a la conclusi\u00f3n de que para muchos problemas, las soluciones de baja tecnolog\u00eda son m\u00e1s adecuadas que las de alta tecnolog\u00eda. Pas\u00e9 semanas conversando con personas de diferentes departamentos. Lo que ves en la primera imagen de la publicaci\u00f3n es c\u00f3mo se ve\u00eda la sala despu\u00e9s de tres d\u00edas de trabajo en mi \u00faltimo proyecto.<\/p>\n

\u00bfQu\u00e9 es DevOps?<\/h2>\n

\nDe hecho, si le preguntas a 10 personas diferentes, dar\u00e1n 10 respuestas distintas. Pero aqu\u00ed est\u00e1 lo interesante: todas esas diez respuestas ser\u00e1n correctas. No hay una respuesta incorrecta. He estado involucrado en DevOps durante aproximadamente 10 a\u00f1os, fui el primer estadounidense en el primer DevOpsDay. No dir\u00e9 que soy m\u00e1s inteligente que todos los que trabajan en DevOps, pero dudo que haya alguien que haya invertido tanto esfuerzo como yo. Creo que DevOps surge cuando el capital humano se une a la tecnolog\u00eda. A menudo olvidamos la dimensi\u00f3n humana, aunque hablamos mucho de todo tipo de culturas. <\/p>\n

\"Siete
\n
\nAhora tenemos muchos datos, cinco a\u00f1os de investigaciones acad\u00e9micas, la validaci\u00f3n de teor\u00edas est\u00e1 establecida a escala industrial. Estas investigaciones nos dicen lo siguiente: si en la cultura organizacional se combinan ciertos patrones de comportamiento, se puede obtener una aceleraci\u00f3n de hasta 2000 veces. Esta aceleraci\u00f3n corresponde a la misma mejora en la resiliencia. Esta es una medici\u00f3n cuantitativa de la ventaja que DevOps puede ofrecer a cualquier empresa. Hace un par de a\u00f1os, habl\u00e9 sobre DevOps con el CEO de una empresa de la lista Fortune 5000. Cuando me estaba preparando para la presentaci\u00f3n, estaba muy nervioso porque necesitaba resumir mis a\u00f1os de experiencia en 5 minutos. <\/p>\n

Al final, di la siguiente definici\u00f3n de DevOps<\/b>: es un conjunto de pr\u00e1cticas y patrones que permiten transformar el capital humano en un capital organizacional de alto rendimiento. Un ejemplo es c\u00f3mo Toyota ha operado durante los \u00faltimos 50 o 60 a\u00f1os.<\/p>\n

\"Siete
\n
\n(A partir de aqu\u00ed, estos esquemas no se presentan como material de referencia, sino como ilustraci\u00f3n. Su contenido variar\u00e1 para cada nueva empresa. Sin embargo, se puede observar la imagen por separado y aumentarla. en este enlace.)<\/a><\/noindex><\/i><\/p>\n

Una de las pr\u00e1cticas m\u00e1s exitosas es mapeo de la cadena de valor<\/b>. Se han escrito varios buenos libros sobre esto, el autor de los m\u00e1s exitosos es Karen Martin. Sin embargo, en el \u00faltimo a\u00f1o he llegado a la conclusi\u00f3n de que incluso este enfoque es demasiado tecnol\u00f3gico. Sin duda, tiene muchas ventajas, de las cuales he hecho uso. Pero cuando el director general te pregunta por qu\u00e9 su empresa no puede cambiar a nuevos rieles, todav\u00eda es muy prematuro hablar de mapeo de la cadena de valor. Hay muchas preguntas mucho m\u00e1s fundamentales que necesitan respuestas previas. <\/p>\n

Me parece que el error de muchos de mis colegas es que simplemente le dan a la empresa una gu\u00eda de cinco puntos y luego regresan despu\u00e9s de seis meses para ver qu\u00e9 ha pasado. Incluso un buen esquema como el mapeo de la cadena de valor tiene, digamos, zonas muertas (blind spots). Despu\u00e9s de cientos de entrevistas con directores de diversas empresas, he desarrollado un cierto patr\u00f3n que permite descomponer el problema en partes componentes, y ahora discutiremos cada una de estas partes. Antes de aplicar cualquier soluci\u00f3n tecnol\u00f3gica, utilizo este patr\u00f3n, y como resultado, todas mis paredes terminan llenas de esquemas. Recientemente trabaj\u00e9 con un fondo mutuo, y al final ten\u00eda entre 100 y 150 de estos esquemas.<\/p>\n

Una mala cultura se come buenos enfoques en el desayuno.<\/h2>\n

\nLa idea principal es la siguiente: ninguna de las metodolog\u00edas Lean, Agile, SAFE y DevOps ayudar\u00e1 si la cultura de la organizaci\u00f3n es mala. Es como bucear en profundidad sin tanque de ox\u00edgeno o operar sin radiograf\u00eda. En otras palabras, parafraseando a Drucker y Deming: una mala cultura organizativa absorbe cualquier buen sistema y no se atraganta. <\/p>\n

Para resolver este problema principal, es necesario llevar a cabo los siguientes pasos:<\/p>\n

    \n
  1. Hacer Todo el Trabajo Visible:<\/b> es necesario hacer todo el trabajo visible. No en el sentido de que deba mostrarse en alguna pantalla, sino en el sentido de que debe ser observable.<\/li>\n
  2. Consolidar los Sistemas de Gesti\u00f3n del Trabajo:<\/b> es necesario consolidar los sistemas de gesti\u00f3n. En el problema del conocimiento \"tribal\" y el conocimiento institucional, en 9 de cada 10 casos el cuello de botella son las personas. En el libro \u00abPhoenix Project\u00bb<\/a><\/noindex> el problema estaba en una sola persona, Brent, cuya causa hizo que el proyecto se retrasara tres a\u00f1os. Y encuentro a esos \"Brents\" por todas partes. Para resolver estos cuellos de botella utilizo los siguientes dos puntos de nuestra lista. <\/li>\n
  3. Metodolog\u00eda de Teor\u00eda de Restricciones:<\/b> teor\u00eda de restricciones.<\/li>\n
  4. Trucos de colaboraci\u00f3n:<\/b> hackeos de colaboraci\u00f3n. <\/li>\n
  5. Toyota Kata (Coaching Kata<\/a><\/noindex>):<\/b> no hablar\u00e9 mucho sobre Toyota Kata. Si te interesa, en mi GitHub hay presentaciones<\/a><\/noindex> casi sobre cada uno de estos temas. <\/li>\n
  6. Organizaci\u00f3n Orientada al Mercado:<\/b> organizaci\u00f3n orientada al mercado.<\/li>\n
  7. Auditores Shift-left:<\/b> auditor\u00eda en etapas tempranas del ciclo.<\/li>\n<\/ol>\n

    \"Siete
    \n
    \nEmpiezo a trabajar con la organizaci\u00f3n de una manera muy simple: voy a la empresa y hablo con los empleados. Como se puede ver, no hay alta tecnolog\u00eda. Todo lo que se necesita es tener algo para escribir. Re\u00fano a varios equipos en una habitaci\u00f3n y analizo lo que me dicen, desde la perspectiva de mis 7 arquetipos. Luego les doy un marcador y les pido que escriban en la pizarra todo lo que hasta ahora han dicho en voz alta. Normalmente, en este tipo de reuniones hay una persona que toma notas, y en el mejor de los casos consigue registrar el 10% de la discusi\u00f3n. Con mi m\u00e9todo, este porcentaje se logra aumentar a alrededor del 40%. <\/p>\n

    \"Siete
    \n
    \n(Esta ilustraci\u00f3n se puede     ver en el enlace<\/a><\/noindex>)<\/i><\/p>\n

    Mi enfoque se basa en el trabajo de William Schneider (William Schneider, The Reengineering Alternative<\/a><\/noindex>). En la base del enfoque est\u00e1 la idea de que cualquier organizaci\u00f3n se puede descomponer en cuatro cuadrantes. Este esquema generalmente es el resultado del trabajo con las cientos de otras esquemas que surgen al analizar una organizaci\u00f3n. Supongamos que tenemos una organizaci\u00f3n con un alto nivel de control, pero con una baja competencia. Esta es una opci\u00f3n extremadamente indeseable: cuando todos siguen \u00f3rdenes, pero nadie sabe qu\u00e9 hacer. <\/p>\n

    Una opci\u00f3n un poco mejor con un alto nivel de control y competencia. Si una empresa es rentable, tal vez no necesite DevOps. Es m\u00e1s interesante trabajar con una empresa que tiene un alto nivel de control, baja competencia y colaboraci\u00f3n, pero al mismo tiempo una alta cultura (cultivation). Esto significa que hay muchas personas en la empresa que disfrutan trabajar all\u00ed, y la rotaci\u00f3n de personal es baja. <\/p>\n

    \"Siete
    \n
    \n(Esta ilustraci\u00f3n se puede     ver en el enlace<\/a><\/noindex>)<\/i><\/p>\n

    Me parece que los m\u00e9todos con recomendaciones estrictamente definidas, en \u00faltima instancia, obstaculizan la b\u00fasqueda de la verdad. En particular, en el mapeo del flujo de valor hay muchas reglas sobre c\u00f3mo estructurar la informaci\u00f3n. En las etapas iniciales de trabajo, de las que ahora hablo, estas reglas no son necesarias para nadie. Si una persona con un marcador en la mano describe en la pizarra la situaci\u00f3n real en la empresa, esa es la mejor manera de entender la situaci\u00f3n. Esa informaci\u00f3n no llega a los directores. En ese momento, es tonto interrumpir a la persona y decirle que ha dibujado mal alguna flecha. En esta etapa, es mejor seguir reglas simples; por ejemplo, se puede crear una abstracci\u00f3n multinivel simplemente utilizando marcadores de diferentes colores. <\/p>\n

    Reitero, sin alta tecnolog\u00eda. Con un marcador negro se representa la realidad objetiva, c\u00f3mo funciona todo. Con un marcador rojo, las personas indican lo que no les gusta en la situaci\u00f3n actual. Es importante que lo escriban ellos, no yo. Cuando despu\u00e9s de la reuni\u00f3n voy a ver al director de tecnolog\u00eda de la informaci\u00f3n, no propongo una lista de 10 cosas que necesitan ser corregidas. Busco encontrar conexiones entre lo que dicen las personas de la empresa y los patrones probados existentes. Finalmente, con un marcador azul se proponen posibles soluciones al problema. <\/p>\n

    \"Siete
    \n
    \n(Esta ilustraci\u00f3n se puede     ver en el enlace<\/a><\/noindex>)<\/i><\/p>\n

    Un ejemplo de este enfoque se muestra arriba. A principios de este a\u00f1o trabaj\u00e9 con un banco. Los empleados del departamento de seguridad estaban convencidos de que no pod\u00edan asistir a las revisiones de requisitos y dise\u00f1o (design and requirement reviews). <\/p>\n

    \"Siete
    \n
    \n(Esta ilustraci\u00f3n se puede     ver en el enlace<\/a><\/noindex>)<\/i><\/p>\n

    Luego hablamos con personas de otros departamentos y descubrimos que hace aproximadamente 8 a\u00f1os los desarrolladores de software expulsaron a los trabajadores de seguridad porque estaban ralentizando el trabajo. Y luego eso se convirti\u00f3 en una prohibici\u00f3n que se percib\u00eda como un hecho. Sin embargo, en realidad no hab\u00eda tal prohibici\u00f3n. <\/p>\n

    Nuestra reuni\u00f3n tuvo un desarrollo bastante confuso: durante alrededor de tres horas, cinco equipos diferentes no lograban explicarme qu\u00e9 estaba ocurriendo entre el c\u00f3digo y la compilaci\u00f3n. Y esto, aparentemente, es lo m\u00e1s sencillo. La mayor\u00eda de los consultores de DevOps suponen de antemano que esto ya es conocido por todos. <\/p>\n

    Luego, la persona encargada de la gobernanza de TI, que hab\u00eda permanecido en silencio durante cuatro horas, de repente cobr\u00f3 vida cuando llegamos a su tema y nos ocup\u00f3 durante mucho tiempo. Al final, le pregunt\u00e9 qu\u00e9 pensaba de la reuni\u00f3n, y nunca olvidar\u00e9 su respuesta. Dijo: 'Antes pensaba que en nuestro banco hab\u00eda solo dos formas de entrega de software, y ahora s\u00e9 que hay cinco, y ni siquiera sospechaba de tres de ellas'. <\/p>\n

    \"Siete
    \n
    \n(Esta ilustraci\u00f3n se puede     ver en el enlace<\/a><\/noindex>)<\/i><\/p>\n

    La \u00faltima reuni\u00f3n en este banco fue con el equipo que desarrolla software para inversiones. Fue en esta ocasi\u00f3n que descubrimos que es mejor escribir esquemas con un marcador en un papel que en una pizarra, e incluso mejor que en una pizarra inteligente. <\/p>\n

    \"Siete
    \n
    \nLas fotos que ven son c\u00f3mo luci\u00f3 la sala de conferencias del hotel en el cuarto d\u00eda de nuestra reuni\u00f3n. Y utilizamos estos esquemas para buscar patrones, es decir, arquetipos. <\/p>\n

    As\u00ed que hago preguntas a los empleados, y ellos registran las respuestas con marcadores de tres colores (negro, rojo y azul). Analizo sus respuestas en busca de arquetipos. Ahora, discutamos todos los arquetipos en orden. <\/p>\n

    1. Make All Work Visible: Hacer todo el trabajo visible<\/h3>\n

    \nEn la mayor\u00eda de las empresas con las que trabajo, hay un porcentaje muy alto de trabajo desconocido. Por ejemplo, es cuando un empleado se acerca a otro y simplemente le pide que haga algo. En grandes organizaciones, puede haber un 60% de trabajo no planificado. Y hasta un 40% del trabajo no est\u00e1 documentado de ninguna manera. Si fuera Boeing, realmente nunca m\u00e1s volver\u00eda a subir a uno de sus aviones. Si solo se documenta la mitad del trabajo, no se sabe si ese trabajo se est\u00e1 realizando correctamente o no. Todos los dem\u00e1s m\u00e9todos resultan in\u00fatiles: no tiene sentido intentar automatizar algo porque el 50% conocido puede ser, de hecho, la parte m\u00e1s organizada y clara del trabajo, cuya automatizaci\u00f3n no dar\u00e1 grandes resultados, y todo lo que es terrible est\u00e1 en la mitad invisible. Sin documentaci\u00f3n, es imposible encontrar todo tipo de trucos y trabajo oculto, no se pueden identificar los cuellos de botella, esos mismos 'Brentos' de los que ya he hablado. Hay un excelente libro de Dominica DeGrandis \u00abMaking Work Visible\u00bb<\/a><\/noindex>. Ella identifica cinco diferentes 'fugas de tiempo'<\/b> (thieves of time):<\/p>\n