Le cycle Développement-test-feedback

Extreme Programming propose d'utiliser un cycle très court de design, développement et test, avec des mises en productions fréquentes.

Une chose à la fois

Les étapes indépendantes et ordonnées du modèle en cascade sont confortables et faciles à comprendre, mais présentent un inconvénient majeur: le délai entre le design de la solution et sa mise en production est trop long. Ce délai entraîne deux conséquences importantes:

1) les différences entre les besoins du client et la solution finale n'apparaissent qu'au moment où le programme est mis en production avec les utilisateurs;

2) le feedback du client et des utilisateurs n'est pas pris en compte durant le design de la solution, au moment où ce feedback aurait un maximum d'impact.

En présentant régulièrement au client la solution la plus courante, en acceptant les ajustements demandés par le client, et en incluant ces changements dans la prochaine itération, ces deux problèmes sont éliminés. Les différences entre la solution présentée et les besoins du client sont immédiatement visibles, et le client peut faire des ajustements ou préciser le besoin avant que d'autres fonctionalités soient implantées.

XP utilise des mises en production fréquentes tout au cours du projet, de façon à diminuer le risque et augmenter la valeur pour le client

L'article Gestion du changement présente en détails la façon dont le changement est inclus dans le processus de développement sous XP. Pour généraliser l'approche, le feedback du client et les ajustements faits pour corriger une erreur seront appelés "changement", bien qu'il s'agisse vraiment de "mise au point" des spécifications du problème ou de la solution.

Question de valeurs

En plus de permettre de faire des ajustements et d'assurer que la solution soit le plus près possible des besoins du client, des mises en production régulières présentent au client un retour rapide sur son investissement. A chaque itération, il est possible de voir un résultat concret, et de mesurer la valeur de ce résultat comparativement à l'effort et aux ressources qui ont été investis. Le gestionnaire du projet pourra aider le client à déterminer l'ordre dans lequel les différentes itérations seront complétées, de façon à créer un maximum de valeur.

Le concept de valeur n'est pas toujours facile à saisir pour une entreprise. Peu importe la taille de l'entreprise ou l'importance d'un projet, il y a de nombreuses variables à considérer. En voici les aspects les plus importants:

- Les coûts d'un projet incluent le matériel, les logiciels, les honoraires des consultants externes, le coût des experts internes, et la formation, pour ne nommer que les plus communs. À long terme, il faut également inclure le coûts des licenses pour les logiciels, et les coûts de maintenance de logiciels et infrastructure.

- En règle générale, la mesure de succès d'un projet d'informatique sera le revenu additionnel ou la réduction de la dépense qu'il aura généré. Bien des facteurs influencent ce calcul: réduction des pertes (temps, inventaire, livraison), augmentation de la productivité, meilleure qualité de l'information, intégration de départements (pour diminuer la redondance), et toute autre mesure spécifique à l'entreprise.

- Un aspect encore plus difficile à saisir est la perception de ce projet par l'entreprise. Si le projet ne semble pas créer de valeur pour l'entreprise, ou semble être redondant avec une fonction existante, il sera difficile de changer cette perception sans des chiffres concrets.

Une erreur commune sur de trop nombreux projets est de démarrer en douce, sous le radar, sans annonce ni support officiels. Un tel projet sera au mieux accueilli avec curiosité. Si le projet semble trop long (la durée est également une question de perception), l'intérêt diminuera et la valeur de ce projet pour l'entreprise sera de moins en moins évidente. Une façon facile d'éviter cette situation est de faire l'analyse coûts-bénéfices du projet, puis de présenter dans une annonce officielle le projet et sa raison d'être. Inutile ici de sortir la fanfare à chaque projet qui démarre, mais communiquer à toute l'organisation l'existence du projet et sa progression est essentiel à son succès.

Une chose à la fois (bis...)

Pour les développeurs, un court cycle de développement augmente la flexibilité, permet de corriger la solution, et de présenter rapidement le résultat au client. Mais qu’advient-il de la structure du programme? Dans le but d’augmenter la flexibilité, il semblerait que le design « apparaît » au travers des itérations du cycle, plutôt que d’être solidement établi à l’avance. Si tel est le cas, la qualité et la solidité de la solution finale sera au mieux douteuse.

Une étape importante de design a lieu durant la première itération, où tous les développeurs, le client et le gestionnaire du projet participent à l’élaboration d’un squelette de solution. La première itération est donc plus longue que les autres, principalement à cause de l’exercice de design, mais aussi parce que la mise en place d’un certain nombre de composantes du programme doit être complétée avant que quoi que ce soit puisse être livré. Une fois la structure mise en place, les itérations de développement peuvent être aussi courtes que quelques jours si nécessaire, et les mises en production de nouvelles fonctionnalités aussi fréquentes que l’équipe le désire.

Le prochain article présentera les Rôles de chaque membre d’une équipe de Extreme Programming, et les Événements d’un projet tel que vu par XP.

Eric Lagacé