Je suis développeur. Tu es développeur. Nous nous reconnaissons car nous avons les bouts des doigts carrés. A force d’appuyer sur un clavier, nous avons déformé l’extrémité de nos phalanges. Plus grave, à force de travailler avec des clients différents, nous avons abandonné l’idée que le client comprenne notre boulot. Alors forcément, vu du point de vue du client, nous ressemblons de plus en plus à une caste sociale difficile à gérer. Peut-être qu’un jour nous serons derrière des barreaux comme au Zoo, et que les clients nous apporterons des spécifications à manger avec une fourche…
Soyons sérieux.
Il semble important d’apprendre aux développeurs quelques techniques pour parler avec le client. Cet enseignement vient de ce que j’ai vu lors de ma formation Domain Driven Design chez Zenika : l’importance d’un langage unique, ce que l’on appelle « Ubiquitous Language« . Je ne parle pas des règles de politesses, mais bien de l’importance de définir une sémantique claire entre l’équipe de réalisation d’une part, et l’équipe de maîtrise d’œuvre d’autre part.
L’Ubiquitous Language dans l’approche Domain Driven Design, est un langage défini autour du modèle du domaine, utilisé par toutes les équipes pour communiquer autour du logiciel réalisé. En l’absence d’UL, il y a un risque important que le travail des développeurs ne correspondent pas à la demande du client. Il s’avère que les développeurs ne font pas toujours l’effort d’apprendre les termes et la langue de travail du domaine. D’un autre côté, certains experts du domaine se rendent inaccessible en ne faisant aucuns efforts de vulgarisation ou d’explications.
Je me souviens de cette charmante personne dans mon ancienne société qui venait nous parler des CDS (Credit defaut swap). On y comprenait rien. Pourtant la définition est très simple :
A credit default swap (CDS) is a swap contract in which the buyer of the CDS makes a series of payments to the seller and, in exchange, receives a payoff if a credit instrument (typically a bond or loan) undergoes a ‘Credit Event’ (often described as a default) defined as events such as restructuring, bankruptcy or even downgrade of credit rating (less common).
C’est super simple non ? Allez vous me faîtes un petit modèle simple sur cette base et on se revoit demain….
Ce qui est intéressant avec les CDS, c’est qu’ils sont à la source de la faillite de l’assureur AIG en 2008. La banque Lehman Brothers était le premier acteur sur ce marché. Les CDS sont des contrats de protections financières entre les acheteurs et les vendeurs, mis en place pour couvrir les risques de crédit. Lorsque vous achetez une maison, votre assurance santé couvre le risque de défaillance de paiement en offrant une couverture en cas de soucis de santé. Les CDS sont des contrats qui protègent le vendeur en cas d’événements de crédits graves comme la faillite d’une banque, une crise monétaire ou autre. C’est plus clair ?
Lorsque le langage n’est pas clair, votre projet informatique prend un sérieux risque de ne pas concrétiser vos attentes. Il est donc primordial de trouver des personnes de la maîtrise d’ouvrage ou de la maîtrise d’œuvre en mesure de parler avec les développeurs. Dès lors que les mots ne sont pas clairs, il y a un risque de dérapage.
Le développeur doit apprendre une langue métier
Crédit photo: Shawn Econo
Parlons un peu de vous, messieurs les développeurs. Quel nom allez-vous donner à votre Class Java, à vos méthodes et vos objets ? Quels mots allez-vous utiliser dans vos schémas d’architecture ? C’est là qu’il devient important d’utiliser l’UL (Ubiquitous Language).
Lorsque les mots ne sont pas clairs, les développeurs entre eux ne peuvent pas se comprendre. Que voulez-vous dire exactement par « Adapteur » ici sur ce schéma ? Il s’agit d’un convertisseur de flux financier ? D’un adapteur réseau ? D’un mot qui ne veut rien dire ?
Il est cependant important de dire qu’il y aura un décalage entre le code écrit et la langue des clients, de l’équipe métier. Trouver le bon nom d’une classe pourra demander plusieurs itérations. Travailler même avec des développeurs d’un autre pays demandera un effort de vulgarisation et de documentation plus important que prévu.
Comment s’en sortir alors ?
Revenez sur votre modèle. Je ne parle pas forcément UML ici. Je parle simplement de ce schéma qui décrit votre logiciel. En fait, il ne doit contenir que des mots validés par le métier. Si quelque part je vois « ESB » alors je dis : « danger !!! ». Un ESB ne veut rien dire pour quelqu’un qui n’est pas développeur.
Imaginez les cartes routières. Pensez-vous que celles-ci seraient exploitables si elles utilisaient le format de l’armée ? Ou celui des géomètres ? Non !
Il y a eu un effort de transcription et de simplification pour que vous, le client lambda, soyez en mesure de comprendre et de vous y retrouver.
Crédit photo : Andrea_r
Il doit en être de même de vos schémas d’architecture. Votre épouse/époux doit pouvoir lire et comprendre ce que fait votre logiciel. En fait, votre fils de 6 ans doit pouvoir redessiner ce schéma. Bon j’exagère un peu, mais vous comprenez le sens de ce que je veux dire.
Le langage dépasse les schémas. Ce sera surtout cet ensemble de mots que vos développeurs utiliseront chaque jour. Lorsqu’un développeur dira « événement financier avec risque » ou « emprunts », chacun aura une vision claire.
Lorsque je dis « moteur de génération de rapports financiers » il n’y a pas d’ambiguïté sur le fond. Parler de « moteur transactionnel de génération de rapports BIRT » à un financier n’a pas de sens. De même, parler de « plateforme d’externalisation des documents légaux financiers par voie électronique » ne parlera pas à un développeur. Soyez créatif, inventez-vous un vocabulaire et une langue de travail.
En cas de doutes sur la signification d’un terme, il faut faire appel à l’expert du domaine. C’est la personne qui représente le client, et qui a assez d’autorité pour trancher. Ne prenez pas de décisions sans en parler avec lui.
Conclusion
L’Ubiquitous Language de la pratique du Domain Driven Design demande aux développeurs et aux architectes d’améliorer leur communication avec le client. Pour cela, les architectes doivent travailler avec les clients du projet afin de capturer les mots, de définir les notions et le sens de chaque élément. Essayez de reprendre vos schémas fonctionnels, et assurez-vous qu’il n’y ait pas trop d’abréviations. Je déteste cela. Je trouve que c’est un moyen trop facile de jargoniser son projet. Pensez à celui qui arrive dans le projet. Ce n’est pas à lui de vous comprendre, c’est à vous de vous faire comprendre. Soyez humble, abandonnez cette chaise de juge arbitre de Tennis, d’où vous jetez les acronymes sur la population du développeur.
Quant à toi mon cher développeur, tu ne t’en sortiras pas comme cela. Si je te vois encore parler de transaction sérialisée en SGBDR, de 2-phases-commit, de repository de datas ou de je ne sais quelle perle de geek à ton client, tu vas entendre parler de moi. C’est à toi d’apprendre à parler Klingons, pas à eux.
Sur ce, je vous laisse, j’ai mal aux doigts après avoir tapé cet article, j’ai les bouts des doigts carrés… bizarre.
0 no like
A apprendre par coeur.
Ceci dit c’est un peu le passage du « développeur » à l' »architecte » dont tu parles, là. L’architecte pour moi est celui qui a le pouvoir de la parole. Qui fait la médiation entre le client et les técos.
Au passage ça me fait penser à ce qu’on m’a souvent raconté à propos d’un architecte de génie qui s’appelle Pascal Grojean. En lisant une propale, en écoutant bien le client, il peut redéfinir techniquement mais à sa manière tout le métier du client. Il lui ré-explique son propre métier, avec ses propres mots, et en plus en lui trouvant ce qui cloche et en ouvrant des perspectives… Les mecs en face, ils pleurent de joie.
@Gabriel je trouve justement dommage de penser que seul un architecte peut parler avec le client.
J’aimerais que les développeur ne soit plus considéré comme des techos, et
j’aimerais que justement chacun devienne architecte.
Sinon, @touilleur, très bon billet, et tellement vrai.
@Gabriel Je n’ai jamais compris cette classification en développeurs et architectes. Pour moi, ça n’a pas de sens. Il y a des développeurs séniors qui sont les plus à mêmes de définir l’architecture d’un projet et des développeurs juniors qui devront arriver un jour à définir une architecture.
Bref, les jeunes doivent apprendre des expérimentés et les expérimentés doivent se remettre au goût du jour par les connaissances « up to date » des jeunes. Ainsi tout le monde progresse.
Sinon l’article est très bon et à mon humble avis, le DDD ne devrait pas exister, ça devrait être la façon normale de développer. Tout le monde doit comprendre le métier du client avant de commencer à coder, sinon comment répondre à son besoin ?
Je n’ai pas fait de différence dans mon propos entre archi et dev. Ce serait appliquer une grille de lecture « habituelle » mais ce n’est pas ce que j’ai dit. Je pense plutôt qu’il y a un spectre incroyable entre les deux taches.
Pendant longtemps comme vous je n’ai pas fait de différence entre les archi et le développeur senior. Maintenant un peu plus. Tout dépend du projet, du contexte, des protagonistes, de leur manière de bosser. Mais des archi qui ne codent pas, ça existe et ce ne sont pas forcément les plus mauvais.
Bon, pour éclaircir un peu mon propos, je pense qu’il y a différentes fonctions et qu’elles peuvent être tenues par un développeur, ou un architecture, mais la frontière entre les deux est fine et sujette à bouger, voire à sauter.