DevOps VII

Esas medidas más concretas, que mencionaba en el artículo de ayer, irán orientadas principalmente:

– A reducir la incertidumbre: Definición de políticas por parte del Departamento de Sistemas, consensuadas con el Departamento de Desarrollo que pueden ir orientadas a definir un «catálogo de sistemas base», es decir: estos son los servidores de aplicaciones con tal versiones, estos los de bases de datos, este el gestor documental, etc…, una serie de condiciones con respecto a la entrega de las versiones (instalación en entornos previos lo más parecidos posibles al de producción y verificación de su correcto funcionamiento), etc…, y la participación de personal de Sistemas en el proyecto, con más intensidad en la fase en la que se defina el entorno tecnológico, etc…

– A mejorar la coordinación: Que ambos departamentos tengan información actualizada sobre las operaciones, eventos y entregas que puedan afectar al otro, consensuar soluciones o prioridades en el caso de que se prevean períodos de importante carga de trabajo, establecer estrategias para gestionar el WIP (Work in Progress) como puede ser la aplicación de Kanban que pueden resultar de utilidad para detectar cuellos de botella o para realizar ajustes en los equipos de trabajo, etc…

– A reducir las actividades mecánicas en el proceso de entrega e instalación de manera que tanto desarrollo como sistemas puedan dedicarse a las actividades realmente importantes: ¿para qué realizar instalaciones o ejecutar scripts a mano si se puede automatizar?. Esto al principio choca, porque para muchos supone un cambio de paradigma, sin embargo, si se establecen una serie de medidas para reducir la incertidumbre y se demuestra que el modelo funciona y es el adecuado para un conjunto de sistemas (aunque se empiecen con determinados sistemas piloto), terminará por asentarse porque es productivo, disminuye errores humanos y lo que decía antes, se puede invertir más tiempo en otro tipo de actividades donde se requiere un mayor esfuerzo intelectual.

Todo ello sin olvidar que los más importante, al final, son las personas.

DevOps VI

Es cierto que un modelo organizativo más ordenado y racional ayuda y que las personas pueden crear puentes y dar soluciones ante situaciones de bloqueo, pero sigue siendo necesario dar un paso más que permita agilizar todo ese proceso de entrega y paso a producción reduciendo o eliminando esos cuellos de botella que sin duda aparecerán y que además, permitan resolver problemáticas concretas de determinadas aplicaciones que requieran de manera puntual o continua que sus cambios lleguen a producción cuando se necesita (que no es ni pronto, ni tarde).

Ese paso más supone nuevos cambios, algunos de los cuales suponen una transformación de los métodos o procedimientos utilizados hasta ahora. Es normal que cuando se propongan, sean tomados con cautela y que incluso provoquen rechazo porque es muy posible que no se terminen de entender los motivos y/o que no se alineen con las políticas del departamento (o con la visión de cómo deben hacerse las cosas que tenga el responsable correspondiente).

Por eso comentaba la importancia de sentar primero unas bases: primero la intención de un cambio, unas personas dispuestas a modificar el modelo actual, unos objetivos a nivel de la organización (y del departamento TIC a menor escala) y la necesidad de un mejora continua, y a partir de ahí definir medidas más concretas aplicadas paulatinamente en proyectos reales para medir sobre los mismos su efectividad. Es ahí donde se empezarán a despejar dudas y a eliminar resistencias porque si la solución adoptada es buena probablemente dejará satisfechos a todos.

DevOps V

Este marco de trabajo, basado en la colaboración efectiva entre equipos distintos, en los que sobre unos procesos que establecen unas reglas generales del juego, se encuentran una serie de personas que se comunican, interactúan y llegan a acuerdos para llegar a cumplir una serie de objetivos comunes, hace que se asocie DevOps a la aplicación de agile más allá del proceso de desarrollo.

Pero no es solo eso, sería muy simple dejarlo en eso, va más allá, porque agile ya preveía desde el manifiesto ágil la colaboración entre equipos. En este caso se trata de aplicar sus fundamentos para acercar esos departamentos que tienden a funcionar por separado, a romper esas barreras culturales y conseguir que trabajen de manera conjunta para servir a unos objetivos generales.

