En el desarrollo de software a medida tener una mentalidad circular de desarrollo → implementación → monitoreo → mejorar ha sido una constante. No lo sé, llámame loco, pero allá por 1990 cuando trabajaba haciendo aplicaciones de gestión en Clipper que corrían sobre entornos Novell (en aquel momento era de lo más top en el mundo de las PYMEs y las administraciones no muy grandes), es algo que se hacía por pura lógica.
¿Existe una necesidad? ¡Sí! ¿Podemos aplicar una solución informática? ¡Sí! ¡Pues hagámoslo! Y se hacía. Y se implementaba. Y el usuario empezaba a usarla para luego… ¡Ops, es que esto no me sirve y aquí me falta y allá da un mensaje raro si intento no sé qué idea macabra!
Así que cogías esos «no me sirve», «aquí me falta», «allá da un mensaje de raro» y adaptabas el desarrollo a lo que el usuario pretendía hacer y necesitaba hacer.
Y volvías a hacer una segunda instalación. Y el ciclo se repetía.
¡De dónde si no nace la necesidad de añadir a cada instalación un número de versión!
El mundo del marketing, también el marketing en el área de la programación, siempre ha sido «amiga» de inventar palabras y abreviaturas. Ahora tenemos entre manos la metodología DevOps.
Con este invento conseguimos vender cursos, actualizar el contenido de las formaciones que ya rulaban por ahí, vender aplicaciones de soporte, poder ofrecer servicios diferenciados hasta que la competencia se ponga las pilas y parecer más innovadores, parecer ser punta de lanza. Solo porque le has puesto un nombre diferente a algo ya existente. Pero…
(Ojo)
No digo que eso esté mal porque tiene su lado positivo.
Protocolizas la metodología. Al establecer un «paso a paso» es más fácil que las nuevas generaciones de desarrolladores webs o de aplicaciones adquieran un hábito -de sentido común pero que no siempre se aplicaba-.
Además al asumir esta metodología das la posibilidad a la empresa de desarrollo a mantener la relación con el cliente ya que no se trata de hacer una aplicación, entregarla y divorciarse.
Es más bien como casarse y trabajar para que ese matrimonio (cliente y proveedor) puedan sacar adelante a ese hermosa hija que han tenido (aplicación que soluciona algo).
La cuestión es que el fracaso de un desarrollo, una estrategia de marketing o el lanzamiento de un producto o un servicio siempre tiene el mismo origen: la distancia que hay entre la idea planificada inicial y lo que la necesidad final del consumidor o usuario demanda.
La única forma de acortar esa distancia es con la retroalimentación continua.
Es algo que ya estimula el Método Lean y el concepto del MVP (Producto Mínimamente Viable), que simplificándolo mucho y escrito a mi manera podemos describir como un algoritmo tal que así:
- Detectas una necesidad.
- Diseñas una solución.
- Desarrollas la solución.
- La lanzas al mercado.
- MIDES SU DESEMPEÑO. (¡De vital importancia!)
- Obtienes un aprendizaje.
- Rediseñas la solución.
- Iteras al paso 3.
Cómo verás, este pseudocódigo es infinito. No hay un punto de ruptura (excepto que el cliente deje de pagar o la necesidad final desaparezca y la solución se vuelva innecesaria).
Esto me parece TAN BÁSICO actualmente que me sorprende que aún haya startups, empresas o ingenieros que tengan una mentalidad de «desarrollo final». Una mentalidad de «entrega de producto».
Y las hay.
INDRA sin ir más lejos. Bla, bla, bla, que sí, lo que tú digas, que es una gigantesca consultora tecnológica pero ya te digo yo que sus desarrollos tienen una mentalidad de «producto final» lleno de errores al que les cuesta horrores ponerle remedio al punto que, por ejemplo, su M@GIN no lo quiere ninguna administración tributaria del país. ¿Por qué será?
Así que queda claro, NO existe un «desarrollo final».
Es un círculo infinito. Siempre lo ha sido. Tal y como se representa en la metodología DevOps.
Pero esta vez, en lugar de hacer algo por intuición es algo que harás de una manera protocolizada, con aplicaciones de apoyo en cada paso, con automatizaciones, con KPIs predefinidos. Cada avance tiene un how-to que permite engarzar la cadena de manera eficiente.
Lo que es más útil, teniendo muy claro qué observar y de dónde extraer el aprendizaje en el paso de monitoreo. Porque para mí es la clave de todo. Uno de los puntos críticos. Y el lugar dónde suele generarse el error crítico del DevOps.
La metodología DevOps incluye, en su manera de actuar, de hecho, a la metología Lean, e incluso en la fase de desarrollo es factible de introducir una metodología Agile que acelere el proceso. Aunque hay quien anda por ahí queriendo defender su reino de taifas y contraponen la entrega continua, como también se conoce al DevOps, con el scrum, o metodología ágil. Es normal. Aquello por lo que eras un referente ahora es solo la parte de un todo mayor. No mola. Eso no vende libros ni genera invitaciones a eventos como charlante de turno.
Para entenderlo mejor te detallo estos principios y las 5 claves que determinan el proceso global.
- Pensamiento sistémico: las aplicaciones son sistemas complejos que no se limitan a la simple codificación, interviniendo en su desarrollo múltiples actores y facetas que van desde la plataforma sobre la que corren, la gestión de repositorios y versiones, el propio lenguaje y entorno… hasta el usuario que las usa pasando por el cliente que las paga, que no siempre son la misma cosa.
- Reforzar el feedback: por lo tanto, es esencial mejorar la comunicación multi-direccional en el equipo y, hiendo más lejos, con todas las personas que intervienen en el proceso de una u otra manera. Lo que requiere a su vez cierto grado de transparencia (algo que genera sarpullidos en los inversionistas).
- Cambio de mentalidad: hay que motivar al desarrollador a salir de su burbuja, a perder el miedo a experimentar y que eso le lleve a un aprendizaje continuo. Sí, hay que dejar un momento para la cerveza y para el ligoteo, para jugar con lo que hace la competencia, para hacer los puñeteros cursos y actividades que, al menos en teoría, mejoran y engrasan el funcionamiento del equipo. Y tomarse esa mierda en serio porque es útil de verdad. Si falla es porque las personas que participan no quieren comprometerse. Y esa falta de compromiso derrumba todo el DevOps.
Bien, estos tres principios se desarrollan sobre 5 teclas a pulsar, las conocidas como CALMS (keep calm and carry on, my friend):
- Culture: referido como el cambio cultural, de mentalidad, en el desarrollo; lo que es una fase esencial para que el trabajo en equipo funcione de forma más cohesionada. (Y eso pasa porque, sí, efectivamente, tendrás que ir un fin de semana a hacer el tonto con tu equipo de programadores.)
- Automatization: referido a las herramientas que aumentan la velocidad porque eliminan del día a día las tareas repetitivas y garantiza una mayor calidad al disminuir el error, lo que deja más espacio a la creación y la experimentación.
- Lean: la metodología de mejora continua donde la aceptación de los errores constituyen las bases de una cultura experimental, aplicando por lo tanto el concepto MVP o producto (servicio) mínimamente viable, ya que es imposible experimentar sin someter a prueba y juicio.
- Measure: hace referencia a la práctica de medir a través de KPIs preestablecidos, los resultados de nuestro MVP, en la fase que sea que se encuentre, y que son útiles para para mejorar el propio producto o servicio, pero también los procesos de desarrollo. Insisto, también mejoran los procesos.
- Sharing: es decir, que no te puedes guardar el conocimiento para ti, que tienes que relacionarte con el equipo además de con la pantalla, donde cada persona se convierte en punta de lanza de la transformación de la empresa con una visión DevOps a través del esfuerzo conjunto y en la adopción de estas prácticas.
Y por último, sí, Agile puede entrar, ayudar (y mucho) dentro de un enfoque DevOps. Pero eso lo dejo para otro día.