headerphoto

MD Day - agilité, modélisation et modélisme

Jeudi dernier, le 25 novembre, se tenait le quatrième MD Day, une journée intéressante à plus d'un titre.

La conférence était hébergée dans le très beau centre de conférences de Microsoft à Issy, auquel le seul reproche que je puisse faire est une connectivité 3G limitée (et je n'avais pas les infos pour me connecter au réseau WiFi en tant qu'invité). Cela n'a pas empêché de nombreux commentaires sur Twitter.

Cette année le thème retenu était "Model-Driven et Agilité", un lien thématique qui se traduisait dans le programme: le mot "agilité" apparaissait dans le titre de quatre des 10 sessions prévues, plus une "table ronde" au sein de laquelle Xavier Warzee et votre serviteur avaient pour mission de représenter le point de vue Agile.

J'étais un peu anxieux à l'idée d'apporter en quelque sorte une "caution" Agile à un événement organisé autour d'une approche du développement, le fameux "model-driven", à laquelle je n'adhère personnellement pas et qui peut sembler aux antipodes du discours Agile: en caricaturant, elle semble marginaliser le rôle du développeur (remplacé par la génération automatique de code) au profit de celui de l'architecte (traçant des diagrammes de modèles dans le but de les convertir en code automatiquement).

Lors d'une intervention aux Valtech Days il y a quelque temps, j'avais ainsi opposé "modélisation" et "modélisme":
En fait de modélisation, on pratique trop souvent ce que j'appellerai le "modélisme": une activité somme toute assez prenante, et qui constitue un excellent passe-temps, mais qui ne produit pas des résultats très constructifs. Ma définition de "modèle" est la suivante: un modèle est une représentation d'une situation réelle, qui sans y être fidèle dans tous les détails est utile pour répondre à des questions concernant cette situation.
On peut illustrer le "modélisme" par ce diagramme par exemple, obtenu à l'aide d'un outil UML qui analyse du code existant. Trente classes différentes sur un seul diagramme ce n'est tout simplement pas lisible, pertinent, ou utile: c'est uniquement une perte de temps.

Il me semblait cependant important d'accepter l'invitation, pour plusieurs raisons. D'une part, je suis favorable aux échanges entre les diverses communautés de professionnels qui se retrouvent autour d'une volonté commune d'améliorer leur pratique d'un métier, en l'occurrence le développement de logiciels. D'autre part, la communauté "model driven" me semble avoir un rapport plus étroit avec le milieu de la recherche, privée ou publique, que la communauté Agile, et l'une des missions de l'Insittut est de resserrer ces liens.

