• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

DevOps

Domain Driven Design: del Modelo al Diseño

Introducción

Este es el segundo artículo sobre las lecciones aprendidas aplicando Domain Driven Design en el equipo de desarrollo de Jerónimo Palacios & Associates. 

En la anterior entrada, te hablé sobre el mapeado del dominio en el modelo. En esta ocasión, te contaré cómo realizamos el segundo paso, la implementación del modelo en el diseño. 

Creando el diseño: ida y vuelta.  

Los técnicos estamos acostumbrados a transformar modelos en diseños. Formalicemos o no el modelo en un documento, cuando nos describen un problema, inmediatamente nos ponemos a pensar solución en código. Es nuestra forma de razonar. No podemos evitarlo. 

Una de los aprendizajes más difíciles e importantes para un técnico es oponerse a este instinto. Cuando estamos construyendo el modelo debemos evitar contaminarlo con detalles de diseño para que sea útil como herramienta de comunicación con negocio. Pero esto no significa que el modelo esté aislado del diseño. No es una entidad abstracta que esté por encima y domine al diseño. Todo lo contrario, el modelo debe ser realista e implementable. 

Es totalmente normal y esperable que, como consecuencia de su trabajo,  el equipo de desarrollo encuentre problemas en el modelo. Estos problemas pueden tener su origen en la implementación o errores en el modelado del dominio puestos de manifiesto en la práctica. Sea cual sea el caso, los cambios en el modelo se evalúan con negocio (Product Owner, Business Analyst) para garantizar su consistencia.

Este proceso de realimentación mejora el modelo y, sobre todo, proporciona transparencia a negocio sobre su implementación. El conocimiento de la realidad del código por parte de negocio les permite comprender las limitaciones de la solución. Este conocimiento “técnico” es tan importante para la evolución de la aplicación como el conocimiento del equipo de desarrollo sobre el dominio del negocio. Y, de nuevo, el modelo va a jugar un papel central en este intercambio de información.  

Formalización del Diseño

El diseño es propiedad del equipo de desarrollo y ellos deciden la mejor forma de reflejarlo. En  muchas ocasiones no es necesario un documento formal. La documentación de diseño es muy costosa de mantener. Tan pronto como pongo el punto y final en un documento de diseño, queda desactualizado. Las dudas sobre la veracidad de esta documentación nos lleva continuamente a acudir a los artefactos de implementación como origen inequívoco de la verdad del sistema. En muchas ocasiones, el esfuerzo no compensa y es mejor prescindir de documentación e ir directamente a la fuente. Somos técnicos, sabemos leer el código. 

Como te comentaba en la serie de entradas sobre diagnóstico de arquitectura , la documentación formalizada de diseño es útil para proporcionar una visión rápida y general sobre la solución. En caso de necesitarla, la documentación debe limitarse a los elementos más estables. Es decir,  los más difíciles de modificar.  

El  nivel de arquitectura (servicios, orquestación, despliegue y componentes) es muy costoso de refactorizar, por lo que suele ser bastante estable. Otro caso son las clases o funciones centrales en la red de dependencias. Son aquellas que reciben más dependencias entrantes y, por lo tanto, son más significativas para la aplicación. Son difíciles de modificar porque tienen un enorme impacto colateral. Ambas vistas del sistema son muy relevantes para su mantenimiento por lo que suelen estar en la documentación formalizada de diseño. 

Patrones DDD como piezas de diseño. 

DDD propone una serie de patrones bien conocidos para mapear el modelo en el diseño. Por ejemplo: Value Objects, Entities, Factories, etc. En general, las indicaciones sobre su aplicación son muy razonables y se corresponden con el uso conocido de estos patrones. Sin embargo, el catálogo de patrones me resulta un poco reducido y de alto nivel de abstracción. Para algunos casos de uso, hemos recurrido a patrones más especializados como: builder, command, interactors o presenter. 

