¿DDD es de derecha?

Nov 29 2022

"¡DDD es una cosa de derecha!" Detrás de esta provocativa declaración (ideal para lanzar una sesión unconf y tener gente), Simon Chaveneau quería preguntarse cuál sería el impacto del Domain Driven Design (DDD) en nuestra organización (Product-Tech) para producir software. Esto sucedió durante nuestra primera no conferencia en Agicap, organizada para permitir que la gente de Producto y la de Tecnología se reúnan para discutir, aprender, compartir, reír, pero sobre todo ganar altura en relación con nuestra vida cotidiana.

"¡DDD es una cosa de derecha!"

Detrás de esta provocativa declaración (ideal para lanzar una sesión unconf y tener gente), Simon Chaveneau quería preguntarse cuál sería el impacto del Domain Driven Design (DDD) en nuestra organización (Product-Tech) para producir software. Esto sucedió durante nuestra primera no conferencia en Agicap, organizada para permitir que la gente de Producto y la de Tecnología se reúnan para discutir, aprender, compartir, reír, pero sobre todo ganar altura en relación con nuestra vida cotidiana.

Nuestra primera desconferencia en Agicap, 13 de octubre de 2022

Durante una desconferencia, el programa lo establece la audiencia. Se realiza durante una sesión inicial de “Market Place” por la mañana. Durante esta primera sesión plenaria del día, todos y cada uno pueden tomar notas adhesivas, un marcador y luego presentar sus sesiones frente a todos. Luego la gente los posiciona en el programa del día (para más información sobre esta desconferencia, hay este hilo de twitter )

Pero volvamos al tema ya la intrigante sesión que propone Simon.

Versión francesa de “¡DDD es una cosa de derechas!”

¿El reino de la propiedad privada?

Para resumir el argumento inicial de Simon: si secciones enteras de nuestro IS pertenecen a equipos, cada uno responsable de uno o más contextos delimitados (BC), ¿no nos enfrentamos a una versión de software de propiedad privada (con alambre de púas alrededor de los BC, etc.) .)? De ahí su provocativo “¡ DDD es cosa de derechas! ”

Y con la pregunta subsidiaria: “¿No seríamos más eficientes con una organización basada en equipos de características? (con todos capaces de trabajar en todos los BC en el camino a sus casos de uso)”

Bueno… Debo admitir que esta sesión resultó ser mucho más fructífera de lo que inicialmente esperaba porque se produjo una discusión realmente fascinante sobre nuestro modo de organización Producto/Tecnología.

Pero más que detallar el camino recorrido por esta sesión en la que fuimos muy numerosos (seguramente interesante de describir en el contexto de otro post), describiré directamente lo que he retenido y pensado sobre el tema.

algunas observaciones