De ce point de vue, l'important était de participer. Mais je me devais d'apporter un regard plus attentif, et dès le début de la journée je m'étais fixé comme objectif de répondre à la question suivante: la communauté "model driven" ici présente est-elle motivée par un réel intéret pour les pratiques agiles, ou s'agit-il (pour l'instant) d'une simple curiosité, piquée par le "buzz" de plus en plus présent autour de l'étiquette "Agile"?

Mon canevas d'évaluation était, comme il se doit, le Manifeste Agile et la liste des pratiques Agiles: lors des sessions, est-ce que les orateurs évoquaient ce qui, dans leurs solutions proposées, privilégiait les individus et les interactions, la livraison de logiciels opérationnels, la collaboration avec le client, et la réponse au changement? Est-ce que les orateurs mettaient en avant l'inclusion dans une stratégie "model-driven" de telle ou telle pratique appartenant à la "boîte à outils" Agile? J'ai prévenu les orateurs des différentes sessions auxquelles j'assistais, afin de ne pas les prendre en traitre, de mon intention de distribuer en fin de journée un "carnet de notes" avec mention des bons et des mauvais élèves.

Alors, quel bilan de cette journée?

Force est de constater qu'il y a encore loin de la coupe au lèvres, et que la communauté "model-driven" n'est pas encore pleinement Agile. Le mot "agile" était plus utilisé pour légitimer un discours déjà établi, que pour y chercher un véritable contenu pouvant constituer un apport.

La première présentation, celle de Grégory Weinbach et Jérémie Grodziski, se distinguait par un rappel explicite du Manifeste Agile, et un véritable "zoom" sur des pratiques, en l'occurrence le Behaviour-Driven Development (BDD) et le Ubiquitous Language issu de l'approche Domain-Driven Design. D'autres éléments Agiles y étaient présents, portant à... quatre le nombre des pratiques Agiles mentionnées lors de cette intervention. C'est honorable mais sans doute en-deça de ce qu'il serait possible de faire en combinant les deux approches, et je suis resté un peu sur ma faim.

Malheureusement, le reste de la journée n'allait pas combler mon appétit pour une mise en valeur de pratiques et de réalités de terrain: les autres sessions auxquelles j'ai assisté se résumaient à peu de choses près à des démos d'outils. La session proposée par l'éditeur W4 abordait (en passant) deux pratiques que j'ai pu reconnaitre comme issues du discours Agile, mais il aurait été plus juste de parler de RAD pour caractériser l'approche présentée. Pour les autres les retours clients étaient (à mon goût) réduits au strict minimum et laissaient la part belle au "pitch" de l'ingénieur commercial montrant (tout seul au clavier) ce qu'on peut faire avec l'outil.

J'ai été particulièrement frappé par une remarque d'un des orateurs, en fin de journée: "pour la suite je vous demande de m'excuser mais il va falloir que je rentre un peu dans les détails du métier de l'assurance...". Mais non, c'est justement l'attention portée au métier de vos clients qui fait, en tout cas pour moi et en tant "qu'Agiliste", toute la valeur et la saveur de votre retour d'expérience.

Car encore une fois, qu'est-ce que modéliser sinon poser des questions à un client dont, en tout cas en début de projet, on ne connaît pas le métier? Pour être vraiment convaincante, une démonstration de l'approche "model driven" soutenue par un outil devrait se tenir sous la forme suivante: on choisit au hasard dans l'assistance une personne qui propose une situation à traiter, issue d'un domaine d'expertise non technique - ou même de la vie courante, par exemple "gérer la fréquentation d'un musée" ou "réserver une table au restaurant" - et on construit en direct une solution à base de modèles. C'est à mon avis dans ce genre d'exercice qu'on s'apercevrait le mieux des bienfaits ou des limites de tel outil ou de telle approche.

Quand on l'aborde sous cet angle, celui où développer des logiciels consiste à encoder et formaliser des connaissances sur un domaine, la distinction entre "code source" et "modèle" commence à mon sens à s'effacer, proposition qui m'a servi de conclusion lors de la table ronde. Toutes les préoccupations que nous avons vis-à-vis du code source sont applicables aux modèles, dès lors que nous sortons du "modélisme" (faire de beaux documents visuels) et que nous cherchons à répondre à la demande d'un client: est-ce que le résultat est correct (ne donne pas des réponses fausses), est-ce qu'il est utilisable (son ergonomie s'adapte à l'utilisateur), est-ce qu'il créée de la valeur?

Dans une approche qui consiste à créer des modèles pour générer automatiquement du code source, cette seconde étape s'apparente à de la compilation, par conséquent le modèle devient le véritable code source. Mais d'un autre côté on constate que les langages modernes (par exemple Ruby) permettent de plus en plus, par le biais de l'abstraction et de techniques comme les DSL, de séparer les préoccupations purement techniques et algorithmiques de l'expression (dans le même langage) des connaissances sur le domaine fonctionnel et des exigences: le code source devient tout à fait adéquat pour exprimer ce qu'on appele en général le "modèle".

11 commentaires:

Anonyme a dit…

Bonjour,

Je suis surpris de voir dans vos écrits la comparaison voire l'opposition entre "Model-Driven" et "Agilité". Agilité et "Model-Driven" ne sont pas forcément aux antipodes l’un de l’autre, bien au contraire, et certains de nos clients le constatent tous les jours dans la mise en oeuvre de notre produit CodeFluent Entities. Vous auriez profit à échanger avec l’un de nos clients majeurs ayant mené un projet de plus de 12 000 jours homme de développement en utilisant l'approche Model-Driven que nous proposons et la méthodologie SCRUM.

En ce qui nous concerne chez SoftFluent, nous nous efforçons justement d'apporter une solution agile au travers d'une approche pragmatique pilotée par les modèles qui va bien au-delà du simple "modélisme". Elle est issue justement du cumul de dizaines d'années d'expérience dans le développement d'applications et l'agilité est le premier avantage qu'a évoqué notre témoin client au MD Day.

Je suis par contre tout à fait d’accord sur le fait que de nombreux acteurs du métier « surfent » sur la vague de l’agilité alors que leurs produits n’affichent malheureusement pas l’agilité espérée car étant très complexes à comprendre et mettre en œuvre. Vos commentaires s'appliquent probablement à certaines solutions basées sur UML qui focalisent beaucoup de l'énergie sur des modèles principalement documentaires, mais il faudrait a minima prendre quelques précautions d'introduction avant d'opposer les deux concepts.

Il existe effectivement de nombreuses méthodologies dites "agiles" mais tout repose au final sur l’individu. Un projet peut clairement aller dans le mur (et ça s’est vu…) même s'il est piloté avec la plus efficace des méthodologies Agile. Tout dépendra au final de la compétence et du professionnalisme de chaque individu, incluant bien évidemment le rôle critique de chef de projet. Les méthodes Agile doivent plutôt être utilisées pour maximiser les chances de réussite d’un projet et non pas comme une formule magique qui ferait réussir un projet par un simple claquement de doigt.

Mon propos reste valable avec les outils de développements qu’ils soient pilotés ou non pas les modèles. Un outil (j’y inclus les frameworks) doit aider le développeur dans ses tâches quotidiennes liées au développements sans pour autant augmenter l’entropie d’un projet, ce qui est malheureusement le cas si j’en réfère aux nombreux audits de code clients que nous menons chez SoftFluent. Dans ce cas l’agilité disparait clairement au profit de la complexité.

Nous essayons précisément au travers de CodeFluent Entities d’apporter une méthode de développement couplée à un outil Model-Driven permettant de générer un code professionnel tout en garantissant une agilité dans les développements. Je vous invite à consulter notre livre blanc intitulé Livre blanc du développement logiciel disponible à l’adresse suivante : http://www.codefluententities.com/Whitepaper.aspx car nous y expliquons notre vision du Model-Driven avec une approche Agile basée sur CodeFluent Entities (Section IV.B).

Au final, notre méthode et le produit qui la sous-tend s'alignent totalement avec les 4 principes du Manifeste agile : favorisation des interactions, modèle directement exécutable, collaboration avec le fonctionnel et approche itérative.

Omid Bayani.
SoftFluent.

Unknown a dit…

Bonjour

Sujet qui m'anime depuis belle lurette !
http://davidbrocard.org/taxonomy/term/4

Je fais partie des défenseurs de la "réconciliation". Cependant, je n'ai pas à mon actif de prototype suffisamment abouti pour apporter des preuves mais je reste sur une profonde conviction.
Cultivons l'ouverture comme valeur agile aussi.

Unknown a dit…

Bonjour Omid, merci pour le commentaire sur SoftFluent et les précisions sur votre approche.

Je dois préciser que mes remarques ne concernent pas les produits ou les entreprisques qui intervenaient lors du MD Day mais seulement le contenu des présentations.

Vous dites "notre méthode et le produit qui la sous-tend s'alignent totalement avec les 4 principes du Manifeste agile" et je suis ravi de l'entendre, ce n'était pas apparent lors de la présentation qui s'est largement concentrée sur l'outil, n'a pas fait allusion au Manifeste et n'a mentionné aucune des pratiques Agiles.

Je suis pleinement ouvert à ce qu'on se rencontre pour étudier ensemble un cas client avec une grille de lecture plus spécifiquement Agile, si cela vous semble utile pour un prochain MDDay ou un autre événement de ce type. :)

Il y a des choses que j'ai apprécié par rapport au produit, et j'ai même entendu des remarques notamment de Ivan Audonnet sur un intérêt de la génération de code que je n'avais pas envisagé: son aspect pédagogique pour des développeurs novices à qui il peut transmettre de "bonnes pratiques". (Je reste quand même très sceptique sur l'intérêt de la génération de code, si c'est du code qu'on retouche manuellement ensuite ou même qu'on doit "maintenir" au sens usuel, c'est à dire qui génère une charge cognitive.)

