IT is part of the business

Todos estamos ya familiarizados con el concepto de DevOps, pero es muy probable que mucha gente piense en ello como una práctica que afecta sólo a los programadores y al equipo de operaciones, incluso se puede llegar a pensar que simplemente va de usar ciertas tecnologías, pero no; DevOps va mucho más allá. DevOps no es sólo tema de desarrollos y operaciones, sino que impacta a toda la empresa, porque implica un cambio de mentalidad y de cultura y por ello no vamos a hablar de herramientas ni entrar a ver las “pipelines” para realizar automatizaciones ni nada semejante, sino que vamos a ver algunos aspectos de lo que implica DevOps y su impacto en general en la empresa.

DevOps existe para mejorar el proceso de entrega de software, hacerlo repetible y poco intrusivo, minimizando los impactos en el funcionamiento normal de las soluciones informáticas de la compañía. Principalmente, lo que hace es que dos grupos de trabajo como son desarrollo y operaciones trabajen de una manera conjunta y coordinada, por ejemplo, compartiendo métricas y objetivos. Hasta aquí nada nuevo que no hayamos leído en múltiples ocasiones, pero al romper estos dos silos y modificar su modo de trabajar, veremos cómo se crearán en la compañía unas fuerzas de cambio de cultura que impactarán a otros departamentos y personas, a los que hay que sumar a este cambio de filosofía de desarrollo de software.

Antes de comenzar a trabajar con DevOps, debemos pensar en algo: si queremos implantar esta manera de trabajar, es porque actualmente somos conscientes de que tenemos un problema en las entregas de los desarrollos o porque queremos mejorar dicho proceso, y si pensamos que podemos mejorar el proceso es que posiblemente tenga algún problema.  Dicho esto, para conocer la mejor manera para mitigar los problemas que tengamos en el proceso, será identificarlos y conocerlos en profundidad, esto significa que hay que analizar el proceso actual de entrega de software y ver en qué puntos existen dificultades y/o conflictos para poder atajarlos. En este momento, alguno puede pensar que en su proceso no existen problemas y que es muy eficiente, pero puede ser que no sea consciente de ellos, que no quiera reconocerlos, o que no sepa que se puede mejorar el proceso; algunas tribus pensaban que para defenderse lo mejor eran los arcos y las flechas, hasta que la competencia llegó con las escopetas y pistolas; el resultado es conocido.

Una de las mejores soluciones para identificar los problemas de un proceso, sería poder leer el pensamiento de cada uno de los implicados en él; si lo hiciéramos, quizá nos encontraríamos algo como:

• [Negocio]: “Necesito que este distribuidor me suba las facturas al portal y hace tiempo que pedí esta funcionalidad a los de IT. ¿Qué deben estar haciendo el equipo de desarrollo que no lo tienen ya?

• [Desarrollador]: “Tengo generar código para implementar todas las funcionalidades requeridas por la compañía; yo voy haciendo, pero no entiendo por qué mi código no se está ejecutando aún en producción, y negocio me llama por teléfono para preguntar y no me deja en paz”.

• [Operaciones]: “Tengo que mantener los sistemas estables y libres de errores, a ver si puedo hacer pocos transportes y esta vez los desarrolladores no me rompen nada, que ya tengo bastantes quejas de usuarios y parece que programan a lo loco sin probar ni tener en cuenta la seguridad”.

• [Distribuidor]: “Hace seis meses que me han dicho que prepararían el portal para que suba las facturas ahí, pero no veo donde está esta funcionalidad”.

Como podemos observar, cada uno ve la situación desde su punto de vista, y los pensamientos y sentimientos de todos son los que nos dan pistas de cómo mejorar el proceso. Como aún no podemos leer la mente de las personas, lo mejor es poner estos pensamientos en común y poder así analizar los procesos.

Para analizar los procesos actuales de desarrollo y entrega de software, lo mejor es realizar sesiones de trabajo donde las personas involucradas en ellos expliquen su visión y sus sentimientos, qué problemas ven y cómo lo harían para sentirse mejor.  Dentro de las personas a invitar a estos grupos de trabajo, estarán por supuesto desarrolladores y gente de operaciones, pero también personas de negocio (e incluso de empresas externas), que son los que nos remiten los requisitos y los usuarios finales de las soluciones.

Quiero hacer notar tres cosas del párrafo anterior:

