¿Qué frena a su equipo de DevOps? (además de su nombre)

Ignorar el rol del desarrollo ágil en el éxito de DevOps se traduce en que la mayoría de las empresas se esforzarán por alcanzar los niveles más altos de madurez.

La teoría de DevOps es distinguidamente simple. Elimine la delineación tradicional entre los grupos de desarrollo y operaciones para acercarse a los clientes e implementar funciones más relevantes con más frecuencia. En otras palabras, para innovar.

La realidad no es tan así, por lo que cualquier organización que diga que tiene un equipo de DevOps ya ha cometido un error fatal. Crear un equipo no es lo mismo que transformar todo el modelo operativo para poner la opinión de los clientes en el centro de la estrategia de su empresa. Además, muchas personas creen que es solo una cuestión de herramientas y pasan por alto el hecho de que si no tienen el soporte cultural correcto para DevOps, las herramientas nunca ofrecerán el máximo beneficio en cuanto a la eficiencia. Ante todo, esta cultura es una que necesita de la mayor colaboración. Para respaldar esto, debe haber un sentido de responsabilidad compartida entre los equipos de desarrollo y operaciones (la famosa mentalidad: "Usted lo desarrolla, usted lo ejecuta" inmortalizada por el CTO de Amazon, Werner Vogels, en 2006). Desde el punto de vista de la organización, no deben estar aislados y se les debe permitir que funcionen de manera automática.

El motor de procesos que puede apoyar este desarrollo cultural esencial es otra metodología muy experimentada, pero poco comprendida: el desarrollo ágil.

En pocas palabras, no puede hacer la transición a un modelo y a una cultura de DevOps real sin adoptar prácticas ágiles. Puede desplegar tantas herramientas de DevOps como guste, pero si no cuenta con prácticas ágiles, tan solo perderá el tiempo con la manera en que diseña las diferentes pilas de sus aplicaciones. Diseñará cada capa con más automatización antes del siguiente control, pero si no elimina esos controles por completo, a fin de cuentas, sus clientes, y sus programadores, no notarán grandes diferencias.

Cómo la agilidad impulsa la innovación

El enfoque tradicional de la innovación es un proceso largo que implica mucha inversión. Los grupos de productos presentan las ideas en las que quieren trabajar el próximo año y, luego, reciben una suma de dinero importante para dedicarse a eso. Puede haber revisiones intermedias regulares para volver a evaluar los aspectos del plan, pero es poco probable que el objetivo cambie significativamente. Así que, de inmediato, esperan millones de dólares sin saber cuál podría ser el resultado, lo que hace que el costo del fracaso sea muy alto.

Esto tiene sentido cuando se entrega el hardware —una plataforma de perforación o un portaaviones parcialmente construidos no son muy útiles—, pero no tiene sentido con el software, donde las características del producto se pueden agregar y refinar mientras la solución está en el mercado.

El desarrollo ágil refleja esto, ya que posibilita la entrega de soluciones útiles en un plazo más corto de tiempo y con menos inversión. En lugar de hacer apuestas millonarias con plazos de 18 meses, el desarrollo ágil le permite hacer apuestas de 200,000 dólares en productos viables mínimos (MVP, por sus siglas en inglés) que se pueden entregar en un período de entre tres y seis meses. De esa manera, el costo de descubrir que no hay un mercado para sus funciones es mucho más bajo, y los equipos pueden fluctuar rápido hacia donde, en realidad, está la demanda.

Todo esto se basa en organizar a las personas, los procesos y la tecnología para ofrecerles rápidamente a los clientes funciones de trabajo que tengan valor, recopilar su feedback y, luego, priorizar el desarrollo en función de ese feedback.

Y aquí es donde las organizaciones que tienen dificultades con DevOps tienden a quedarse sin dinero.

Los modelos operativos ineficaces socavan el poder de las personas

Sin adoptar un modelo operativo ágil, es difícil mantener la arquitectura, las operaciones y los grupos de ingeniería alineados, y sus conflictivas prioridades frustrarán rápido los esfuerzos para lanzar el código lo antes posible. Cuando se disponen como grupos separados, estos equipos siempre harán sus propias tareas a su ritmo, y entregarán cada capa al otro con un modelo tipo cascada solo cuando esté lista.