Je suis par ailleurs un fervent partisan de la modélisation, que je comprends dans un sens plus large que celui que lui donne encore la communauté MD; pour moi on peut modéliser avec profit bien plus que le produit logiciel; par exemple on peut modéliser le contexte client (approche Soft Systems), on peut modéliser le processus de développement comme je l'ai appris avec mes amis du Systems Thinking Group.

Encore faut-il savoir pourquoi modéliser, dans quel contexte, et comment développer de réelles compétences en modélisation, toutes choses qu'une démo produit ne fait pas apparaître.

Anonyme a dit…

Bonjour Laurent,

Merci pour toutes ces précisions. C'est toujours mieux avec davantage d'explications:). Il m'est quasiment impossible avec un temps de parole de 40 minutes de démontrer l'ensemble des bénéfices de notre produit et de la méthodologie "Agile" que nous embarquons.
Je suis par ailleurs tout à fait prêt à partager notre expériences de la modélisation (telle que nous la concevons chez SotFluent) et de la génération de code, d'autant que nous avons créé ce produit justement pour réduire le fossé entre les modélisateurs et les développeurs. Le modèle produit avec CodeFluent Entities est "exécutable" et génère du code prêt l'emploi ce qui oeuvre pour une meilleure agilité dans le cycle de développement. D'ailleurs, il est tout à fait possible de rajouter son propre code au côté du code généré (au travers de classes partielles), code qui sera conservé après de multiples générations.
Par contre il est clair que le modèle ne s'appuie aucunement sur UML que nous paraît assez incompatible avec l'agilité.

