Gestion du changement

XP traite le changement comme une réalité plutôt qu’un indésirable, et propose une approche différente pour l’intégrer au processus de développement.

Le passé

Les cours de génie logiciel, la littérature, et presque toutes les méthodologies de développement jusqu'au milieu des années '90 suggéraient que le coût relié à des changements dans les spécifications d'un problème ou le design d'une solution augmente de façon exponentielle à mesure que le projet avance. D’innombrables références et études sont disponibles dans des livres et articles, et l’idée est une notion acquise pour plusieurs générations de gestionnaires de projet. En fait, certaines méthodologies basées sur le modèle en cascade reposent entièrement sur cette prémisse et ignorent complètement les requêtes de changement, ou encore imposent des processus très stricts pour gérer ces requêtes (possiblement dans le but de les éliminer).

Dans la réalité, quelqu'un a-t-il déjà travaillé sur un projet d'informatique (ou n'importe quel projet) où il n'y a pas eu de changement? Est-ce même possible? Peu importe la taille du projet, peu importe le contexte, peu importe l'industrie, le changement est inévitable. Depuis qu'il y a des projets d'informatique, il y a des requêtes de changement; pourquoi les ignorer? Pourquoi supposer que ce projet sera différent?

Retour vers la réalité

Le court cycle de développement utilisé dans XP règle le rythme du projet, et a un effet direct sur la qualité du produit fini. En ayant des mises en production fréquentes, les éléments les plus importants sont produits en premier; les mises en production suivantes permettent d’ajouter des fonctionnalités tout en testant le résultat à chaque nouvelle étape. Le sujet sera abordé plus en détails dans un futur article.

Le graphique présente le coût du changement d’après XP. On peut voir que le coût du changement augmente légèrement durant les premières étapes, alors que le design devient plus complexe et que l’effet d’un changement a de plus en plus de répercussions. Après un certain point, cependant, le coût atteint un plateau et diminue légèrement; ceci est causé par la « factorisation » du programme (expression pompeuse pour dire « simplification »).

Une des grandes forces de XP est d’accepter le changement comme une réalité, et de l'inclure comme partie intégrale du processus de développement. Les boucles rapides de développement-test-feedback permettent d'intégrer le changement de façon contrôlée, sans avoir à "revenir en arrière". En permettant au changement de prendre place à tout moment, il est possible de prédire le temps et le coût associé, et de rapidement présenter au client la conséquence de ce changement. Le coût du changement devient donc une constante plutôt qu’une variable.

Bien entendu, une requête qui aurait des conséquences profondes sur le design d'une base de données ou d'une architecture devra être évaluée sérieusement, et le client sera informé rapidement du coût en temps et ressources; il est possible qu'une requête de changement soit rejetée. De la même manière, il serait naà¯f de complètement ignorer les réalités économiques du projet, et d'accepter d'implanter des changements de toutes sortes, n'importe quand, tout en continuant de viser une date de livraison fixe. Le gestionnaire du projet garde le doigt sur le pouls des variables: temps, étendue (scope), ressources, qualité; son intervention permet de garder le projet à un niveau réaliste tout en fournissant au client un maximum de résultats pour son investissement.

Le prochain article présentera la Programmation en paire, un des aspects les plus intéressants de XP pour son influence sur la vitesse du développement et la qualité des livrables.

Eric Lagacé