« DDD est un truc de droite !

Derrière ce propos provocateur (idéal pour pitcher une session unconf et avoir du monde), Simon Chaveneau a voulu se poser la question de l'impact du Domain Driven Design (DDD) sur notre organisation (Product-Tech) pour produire des logiciels. Cela s'est passé lors de notre première non conférence à l'Agicap, organisée pour permettre aux Product et aux Tech de se rencontrer pour discuter, apprendre, partager, rire, mais surtout prendre de la hauteur par rapport à notre quotidien.

Lors d'une contre-conférence, le programme est établi par le public. Elle se fait lors d'une première séance « Market Place » le matin. Lors de cette première plénière de la journée, chacun pourra se munir de stickies, d'un marqueur, puis pitcher ses sessions devant tout le monde. Puis les gens les positionnent sur le programme de la journée (pour plus d'infos sur cette anti-conférence, il y a ce fil twitter )

Mais revenons au sujet et à la séance intrigante proposée par Simon.

Le règne de la propriété privée ?

Pour résumer le pitch initial de Simon : si des pans entiers de notre SI appartiennent à des équipes — chacune responsable d'un ou plusieurs Bounded Context (BC) — ne sommes-nous pas face à une version logicielle de propriété privée (avec des barbelés autour des BC, etc. .) ? D'où son provocateur « DDD, c'est de la droite ! ”

Et avec la question subsidiaire : « Ne serions-nous pas plus efficaces avec une organisation basée sur des feature teams ? (avec tout le monde capable de travailler sur tous les BC sur le chemin de leurs cas d'utilisation) »

Bon… Je dois avouer que cette session s'est avérée beaucoup plus fructueuse que je ne l'avais espéré au départ car une discussion vraiment passionnante s'en est suivie sur notre mode d'organisation Produit/Tech.

Mais plutôt que de détailler le chemin parcouru par cette session où nous étions très nombreux (sûrement intéressant à décrire dans le cadre d'un autre post), je vais directement décrire ce que j'ai retenu et pensé sur le sujet.

Quelques remarques

• Un logiciel efficace est un logiciel aligné sur les défis de l'entreprise . Par aligné, nous entendons un logiciel qui emprunte les bons termes au champ du domaine, qui articule correctement les concepts clés du métier et convoque le moins possible la complexité accidentelle apportée par les problèmes techniques. C'est l' un des principaux enjeux du Domain Driven Design (DDD), comme expliqué ici en 3 minutes .
• La loi de Conway n'est pas une option que l'on pourrait choisir de ne pas prendre.‍♂️ Elle agit un peu comme certaines lois physiques telles que l'attraction de la gravité. On peut essayer de lutter contre ça ;-) mais c'est toujours valable sur terre. La loi de Conway est cette loi de 1967 qui stipule que
  "toute organisation qui conçoit un système (défini au sens large) produira une conception dont la structure est une copie de la structure de communication de l'organisation".
  Autrement dit, l'architecture d'un logiciel est nécessairement le résultat des modes de communication des personnes impliquées dans sa conception. Par exemple, un compilateur développé par 3 équipes fonctionnera très probablement en 3 passes ou aura 3 modules distincts.
• Inverse Conway Maneuver (ICM) vous laisse penser que l'on peut contrôler la loi de Conway. Au départ, cette manœuvre inverse recommandait judicieusement de « casser les silos qui contraignent la capacité de l'équipe à collaborer efficacement ». Mais s'est transformé au fil des années en une recommandation idiote : « changez votre organisation afin d'atteindre votre architecture cible ». Stupide parce que rappelez-vous : "La culture mange la stratégie au petit-déjeuner". Plus d'informations ici dans ce fil intéressant.
• Le Domain Driven Design n'impose aucune organisation. Il donne des clés pour permettre la survie, y compris dans les cas d'organisations dysfonctionnelles (avec des équipes qui se font la guerre ou s'ignorent). DDD nous aide à comprendre les enjeux de pouvoir et les enjeux sociaux entre les équipes. Du coup c'est plutôt un outil de libération contre nos déterminismes ( donc un outil de gauche je dirais ;- )
• D'autre part, DDD nous donne des outils pour pouvoir concevoir un logiciel efficace et le plus aligné possible par rapport au domaine. Parmi eux le concept de Bounded Context (BC) qui nous propose de concevoir des modèles d'usages, de les entourer et de se prémunir contre les confusions/faux amis/malentendus issus d'autres contextes.
• Pour plus d'alignement et d'efficacité, DDD recommande aussi fortement de challenger régulièrement notre vision et notre modélisation de la solution. C'est aussi révolutionner et changer de modèles de temps en temps suite à un moment eureka (appelé Design Breakthrough ). C'est pourquoi nous avons régulièrement ici des sessions Context map qui affinent en permanence notre vision du terrain avec les Product people.
• Les équipes de développement ont des équilibres fragiles. Il faut environ 6 mois de vie commune et de relations interpersonnelles pour qu'une équipe de développement soit vraiment efficace. Vous ajoutez ou supprimez une seule personne de cette équipe et ce n'est plus la même équipe (voir Dynamic Reteaming ). En termes d'efficacité, je préfère les équipes qui restent groupées et changent de sujets, que les équipes qui sont juste éclatées/redistribuées selon les sujets. Bien sûr, si quelqu'un en a marre de son équipe ou de ses sujets, tout doit être fait pour lui permettre de changer d'équipe (être bien personnellement est encore plus important pour notre efficacité collective)
• Notre organisation actuelle et nos équipes ici à Agicap sont plutôt affiliées à un ou plusieurs Contextes Délimités afin de prendre en compte la complexité de la problématique et de capitaliser un minimum sur nos expertises métiers respectives. De temps en temps, certaines équipes peuvent avoir une portée trop large et nous devons mieux couper et attribuer notre contexte délimité. En revanche, cette division des CB doit rester liée aux concepts métiers (rappel DDD)
• Rien n'interdit d'avoir des équipes de fonctionnalités dans une organisation qui fait du DDD , tant que tout le monde respecte les limites des contextes délimités.
• Pour l'instant, nous préférons largement la pratique du Swarming (sorte de task force constituée de personnes de plusieurs équipes mais où la responsabilité et la propriété de l'artefact final (outil, api, bibliothèque) sont définies dès le départ. Cela aide pour éviter le syndrome du "Bon, on a fait quelque chose ensemble, mais qui va le maintenir maintenant ?!?"). Au-delà de son efficacité à faire collaborer les bonnes personnes selon le sujet, le swarming apporte beaucoup de capital social à notre organisation en favorisant temporairement les relations interpersonnelles inter-équipes (super utile pour le futur quand chacun reviendra dans son équipe).
• Notre organisation produit actuelle est définie sur 1 Product Manager (PM) par équipe de développement, mais peut-être serait-il intéressant d'avoir des PM plus associés à des sujets métiers qu'à leur équipe ?

Enfin, je dirais qu'il n'y a pas plus de solution miracle dans l'organisation que dans le développement. La rétroaction continue, le questionnement et l'expérimentation sont nos compagnons sur cette voie d'amélioration continue pour créer efficacement des logiciels pertinents pour nos utilisateurs.

Note : ce post est une traduction d'un article français écrit la semaine dernière (14 octobre 2022)

Pour en savoir plus sur Agicap :

• Montrez-moi votre domaine ( Séance de cartographie contextuelle pour le suivi et la prévision des flux de trésorerie )
• https://agicap.com/
• https://career.agicap.com/