Le Mythe du périmètre variable
De nombreux principes Agiles me semblent mal compris dans leur finalité. La notion de périmètre variable est le premier que je vais aborder. J’ai choisi cette technique qui est peut-être la plus mal interprétée par les informaticiens et la plus controversée par les utilisateurs.
Récemment dans une conférence, un utilisateur questionna « Est-ce que cela signifie que je n’aurais pas toute mon application ? ». Très naïvement le conférencier lui répondit « Exact, c’est cela le principe Agile ». Attristant pour l’utilisateur, amusant pour moi, mais dangereux pour un prestataire face à son client.
La première chose à comprendre concernant l’Agilité face aux contraintes d’un projet est justement la notion de contraintes. En synthèse le chef de projet doit composer avec 4 grandes classes de contraintes : le coût, le délai, le périmètre et la visibilité. Dans les approches classiques, la notion de visibilité n’était pas intégrée mais le chef de projet avait déjà pas mal à faire avec les trois autres qui ne pouvaient absolument pas être initialement variables, du moins en théorie. En pratique, le temps et les aléas du projet finissaient régulièrement par ramener ces ambitions prédictives à ce qu’elles étaient réellement : des vœux pieux.
L’apport de J. Martin avec la méthode RAD fut d’énoncer le premier postulat Agile, à savoir que pour une prédiction de projet puisse se réaliser à tous les coups, il fallait que certains aspects du pilotage soit fixes et que d’autres soient variables. Il proposa donc des techniques pour gérer les diverses variantes possibles de ces situations :
- Un délai fixe (dead line) est imposé : utilisez une Time-box pour limiter la durée des itérations.
- C’est le budget qui est fixe : utilisez le Design-to-cost (l’équivalent du backlog en « Agile moderne »).
Figure 1. - Les formes Agiles de planification stratégique
Lorsqu’en 1994, j’introduisis les notions additionnelles de visibilité, de risque et de fiabilité (ou de qualité) comme variables d’un projet, la couverture Agile venait de s’étendre à la notion de planification stratégique.
Comme, bien évidemment, aucune de ces variables ne pouvait être totalement indépendante des autres et que leur combinatoire devait pouvoir être facilement adaptée, je créais un utilitaire (Evaluateur, toujours disponible sur RAD.fr) permettant de faire varier simplement les quatre curseurs.
Figure 2. - Petit outil d’optimisation combinatoire
L’ensemble des contraintes se matérialisait, en termes de développement, par un périmètre priorisé déterminant des itérations. Cette « Architecture de réalisation » fondée sur le principe itératif incrémental adaptatif connue ses lettres de noblesse en 1999 dans un rapport de conseil du Gartner Group qui lui était dédié. Il est amusant de constater que cette approche tombée en désuétude n’a toujours pas grand-chose à envier au couplage actuel de Scrum à XP (à l’exception de l’extrême systématisation des pratiques dans XP).
Figure 3. - Itérations et formes de qualité
Conclusion : comme il vient d’être précisé, ce n’est pas systématiquement le périmètre qui est variable et heureusement !