• Que hablamos de visión del proceso, porque cada una de las personas vive el proceso y sus problemas de manera diferente, y en estas sesiones nos permitirán “andar con los zapatos del resto de los implicados”, conocer otros puntos de vista. Todos las opiniones y comentarios son importantes, porque en ocasiones, no somos conscientes de que cuando hacemos algo, o no lo hacemos, o lo hacemos tarde, por pequeño que sea, puede impactar mucho más adelante en el proceso. Por ejemplo, algo tan sencillo como no tener introducidos las facturas en el sistema el día indicado y con el formato establecido, puede hacer trabajar más horas de la cuenta a las personas encargadas de hacer el cierre de mes, y lo que para alguien son unos minutos, para otra persona se pueden convertir en horas de trabajo adicional. Tener una visión completa del proceso y conocer los puntos de dolor del resto de las personas implicadas, hace que empaticemos con ellos y que, en el futuro, el flujo del proceso sea mucho mas ágil, a la vez que surgen muchas más ideas de mejora.

• Que en estas reuniones habrá muchas personas involucradas, de diferentes departamentos (a veces de distintas compañías) y de distinta categoría; esto puede dificultar la interlocución y la sinceridad, por lo que habrá que pactar previamente ciertas normas (algunas de sentido común, pero mejor pactarlas) a la hora de analizar los problemas, para que no sea una batalla de acusaciones o faltas de respeto. No hay que olvidar que estamos para ver los problemas que encuentra cada uno y ver cómo mejorar el proceso de manera que todos salgamos ganando.

• Que hemos hablado de sentimientos, porque cuando los workshops se llevan a cabo, no sólo se hablará del procedimiento, sino también de los sentimientos de cada una de las personas que interactúan a lo largo del proceso, un customer journey de cada uno de los actores implicados; y hay que estar preparado para lo mejor y lo peor, una palabra que surge muchas veces es “frustración”.

Como se puede ir observando, estamos hablando de incluir a gente de toda la compañía e invitamos a comentar de manera transparente y abierta sus impresiones sobre el proceso y a los responsables de él a aprender y mejorar con ello, esto supone un cambio de mentalidad en casi todas las empresas.

En lo referente a cómo llevar a cabo estas sesiones (las que haga falta), lo mejor es de manera física en una sala (cuando sea posible) o al menos con video llamada, evitando a toda costa el uso simplemente de voz. En el caso de video llamada, lo ideal es tener a todos con las cámaras encendidas y siempre centrados en la actividad, haciendo pausas para atender mails y temas importantes que puedan surgir. El entorno debe favorecer la participación abierta, para lo cual nos ayudaremos de algunas pizarras y lugares donde poder pegar papeles con anotaciones. Para dinamizar las sesiones, podemos basarnos en algunas técnicas como la Estrella de mar, una variante más reducida como StoStaKee, el barco de vela, o el análisis de cadena de valor, técnica extraída directamente de los procesos industriales.

Dado que vamos a incluir en nuestros grupos de trabajo a gente de otros departamentos, habrá que pedir disponibilidad de ellos a sus gestores (ya hemos dejado claro que DevOps no sólo afecta a desarrolladores y operaciones), en este momento nos podremos encontrar con una situación similar a la que nos encontramos con las adopciones de cualquier tipo de proceso o tecnología: departamentos y gerentes que no tengan objeción desde un principio en que ellos y sus equipos participen en las sesiones porque ven un claro beneficio para la compañía (innovators y early adopters), departamentos y personas que vayan participando según vean que otros participan (followers) y departamentos y gerentes que será reacios hasta el último momento y que predicarán incluso el final del mundo por la introducción de estos cambios (laggards). Nuestra misión es no defraudar a los primeros en adoptarlo, convencer a los followers y no hacer caso a los laggards.

La introducción de DevOps en la empresa no es algo de un día, es una carrera de fondo, por lo que necesitamos que la confianza de los innovadores y los adoptadores tempranos no decaiga, porque nos servirán de evangelizadores y nos conseguirán a más personas que quieran unirse y aportar su grano de arena en esta iniciativa, y para ello, necesitamos darles “algo” para que vean que no se han equivocado al embarcarse en el proceso de adopción de DevOps, que han apostado por caballo ganador, y aunque en ocasiones no tengamos mucho que ofrecerles, sobre todo al principio, siempre es buena la transparencia y la información.