Desde el punto de vista operativo, la solución no es simple porque se parte una situación muy heterogénea: múltiples proyectos que se encuentran en diferentes momentos de su desarrollo y/o de su ciclo de vida, desarrollados además con diferentes enfoques, con diferentes tecnologías, cada uno con sus propias prioridades que varían a lo largo del tiempo, unos con muchos problemas, otros con menos, unos con unas fechas de entrega rígidas, otros más flexibles, etc… y todos ellos llegan a una misma puerta de entrada: departamento de sistemas, el cual además, realiza operaciones relacionadas con el mantenimiento de la infraestructura, de la seguridad y de las comunicaciones, tanto a nivel físico como lógico y que cuenta con unos medios limitados tanto personales como materiales.

DevOps IV

Es complicado enfocar las culpas hacia una de las partes, por lo menos en términos generales, ya que cuando se producen problemas en los puntos de integración entre diferentes departamentos es síntoma de que lo que está fallando es el sistema. Esto no quita que existan problemas adicionales, como el hecho de que además de lo anterior, existan personas que se muestren intransigentes y no vean más allá del límite, no ya de su propio departamento, sino de su propio yo.

La solución al problema no es simple pero para empezar es fundamental tener perfectamente definidos y que sean bien conocidos por todos, los objetivos del Departamento TIC, establecer un modelo de mejora continua que tenga como finalidad que la evolución, prioridades y actuaciones de los diferentes departamentos atiendan a esos objetivos, que su interacción sea efectiva, que la información fluya en el momento adecuado a todos los que deberían ser conocedores de la misma y que se fomente la colaboración y cooperación entre todos los implicados.

A lo anterior hay que sumar mecanismos que permitan prever y si no es posible, arbitrar, situaciones de conflicto minimizando el impacto de las mismas en las actuaciones implicadas.

Pero por encima de todo lo anterior, es fundamental que las personas entiendan que hay que mirar hacia la organización y no exclusivamente hacia dentro de su departamento (o a más bajo nivel hacia sus proyectos o hacia los sistemas que administran), porque lo segundo sin lo primero ni existiría ni tendría razón de ser.

De esta forma, no podemos dejar la solución en mano de los procesos y procedimientos porque al final son las personas las que los hacen buenos o malos, sobre todo teniendo en cuenta que lo que se pretende es romper barreras culturales entre los integrantes de ambos departamentos, barreras que se repiten organización tras organización.

DevOps III

Realmente, no se trata exclusivamente de un problema de predecibilidad o de que ambas partes no se hayan tenido en cuenta a la hora de programar sus tareas (que lo es), sino que hay, además, un aspecto importante que hay que tener en cuenta y es que cada paso a producción genera incertidumbre.

Una nueva versión con problemas puede afectar no solo a su conjunto de usuarios, sino que puede comprometer la disponibilidad o el rendimiento de otros sistemas con los que comparte infraestructura o incluso afectar a la seguridad.

No ayuda el hecho de que los desarrolladores tengamos malas prácticas, no probemos los productos lo suficientemente o no nos preocupemos por el impacto que tienen nuestros desarrollos sobre la infraestructura de sistemas («¿optimizar?, ¿para qué si la «chapa» es barata?»).

Podemos luchar contra esa incertidumbre, pero no podemos luchar contra la aparición de nuevas versiones ni con la ventaja competitiva (o de ahorro de costes) que tiene liberar y poner en producción una nueva versión a tiempo, porque lo que es seguro es que nos movemos en un contexto donde el cambio es inevitable y necesario.

Por esta razón, los Departamentos de Sistemas no pueden convertir el proceso de aceptación de las aplicaciones en algo lento, farragoso y con continua devolución de versiones a desarrollo por el incumplimiento de ciertas normas que no aportan valor a nadie.

DevOps II

Por ejemplo, supongamos que un departamento de la organización necesita poner en producción en un plazo de una semana una determinada versión de un sistema. Supongamos también que ha sido validada funcionalmente y que se han realizado tareas de testing que no ha encontrado defectos que aconsejen su corrección antes de su puesta en marcha.

