MODELISATION, GENERATION ET AGILITE (MDE1)

Je souhaite réagir à l'article "Productivité, agilité, industrialisation : même combat?" paru ce mois dans le numéro 113 du magazine PROgrammez. Cet article fait parti d'un dossier spécial dédié à la productivité.

L'auteur y défend l'efficacité de la démarche Model-Driven avec génération du code. Il utilise certains arguments pour lesquels j'ai d'autres points de vue.

Tout d'abord, l'auteur affirme que "[la maintenance des modèles] est moins coûteuse que celle d'un code car celui-ci est dépendant de la technologie, des évolutions des outils, etc."
L'auteur a en tête les Platform-Independant-Models qui ne dépendent pas de la plateforme technologique. Par contre, il ne faut pas se leurrer: le modèle est très dépendant de la technologie MDE, de l'outil de modélisation, des outils de transformation de modèles et de l'outil de génération de code. Ainsi, les modèles restent dépendants de la technologie et des évolutions des outils.

Ensuite, l'auteur affirme que "L'éclectisme du code résultant des cultures et sensibilités diverses et variées des programmeurs se paye aussi comptant au moment du calcul des prix de revient des applications." Par expérience, j'ai remarqué qu'il existe autant de manières de modéliser une idée que de manières de la coder. Malgré un standard commun, j'ai pu constater que plusieurs développeurs au sein d'un même projet modélisent de manières différentes. UML n'est qu'une notation. De même, plusieurs rédacteurs rédigeront une même histoire de façons multiples.

Puis, l'auteur donne un avis avec lequel je suis fortement en désaccord: "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!" La pratique du pilotage par les tests, le remaniement en continu, la suppression systématique des duplications et l'adoption de la solution la plus simple qui soit viable sont des voies pour modifier du code à moindre effort. Surtout, le pilotage par les tests (systématiques et couvrants) offre la seule garantie concrète que l'application ne régresse pas suite à une modification de code. La génération de code à partir de modèles n'offre pas de telles garanties. Qu'est-ce qui vous garantit que les défauts n'ont pas été introduits dans le modèle? Pourquoi les diagrammes n'exprimeraient que des idées justes? Pourquoi un modèle serait-il correct à priori? Seule l'exécution du logiciel permet d'affirmer qu'il est correct. Ne croyez pas que je dévalorise les modèles. En équipe, nous modélisons tous les jours ... avec des marqueurs et sur des tableaux blancs. Et puis, si nous modélisons en mode esquisse, c'est aussi parce que nous avons échoué en approche MDE ...

Plus loin dans son article, l'auteur avance que "maintenir un logiciel c'est raisonner sur des modèles UML sans présumer d'une technologie spécifique." Pour toutes les raisons vues précédemment, je ne suis d'accord avec aucune partie de cette affirmation. Nous maintenons efficacement des logiciels sans avoir recours à des modèles électroniques. Aussi, la modélisation électronique présume de technologies spécifiques.

Enfin, un leitmotiv flotte à travers l'article. Il est dit qu'il n'est pas toujours possible de développer avec "du personnel d'excellence", des "programmeurs hors-pairs". Parfois, il faudrait se contenter de "simples développeurs". Et puis pourquoi parle t-on si souvent de programmeurs et non simplement de développeurs? La modélisation et la génération de code seraient-ils des outils permettant de tirer le niveau vers le bas? Ces pratiques permettraient-elles de ne pas développer les compétences des équipes? Clairement, il me semble que l'auteur ne fait pas confiance aux développeurs et que la programmation est considérée comme une tâche ingrate.

Mais, pourquoi le mot "agilité" est-il utilisé dans le titre?

SCRUM ET ICEBERGS

Le dernier billet de Bruno Orsier m'a beaucoup plu. Notamment, il m'a fait découvrir la passionnante vidéo d'une conférence donnée par Ken Schwaber à Google.