Omid Bayani.

Unknown a dit…

Laurent,

Juste pour préciser, nous ne nous sommes pas donnés comme objectif de présentation de présenter l'agilité, et ce d'autant que le client témoin l'a mentionné comme premier bénéfice, il ne nous semblait pas utile d'en rajouter.

De plus, nous l'avons déjà fait à maintes reprises :
- J'étais présentateur de l'agilité aux TechDays 2009 aux côtés de Xavier Warzee
- Début 2010, Cegid Retail a effectué à l'AFDEL une présentation complète de la méthode agile mise en oeuvre chez eux avec notre produit (Scrum).

Dans le webcast ci-après, en 2e partie, tu auras la grille de lecture agile détaillée que tu appelles de tes voeux, expliquée par le client, par ailleurs vétéran des méthodes agiles !

http://afdel.tv/event/461/r-d/r-d-logicielle-nouvelles-approches-nouvelles-methodologies/l-approche-modeles-en-univers.net

Daniel COHEN-ZARDI

Oaz a dit…

"nous cherchons à répondre à la demande d'un client : est-ce que le résultat est correct ?"

Voilà une question intéressante, qui débouche, entre autres, sur la question des tests.
Mon expérience sur le "model driven" est quasi-inexistante, mais il y a une chose que je n'arrive pas à visualiser : comment développer en "test driven", c'est à dire en commençant par écrire des tests exécutables, et apporter des réponses sous forme de code "model driven" aux tests qui ne passent pas encore ?

Xavier SEIGNARD a dit…

Bonjour,
Evidemment que l'ingénierie des modèles peut être agile! Tout comme des équipes Scrum ne sont parfois pas du tout agiles...
Tout est question d'outillage. L'idée est de choisir l'outil effaçant les pseudos lourdeurs de la démarche MDE. Pour cela, j'estime qu'il y a 4 éléments clés que l'outil MDE doit remplir :
- synchronisation automatique du modèle et du code
- validation en live du modèle
- repository de modèles (et merge de modèles!)
- interoperabilité des outils

