Le sujet est venu car le magazine papier « Programmez » a publié dans son numéro 113 un article intitulé « Développeur, boostez votre productivité ». Emmanuel Chenu sur son blog rapporte que l’auteur explique que la modélisation MDA est un processus améliorant la productivité et l’agilité du développeur. J’avais déjà dit que pour moi la modélisation n’est pas une méthode Agile, ou qui ajoute une quelconque agilité au développement. Emmanuel a écrit 2 billets que je vous recommande car il écrit très bien.
En résumé, son premier billet et son deuxième billet peuvent se résumer comme suit :
Après avoir rappelé que la modélisation MDA et les PIM ne sont qu’un autre moyen de représenter de l’information, Emmanuel pointe le fait qu’il faut des outils supplémentaires pour effectuer cette modélisation. La question qu’il pose dans l’extrait ci-dessous est intéressante :
Extrait de son billet 2
[…] Pour sonder une éventuelle compatibilité, on peut commencer par se demander si le MDE est compatible des valeurs du Manifeste Agile.
Il me semble que le pilotage par les modèles met fortement l’accent sur les outils. L’éditeur UML, les transformations de modèles et les générateurs de code sont autant d’outils sur le chemin critique du développement. Ces outils particuliers viennent s’ajouter aux incontournables outils tels que le gestionnaire de versions, le compilateur, le framework de test, l’IDE, etc.
Je partage son idée lorsqu’il s’oppose à l’argument du journaliste. Celui-ci propose de dire que la modélisation simplifie la maintenance puisque le développeur n’a pas accès au code.
(Extrait de la page 69 de Programmez numero 113) Comment faire pour qu’un programmeur maintienne sans effort conséquent le code d’un autre? Comment faire pour qu’un programmeur retouchant celui d’un autre n’introduise pas, par simple incompréhension, des bogues? Réponse : le transformer en créateur de modèles et générer le code à partir de ses modèles!«
C’est ce que les éditeurs ont essayé de nous vendre il y a 7 ans. Prenez mon gros modeleur professionnel et vos informaticiens de base ne toucheront plus au code, seul l’Architecte pourra modéliser le logiciel. Nous sommes tous d’accord pour dire qu’aujourd’hui cette image a du plomb dans l’aile. Et pourtant je me souviens très bien avoir pensé un moment que nos diagrammes UML deviendront un vrai logiciel.
En fait je vais vous avouez un secret : je fais de la modélisation.
Pas comme vous l’entendez, au sens avec AndroMDA ou compagnie… Non pas du tout.
Ma modélisation à moi c’est une feuille et un crayon. Je pense que les personnes qui travaillent avec moi depuis septembre ont remarqué que j’ai pour habitude de dessiner rapidement le système sur lequel nous discutons. Et croyez moi, c’est suffisant. Cela permet de mettre à plat une idée, d’expliquer un flux de données, d’affiner un point technique délicat, ni plus, ni moins.
Pour revenir à l’article d’Emmanuek, après avoir passé en revue quelques associations comme Scrum et Modélisation ainsi que XP et modélisation, sa conclusion est la suivante :
En fait, je pense qu’un développement piloté par les modèles gagne à être conduit dans une démarche agile, comme Scrum. Ainsi, le projet gagnera en transparence et du logiciel opérationnel sera régulièrement disponible.
Il faut savoir que les pro-MDA-c’est-Agile sont allés jusqu’à penser (en 2004) que le modèle dynamique du PIM serait suffisant pour répondre à l’exigence d’agilité. J’ai lu des vieux articles dans lesquels les auteurs se gaussent d’UML2 et de la modélisation dynamique. Honnêtement, levez la main ceux qui connaissent la représentation UML2 des diagrammes dynamiques ? Ah y’a une personne là-bas au fond à gauche qui lève la main… Attendez vous vous appuyez sur le mur ? Désolé…
Quel est l’intérêt de la modélisation ?
C’est un moyen d’apporter de la réflexion, de faire travailler des gens qui ne sont pas développeurs sur la valeur d’un logiciel : le code métier. Je ne suis pas contre la modélisation, je trouve même cela élégant et très pratique lorsqu’il s’agit de modéliser des processus métiers complexes.
En lisant en ce moment « Enterprise Integration Pattern » de Gregor Hohpe, je peux vous assurer que j’adore l’utilisation de la modélisation pour ce qu’elle apporte en terme de clarté et de concision.
Je suis donc pro-modélisation mais je suis opposé à cette idée qui est de faire croire aux décideurs que la maintenance sera plus légère, que les coûts seront réduits, et que les développeurs arrêteront de faire n’importe quoi. Au contraire, malheureusement il faut trouver tout d’abord des personnes avec de bonnes compétences en UML, en utilisation des outils de modélisation, avec aussi un oeil d’architecte et d’intégrateur. Idéalement il faut un bon communiquant car ce modeleur doit représenter la complexité métier d’un moteur de calcul d’assurance ou de gestion du risque en finance… Ne sommes-nous pas là entrain de créer un Dieu qui viendra ensuite vous demander un salaire exorbitant tout en se mettant une équipe de développeur sur le dos ?
Bref attention à ce monsieur en face qui vous vend MDA.
Soit c’est un génie et signez-lui un chèque,
soit c’est le père Noël mais vous m’aviez dit que vous aviez arrêté d’y croire…
Passons au sujet 2, je n’ai aucuns soucis à mélanger le tout dans un seul article.
La guerre anti-scrum est ouverte
Un autre article qui nous ouvre les yeux sur Scrum : « The Decline and Fall of Agile » de James Shore. Tout d’abord je vais vous résumer ici quelques idées clés, je vous conseille de le lire par vous même dans le but de vous faire votre propre opinion.
L’auteur explique tout d’abord qu’il constate un changement dans son métier de consultant sur l’Agilité. Là où il était appelé pour mettre en place de l’Agilité, il est aujourd’hui appelé pour venir sortir du trou des équipes noyées sous de la pseudo Agilité. Scrum est le responsable numéro un car c’est l’une des méthodes les plus populaires introduites ces dernières années. Des flots de Scrum Certified Master ayant suivi deux jours de formation sont lachés dans la nature. La difficulté de Scrum est que contrairement à ce que les gens pensent, c’est loin d’être facile.
Scrum étant un processus qui fonctionne en petits cycles, il n’y a pas de pratique de développement. Vous pouvez coller du XP par dessus si vous le souhaitez. Il n’y a donc pas de spécifications ou de recherche (NDLR : je ne partage pas cet avis). Les équipes se creusent alors un puit sans fin, en n’ayant pas assez capitalisé sur la technique. Les projets sont alors certes en ligne, tel que Scrum le vend. Mais les coûts de maintenance ? Les effort de documentation ? Le changement coûte alors cher.
[…] des équipes se disent Agile mais finalement elles ne font rien de plus que de la planification chaque semaine. Elles n’ont cependant pas changé leurs méthodes, il n’y a pas d’espace de travail en commun, le client n’est pas présent…. […]
Au final il y a des équipes qui commencent des éléments du sprint backlog, mais rien n’est terminé, le tableau se rempli. Il y a aussi les chefs qui changent les éléments du sprint en cours… car l’urgence c’est l’urgence… […] Des équipes essayent d’adopter qu’une partie du processus de Scrum, car c’est la nature humaine. Il est plus facile d’accepter le côté sympathique et de laisser la partie rébarbative, en se couvrant au nom de l’Agilité.
Bon et bient cela fait pas mal non ? C’est plutôt à charge non ? Et pourtant…
Rob Bowley prédit même que les méthodes à la mode en cette fin 2008, Lean Development, Kanban, Minimal Marketable Feature, prendront le même chemin que Scrum.
Attendons un peu et nous devrions voir des articles sur Lean Development Software qui se propose de remplacer Scrum… (note : je ne dis rien car j’avoue que l’idée m’a traversé l’esprit).
Il se demande si tout simplement si le problème ce n’est pas nous
Many of the reasons people aren’t being as succesful as they’d like with Scrum are exactly the same reasons they won’t be any more successful with any other methodology. People tend to focus on tools because it’s a lot easier than trying to tackle the often very difficult, challenging and more fundamental problems they grew from. Real change is hard and takes time, a very long time in some cases.
ce qui donne en français
Beaucoup de raisons pour lesquels les gens n’ont pas autant de succès avec Scrum qu’ils l’espèrent sont les mêmes pour lesquels ils n’auront pas plus de succès avec d’autres méthodologies. Les gens tendent à se focaliser sur les outils car c’est plus facile que d’adresser les problèmes plus profond, complexes et fondamentaux dont ils ont été entourés. Le vrai changement est difficile et prend du temps, vraiment beaucoup de temps dans certains cas.
Scrum ? What else ?
Regardons de manière objective ce qu’est Scrum : une méthode simple et bien markété qui permet à des personnes intelligentes de bien gagner leur vie, je parle des personnes qui vous font passer la certification.
Honnêtement je remercie Scrum de m’avoir ouvert les yeux sur la lourdeur du processus classique de développement, de m’avoir fait comprendre qu’il est important de communiquer, de mettre à plat une liste des demandes du client classées par priorité, de privilégier l’humain par rapport à l’outil, d’être honnête et transparent.
J’ai un peu plus de recul et je me rends compte que cette méthode anglo-saxonne n’est pas la méthode miracle. C’est un très bon socle de départ, je recommande aux personnes n’ayant aucuns idées de l’Agilité de s’y intéresser. Je vous demande simplement de prendre le temps de bien réfléchir. Etes-vous prêt à engager toute votre équipe, votre manager, vos dirigeants dans une refonte de votre organisation ? de votre produit ? Avez-vous tous les moyens ? Avez-vous pensé à ce que sera votre projet après Scrum ?
Au final il est important avant d’appliquer une méthode de bien comprendre l’environnement, l’écosystème d’un projet, d’un produit. Ensuite il ne faut pas s’interdire d’adapter le processus à son équipe et à son produit.
Cependant je pense qu’il faut faire attention dans ce cas à ne pas tomber dans de la fausse Agilité, de casser l’organisation d’un projet ou de se mettre les managers à dos. Rien de pire au final, tout repose sur vous et sur ce que vous faîtes.
Il n’y a pas de méthodes, il n’y a que vous pour faire avancer votre logiciel, votre produit.
