¿Hacia dónde va DevOps? ¿Está ‘muerto’ como algunos están sugerencia, para ser sustituida por otras disciplinas como la ingeniería de plataformas? Propondría que, si bien nunca fue tan easy como eso, ahora es un buen momento para reflexionar sobre enfoques como los discutidos en los círculos de DevOps. Por lo tanto, consideremos qué hay en su corazón y veamos cómo se pueden aplicar para ofrecer innovación basada en software program a escala.
Un poco de historia. Mi primer trabajo, hace tres décadas, fue como programador; Más tarde ejecuté herramientas de software program e infraestructura para grupos de desarrollo de aplicaciones; Continué asesorando a algunas organizaciones bastante grandes sobre cómo desarrollar software program y cómo administrar centros de datos, servidores, almacenamiento, redes, seguridad y todo eso. Durante ese tiempo, he visto una gran cantidad de software program entregado con éxito, y una cantidad no insignificante se descarriló, fue reemplazada o no cumplió con los requisitos.
Curiosamente, aunque he visto muchas aspiraciones en términos de mejores formas de hacer las cosas, no puedo evitar sentir que todavía estamos trabajando en algunos de los aspectos básicos. DevOps nació a mediados de la década de 1990, como una forma de romper con los modelos más antiguos y lentos. Sin embargo, diez años antes de eso, ya estaba trabajando al frente del ‘growth ágil’, como consultor de Metodología de Desarrollo de Sistemas Dinámicos (DSDM).
A mediados de los años noventa, se estaban reconsiderando enfoques más antiguos y pesados para la producción de software program, con plazos de entrega de dos años y sin garantías de éxito, a la luz del rápido crecimiento de Web. Y antes de eso, los métodos en espiral de Barry Boehm, el desarrollo rápido de aplicaciones y similares ofrecían alternativas a las metodologías en cascada, en las que la entrega se empantanaba en requisitos sobreespecificados (la llamada parálisis de análisis) y regímenes de prueba agotadores.
No es de extrañar que los gurús del desarrollo de software program como Barry B, Kent Beck y Martin Fowler buscaran volver a la fuente (sic) y adoptar el enfoque JFDI que continúa en la actualidad. La thought period, y sigue siendo, easy: tómese demasiado tiempo para entregar algo y el mundo habrá seguido adelante. Esto sigue siendo tan aspiracionalmente cierto como siempre: el objetivo period, es y sigue siendo crear software program más rápido, con todos los beneficios de una retroalimentación mejorada, un valor más inmediato, and so on.
Ciertamente vemos ejemplos de éxito, entonces, ¿por qué estos se parecen más a la entrega de un disco exitoso o una novela asesina, que a los negocios como de costumbre? Las organizaciones en basic miran con esperanza hacia los equipos de dos pizzas, los principios SAFe Agile y las métricas DORA, pero aún luchan por hacer que los enfoques ágiles se escalen en sus equipos y negocios. Las herramientas deberían poder ayudar, pero (como comento aquí) pueden igualmente convertirse en parte del problema, en lugar de la solución.
Entonces, ¿cuál es la respuesta? En mi época como consultor de DSDM, mi trabajo consistía en ayudar a los chicos geniales a hacer las cosas rápido, pero bien. Con el tiempo, aprendí un issue que se destacó por encima de todos los demás, que podría hacer o deshacer una práctica de desarrollo ágil: la complejidad. La última verdad con el software program es que es infinitamente maleable. Dentro de los límites de lo que el software program puede habilitar, realmente puedes escribir lo que quieras, potencialmente muy rápido.
Podemos agradecer a Alan Turing por reconocer esto cuando ideó su máquina homónima y basada en cinta de papel, en la que basó su teoría de la computación. En pocas palabras, la máquina de Turing puede (en principio) ejecutar cualquier programa que sea matemáticamente posible; no solo esto, sino que incluye el programa que representa cómo funciona cualquier otro tipo de computadora.
Entonces, podría escribir un programa que represente una computadora Cray, digamos, girarlo en una Apple Mac y, en él, ejecutar otro que emule un mainframe de IBM. No está claro por qué querrías hacerlo, pero para un ejemplo divertido, puedes ir a la madriguera del conejo y descubrir las diferentes plataformas a las que se ha portado el juego de disparos en primera persona Doom, que incluye sí mismo.
Buenos tiempos. Pero la inmediatez de la posibilidad infinita debe manejarse con cuidado. En mis días de DSDM aprendí el poder del principio de Pareto, o en términos sencillos, “separemos las cosas que absolutamente necesitamos, de las que es bueno tener, pueden venir más tarde”. Este principio del ochenta y veinte es tan cierto y necesario como siempre, como lo es el primer peligro de poder hacer todo ahora, tratar de hacerlo todo, todo a la vez.
El segundo peligro es no registrar las cosas sobre la marcha. Imagina que eres Teseo, descendiendo para encontrar al minotauro en el laberinto de cavernas debajo. Sin detenerse a respirar, recorre muchos pasillos antes de darse cuenta de que todos tienen un aspecto related y ya no sabe cuáles priorizar para la próxima compilación de su aplicación de creación de mapas nativa de la nube.
Está bien, estoy estirando la analogía, pero entiendes el punto. En un panel en línea reciente, comparé a los desarrolladores con el aprendiz de brujo: una cosa es poder hacer una escoba a voluntad, pero ¿cómo vas a manejarlos a todos? Es una analogía tan buena como cualquier otra, para reflejar lo easy que es crear un artefacto basado en software program y para ilustrar los problemas que se crean si a cada uno no se le asigna al menos una etiqueta.
Pero aquí está la ironía: la complejidad que resulta de hacer las cosas rápido sin controles, ralentiza las cosas hasta el punto de que mata la misma innovación que pretendía crear. En conversaciones privadas, aprendí que incluso los niños del cartel de las megaempresas nativas de la nube ahora luchan con la complejidad de lo que han creado. -La gestión de configuración pasada de moda estuvo desactivada durante tanto tiempo.
Empecé a escribir sobre la ‘brecha de gobernanza’ entre el mundo de hacer las cosas y el resto. Esto funciona de dos maneras, primero que las cosas ya no se hacen; y segundo, que incluso cuando lo son, no necesariamente se alinean con lo que la empresa o sus clientes realmente necesitan; llame a esto el tercer peligro de hacer las cosas con prisa.
Cuando el término Worth Stream Administration comenzó a ponerse de moda hace tres años, no lo adopté porque quería subirme a otro carro. Más bien, había estado luchando con la forma de explicar la necesidad de abordar esta brecha de gobernanza, al menos en parte (DevSecOps y el movimiento de cambio a la izquierda también están en la lista de invitados a esta fiesta). VSM llegó en el momento adecuado, no solo para mí, sino también para las organizaciones que ya se dieron cuenta de que no podían escalar sus esfuerzos de software program.
VSM no nació por capricho. Surgió de la propia comunidad DevOps, como respuesta a los retos que su ausencia provocaba. Esto es realmente interesante y ofrece un gancho para cualquier tomador de decisiones senior que se sienta fuera de lugar cuando se trata de abordar la falta de productividad de sus equipos de software program más avanzados.
Hágase a un lado, síndrome del impostor empresarial: es hora de aplicar algunas de esas viejas sabidurías, como la gestión de configuración, la gestión de requisitos y la gestión de riesgos. No es que los enfoques ágiles estén equivocados, pero necesitan tales prácticas empresariales desde el principio, o cualquier beneficio se desmoronará rápidamente. Si bien las empresas no pueden convertirse repentinamente en nuevas empresas sin preocupaciones; pueden tejer la gobernanza tradicional en formas más nuevas de entregar software program.
Esto no será fácil, pero es necesario y contará con el apoyo de los proveedores de herramientas a medida que ellos también maduren. Hemos visto a VSM pasar de ser uno de varios acrónimos de tres letras que abordan la visibilidad de la gestión en la tubería de desarrollo, a convertirse en el que la industria está impulsando. Incluso mientras se desarrolla un debate sobre su relación con Mission Portfolio Administration (PPM) de arriba hacia abajo (como lo ilustra la adquisición de Tasktop por parte de Planview), estamos viendo un mayor interés en las herramientas de análisis de desarrollo de software program que vienen de abajo hacia arriba.
Durante el próximo año, espero ver una mayor simplificación y consolidación en las herramientas y el espacio de la plataforma, lo que permitirá más enfoques basados en políticas, mejores medidas de seguridad y una automatización mejorada. El objetivo es que los desarrolladores puedan ponerse manos a la obra y hacer las cosas con un estorbo mínimo, incluso cuando los gerentes y el negocio en su conjunto sientan el beneficio de la coordinación.
Pero esto también requerirá que las organizaciones empresariales, o más específicamente, sus grupos de desarrollo, acepten que no existe tal cosa como un almuerzo free of charge, no cuando se trata de software program de todos modos. Cualquier enfoque para el desarrollo de software program (ágil o de otro tipo) requiere que los desarrolladores y su administración mantengan un management estricto de las riendas de las entidades vivas que están creando, acorralándolas para generar valor.
¿Creo que el software program debería entregarse más lentamente o estoy a favor de volver a las metodologías anticuadas? Absolutamente no. Pero algunos de los principios que defienden estaban ahí por una razón. De todas las verdades en el software program, reconozca que siempre existirá la complejidad, que luego debe administrarse. Ignore esto bajo su propio riesgo, no está siendo un aburrido viejo al poner la gobernanza de entrega de software program sobre la mesa.