En general, respecto a arquitectura y patrones, somos más de Robert C Martin que de Eric Evans. Particularmente, el modelo de capas en forma de cebolla que propone Uncle Bob, me resulta más natural. Con el dominio en el centro y diana de las dependencias del sistema, frente al apilado de capas sugerido en DDD.  En cualquier caso, hay una correspondencia clara entre los niveles de abstracción de uno y otro, por lo que no son incompatibles. En la siguiente figura tienes los niveles identificados en Clean Architecture (rojo) y las correspondencias en DDD (azul)

Relación entre capas descritas por Eric Evans en DDD y Robert C Martin en Clean Architecture

Tecnologías de Desarrollo

Como describo en el artículo sobre arquitecturas emergentes, debemos centrarnos en lo realmente importante, el dominio, y aplazar  al Last Responsible Moment la elección de herramientas concretas como frameworks y middleware.

Me gusta emplear una estrategia oportunista, recurriendo a las herramientas que mejor se adaptan al caso de uso. Pero, como todos, en JPA tenemos preferencias por las tecnologías que dominamos y con las que nos sentimos más cómodos. Algunos ejemplos son el paradigma orientado a objetos y los lenguajes con validación estática de tipos. 

Paradigma OO

La programación Orientada a Objetos es una forma natural y directa de implementar la mayoría de los modelos. De los atributos de la programación orientada a objetos: abstracción, polimorfismo, herencia y encapsulamiento; es ésta última la que más me gusta y la que, por tanto, echo más en falta cuando trabajo con otros tecnologías que no le dan soporte directo (como Javascript o Python). Ocultar elementos de la implementación nos hace posible exponer una interfaz clara para dependencias y es la mejor forma de limitar el impacto de los refactoring. 

Paradigma Funcional

El  funcional se aplica muy bien en las partes del modelo que tienen una naturaleza claramente matemática. Para eso se creó. En nuestra herramienta Metrics, toda la base de cálculo se ha implementado empleando patrones funcionales:  funciones de alto nivel, inmutabilidad y librerías de colecciones. 

Validación estática de tipos. 

Los lenguajes con validación estática de tipos me resultan más cómodos para desarrollar lógica compleja. Anticipar la detección de errores al tiempo de compilación me da mayor seguridad sobre la robustez del resultado. La estrategia Shift-Left DevOps dirige nuestras prácticas. Qué puede anticipar más los chequeos, a que sea el propio IDE quien me corrige errores mientras tecleo.  

Por otro lado, tengo menos memoria que Dory. Ir tecleando y que el IDE me sugiera los métodos de una clase o me autocomplete, me da la vida. 

Por último, los patrones de refactoring están mejor soportados en este tipo de lenguajes. Si habéis sufrido el refactoring en Javascript, os sugiero probar a disfrutar de la misma experiencia con Java. 

Conclusiones

Con este artículo completo mi primera entrada sobre la aplicación de Domain Driven Design en el equipo de desarrollo de JPA. Os he contado algunas prácticas y herramientas que empleamos en JPA para realizar la transformación del modelo al diseño y su implementación. 

No cierro el tema, todo lo contrario. Me encanta debatir sobre tecnología. Pon tus comentarios o escríbeme y encontremos juntos mejores soluciones. 

DevOps es ante todo Cultura, nipollas*

* ‘,nipollas’. Operador granaino unitario post-fijo de negación;  x,nipollas == !x. Ej. si,nipollas == no

Estoy harto de encontrarme con publicaciones en las que se prioriza, por encima de cualquier otro factor, el cambio cultural como elemento fundamental de la transformación DevOps. Esta idea se ha convertido en omnipresente. Te pongo un par de ejemplos: 

  • “La adopción de DevOps es un factor al 80% cultural, de esta forma, la cultura debería ser siempre tratada primero”. CloudOps
  • “DevOps es una filosofía […] que prioriza personas sobre procesos y procesos sobre herramientas”. Emily Freeman
  • “DevOps es cultura, […] cualquiera que te diga otra cosa te está vendiendo algo”. Bridget Kromhout 