Una vez tengamos recopilados los problemas e inquietudes sobre los procesos de entrega de software, debemos analizarlos para ver cómo eliminarlos mediante DevOps, generando así el plan para su implementación. Algunos de los problemas que nos encontraremos serán:

• Releases demasiado grandes con muchas funcionalidades
• Pasa mucho tiempo desde que se descubre un bug hasta que se soluciona
• Mucho tiempo y decisiones en cada paso del proceso
• Burocracia
• Etc

Son los sospechosos habituales en todas las casas.

A la hora de realizar el plan de implementación, es bueno tomarlo como una empresa (si miramos la definición literal de empresa, realmente, esta adopción es una empresa: “una empresa es un intento o designio de hacer algo.”), marcando una misión, una visión y los objetivos. Cuando los tengamos definidos, es bueno contrastarlos con otros departamentos para ver que están alineados y con el departamento de marketing y comunicaciones para que nos ayude a hacer un poco de publicidad interna y que todos sepan de la iniciativa, escribiendo una newsletter, poniendo posters con alguno de los objetivos, etc.

La comunicación en el proceso de implantación de DevOps es muy importante, hay que procurar que todas las personas sepan que está en marcha este proceso y para ello, habrá que hacer tareas de relaciones públicas, sesiones explicándolo a los departamentos, haciendo publicidad de ello, etc. así conseguiremos visibilidad en las capas altas, que los que están involucrados recuerden que son parte de ello y que más gente se quiera involucrar. En este sentido también podemos fijar la figura del evangelista DevOps, que ayude a otros departamentos a comprender qué está pasando en la empresa en cuanto a desarrollo de soluciones se refiere, cómo les va a impactar y cómo será el futuro.

Un tema importante a tener en cuenta cuando informemos, es ser coherente y usar siempre las mismas palabras, para ello es bueno crear un glosario de las palabras que utilizaremos, explicando lo que son y lo que no son, de manera que no haya ambigüedades y que si alguien habla de una release, todos sepamos que es “una instalación o despliegue de un bloque de código en un entorno (productivo, test, etc)” y no es, por ejemplo,  “una subida de versión de sistema operativo“.

Informar informar e informar

Es muy importante tener a todas las personas informadas y mantenidas al día, y no me refiero sólo a las involucradas directamente en el programa, sino a las que están impactadas por el despliegue de este; dicho de otra manera, a toda la compañía. Está claro que el nivel de información no tiene que ser el mismo para los que están involucrados de primera mano y para los que no quieren saber nada del programa, por ejemplo, no sería buena idea enviar todos los días un mail con información a una persona que es reticente a la adopción de DevOps, porque sería contraproducente.

¿Como informar sin ser intrusivo? Pues dependerá mucho de cada situación, si el Budget y el entorno nos lo permiten, la instalación de pantallas en algunas salas como la del café mostrando indicadores de evolución y noticias, podría ser una buena opción.

Si no tenemos Budget para ello o las circunstancias no nos lo permiten, podemos buscar otras ideas ingeniosas como posters con un mensaje sobre el programa de implantación de DevOps y un QRCode con un enlace al panel de control de los indicadores de evolución o un apartado en las publicaciones de la compañía.

Hay que informar de todo, y las cosas no siempre salen bien, pero en ese caso, también informaremos. Si hemos pedido transparencia y aceptación al resto cuando hemos hecho los workshops de análisis de los procesos, nosotros debemos predicar con el ejemplo. DevOps también es eso, transparencia y confianza. Cuando haya accidentes o errores, se comunicarán, no se les dará más importancia de la que tienen y no se acusará ni culpará sin motivos, se analizarán y se aprenderá de ellos, continuando con el proceso. Es un paso más en el cambio de mentalidad, pasando de la acusación al aprendizaje.

Y hay que recordar que, si no hay noticias, es que no hay noticias así que hay que publicitar e informar; incluso marcas de refrescos históricas de color oscuro y con burbujas, nos recuerdan en la televisión su existencia a través de los anuncios.

Pero para informar, informar e informar, debemos medir, medir y medir.

Medir medir y medir

Pero ¿qué medir? La respuesta rápida es todo lo que podamos.

Existen métricas en DevOps bastante comunes como pueden ser:

• MTBF (mean time between failures)
• MTTR (Mean time to resolution)
• Bug scape distance
• Duplicacion de código
• Commit rates
• etc