El software efectivo es software alineado con los desafíos del negocio . Por alineado, nos referimos a un software que toma prestados los términos correctos del campo del dominio, que articula correctamente los conceptos clave del negocio y evoca lo menos posible la complejidad accidental que traen los problemas técnicos. Este es uno de los principales desafíos del Diseño Dirigido por Dominio (DDD), como se explica aquí en 3 minutos .
La Ley de Conway no es una opción que uno pueda elegir no tomar. ‍♂️ Actúa un poco como ciertas leyes físicas, como la atracción de la gravedad. Podemos intentar luchar contra eso ;-) pero sigue siendo válido en la tierra. La Ley de Conway es esa ley de 1967 que establece que
“Cualquier organización que diseñe un sistema (definido ampliamente) producirá un diseño cuya estructura sea una copia de la estructura de comunicación de la organización”.
Dicho de otro modo, la arquitectura de un software es necesariamente el resultado de los modos de comunicación de las personas involucradas en su diseño. Por ejemplo, un compilador desarrollado por 3 equipos probablemente funcionará en 3 pases o tendrá 3 módulos distintos.
La maniobra inversa de Conway (ICM) le permite pensar que uno podría controlar la ley de Conway. Inicialmente, esta maniobra inversa recomendaba sabiamente “ romper los silos que restringen la capacidad del equipo para colaborar de manera efectiva”. Pero se ha transformado a lo largo de los años en una recomendación tonta: “ cambia tu organización para llegar a tu arquitectura objetivo ”. Tontería porque recuerda: “La cultura se come a la estrategia en el desayuno”. Más información aquí en ese interesante hilo.
El Diseño Impulsado por el Dominio no impone ninguna organización. Da claves para permitir la supervivencia, incluso en casos de organizaciones disfuncionales (con equipos que están en guerra o se ignoran). DDD nos ayuda a comprender los problemas de poder y los problemas sociales entre los equipos. Como resultado, es más bien una herramienta de liberación contra nuestros determinismos ( por lo tanto, una herramienta de izquierda diría yo ;-)
Por otro lado, DDD nos da herramientas para poder diseñar software eficiente y lo más alineado posible con respecto al dominio. Entre ellos el concepto de Bounded Context (BC), que nos propone diseñar modelos para usos, y rodearlos y protegerlos de confusiones/falsos amigos/malentendidos provenientes de otros contextos.
Para una mayor alineación y eficiencia, DDD también recomienda encarecidamente que desafiemos regularmente nuestra visión y nuestro modelo de la solución. También significa revolucionar y cambiar modelos de vez en cuando siguiendo un momento eureka (llamado Design Breakthrough ). Es por eso que regularmente tenemos sesiones de mapas de contexto aquí que refinan constantemente nuestra visión del campo con la gente del Producto.
Los equipos de desarrollo tienen equilibrios frágiles. Se necesitan aproximadamente 6 meses de convivencia y relaciones interpersonales para que un equipo de desarrollo sea realmente efectivo. Agrega o elimina a una sola persona de este equipo y ya no es el mismo equipo (consulte Reorganización dinámica del equipo ). En términos de eficiencia, prefiero equipos que permanecen juntos y cambian de tema, que equipos que simplemente se explotan/redistribuyen según los temas. Por supuesto, si alguien está harto de su equipo o de sus súbditos, se debe hacer todo lo posible para que pueda cambiar de equipo (estar bien personalmente es aún más importante para nuestra eficiencia colectiva)
Nuestra organización actual y nuestros equipos aquí en Agicap están más bien afiliados a uno o más contextos acotados para tener en cuenta la complejidad del problema y capitalizar al mínimo nuestra experiencia comercial respectiva. De vez en cuando, algunos equipos pueden tener un alcance demasiado grande y necesitamos cortar y asignar mejor nuestro contexto acotado. Por otro lado, esta división de BCs debe permanecer ligada a conceptos de negocio (recordar DDD)
Nada prohíbe tener equipos de características en una organización que hace DDD , siempre que todos respeten los límites de los contextos delimitados.
Por el momento, preferimos en gran medida la práctica de Swarming (una especie de grupo de trabajo creado con personas de varios equipos, pero donde la responsabilidad y la propiedad del artefacto final (herramienta, api, biblioteca) se definen desde el principio. Ayuda para evitar el síndrome de “Bueno, algo tenemos juntos, pero ¿¡¿quién lo va a mantener ahora?!?”). Más allá de su efectividad para lograr que las personas adecuadas colaboren según el tema, el swarming aporta mucho capital social a nuestra organización al promover temporalmente las relaciones interpersonales entre equipos (muy útil para el futuro cuando todos regresen a su equipo).
Nuestra organización de productos actual está configurada en 1 gerente de producto (PM) por equipo de desarrollo, pero tal vez sería interesante tener PM más asociados con temas comerciales que con su equipo.

Finalmente, diría que no hay más bala de plata en organización que la que tenemos en desarrollo. La retroalimentación continua, el cuestionamiento y la experimentación son nuestros compañeros en este camino de mejora continua para crear software que sea relevante para nuestros usuarios.