Sans ces 4 points (au moins!), j'estime à 70% la probabilité d'échec d'une démarche model driven agile. En effet ils permettent de répondre au point du manifeste suivant : "Individuals and interactions over processes and tools" en permettant à chaque developpeur d'avoir dans son workspace une version du code et du modèle alignés et toujours à jour sans efforts.

En ce qui concerne les autres points du manifeste agile, je ne voit pas en quoi ils sont incompatibles avec le MDE :

- "Working software over comprehensive documentation" : c'est le but du MDE
- "Responding to change over following a plan" : le MDE facilite cela

Les principes agiles sont totalement compatibles, je viens de les relire, et j'irai même plus loin en disant que le MDE facilite la mise en oeuvre des principes agiles.

Bonne journée,
Xavier Seignard

Unknown a dit…

Merci Xavier pour votre contribution, je suis assez en phase avec cette analyse.

@Oaz: dans le cas de notre produit, nous pouvons inclure dans nos modèles des données, ce qui facilite le test-driven également. Je ne sais pas bien si nous sommes les seuls sur ce point.

Daniel

Unknown a dit…

Bonjour Laurent,

Merci pour ce point de vue intéressant. Vouloir vérifier à quel point l'étiquette "Agile" correspond à ce qui est pratiqué par la communauté Model-Driven, l'intention est louable! Mais tout comme Omid, je ne comprends pas comment le Model Driven peut paraître "aux antipodes du discours agile".

C'est vrai, les programmeurs ne trouvent pas toujours leur compte quand ils utilisent des outils MD (automatisation oblige), mais la satisfaction du client ne passe pas forcément par celle du programmeur. L'acceptation du changement, cheval de bataille de l’agilité, est grandement favorisée quand on communique et qu'on raisonne au niveau modèle, car on est alors capable de se rapprocher des acteurs du métier en parlant leur langage.

D'après nos observations sur le terrain et les résultats sur les nombreux projets auxquels W4 participe en collaboration étroite avec ses clients (et pas seulement en mode RAD), les principes et les valeurs du manifeste agile sont essentiellement renforcés quand un développement est piloté par le modèle. Non, il ne s'agit pas de buzz : le MDE est indéniablement vecteur d'agilité.

En ce qui concerne W4, nous répertorions sur notre site web, sous http://www.w4.eu/workflow-bpm-methode-agile.htm , en quoi notre produit renforce, selon nous, le mise en œuvre des principes et des valeurs du manifeste agile. Cela est encore favorisé, ils nous semble, par l’approche MDE que nous préconisons : pas de génération de code mais une exécution ‘à la volée’ du modèle.

Jean-Loup Comeliau

Unknown a dit…

@oaz
"comment développer en "test driven", c'est à dire en commençant par écrire des tests exécutables, et apporter des réponses sous forme de code "model driven" aux tests qui ne passent pas encore ?"

Tu codes ton test, en manuel ou en DSL dédié ou ce que tu veux (préférence pour le mode manuel pour ne pas perdre la pratique agile). Après, au lieu de coder manuellement le code de prod, tu mets en oeuvre la chaine modele-generateur-code pour faire passer ton test. La mise à jour incrémentale de modèle et de générateur peut aller très vite, là j'ai des preuves (avec solution MIA Generation par exemple)
La conception émergente et le refactoring peuvent donc être adressés par MD, mais par une approche différente, qui peu s'avérer tout aussi agile voire plus.

Faut rester pragmatique et tester cette méthode sur des projets réels, à enjeux de production.
Dans mon cas, je suis toujours au stade d'élaboration de proto par manque de temps (je n'y ai pas retoucher depuis un an, c'est dire !)

Je pense qu'il faudrait un bon vieux financement R&D pour aller au fond des choses un fois pour toutes.
Il faut rester ouvert et honnête en regard des faits. Je m'engage à reconnaître le cas échéant toute démonstration d'incompatibilité.

