MtoM Mag - Le journal de l'MtoM.

C’est un bouclier contre la dette technique, un rempart au tout jetable consommateur de ressources. C’est aussi et surtout le résultat de nombreuses années d’expérimentations et d’essai, de compromis et de perfectionnements. Pour aboutir à ce degré de perfection, il a fallu essuyer quelques plâtres.

L’alliance de la créativité, de la liberté et de la rigueur

La philosophie du développement applicatif a beaucoup évolué, et avec elle ses méthodes, ses cadres et les façons dont on peut le conceptualiser en entreprise, d’un côté comme de l’autre, faiseur et client. Joy Inc. paru en 2014, de Richard Sheridan, le co-fondateur de Menlo Innovations, est certainement l’ouvrage dont je conseille le plus la lecture à toute personne souhaitant disposer de développements cousus main. S’extirpant des cadres méthodologiques inefficaces, Richard Sheridan a laissé libre cours à l’imagination de ses équipes pour expérimenter de nouvelles approches. Le pair programming, (le développement en binôme en direct) et les tests unitaires en sont issus.

Pour pousser cette pratique à l’extrême (fondements de l’extreme programming ou XP), Sheridan et son équipe se sont appliqué une approche encore plus rigoriste : le TDD, test-driven development ou développement piloté par les tests. À ce stade, le travail consiste à écrire le code de manière itérative en corrigeant les erreurs en temps réel. L’objectif est évidemment d’atteindre un ensemble parfaitement cohérent, dont la solidité est garantie par une qualité de programmation de bout en bout. Cerise sur le gâteau, l’équipe gagne un temps infiniment précieux. Le succès du procédé a conduit à une importante documentation, de multiples articles et commentaires, et la reconnaissance du milieu.

Quand l’amélioration continue se bonifie

Une application bien conçue est une application dépourvue (peu ou prou) de bogue, ce qui conditionne à la fois sa résilience à long terme et sa capacité à accueillir des évolutions. Une statistique intéressante doit ici être livrée : 60 % du temps d’un développeur sont consacrés au débogage, lequel consiste à trouver puis à corriger les erreurs. Pour faire chuter cette dramatique statistique, pair programming et TDD devraient en toute logique s’appliquer. Mais ils ne suffisent pas.

Les méthodes de gestion ont, elles aussi, beaucoup évolué, à l’instar des méthodes agiles, qui, si elles s’appliquent à un projet de développement applicatif, n’en sont pas exclusives. Le fameux cycle en V tend à disparaître des usages (même si d’aucuns diraient qu’ils le rencontrent encore trop souvent à leur goût), au profit de sprints avec la méthode scrum et de cycles itératifs avec Kanban. Mais, ce qui a principalement évolué aux yeux des clients est moins l’adoption formelle du DevOps et des méthodes agiles que les retours plus nombreux et plus réguliers des équipes de développement. En fin de compte, le respect plus ou moins rigoriste des cadres de gestion est un sujet de prestataire, pas un sujet client, qui se fiche bien de savoir si les rituels sont respectés à la lettre tant que la fonctionnalité requise est proprement développée, dans les temps impartis. Ce point de vue a ceci d’utile qu’il permet de prendre du recul sur le dogme. Quitte à piocher à droite à gauche dans les différentes méthodologies pour donner de l’oxygène aux équipes, il présente l’immense avantage de remettre le critère de la qualité au premier plan. Chose fantastique, cette approche du développement par la qualité aide substantiellement au passage vers le DevOps, dans les entreprises encore frileuses à programmer plus de deux ou trois mises à jour importantes par an. Doit-on en conclure que la recherche de qualité participe de l’adoption des meilleures pratiques de gestion à un contexte donné ? Certainement.

L’audace d’une culture commune

Le Software Craftsmanship s’infiltre et se métamorphose en fonction des contextes et des cultures d’entreprise. S’il est affaire de compromis, c’est bien parce qu’il n’appartient pas à l’entreprise cliente de se plier aux méthodes de ses prestataires.

Ce que l’évolution de la philosophie du développement nous enseigne, c’est que l’on n’impose pas de méthodologie à ses clients, aussi essentielle soit-elle, et malgré tous les efforts et le travail nécessaires pour être maîtrisée. L’agilité que l’on souhaite insuffler se trouve dans une approche beaucoup plus douce, plus subtile, tout en rondeur, à petits pas. Parce que tout est affaire de contexte qu’il faut savoir saisir.

L’interaction entre les métiers et les développeurs est un espace dans lequel on s’est le plus interrogé sur les bonnes méthodes à appliquer. Pendant des années, l’incompréhension et les malentendus ont fait rage. De ces débats enflammés ont émergé des techniques aux noms exotiques comme les 5 Why et les 3 Amigos, qui s’intègrent aux BDD, behavior driven development ou DDD, domain driven design. Elles ont toutes vocation à établir un langage commun et favoriser la compréhension des besoins et des contraintes des uns et des autres. Appliquées avec la certitude d’aboutir (c’est important), ces techniques conduisent développeurs et métiers à prendre la véritable mesure des challenges de chacun et à aborder l’exercice avec toute la connaissance requise.

Encore des techniques, des méthodes et des cadres, me direz-vous. Mais elles ne sont que l’affaire des équipes de développeurs. Il n’est d’ailleurs pas utile d’en citer les noms, tant que la qualité reste à la barre pour piloter le processus.

https://www.bluesoft-group.com/