Y resulta que el departamento de sistemas tiene programada esa semana una serie de actuaciones de mantenimiento que provoca que buena parte del equipo esté ocupada de las mismas, y además, exigen que la entrega de la versión cumplan una serie de condiciones para ser aceptada, las cuales, pese a no ser importantes, provocan una serie de conversaciones entre las áreas de desarrollo y de sistemas, que pese a terminar en acuerdo tienen como consecuencia la pérdida de varios días.

Al final, suele suceder que los plazos fijados no se cumplen.

Bien es cierto que si fuera algo crítico o estratégico probablemente alguien con suficiente poder dentro de la organización hubiera dejado clara la prioridad y se hubieran volcado los esfuerzos en que todo hubiera salido hacia adelante. Pero también es cierto que cuando no es así, resulta complicado ser predecible con las fechas en que se prevé que una versión llegue a producción y esto a veces tiene poca importancia y en otros casos tiene un coste económico que podría ser poco significativo hasta que el número de veces en que se producen este tipo de circunstancias hace que el coste económico, gota a gota, sea sensible.

No se trata de echar la culpa a sistemas, en el ejemplo que he puesto la culpa perfectamente ha podido ser de desarrollo, ya que lo mismo sistemas avisó con suficiente tiempo de sus tareas y/o las condiciones de entrega y la falta de flexibilidad eran perfectamente conocidas y se podía haber comenzado el diálogo mucho antes.

DevOps I

Se considera parte del ADN de nuestro negocio que los departamentos de desarrollo, sistemas y explotación funcionen como reinos independientes con sus propias reglas y prioridades, que si bien tienen que colaborar entre sí, la fluidez con que se realizan esas colaboraciones dependen más de las relaciones personales existentes entre sus miembros que por unos objetivos a nivel organizativo o las necesidades propias de un proyecto.

Que personas puedan resolver problemas más allá de un contexto poco favorable para un trabajo cooperativo siempre es positivo, de hecho, como veremos más adelante, es fundamental.

Sin embargo en un mundo tan profesionalizado como el nuestro, las cosas tienen que salir adelante independientemente del grado de afinidad que tengan determinadas personas o de si un día alguien se ha levantado con más o menos humor que de costumbre.

La realidad es que cada departamento evoluciona de manera independiente, como si estuvieran desenchufados, como si no tuvieran nada que ver, lo que hace que definan sus propias interfaces, su propio modelo de relación y eso se termina convirtiendo en una fuente continua de conflicto porque cada uno de ellos enfoca sus prioridades a objetivos que siendo perfectamente legítimos, pueden no estar en consonancia con lo que la organización necesita en ese momento.

Es decir, ambas partes pueden llevar razón, incluso sus actuaciones podrían considerarse como válidas, sin embargo, en muchos casos esos resultados parciales positivos cuando no se realizan teniendo en cuenta al resto de la organización, sus tiempos y objetivos pueden tornarse en perjudiciales.

DevOps II
DevOps III
DevOps IV
DevOps V
DevOps VI
DevOps VII

Los enfoques ágiles requieren más intensidad

Quien piense que desarrollar con metodologías ágiles es más tranquilo o más sencillo, está totalmente equivocado, bien porque no sabe realmente qué es esto o porque los proyectos en los que ha participado o seguido y en los que teóricamente se aplican principios y prácticas ágiles no lo son en realidad.

Si hay algo que caracteriza a los desarrollos aǵiles es la intensidad. ¿Cómo si no se puede sacar cada poco tiempo una versión del producto potencialmente dispuesta para pasarse a producción?. Esto solo se consigue si todas las partes: desarrolladores, usuarios y restos de implicados participan con gran implicación en el proceso de desarrollo.

Si te duermes no cumples los compromisos.

A cambio de eso encuentras otras satisfacciones como el hecho de que se valore más el trabajo de las personas, la comunicación e interacción entre las mismas y el concepto de equipo (hay de todo, pero si las personas y el producto no son el centro de todo, estaremos hablando de metodologías ágiles pero no de agilidad real), la posibilidad de autogestionar tu trabajo y algo muy importante, ver como poco a poco vas construyendo un producto que sabes que va a resultar de utilidad y que no se va a quedar en una rama perdida en el sistema de gestión de versiones.