Alguien que se aproxima al movimiento DevOps por primera vez tiene la impresión de que es una iniciativa diseñada por el ingenio de Agile Coaches, Change Managers y otros facilitadores de similar calaña. Y NO es así.

 ¿Cómo hemos llegado a este estado de cosas?

Quizás porque los técnicos están tan ocupados en crear soluciones que no tienen tiempo de publicar… No, en serio, dejo mi indignación aparte y me centro. 

DevOps es hijo de su tiempo. Surgió hace diez años porque el contexto lo hizo posible. Por un lado, se sube a los hombros de dos modelos de desarrollo consolidados: Agile y Lean Development.  Por otro lado, es posible gracias a la consolidación de las tecnologías que hacen posible las prácticas de Continuous Delivery: Cloud y Automation.

La comunidad Agile es muy prolífica en la creación de contenidos. Y se  ha centrado, casi en exclusiva, en los aspectos organizativos y culturales. En parte se debe a una aplicación, a modo de mandamiento, del primer principio agile:  “Personas e Iteraciones sobre procesos y herramientas”. En parte, por falta de interés en la tecnología, que lleva a algunos agilitas a desentenderse de la realidad del trabajo diario en desarrollo y operaciones. 

Ejecutivo meditando

Lamentablemente, no me son extraños los mensajes en los que no se considera o se menosprecia la base tecnológica. A lo largo de mi carrera profesional, demasiado frecuentemente me he encontrado con el mantra de “nos centramos en el negocio, la tecnología es lo de menos”. No puedo evitar esbozar una sonrisa cuando ejecutivos y managers se llenan la boca con la “Transformación Digital”. Queremos mejorar la competitividad de la empresa empleado tecnologías punta como IoT, blockchain o  big data. Pero esto, solo es posible contando con un equipo técnico con un alto grado de conocimiento práctico en el uso de las herramientas que las sustentan. 

DevOps son Prácticas y Herramientas. 

DevOps va de incrementar la productividad del equipo IT aumentando la velocidad de despliegue sin sacrificar la calidad de las operaciones. Evidentemente, que la organización tenga una cultura generativa, facilita este objetivo. De la misma forma  que facilita la producción de la chirimoya salvaje. Pero, cuando hablamos de desarrollo y operaciones de software, la eficiencia solo es posible contando con la maestría en el uso de herramientas y prácticas como: arquitecturas desacoplados, gestión de la configuración, continuous delivery o monitorización. Señ[email protected], esto no se puede hacer solo con buenas intenciones y post-it.

Herramientas
Imagen de Barns en Unsplash.

Hablemos de gestionar la transformación DevOps. Buscamos eliminar los bloqueos característicos de las transferencias de responsabilidad. Para eso, es imprescindible romper con los nichos de conocimiento. Y, la forma en la que los profesionales de IT intercambian conocimiento es formalizado en herramientas y artefactos. Un desarrollador será autónomo en la configuración de sistemas, cuando haya practicado en pairing con su compañero de operaciones, disponga de los playbooks de Ansible en el repositorio centralizado Git y pueda lanzar en Jenkins los test automáticos de integración sobre un entorno aprovisionado a demanda con Vagrant. 

Pero es más. Los técnicos vemos la realidad a través de las herramientas que utilizamos (si, somos así de simples). He perdido la cuenta de las ocasiones en las que una nueva herramienta me ha facilitado entender una forma distinta de realizar mi trabajo, ha cambiado mis prácticas y, finalmente, ha impactado en mi entorno cultural. Sin contarte la mili: SCM, IoC, SOA, Test automáticos, motores de integración, cloud, contenedores, orquestación,  … 

Si, DevOps es también cultura. 

No voy a negar la importancia de la cultura en el entorno de trabajo. Para mi, cultura y organización son sinónimos. Como parte de mi trabajo, en muchas ocasiones he presentado la compañía a nuevos compañeros. Y, lo que les he contado son los valores y objetivos, las prácticas y las reglas tácitas. Es decir, les he descrito la cultura de mi organización.  