Parmi les sujets abordés par le co-créateur de Scrum, il y en a un qui me touche beaucoup en ce moment. Il y a peu, je l'ai abordé à l'occasion d'un billet sur les conflits qui apparaissent tôt lorsqu'on pratique une démarche agile.

Ken Schwaber affirme que la pratique de Scrum par une organisation est un test de sa capacité à accepter les problèmes qui seront soulevés souvent très tôt.

Ces problèmes sont dévoilés tôt par les démarches agiles car elles visent à livrer très tôt un produit partiel et potentiellement livrable. Livrer au plus tôt un produit oblige à exercer au plus tôt toutes les formes de collaboration, de communication et de travail d'équipe nécessaires à la création de valeur pour le client. Exercer au plus tôt toutes les activités révèle au plus tôt les obstacles à la création de valeur.

Ces problèmes ne sont pas dûs à la pratique de Scrum. Ils existaient bien avant, cachés et ignorés. Par contre, l'application de Scrum (ou d'une autre démarche agile) révèle vite la partie immergée de l'iceberg. La transparence, le retour d'information et le cycle itératif et incrémental contribuent à identifier au plus vite les obstacles.

Révéler les freins à la productivité est un test pour l'organisation. Aura t-elle la maturité et le recul pour accepter ces obstacles en son sein? N'est-il pas plus confortable à court terme de revenir à une ancienne démarche et de se rassurer en pensant que tout va bien pour le moment?

Au sein d'une même organisation, considérons deux projets. L'un travaille en cycle en V alors alors que l'autre avance en agile. Immanquablement, le deuxième projet révèlera plus tôt des difficultés. Quelle conclusion hâtive est si aisée?

Comme j'ai déjà eu l'occasion de le dire lors d'un précédant billet, nous avons déjà vécu cette situation. Sur un projet d'envergure, nous avancions en mode eXtreme-Programming au sein d'un programme plus large travaillant en cycle en V. A l'époque, on nous a reproché de révéler trop tôt et trop fréquemment des problèmes. Notre équipe dénotait car elle butait déjà sur des obstacles. Notre organisation n'avait probablement pas la capacité de reconnaitre que nous déterrions tôt certains problèmes en son sein.

De même, lorsque tôt dans le projet les mesures de vélocité montrent que le produit ne pourra être livré à la date anticipée, l'organisation sera tentée de penser que l'équipe est inefficace alors qu'elle ne fait que révéler tôt que le planning initial est intenable sans réorganisation. Alors, plusieurs choix sont possibles: refuser d'admettre les faits, trouver une organisation projet mieux adaptée, revenir à une ancienne démarche de travail ou exiger une plus grande vélocité, ce qui se fera immanquablement au détriment de la qualité et donc de la date de livraison.

Face à une telle situation, l'organisation doit décider si elle veut agir sur le problème ou sur ce qui a révélé le problème. Accepte t-elle de voir la partie immergée de l'iceberg? En effet, l'organisation passe un test de maturité.

AGILE TOUR VALENCE VU PAR LES PARTICIPANTS

Ainsi, l'Agile Tour est passé à Valence le jeudi 23 Octobre 2008. Nicolas Blanpain a synthétisé les questionnaires de satisfaction remplis par les participants.

Il s'avère que 111 participants se sont déclarés le jour J à l'accueil, sans compter les membres de l'ESISAR. Le taux de participation est de 78% du nombre d'inscriptions. 12% des participants se sont présenté sans être préalablement inscris. 70% des participants ont eu la gentillesse de remplir un questionnaire de satisfaction dont vous lisez actuellement une synthèse. Les participants étaient à 50% des développeurs, à 20% des chefs de projet et à 15% des managers hiérarchiques. Sur une échelle de familiarité avec l'agilité de 1 à 5 par ordre croissant, les participants s'évaluent en moyenne à un niveau de 2. Il ne s'agit donc pas encore d'une communauté de praticiens.