En su lugar, los equipos con una estructura vertical en cuanto al desarrollo ágil reúnen a los miembros de cada organización en grupos autónomos y autodirigidos, que pueden ofrecer funciones específicas mucho más rápido.

La adopción ágil inconsistente conduce a procesos mal fundamentados

Si bien vemos que una gran cantidad de organizaciones adoptan prácticas ágiles y gran parte del lenguaje, vemos que menos se mantienen fieles a sus principios. Cuando cumplen al pie de la letra las prácticas, pero falta el propósito, no aplican los procesos de forma consistente ni los respaldan con medidas o métricas adecuadas.

En realidad, el resultado es que se insertan más puntos en el flujo de valor (el número de pasos entre una idea y la entrega de una función al cliente), lo que significa que los lanzamientos suelen tardar más que antes. Cuando eso ocurre, la confianza del equipo en el desarrollo ágil se evapora, la moral se desploma y los clientes se quedan con las manos vacías.

Tecnología y herramientas inadecuadas

La tecnología y las herramientas se combinan para presentar un desafío doble, a fin de brindar una base ágil para el éxito de DevOps. Primero, la base de código para sus aplicaciones debe rediseñarse en torno a los contenedores y los microservicios para posibilitar la implementación función por función. Sin esto, sus equipos no pueden desglosar sus "historias de usuarios" (una explicación informal del objetivo de una función que se cuenta desde la perspectiva del usuario) de forma vertical, que es una función clave de DevOps.

Cuando se trata de las herramientas, por lo general, vemos herramientas heredadas de administración de configuración de cambios en el código que conducen, invariablemente, a procesos de administración de configuración de cambios obsoletos en general. Y si utiliza herramientas de administración de proyectos antiguas, sin duda, cuenta con el conjunto de herramientas incorrecto.

Los seis factores críticos de éxito para la madurez de DevOps con metodología ágil

Para que pueda superar estos desafíos y retomar su estrategia de DevOps con procesos ágiles en su esencia, recomendamos que los líderes tecnológicos se centren en la entrega de los siguientes factores críticos de éxito.

1.    Haga una cosa por vez. Identifique un producto específico para comenzar y, luego, seleccione/desarrolle un equipo para transformarlo al tiempo que trabaja con procesos ágiles.

2.    Intensifique y posibilite la metodología ágil desde el principio, y tómese el tiempo necesario para entenderla y apoyarla. Solo con la participación del equipo directivo se puede incorporar la opinión del cliente a la visión estratégica de la empresa. La clave de esto es permitirles a los equipos técnicos establecer la cadencia de los lanzamientos de las funciones mediante el seguimiento de las fechas de lanzamiento esperadas para definir el nivel de MVP que es posible en el tiempo permitido. (Esto también llevará a que los programadores se comprometan más con su trabajo y con las mejoras culturales en general).

3.    Realice un ejercicio de asignación de flujo de valor para entender cuántos pasos se necesitan actualmente para llevar una idea desde la concepción hasta el cliente y luego aproveche el modelo operativo con una estructura vertical en cuanto al desarrollo ágil para reducir la cantidad de pasos.

4.    Cierre sus ciclos de feedback incorporando la opinión del cliente en períodos regulares. El tiempo es importante, ya que si lo plazos son muy largos, los clientes no se sienten escuchados. (El ejercicio de mapeo de flujo de valor también lo ayudará a identificar dónde y cuándo se produce este ciclo de feedback o si se ha discontinuado).

5.    Evalúe y establezca una base de referencia de sus DevOps y metodologías ágiles en relación con las mejores prácticas e identifique resultados y métodos mensurables para el seguimiento del rendimiento en relación con ellas.

6.    Finalmente, intente transformarse en un modelo operativo de DevOps como un ejercicio ágil en sí mismo priorizando la mejora continua. Eso significa hacer un plan para permitir que los equipos aprendan de su rendimiento y hacer que el proceso detrás de cada nuevo lanzamiento sea mejor que el anterior.

Join the Conversation: Find Solve on Twitter and LinkedIn, or follow along via RSS.

Stay on top of what's next in technology

Learn about tech trends, innovations and how technologists are working today.