Una cultura generativa es fundamental en una industria, como la nuestra, que vive del talento. Pero la cultura es un concepto principalmente abstracto sobre el que es muy difícil de actuar de forma directa. En su lugar, podemos cambiar nuestra forma de trabajar y que el día a día imponga una forma distinta de hacer las cosas. El cambio debe estar permitido por el nivel ejecutivo y facilitado por managers y agilitas. Pero se producirá, de abajo hacia arriba, desde los técnicos.

“No puedes cambiar la cultura actuando directamente sobre ella, pero puedes cambiar las prácticas y éstas se convierten en cultura” – Lloyd Taylor

Y a las pruebas me remito. La señora Nicole Forsgren en su trabajo Accelerate (faro del movimiento DevOps), identifica científicamente las relaciones causa-efecto que empujan la transformación DevOps. Y lo que encuentra, es una relación de predictibilidad entre la aplicación de prácticas DevOps y la cultura de la organización (no al revés).

Bueno, al final, me quedo con los dos. 

Si piensas que no tengo criterio, estás en lo cierto. Estoy convencido las herramientas y prácticas DevOps son fundamentales para el cambio cultural. Pero este, a su vez, es necesario para consolidar y escalar a toda organización. Ambos factores, correctamente cuidados por técnicos y agilistas, se realimentan en un bucle positivo que es el auténtico motor del cambio DevOps.  

Motor DevOps

 

Imágenes de: Aaron Blanco, Icon8 y Burns todos en unsplash.com

La convergencia de DevOps y Scrum

DevOps es un área de mi interés desde hace varios años. En Diciembre de 2014, en la CAS de Barcelona, di una charla en Inglés sobre la experiencia haciendo que DevOps fuera uno de los pilares de la agilidad en la DVLA -Una suerte de DGT británica-. Hace un año y medio también publiqué un artículo introductor al tema de DevOps y Scrum.

Tres años después, veo que DevOps y su convergencia con Scrum sigue sin arrancar. Me encuentro con profesionales de ambas áreas que en lugar de colaborar, tienden a ensanchar aún más sus diferencias. Los motivos que encuentro son: Resentimiento de la comunidad técnica hacia el éxito de Agile y Scrum, Incapacidad para entender que operaciones forma parte del proceso de desarrollo y un conflicto personas vs procesos.

Resentimiento en la comunidad de operaciones hacia el éxito de Agile y Scrum

A pesar de que ahora pensemos que hemos reinventado todo, la comunidad de operaciones lleva muchos años manteniendo a raya los sistemas críticos de organizaciones grandes y pequeñas.

Se trata de profesionales muy especializados que han visto como el número de Agile Coaches, unos mejores y muchos peores, de pronto cobraba un protagonismo muy importante en las organizaciones que se habían encargado de mantener. Una pena. Y una fuente de frustración

Eso ha hecho que se crearan castas dentro de las propias organizaciones. Desarrollo tiene un papel muy importante mientras que operaciones siguen siendo los tipos del sótano que se encargan de seguir las instrucciones que mandan los de arriba. En ocasiones bajo las mismas restricciones presupuestarias.

Todo esto, unido a la baja calidad de muchos profesionales de Agile, muchos de los cuales no sólo carecen de conocimientos técnicos sino que los minusvaloran, ha creado una brecha todavía más grande entre las dos comunidades profesionales, haciendo que DevOps fuera casi un enemigo para Scrum. Y viceversa.

Incapacidad para entender que operaciones forma parte del proceso de desarrollo

Sorprendentemente, sigue existiendo una incapacidad para querer entender que en el ciclo de vida del desarrollo de Software, la programación pura y dura no suele suponer más de un 12% o un 15% del mismo. Ese software debe de ser diseñado, mantenido y puesto en producción, y a pesar de eso seguimos empeñados en que lo importante es programar, no tener productos terminados y usables por parte del cliente.