Esto puede verse por los desarrolladores e ingenieros como que les espiamos y no confiamos en su trabajo, y nada más lejos de la realidad, con lo que hay que tener cuidado a la hora de transmitir los mensajes y hacerlo de la manera correcta, ya que estas mediciones les van a ayudar a medir el rendimiento de sus desarrollos, les van a servir para eliminar código duplicado, etc. En definitiva, les van a ayudar a mejorar.

Además de estos indicadores, podemos aprovechar para ampliar la gama de mediciones, por ejemplo, cuando el software esta desplegado en producción y comienza a haber fallos de rendimiento, comienzan los problemas de saber si es parte de la plataforma de software o de la infraestructura y redes. Por eso una buena regla es medir todo lo que se pueda, del mismo modo que un formula 1 está lleno de sensores que emiten en cada momento la salud de cada parte del coche, lo mismo deben ser nuestras aplicaciones. Podemos incorporar logs donde vayamos almacenando tiempos de respuesta de cada una de las partes del código y cada cierto tiempo hacerlas llegar a un sistema central que pueda analizar estos logs y pintar de manera gráfica el rendimiento y enviar alertas automáticas cuando se detecten cambios sustanciales en el rendimiento; así, nos será muy fácil detectar cambios de rendimiento tras cada despliegue que hagamos, sin tener que esperar a enterarnos cuando el usuario final se queje.

Y si hemos hablado de que DevOps no es sólo tecnología y que impacta de manera global, una buena idea es también medir el impacto que está teniendo en las personas de toda la compañía, esto es un poco más difícil de capturar y medir que los tiempos entre despliegues, pero nos dará una visión de la huella que está dejando DevOps en el activo más importante: las personas. Una de las mejores maneras de realizar esta captación de información es realizar periódicamente entrevistas cortas o poner a disposición cuestionarios donde aparezcan preguntas como:

• ¿Crees que tienes las herramientas adecuadas para realizar tu trabajo?
• ¿Crees que la colaboración entre negocio y desarrollo es efectiva?
• ¿Crees que DevOps está mejorando los procesos de entrega de software?
• ¿Como valorarías la entrega continua de software?

Es muy importante que no sean largas, de lo contrario, la gente no las contestará, de igual forma, lo mejor es que las respuestas sean cerradas, por ejemplo, escalas del 1 al 5.

Todas estas métricas nos servirán para conocer cómo va evolucionando la implantación de DevOps a nivel de procesos, rendimiento y personas y poder actuar en caso de ver derivas no esperadas. Si no se mide, no se puede controlar.

DevOps es algo vivo, no llega un momento donde podemos decir que está implantado en la manera de trabajar y nos olvidamos, sino que hay que mantenerlo y adaptarlo. Siempre surgirán nuevas tecnologías, nuevos procesos, nuevos retos que debemos afrontar y adaptar nuestra forma de trabajar a ellos. En este sentido, podemos ver el proceso de adopción de DevOps como el de una casa en el campo que lleva tiempo allí y que no se ha cuidado, donde posiblemente encontremos polvo y maleza, la pintura esté desconchada, etc. Durante los primeros meses, estaremos quitando esas malas hierbas, pintando la casa o cambiando a lo mejor alguna ventana. Lo que está claro, es que si cuando pensemos que está acabada no hacemos nada más, en unos meses volveremos a tener malas hierbas e incluso goteras, por ello vamos revisando el estado de la casa y arreglando lo que se tenga que arreglar y mejorando lo mejorable (quizá un enanito en el jardín, quien sabe). Del mismo modo, el entorno en la compañía cambiará, y si desatendemos los procesos de DevOps, podemos perder el camino andado, por ello se debe vigilar y adaptar los procesos a este entorno cambiante. Una de las maneras de realizarlo es mediante ciclos de Deming (de Edwards Deming) o ciclos PDCA (del inglés Plan, Do, Check, Act) mediante los cuales podremos ejercer una vigilancia y mejora de los procesos, de manera sencilla y recordándonos que no debemos dormirnos en los laureles pensando que todo irá bien desde ahora.

Con este pequeño viaje de implantación de DevOps, hemos podido ver que algo que pensábamos que afectaba solamente a un par de grupos de trabajo, realmente afecta a toda la empresa y que pese que a lo mejor al principio supone un sobresfuerzo para grupos de trabajo ajenos al núcleo de desarrollo y operaciones, los beneficios a la larga son para todo el negocio

Podemos decir que DevOps no es

sino