Los enfoques clásicos son mucho más irregulares en ritmo y si no hay premura en los plazos tienden a eternizarse, esto se hace más evidente en el desarrollo de grandes sistemas de información que parece que no terminan de ponerse en producción nunca y no es raro encontrarnos con sistemas que llevan más de dos o tres años de desarrollo (incluso con exigencia) y que no terminan de rematarse, algo que no es, en absoluto, una buena señal, porque se pondrá en marcha una aplicación mastodóntica sobre la que se tendrán que realizar ajustes, siendo el número de ellos proporcional a su tamaño y complejidad.

Se asocia ágil a desorganizado, a improvisación y no es así, si así fuera sería impensable tratar de cumplir unos compromisos cada poco tiempo. Muchas veces lo que parece organizado por el simple hecho de tener definidos ciertos entregables no es más que una fachada que esconde una gestión caótica.

La interacción necesaria entre desarrolladores y responsables funcionales

No resulta positivo que los desarrolladores intervengan en exceso en la definición de las historias de usuario, más allá de dar salida a las especificaciones de usuario con prototipos (pantallazos) que permitan facilitar la comprensión al usuario del efecto que tiene la definición que ha realizado.

No debemos olvidar que el producto no es para los desarrolladores sino para los usuarios.

El otro extremo, en los que los desarrolladores son meros ejecutores de las historias de usuario tampoco es el mejor modelo, ya que los desarrolladores pueden detectar funcionalidades que no terminan de encajar en el sistema y/o que tienen una complejidad que está muy por encima de los beneficios o valor que va a proporcionar a los usuarios.

Alistair Cockburn lo resume bien en la siguiente reflexión (traducción libre): «Un proyecto sufre cuando los desarrolladores no mencionan los problemas que descubren. El proyecto pierde la interacción creativa de programadores ofreciendo sus conocimientos para perfeccionar las peticiones de los clientes».

La mejor solución es la doble dirección, es decir, desarrolladores y usuarios realizando y conociendo sus responsabilidades y funciones, colaborando, ofreciendo conocimiento y abriendo debates cuando sea necesario.

La agilidad y el alcance III

¿Y que tiene que ver la agilidad en todo esto? En admitir una realidad que no es otra que la necesidad de adaptarse al cambio, a esas nuevas circunstancias que nos vamos encontrando en el proyecto y que nos obligan a tomar decisiones que se ajusten a las mismas.

Para ello las personas y el producto tienen que estar en primer plano.

Las personas tendrán que trabajar juntas, interactuando, comunicándose, para resolver las contigencias y problemas del día a día, siempre pensando en el producto y en tratar de conseguir el mayor valor para el mismo, tratando de mantener el clima más favorable para que el proyecto pueda ir hacia adelante.

Por parte del equipo de desarrollo se tienen que gestionar adecuadamente las expectativas, esto requiere transparencia, honestidad y saber comunicar de manera razonada las posibles desviaciones sobre los compromisos. Por parte del área usuaria, se requiere capacidad de comprensión de las circunstancias que la han provocado. Esa comprensión se irá haciendo más fuerte conforme vaya creciendo la confianza.

En el artículo anterior, hablaba de definir unas condiciones contractuales en las que se comparta el riesgo. Esto no solo es compatible con lo que estoy comentando, sino que es absolutamente necesario. Tiene que haber reglas del juego, conocidas, y sobre ellas ir tomando decisiones, siendo flexibles cuando sea necesario y justo.

La colaboración entre cliente y proveedor siempre debe estar por encima de la negociación contractual, tal y como indica el manifiesto ágil, ya que las condiciones de un proyecto varían de la noche a la mañana y el contrato es estático.

Al final, todo queda en mano de las personas, todo se reduce a eso y salvo que las condiciones iniciales del proyecto sean malas de partida (Death March Project) y/o haya grandes fluctuaciones sobre el enfoque del proyecto y sus objetivos, en ellas queda la mayor parte de la responsabilidad de que el proyecto pueda llegar a algún sitio.