Cuando trabajamos usando Scrum, el objetivo no es el proceso, es el producto terminado. Los Sprint Reviews no son compuertas a la siguiente fase -operaciones-, sino que son herramientas para inspeccionar y adaptar nuestra táctica en función de la estrategia. Operaciones debe ser parte del Sprint y de los equipos Scrum. Dependiendo del contexto, puede que trabajen permanentemente dentro de un equipo o que vayan haciendo de consultores que están completamente disponibles para los equipos.

Conflicto personas vs procesos

Mientras que la tendencia en la comunidad ágil es hacia las personas, en la comunidad de operaciones es más hacia los procesos. Esta dicotomía es sólamente resultado de las diferencias que existen en el trabajo de ambas áreas. Mientras el trabajo en desarrollo esta más orientado a descubrir, el trabajo de operaciones está más orientado a ejecutar. Permíteme explicar eso. El desarrollo de Software es complejo, y continuamente tenemos que descubrir soluciones a problemas que no habíamos previsto. El trabajo de operaciones se enfoca en optimizar todo el proceso de puesta en producción y mantenimiento de ese software en producción. Mientras que la variabilidad es inherente al desarrollo y podemos obtener beneficios de la misma (por ejemplo, cuando descubrimos que optando por una librería en lugar de un diseño ad-hoc ganamos en rendimiento y mantenibilidad), la variabilidad es algo a evitar en operaciones. Hay que estandarizar el proceso.

Si además le unimos la baja calidad de algunos profesionales en Agile, eso provoca una desconexión total entre desarrollo y operaciones. DevOps tiene que orientarse a converger con Scrum, y es donde mejor resultado obtienen ámbos.

No todos los sabores funcionan en todas las organizaciones

¿Como resolvemos estos problemas? En primer lugar, adoptando una mentalidad crítica hacia Scrum y DevOps y luego entendiendo el contexto de la organización. No podemos cambiar organizaciones a martillazos, diciéndoles que lo que tienen que hacer es sustituir a todo su equipo de operaciones y dejar ese trabajo a los equipos de desarrollo. No es viable. No es una solución.

En lugar de eso, hay que intentar introducir una cultura que cierre las brechas que se explican más arriba para posteriormente ir mejorando nuestra capacidad de automatización. Un gran banco no puede, de la noche a la mañana, automatizarlo todo. Y es que eso no es DevOps. Es NoOps.

NoOps puede funcionar perfectamente en una pequeña startup, pero en el momento que hay que cumplir requisitos regulatorios, de negocio, seguridad, no es tan fácil automatizarlo todo. El reto está en volver a los orígenes, a la Agile Infraestructure que asentó las raíces de DevOps en sus comienzos. Muchos profesionales de operaciones insisten en que DevOps es automatización, cuando no lo es. Es mucho más.

Si quieres leer más sobre la convergencia de DevOps y Scrum, te recomiendo que eches un vistazo al whitepaper que hemos publicado conjuntamente con el DevOps Institute en Scrum.org

Devops con Scrum ¿Merece la pena?

Durante los últimos cinco años, cada vez son más los que han ido apostando por acercar el desarrollo y las operaciones de IT, aunque sigue siendo una asignatura pendiente en las grandes organizaciones. Cuando hacemos Scrum, ¿merece la pena DevOps?

En primer lugar, ¿Qué es DevOps?

DevOps es un movimiento. Una cultura. No es una metodología o una herramienta específica. Para entender el movimiento DevOps, hay que remontarse a cómo se han hecho las cosas en el mundo del desarrollo de Software.

Hace muchos años, había una clara división entre aquellos que desarrollaban software y aquellos que se encargaban de poner el software en producción y mantenerlo. Además, existía un tercer sector: calidad -aquellos que se aseguran de que el software cumple con lo que se espera-.

La división venía de la cultura de producción industrial. Al fin y al cabo, en España, informática es una ingeniería y se enseña siguiendo los mismos modelos que se siguen en ingenierías clásicas. Además, esto permitía que no todo el poder recayera en un sólo grupo que pudiera secuestrar todo el proceso en una organización. Las metodologías en cascada contribuyeron a este proceso dividido.

