Le onzième commandement du développeur

Au cours de ma carrière dans le monde du développement informatique, j’ai vu de Merise à Agile de nombreuses approches ou méthodologies utilisées dans différentes organisations. Lorsqu’une nouvelle (meilleure naturellement) approche est diffusée, ceux qui l’adoptent ont tendance à avoir une attitude proche du zèle religieux. Les éditeurs de logiciels ont d’ailleurs constaté ce phénomène et emploient des « évangélistes produit ». Dans cette situation, les nouveaux convertis ont tendance à rejeter tout ce qui a été fait auparavant et adoptent une attitude « ceux qui ne sont pas avec nous sont contre nous », spécialement lorsque la nouvelle approche est encore le fait d’une minorité qui lutte contre une méthodologie établie.

Ce phénomène se passe aussi pour Agile, même si les mots mêmes du manifeste agile ( »bien que les éléments de droite aient de la valeur, nous accordons plus d’importance à ceux de gauche ») tentent d’éviter ce phénomène de terre brûlée. La plupart des coachs Agile favorisent aussi la prise de décision selon l’esprit de l’approche en fonction du contexte, mais pour certaines personnes il est plus facile de suivre aveuglément un modèle plutôt que d’absorber une philosophie. Vous connaissez le proverbe : « Donnez un poisson à un homme, il mangera un jour. Apprenez-lui à pêcher, il mangera toute sa vie. » Il est cependant plus facile d’apprendre à utiliser JUnit que de créer de bons cas de tests unitaires. Les puristes d’Agile ont vite trouver leur ennemi : le Waterfall, un processus dinosaure voué à l’extinction et dont on devrait retrouver des fossiles dans les couches du mainframique des l’histoire de la programmation entre deux listings de programmes Cobol. Ceux qui ont un peu plus de culture essaient de combattre RUP ou le CMMI qui sont au Waterfall ce que les tyrannosaures sont aux dinosaures, une évolution plus dangereuse et féroce qui tue des forêts entières pour produire la documentation des projets informatiques.

Le dernier numéro de Methods & Tools contient un article intéressant parlant d’une entreprise qui mélange le CMM et Scrum. Est-ce une hérésie pour les tenants de chaque approche? Peut-être. Est-ce que cet article nous dit qu’il faudrait tous faire la même chose? Non. Les auteurs décrivent seulement ce que la société pense sur la meilleure approche pour son contexte. Est-ce que cela fonctionne? Oui. Mon onzième commandement du développement est donc le suivant: oubliez les dix premiers. Si l’on pouvait résumer le développement de systèmes d’information en quelques règles, on le saurait déjà. Vous devez tout lire avec un esprit ouvert mais critique. Vous pourrez ainsi faire de meilleurs choix en fonction de votre propre contexte. Personne ne détient LA vérité sur les projets de développement de logiciel. Nous faisons tous des erreurs, ce qui est une bonne chose si nous pouvons en tirer des enseignements.