Bref je vois le MD comme une évolution naturelle et inéluctable de la programmation, mais pas à court terme. Et svp, oubliez MDA !
Il s'agit avant tout de trouver le bon équilibre entre l'apport MD comme cohésions d'artefacts et l'apport de l'agilité comme livraisons incrémentales

Romain BERNARD a dit…

Je commence par ma conclusion : l'utilisation conjointe de pratiques agiles et du model-driven peut sous certaines conditions être extrêmement performant.

Je pense qu'il faut définir ce que veut dire "model-driven". En fonction de la stratégie MD choisie, il y a des conséquences sur la compatibilité avec les pratiques agiles ; Exemples :
1. modèle exécutable : implique d'utiliser un environnement MD sur étagère. L'architecture technique cible est imposée par l'outil (au mieux, possibilité de choisir entre quelques variantes). L'effort de modélisation est important, en particulier sur le "code métier". Les formalismes de modélisation associés (state machines, activités, diagrammes de séquence) sont relativement complexes à utiliser (=> contraintes sur les profils des développeurs).
NB : l'approche "modèle exécutable" est très intéressante et pertinente dans certaines situations. J'essaie juste de montrer les contraintes qu'elle impose (ces contraintes pouvant être jugées tout à fait acceptables pour le projet).
2. modèle et code synchronisés : jouable seulement en utilisant un environnement MD sur étagère. Les modèles sont du même niveau d'abstraction que le code, donc complexes et techniques (=> le modeleur devient une sorte d'interface graphique du code). Si on souhaite changer d'architecture technique, tout (ou presque) est à refaire.
N. DSL, UML ou pas, MDA ou pas, GMF, XTEXT, MDSD, MDE, etc.). Combinatoire importante.
999. approche DSL + générateurs spécifiques + pratiques agiles : ma préférée ;-) DSL = Domain Specific Language. Le principe et le suivant : on met en place un vocabulaire (métaphores?) qui permet de qualifier et décrire l'architecture logique du logiciel(par exemple, des "ObjetPersistant", "ServiceCRUD", "ServiceMetier", etc., en fonction de vos besoins). Une architecture logique peut être implémentée en Java, .Net, Android, etc. (sans impact sur le modèle). Pour mettre en oeuvre une approche DSL, le plus simple aujourd'hui est d'utiliser un bon modeleur UML avec un "Profil UML" que vous mettez en place vous même . Le générateur de code est développé au fur et à mesure par l'équipe agile. Les bénéfices de l'aproche :
- le modèle est simple. Donc facile à modéliser, comprendre, faire évoluer. Par exemple, si on marque une UMLClass comme étant un "ObjetPersistant", on peut générer un script DDL, une interface de DAO, une implémentation de DAO, un POJO Java, de la configuration Spring, hibernate, etc. C'est le générateur qui décide comment on met en oeuvre les concepts de l'architecture logique.
- on peut facilement générer et faire évoluer tout le code technique sans refactoring (intervention sur les seuls templates de génération).
- on place le curseur où on veut : généralement, on ne souhaite générer "que" le code technique et laisser le développement du code métier en mode manuel (codage classique). Le positionnement du curseur dépend d'un compromis effort/bénéfice (les fonctionnalités du générateurs sont dans le backlog). Rester pragmatique.
- l'approche met en avant une réfléxion découplée sur les architectures logiques et techniques, qui n'est pas sans intérêts ni bénéfices.
- on gagne en célérité dans les développements (production automatique et en masse de code)
- le modèle est la référence (approche top-down). Il n'est pas désynchronisé du code et est donc représentatif du logiciel (intérêt pour la maintenance à long terme). On peut l'exploiter pour de l'analyse d'impact, détecter des défauts (validation de modèles), générer des docs, calculer des métriques, etc.
- on peut développer les profils UML, les générateurs et le code manuel avec des pratiques agiles. Tout ça n'est que du code après tout.
- si on a bien travaillé, on peut même réutiliser les profils et générateurs pour d'autres projets (capitalisation)

Enregistrer un commentaire