Dans un précédent article, nous avons vu que créer un produit logiciel n’était pas compliqué… Et que par conséquent les méthodologies inspirées des industries lourdes et du BTP (Bâtiment et travaux publics) ne sont pas parfaitement adaptées. Nous ne sommes pas pour autant obligés de rester sans repère.
Je souhaite vous proposer un concentré d’Agilité : trois principes qui vous serviront de mini-guide, de devise, voire de credo. Oui, oui, j’ai bien dit trois principes et non quatre valeurs. Lesdits principes sont inspirés des travaux de Simon Powers. En toute modestie, mais surtout pour le jeu de mots, je me permets de les regrouper sous le terme Agile Manifesto Essence. AME donc!
Principe de complexité
La première chose à faire c’est de se souvenir, comme on l’a déjà vu, que créer un logiciel est une situation qui n’est certes pas compliquée, mais qui reste complexe. Et même complexe et adaptative.
Cela signifie que chercher à apporter une solution à cette situation va la modifier. Il est donc impossible de prévoir les résultats de nos actions. Nous ne pouvons établir de liens causes-conséquences qu’a posteriori. Quand j’obtiens quelque chose, je peux établir que c’est le fruit d’une action que j’ai réalisée au préalable. Il est impossible de procéder en sens inverse.
Par conséquent, les planifications très fines, les estimations utilisant des règles lourdes de calcul, et les engagements à très long terme sont peu adaptés au processus de création d’un logiciel. Dans une situation complexe telle que celle-là, les prédictions sont peu fiables.
Principe de proactivité
Si faire quelque chose modifie le problème, nous pourrions être tentés de ne plus agir en nous disant que cela ne sert à rien. Mais c’est oublier que ce n’est pas parce que nous n’avons pas obtenu le résultat escompté ou que le problème s’est modifié que nous n’avons pas accompli quelque chose ou que nous ne sommes pas arrivés à créer une situation intéressante.
C’est exactement ce que notre deuxième principe met en avant. Il s’agit du principe de proactivité. Même si la proactivité, telle que définie à l’origine par Viktor Frankl, comporte un volet sur l’appréhension des risques, ce n’est pas pour autant le fait de faire des actions par anticipation. Ce n’est donc pas l’opposé de la réactivité.
La proactivité consiste bien en la réalisation d’actions pouvant être faites après un événement (en réaction, donc), mais visant toujours à tirer le meilleur parti d’une situation, voire à tenter d’en extraire une occasion intéressante, qu’il s’agisse à l’origine d’une menace, ou pas.
La proactivité n’est possible que si nous disposons de la liberté de choisir. Elle nécessite du courage et de la volonté et surtout que nous soyons conscients de ses responsabilités.
Principe de personnes
Ces qualités, ce sont surtout ceux qui agissent qui doivent en être munis. C’est le troisième et dernier principe : le principe de personnes.
« Ce sont ceux qui font qui savent. » C’est comme cela que je le résumerais. Cela signifie que ceux qui sont sur le terrain, même dans le feu de l’action, sont les mieux placés pour prendre les décisions les plus adaptées, pour savoir quelles qualités, talents, ressources sont nécessaires, etc. Ces personnes vont faire les meilleurs choix parmi les possibilités qu’ils entrevoient. Il n’y a donc pas de personne malfaisante, souhaitant que la création du produit logiciel ne réussisse pas pour le simple plaisir de la faire échouer.
Il est néanmoins important de garantir les conditions idéales pour que les personnes expriment leur plein potentiel et leurs pleines capacités. Il faut notamment satisfaire au maximum leurs besoins de base (au sens de l’analyse transactionnelle surtout).
Nous pourrions facilement nous prêter au jeu des correspondances entre ces trois principes de l’AME et les quatre valeurs du Manifeste Agile (l’original) ainsi que ses douze principes sous-jacents. Nous vérifierions ainsi que tout ce qui est dans le Manifeste Agile peut être rattaché à un des trois principes de l’AME ou à une combinaison de ceux-ci. D’où le nom d’essence, voire de quintessence du Manifeste Agile que je me suis permis d’accoler à ces principes.
Certains sont même allés plus loin dans l’esprit de resserrement du manifeste et pensent qu’on peut condenser l’Agilité en un seul principe ! C’est le cas de Michael Sahota et de Alexey Krivitsky.
Retenir ces trois principes est bien plus simple (et efficace; d’après moi en tout cas) que de mémoriser les quatre valeurs et les douze principes du Manifeste Agile. Garder en tête et respecter ces trois principes permet de créer un produit logiciel de la meilleure façon possible.
Mais outre cette facilité de mémorisation qui nous rappelle à quel point les fondements de l’Agilité sont simples et pleins de bon sens, outre la beauté de l’exercice de réduction quasi mathématique du Manifeste Agile, suffisant, certes, en une version nécessaire, c’est surtout la mise en lumière d’angles d’approches différents de ceux utilisés habituellement qui constitue l’intérêt premier de L’AME.
Prenons ce premier exemple : la mise en oeuvre des trois principes (surtout des deux derniers) n’est pas forcément aisée. Mais leur énoncé permet de définir assez rapidement les contours d’un rôle d’accompagnateur agile spécialisé. J’aborderai ce sujet dans un prochain billet.
Pas de commentaire