Concernant la valeur apportée par cette demi-journée aux participants, 96% d'entre eux affirment qu'ils reviendront en 2009. En moyenne la réponse aux attentes des inscris est notée à 3,97 sur 5. Quand à elle, l'appréciation globale de l'évènement est évaluée en moyenne à 4.35 sur 5. Concernant le format de l'évènement, 44% des participants sont favorables au maintient du format sur une demi-journée alors que 38% préfèreraient un évènement sur une journée complète. Du point de vue organisation de l'évènement, sur une échelle de satisfaction croissante de 1 à 5, l'accueil des participants a été noté à 4.61, la restauration a été appréciée à 4.57, l'introduction et la conclusion ont été notées à 4.33, les infrastructures ont été appréciées à 4.54 et le timing a été évalué à 4.84.

Parmi les sujets attendus pour la prochaine édition, nous trouvons une présentation des méthodes agiles les plus courantes, la conduite du changement, convaincre dans un environnement hostile, la gestion des conflits, l'agilité dans l'industrie, agilité et criticité, le management agile, l'entreprise agile, agilité et sous-traitance avec la fameuse contractualisation des prestations agiles.

Parmi les aspects positifs, les participants ont apprécié la qualité des présentations, l'accès à des ateliers ainsi que les compétences, le dynamisme et l'enthousiasme des orateurs. Aussi, ils ont retenu la convivialité de l'évènement et le respect d'un timing soutenu.

En revanche, les participants ont regretté le peu de temps restant pour les questions/réponses. Le format en 50min semble un peu court pour les présentations. Aussi, il faudrait identifier les pré-requis pour les séances, voire proposer des circuits thématiques.

Parmi les orateurs et participants, certains ont publié des billets. Vous pouvez lire ceux d'Alexandre Boutin, d'Emmanuel Etasse,de Bruno Orsier, d'Aline Paponaud, de Developpez.com.

A partir des questionnaires, la rétrospective de l'évènement par les organisateurs permettra d'identifier des axes d'amélioration pour la prochaine édition. Ce travail aura lieu la semaine prochaine.

Merci à Nicolas pour sa grande implication dans l'évènement et pour cette synthèse. A l'année prochaine!

PRATIQUES D'EQUIPE - 4EME EDITION

Voici la quatrième édition de l'article décrivant les pratiques de notre équipe de développement.

Cette édition tient compte des remarques de relecture faites par Rémy Sanlaville et par mon chef de service. La principale différence est l'ajout de d'appréciations sur la rentabilité de chaque pratique.

Vous pouvez consulter la nouvelle version de l'article là: http://manu40k.free.fr/articlePratiquesDEquipe.pdf

Attention, le document pdf est assez volumineux car il contient de nombreuses photos de l'équipe "en action".

Une cinquième édition pourra inclure les pratiques de planification d'itération et de rétrospective d'itération, ainsi que les pratiques techniques.

PROGRAMMEZ PAR CONTRAT!

Vous avez sûrement entendu qu'il est peut être efficace de favoriser la collaboration avec le client plutôt que la négociation du contrat?
Et bien, je vous assure qu'il est efficace de programmer par contrat!

Cela n'a rien avoir avec la dualité collaboration/contrat du Manifeste Agile, mais cela a peut-être suscité votre curiosité. Pour découvrir en quoi la programmation par contrat contribue à la mise en pratique des principes agiles et du Lean, lisez le court article suivant: Programmez par Contrat!

ANALOGIES ENTRE L'EQUIPE ET SON LOGICIEL (2NDE EDITION)

La récente conférence de Géry Derbier à l'Agile Tour à Valence et les conflits que nous avons vécu il y a peu sur notre projet m'ont amené à ajouter d'autres dualités dans mon article sur les analogies entre une équipe et son logiciel.
La seconde édition de l'article est consultable ici.

AGILE TOUR 2008 VALENCE - REGIS MEDINA

Pendant 50 minutes, Régis Medina (Crossbow Labs) remanie du code en direct.
Cette session permet de recentrer l'attention des participants sur le (beau) code et les pratiques techniques.