Al fin y al cabo, tiene todo el sentido del mundo. Primero diseño lo que voy a hacer, luego lo planifico, lo desarrollo, lo pruebo y lo pongo en producción. El problema es que hacer software tiene una ligera diferencia con hacer cacerolas en una fábrica. Mientras que cuando hacemos producción industrial siempre producimos lo mismo y podemos optimizar procesos, cuando hacemos software siempre hacemos algo distinto y además no tenemos muy claro lo que queremos conseguir.

Las cosas cambiaron. Nuevos métodos como XP, Crystal y Scrum irrumpen en el mercado. Hay un manifiesto ágil que no hace sino reconocer la complejidad del desarrollo de software y que el proceso en cascada directamente no es válido por su diseño.

DevOps es un movimiento que irrumpe en los últimos años, promoviendo que el desarrollo de software se haga orientado a operaciones, y que los ingenieros que trabajan en uno y otro colaboren para facilitar la puesta del software en producción.

DevOps y Scrum, el matrimonio perfecto

El objetivo de un equipo Scrum es entregar un incremento de producto terminado al final de cada Sprint. La única manera de conseguirlo es mediante la integración de negocio, desarrollo, calidad y operaciones en un mismo grupo, en equipos pequeños, autoorganizados.

Este modelo de organización es el que resulta muy difícil de aceptar para organizaciones que se han construido a sí mismas en torno a pequeños reinos de taifas donde el poder es lo más importante. El poder se mide en dos variables: gente a tu cargo y presupuesto que manejas.

Cuando una organización grande plantea modelos de trabajo más o menos ágiles, se enfrenta a la disyuntiva. No se puede ser ágil si tu organización obliga a unos procesos lentos y pesados por diseño. No solamente DevOps y Scrum son el matrimonio perfecto, sino que además no queda otra manera de hacerlo.

Igual alguna vez has escuchado la frase: Nadie ha sido nunca despedido por contratar a IBM. Esta frase implica mucho más en la cultura de desarrollo de productos y proyectos de lo que pueda parecer en principio. Las consultoras han sido las más interesadas en que movimientos como DevOps o Scrum no salgan adelante. En el caso del primero porque Operaciones era muy importante para dejarlo a cargo de una máquina. En el segundo porque Scrum no es potente para abordar proyectos complejos. Eso, unido a una ignorancia de como funcionan los ciclos de vida de desarrollo de software en los altos niveles, ha llevado a una pérdida de ventajas competitivas para las organizaciones.

¿Y que beneficios me aporta DevOps?

En el informe de Puppet Labs de 2016 “The state of DevOps report” hay algunos datos interesantes. Las organizaciones que incorporan DevOps:

  • Despliegan 200 veces más frecuentemente que las que menos
  • Tienen unos tiempos de entregan 2,555 más rápidos
  • Tiempos de recuperación 24 veces mejores y 3 veces menos errores provocados por cambios
  • Los equipos IT de alto rendimiento pasan un 50% de tiempo menos resolviendo incidencias de seguridad
  • Y un 22% menos de tiempo resolviendo errores y problemas.

Este es el link para descargar el informe completo.

The Phoenix Project

the phoenix projectSi tienes interés en leer más sobre DevOps y además pasar un rato muy entretenido leyendo una novela excelentemente escrita sobre un proyecto IT, te recomiendo que compres “The Phoenix Project”. A través de la visión de un gerente de operaciones, describe cuales son los puntos de fricción más importantes en su compañía y cuales han sido los pasos que le han llevado a implementar DevOps con éxito.

Comprar The Phoenix Project en Amazon

Promoviendo la agilidad en la administración a través de DevOps

En Diciembre de 2014 imparti una de las charlas de la Conferencia Agile Spain titulada: Promoting agility in Civil Service trough DevOps, donde hablo de la estrategia que el GDS y el Gobierno de UK han seguido para promover proyectos ágiles dentro de la administración. Arriba, el video completo de la charla.

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad