• Ir a navegación principal
  • Ir al contenido principal
  • Ir a la barra lateral primaria
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Academy
  • 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
    • Nosotros
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

Blog

Scrum y la Business Agility

Muchas veces se tienen dudas como “Y en Scrum se puede…”, “¿y puedo hacer…?”, “¿y se puede…?”. Parece que Scrum es como un conjuro mágico en el que si solo cambias algunas cositas podría seguir funcionando. Y si en vez de ancas de rana pongo ojos de sapo, ¿funcionará? Scrum está lejos de ser una fórmula mágica que soluciona todos nuestros males. Veamos cómo la Business Agility o Agilidad Empresarial puede ayudarnos con estas cuestiones

¿Qué es la Agilidad Empresarial o Business Agility?

El problema real que encierra esta pregunta es que estamos asumiendo que Scrum es un fin. “¿Se puede hacer esto o lo otro y sigue siendo Scrum?”. Cuando a nadie le debería importar si es Scrum o no. 

El día que un CEO toma la decisión de reservar una buena parte del presupuesto de los siguientes años para comenzar una transformación, no está buscando que los equipos estén haciendo Scrum, Kanban, Product Owners empoderados o equipos auto-organizados. 

Nuestro CEO está buscando la supervivencia de su empresa ganando competitividad e intentando poder luchar de tú a tú algún día con las nativas digitales. Busca alcanzar la Agilidad Empresarial o “Business Agility”:

  • Capacidad de poner en valor rápidamente nuestro desarrollo (fast revenue)
  • Alta gestión de riesgos
  • Poder aprovechar las oportunidades de mercado

Scrum es una herramienta para activar Business Agility en las organizaciones. Lo hace creando al menos un incremento terminado, potencialmente usable, un incremento Done en cada Sprint. De esto va Scrum. No es un fin, es un medio.

Scrum no va de daily, retrospectivas bailando o similares. Va de entregar valor. Scrum nos proporciona elementos: artefactos, eventos y roles, que nos brindan una alta capacidad de inspección, adaptación y transparencia. Los pilares del empirismo. Son las armas que necesitamos para crear incrementos de alto valor y maximizar nuestra capacidad de generar ingresos.

¿Como nos habilita el Incremento “Done” la Agilidad empresarial?

Fast revenue

Los desarrollos de productos se siguen enfocando a proyecto. Primero obtenemos todos los requisitos, creamos un plan para los siguientes meses (o años) y, al final del todo, me voy al mercado a intentar monetizar.

Con el enfoque iterativo incremental que nos propone Scrum y teniendo incrementos terminados, integrados y listos para usarse en cada Sprint, podré ir buscando una version de mi producto que me permita llegar al mercado e ir generando beneficios.

Un ejemplo es el lanzamiento de Amazon Prime Videos. Con poco catalogo, sin soporte para Chromecast o sin aplicaciones nativas para tablets y teléfonos comenzó a poner en valor su nuevo producto lo antes posible.

Alta gestión de riesgos

Podemos hablar de tres grandes riesgos y la manera que tiene Scrum de gestionarlos es resolverlos.

  • Riesgo de mercado: ¿Estoy creando lo que mis usuarios realmente necesitan? Scrum va de crear un incremento y conseguir feedback real para adaptar mis siguientes pasos si es necesario.
  • Riesgo financiero: ¿Esto cuánto me va a costar? Por mucha documentación y planes que hagamos ya sabemos que siempre habrá variables que no conozcamos. E incluso las variables que conocemos tienen baja predictibilidad. La única manera de conocer el coste es realmente empezar a hacerlo y luego intentar obtener predictibilidad basada en datos históricos.
  • Riesgo técnico: ¿Mi idea se puede realizar con las tecnologías que actualmente estoy usando? Una vez más, la única manera de saberlo es empezar a hacerlo e ir obteniendo una nueva versión de mi producto Sprint a Sprint.

Capacidad de aprovechar oportunidades del mercado

Si tienes previsto un desarrollo de más de un año y una oportunidad de mercado llega cuando estás en el sexto mes de trabajo con todo abierto, nada integrado, en definitiva, nada terminado. O Incluso si simplemente has estado documentado lo que vas a hacer los siguientes meses, sumarte a esta nueva ola conlleva muchísimo esfuerzo. Tanto que generalmente se decide dejar pasar o esperar a terminar todo el desarrollo disminuyendo drásticamente tu capacidad de competir. 

Conclusion

Una vez que tenemos claro qué Scrum es un medio para hacer crecer Business Agility en nuestra organización, será fácil respondernos a preguntas “¿en Scrum se puede…?”. Simplemente debemos pensar si al introducir un cambio estoy aumentando o disminuyendo mi Agilidad Empresarial.

¿En Scrum se puede tener dos sprints de desarrollo y luego otro de hardening?

Cuando terminen los sprints de desarrollo:

  • Si viene una oportunidad de mercado…
    • ¿Podré sumarme a ella? No.
    • ¿Alguien me puede asegurar cuándo podré hacerlo? No. Nadie puede asegurar que el hardening vaya a tomar solo un sprint o dos.
  • ¿Puedo poner en el mercado lo que tengo al final del Sprint de desarrollo? No. Adiós al fast revenue.
  • ¿Estamos tomando decisiones del futuro de nuestro producto basándonos en feedback real? No. No lo hemos podido poner en producción por lo que no tenemos ninguna métrica de negocio real. Al no estar nada terminado no tenemos transparencia de la situación del producto, esto nos llevará a discusiones sin fundamento con los Stakeholders en la Sprint Review eliminando nuestra capacidad de adaptación al mercado.

¿En Scrum se puede hacer la Daily Scrum 2 veces por semana?

La Daily Scrum nos permite inspeccionar el avance de nuestro Sprint para alcanzar la Sprint Goal con nuestro Incremento. El Sprint Goal puede representar una hipótesis sobre nuestro producto que negocio quiere comprobar si realmente es lo que quieren los usuarios y si nos va a otorgar el beneficio esperado. Por ejemplo, que mis usuarios van a querer pagar con Paypal. 

La Daily Scrum es una manera de maximizar las posibilidades de que el equipo de desarrollo tenga terminado todo el trabajo relacionado con la Sprint Goal a final del Sprint. Eliminando algunas daily,

¿estoy ayudando a mi Agilidad Empresarial o poniéndola en riesgo?

El estado de Agile en 2020

Hace más de 10 años estuve trabajando en un proyecto financiado con fondos europeos llamado Tratamiento 2.0. El objetivo era definir un marco para la obtención de información para la toma de decisiones médicas y la verificación automatizada de estas decisiones.

Me llevó unas cinco semanas definir ese marco teórico utilizando una metodología desarrollada por la Universidad de Amsterdam y hacerla cumplir con lo que se buscaba, que era una especie de UML para las decisiones médicas.

Ese proyecto se enmarcaba dentro de lo que posteriormente sería Horizonte 2020, un programa de la Unión Europea para el desarrollo de actividades de investigación científico-técnicas. Lamentablemente, mi trabajo nunca llegó a usarse.

Por aquel entonces 2020 era una quimera. Un puerto gris. Algo que quedaba lejano en el tiempo. Y sin embargo, hemos llegado.

La transformación del sector

Durante estos últimos años, el sector de la tecnología en España ha cambiado radicalmente.

Aunque quizás parezca lejano, hasta bien entrado el 2016 seguía existiendo un techo de cristal para las carreras técnicas (Programadores, Arquitectos de Software) que requería pasar a un puesto de gestión para poder ver incrementado tu salario.

En 2013 me mudé a Londres y apliqué a 20 ofertas para desarrollador un Lunes por la noche. Al día siguiente tenía 15 llamadas perdidas y mensajes en el buzón de voz. Contrastaba con la sequía de interés por parte de las empresas en España. En las consultoras andaluzas, el sueldo era de 850€ netos.

Fue una de las primeras cosas que me sorprendió cuando me fui de España en los peores años de la crisis.

Por otro lado, encontrar compañeros de 50 años que arrastraban una carrera técnica sin intención de cambiar, porque sus expectativas estaban más que satisfechas. 

Al principio se me hizo extraño. Nunca había trabajado en equipos técnicos con gente que estaba más cerca de la jubilación que del comienzo de su carrera profesional. Fue interesante descubrir como la madurez personal puede aportar mucho más que los conocimientos técnicos a los proyectos de Software.

Durante ese tiempo tuve la oportunidad de conocer en profundidad proyectos como el del Government Digital Services del gobierno británico, en el que introdujimos principios DevOps para garantizar la calidad de la arquitectura, la testeabilidad y reducir los ciclos de vida del desarrollo y la producción. Hablé de ello en la Conferencia Agile Spain de 2014.

El concepto de transformación digital también llegó tarde a España. Trabajando en la transformación digital de CapOne UK en 2014, vine unos días a España y descubrí a través de una búsqueda rápida en Google que nadie hablaba del tema. Fue BBVA en 2015 la que se embarcó en un proyecto de transformación que todavía dura.

En 2017, los recruiters invadieron el mercado después de haber pasado por Centroeuropa. Se destapó el pastel. A pesar del esfuerzo de muchas empresas para mantener unos salarios contenidos, se hizo patente que no había tanto talento técnico como demanda.

Durante esta década han surgido multitud de pequeñas compañías que se han especializado en el apoyo a determinados aspecto del proceso de transformación. También las grandes se han lanzado con los dos pies a intentar llevarse un trozo del pastel.

Los casos de éxito y de fracaso

Hay pocos casos de éxito a gran escala pero multitud de ellos a pequeña escala. De hecho, hay muchas startups y pequeñas compañías que no existirían de no llevar la Agilidad de Negocio en su ADN.

El motivo para que las grandes todavía no puedan presumir de casos de éxito rotundo es sencillo. La cultura de una compañía de décadas y decenas de miles de empleados no se puede cambiar en uno, dos o cinco años. Probablemente requiere jubilar a una generación de personas para dejar paso a las nuevas ideas.

Muchas personas siguen viendo Agile como algo perteneciente a tecnología. Y a tecnología como algo separado del negocio. Incluso peor: Abrazan Agile como un fin en si mismo cuando en realidad es un medio para conseguir un fin. Organizaciones más competitivas, innovadoras y aptas para sobrevivir.

Por supuesto, el crecimiento de la demanda de Scrum Masters, Product Owners y Agile Coaches no ha hecho sino atraer personas externas al sector que han buscado la mejor manera de incorporarse a puestos bien pagados en compañías que se preocupan de sus empleados. Tardará un tiempo y llevará una criba, pero muchos de ellos han llegado para quedarse.

Tal y como dice un buen amigo y conocida figura del desarrollo de Software: «¿Y cual es el problema? Yo empecé a hacer Software en el 2000 tras pasar un curso de tres semanas en una desaparecida consultora después de suspender las oposiciones a profesor de filosofía»

Conforme arrancamos 2020, Agile no es una palabra desconocida para la mayoría de las organizaciones. Quizás no todos entienden de la misma manera lo que es, pero ya no es desconocido.

Agile no es un puerto gris. Es un puerto que hace tiempo superamos.

Ahora el trabajo es más difícil, ya que supone ir alineando, descubriendo y acompañando organizaciones en descubrir como usar esa amalgama de cosas inconexas para obtener un resultado tangible en su cuenta de resultados.

Hace cuatro años publiqué un artículo en LinkedIn que tuvo cierto éxito: 9 Easy Mistakes to Avoid during your Agile Journey. Uno de los puntos a evitar era «No despedir gente«, en el que hacía una clasificación rápida del tipo de reacciones que la gente tiene ante estos procesos de cambio: Aceptarlas, Irse o lucharlas desde una falsa aparicencia de aceptación.

El problema son los terceros. Tienen una evidente falta de Skin in the game, cuidan mucho su exposición pública, no ponen su nombre junto a lo que dicen y utilizan a otros para sus fines publicitarios.

En el libro Skin in the Game, Nassim Nicholas Taleb explora las asimetrías cotidianas en las que no nos fijamos en lo que la gente dice, sino en como se están arriesgando para defender desde El Mundo Real™ esas ideas.

Los falsos ídolos

No quiero terminar de escribir este artículo sin hablar de las certificaciones: los falsos ídolos.

Al parecer, existe una creencia generalizada en el mercado Agile que las certificaciones son una especie de sistema mágico que te habilita para hacer cualquier tipo de transformación mágicamente.

No lo son.

Las validaciones profesionales existen desde hace muchos siglos como complemento a una experiencia profesional que es insustituible. Habitualmente son una manera de establecer un reto claro en el objetivo es mejorar el conocimiento para luego llevarlo a una realidad. Proporcionan una base que permite comparar, aprender y descartar en función de una variable más. No la única.

Aquí hay dos falacias a explorar.

La primera es que hay grandes profesionales que no ostentan ninguna certificación. Sin embargo, no ostentarla no te hace por defecto un gran profesional.

La segunda es que sirven como muñeco de paja para golpear con el argumento de que sólo sirven para obtener un título y que la formación en torno a ellas es solamente una preparación -un peaje- para ganar más, aunque no tengas ni idea.

Es un problema de calidad de la fruta que compramos.

Hace un tiempo escribí sobre la teoría del mercado de los limones, una metáfora para ilustrar el problema que supone poner a competir un producto de buena calidad con uno de mala calidad. La solución en este entorno es disminuir la asimetría de la información -que el consumidor esté mejor informado- para hacer evidente la diferencia de calidad de los productos existentes en el mercado.

Estas falacias son fácilmente rebatibles.

Agile como moda

Para aquellos que piensen que esto es una moda, les recomiendo que hagan una comparativa de búsqueda entre Agile y Televisión 3D, para descubrir qué es una moda y qué es un movimiento que poco a poco está transformando el mundo.

Agile en 2020 está más vivo que nunca.

Hay muchos retos por delante: Profesionalizar cada vez más el sector, conseguir que los programadores dejen de estar enamorados de su código y empiecen a enamorarse del valor que su código crea y convencer a muchos responsables de toma de decisiones que las bolas mágicas están pasadas de moda.

Por supuesto hay quien seguirá vendiendo Scrum o Kanban como la solución mágica a los problemas de las organizaciones, pero no lo son. Aportan la estructura necesaria para poder afrontar esos problemas, pero no los resuelven.

Esto significa contar con gente técnicamente preparada y darles el espacio que necesitan para poder empezar a aportar, eliminando capas de gestión que están ahí para dar una falsa apariencia de control sobre el Caos.

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. 

Domain Driven Design o Dominio, Dominio y Dominio

Introducción

Domain Driven Design (DDD) es una práctica de desarrollo de software que pone el acento en el Dominio del Negocio como faro del proyecto y en su Modelo como herramienta de comunicación entre negocio y tecnología. En el equipo de desarrollo de JPA empleamos Domain Driven Design  como referencia para afrontar proyectos de desarrollo de cierta complejidad. Fruto de nuestros errores pero, sobre todo, de responder a las preguntas honestas de unos compañeros y los dardos envenenados de otros, hemos ido refinando su aplicación. En este artículo te presento algunas conclusiones y prácticas que pueden facilitarte la aproximación a sus principios. 

Lo más importante es el Dominio. 

Parece de perogrullo ¿Verdad? Como técnico, lo que primero llamó mi atención de DDD fue el conjunto de patrones de diseño recomendados para implementar el modelo: Value Object, Entity, Service, Factory, Repository, etc. Los patrones son herramientas con larga tradición y consolidados en la industria (GOF , Martin Fowler, Eric Freeman, etc). Esta experiencia previa  me llevó a pensar que eran, precisamente estos patrones, la mayor contribución de DDD. Y me equivocaba. 

Lo realmente relevante del DDD es la machacona insistencia en el Dominio como fuente de verdad para el desarrollo de software. Hay que volver a él siempre que pienses que te estás desviando del camino correcto. Por ejemplo, cuando no estés seguro del valor de la funcionalidad que estás desarrollando o cuando sospeches que estás matando moscas a cañonazos (overengineering). Hay que aprender a tener el dominio siempre visible y poner en duda el valor de todo lo que no quepa en él.

“Poner en duda todo desarrollo que no esté contemplado por el dominio es la principal lección de Domain Driven Design”

¿Cómo concretamos el Dominio?

Mediante su modelo.  El modelo es un conjunto de artefactos (diagramas, documentos, prototipos, etc. ) que contiene una representación significativa del Dominio. Es un paso intermedio entre el dominio del negocio y el diseño tecnológico. El valor del modelo es doble: 

  1. Es el glosario del  Lenguaje Ubicuo (“Ubiquitous Language”) . Debe ser comprensible y significativo para negocio y tecnología. Todos los miembros del equipo (incluido negocio) emplean los términos del modelo en sus comunicaciones: Historias de Usuario, Casos de Uso, Features, Tareas, etc. 
  2. Son los cimientos y el espejo del diseño de software.  El equipo de desarrollo emplea el modelo para crear un diseño que lo implementa. Pero además, mantendrá sincronizado diseño y modelo a lo largo de toda la vida del proyecto. Todo cambio en el diseño deba ser validado contra el modelo. Si como consecuencia del desarrollo se considera que el modelo debe ser ajustado, los cambios se revisan con negocio y se llevan al lenguaje ubicuo. 

El punto 2 es el que requiere un mayor esfuerzo de adaptación y concentración cuando nos introducimos en DDD. Mantener sincronizado modelo y diseño es costoso. Es precisamente este coste, el que te lleva a valorar con mucho más cuidad los cambios en el desarrollo. El temido efecto: “pues ya que estoy…”. Pesar la contribución de valor de un cambio frente a su coste se convierte en un ejercicio continuo. 

Elaboración del Modelo

En DDD el modelo nacerá y evolucionará mediante dos fuerzas: negocio y desarrollo. Ambos puntos de vista deben estar implicados en su creación desde el comienzo. El equipo de desarrollo debe apreciar el modelo como un producto más de su trabajo, comprender cómo le ayuda a crear mejores soluciones y sentirse tan orgulloso de la calidad del modelo como de la del código. 

Delegar la creación o el mantenimiento del modelo a un analista externo al equipo, simplemente, no funciona. El equipo debe estar implicado en el esfuerzo cognitivo de análisis y modelado del dominio, sin intermediarios. Es la única forma de mantener un proceso ágil y garantizar la implicación del equipo en su mantenimiento. 

Herramientas de Modelado

Ya soy un veterano de esta industria. He pasado por procesos pesados como RUP. donde se recurre sistemáticamente a artefactos de modelado para comunicar entre etapas. Cuando trabajé  como business analyst o como diseñador, empleé extensivamente UML y BPMN. Posteriormente, con todo el movimiento Agile y especialmente XP, evité estas herramientas bajo el principio de que el código debía ser autoexplicativo. Como siempre, en el equilibrio se encuentra la virtud.

Las herramientas de modelado (UML entre otras) son muy útiles en la construcción de un marco significativo para todos los actores. El código, es mucho más difícil de entender por negocio. Incluso empleando frameworks específicamente adaptados para hacerlos más expresivos, como Domain Specific Languages. 

El código puede ser suficiente para el diseño. La organización en módulos y componentes, una estrategia consistente de asignación de responsabilidades, así como unas prácticas de nombrado uniformes, deben hacer evidente el diseño. 

Puedes apoyarte en herramientas de análisis de código que tienen muchos IDEs para crear diagramas con las entidades y dependencias presentes en el software. Esto facilita la comprensión del diseño y su validación contra el modelo. Los diagramas de análisis tienen la ventaja de ser efímeros, los creamos y los desechamos sin excesivo coste, por lo que no tenemos que gestionarlos. La ausencia de un documento de diseño evita que reemplace a la verdad reflejada por el código. 

Ten cuidado con UML. Es una herramienta muy versátil que permite introducir aspectos de implementación. El Modelo NUNCA debe contener detalles como herencia, encapsulamiento o tipos concretos. Y no lo digo porque el modelo deba ser agnóstico respecto a la tecnología de implementación (raramente buscamos eso en un proyecto), sino porque pierde su papel como paso intermedio al diseño. Recuerda,  es una abstracción empleada para comunicar con negocio y para guiar el desarrollo. 

Es un auténtico sufrimiento estar continuamente evitando escribir detalles de diseño en el modelo. Pero este es precisamente el objetivo de DDD. Forzar el uso por todos los interlocutores de un nivel de abstracción compatible con el lenguaje ubicuo. 

Gestión del Modelo

He trabajado con compañeros que prefieren crear los modelos a mano (con rotulador). El principal argumento es que reflejan la naturaleza siempre cambiante del negocio en un artefacto que está siempre “en construcción”

A míi me resulta farragoso. Si empleamos una pizarra, se borra accidentalmente. Si empleamos papel, rápidamente se llena de tachones y estamos más tiempo pasando a limpio que creando. En ambos casos, la información es difícil de compartir. 

Yo prefiero un formato digital. He empleado herramientas especializadas como Visual Paradigm, o ArgoUML. Conozco todo lo que me aportan y también todo lo que me sobra. Por eso, en muchas ocasiones, prefiero emplear una herramienta más ligera, tipo diagramas. Draw.io me funciona bien para proyectos pequeños y medianos. No obstante, siempre estoy revisando las herramientas disponibles. Si estás usando alguna que te vaya bien, por favor, ponlo en los comentarios. 

Conclusión: Vigila el Modelo

Domain Driven Design es una técnica que implica dos transformaciones, del negocio al modelo y del modelo al software

El modelo juega un papel central para asegurar la correspondencia entre el software y el negocio al que debe representar. El modelo debe estar siempre presente en la mente, en los ordenadores y en las pizarras de los equipos multidisciplinares. Buscamos una mentalidad de “Policía del Modelo” que persiga cualquier desviación de la consistencia de esta correspondencia. 

Este es el primero de una serie sobre lo que hemos aprendido aplicando DDD en Jerónimo Palacios y Asociados. En el próximo, bajaré a la transformación del modelo en diseño. Algunas soluciones propuestas por DDD que hemos empleado y otras que no. 

Imagenes :

  • Matthew Henry on Unsplash
  • Etienne Girardet on Unsplash

Para saber más:

En nuestra formación DevOps profundizamos el papel de Domain Driven Design en la creación de soluciones desacopladas, fáciles de testar y de desplegar. Si te interesa saber más, rellena este formulario para que te podamos enviar información.

Facilitación Gráfica – Sprint

La semana pasada hablamos sobre los eventos que hay en Scrum. En este post vamos a tratar uno de ellos, el Sprint.

¿Qué es el Sprint?

Un Sprint se puede definir como un metaevento de Scrum, contenedor de los demás eventos de Scrum, que son la Sprint Planning, Daily Scrum, Sprint Review y Sprint Retrospective. Al final de este evento tendremos una entrega de incremento.

Características

  • Time box de un mes o menos

    Esto nos ayudará a inspeccionar y adaptar, haciendo que el riesgo sea menor y la complejidad sea menor.
  • No podrán realizarse cambios que pongan el peligro el Goal
  • Se podrá renegociar el alcance entre el Product Owner y el Developement Team
  • Un Sprint comenzará inmediatamente después de acabar el anterior.

Cancelar el Sprint

Esto se da en muy raras ocasiones y el Product Owner es la persona que podrá llevarlo a cabo. Cancelar un Sprint puede darse en el caso de que el Sprint Goal quede obsoleto.

Sprint
  • « Ir a la página anterior
  • Ir a la página 1
  • Ir a la página 2
  • Ir a la página 3
  • Ir a la página 4
  • Ir a la página 5
  • Páginas intermedias omitidas …
  • Ir a la página 41
  • Ir a la página siguiente »

Barra lateral primaria

Jeronimo Palacios & Associates

Somos una consultora boutique especializada en la creación y desarrollo de productos digitales con un enfasis en metodologías ágiles.

Búsqueda

Cursos oficiales certificados

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

Jeronimo Palacios & Associates

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

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