You are on page 1of 5

Progiciels en mode Agile

Scott W. Ambler
Les installations de progiciels1 sont plus fréquentes que vous ne l'imagineriez.
Scott examine les mythes entourant le développement logiciel agile.
Scott travaille en qualité de Practice Leader Agile Development pour IBM Rational.

Traduction par Emmanuel Hugonnet de l’article Agile Package Implementations avec
l’aimable autorisation de Scott Ambler et de Jon Erickson du Dr. Dobb’s Journal.

Lorsque l'on parle d'agilité, dans 99 cas sur 100 il s'agit d'un nouveau logiciel à développer.
Parmi les rares articles qui vont au-delà du développement logiciel, 1 sur 100 peut être
explique comment adopter une approche agile pour les progiciels. C'est vraiment dommage
car les progiciels, que l'on appelle communément "solution sur étagère" (COTS2) sont
couramment rencontrés. Casper Jones, dans son livre Applied Software Measurement,
Third Edition, estime que parmi les 500 plus grandes entreprises, les packages COTS
représentent 35% de leurs logiciels, environ 50% pour les entreprises de taille moyenne, et
jusqu'à 100% pour les entreprises de moins de 100 personnes. La question devient, comment
mettre en œuvre les stratégies agiles avec des progiciels ?
La Figure 1 décrit le cycle de vie d'une solution sur étagère suivant la terminologie de
l'Unified Process pour vous aider à sortir de la vision séquentielle et en cascade qui
prédomine dans la mise en œuvre de solutions toute prêtes. A la surface, ce processus parait
séquentiel, mais cela ne signifie pas que votre approche ne peut être agile.

Figure 1

La bureaucratie peut vite devenir envahissante sur un projet de mise en œuvre de progiciels –
le désir de prendre la décision parfaite plutôt qu'une décision acceptable motive le
management à exiger des niveaux élevés de bureaucratie ce qui ne fait qu'augmenter les
risques du projet. La stratégie agile est de se concentrer sur les activités à forte valeur ajoutée,
de travailler le strict nécessaire pour réaliser les objectifs, et d'éviter la documentation
superflue et les revues inutiles. La chose la plus importante à réaliser est de constituer une

1
Ndt.: selon Wikipédia un progiciel est un logiciel commercial vendu par un éditeur sous forme d'un produit
complet, plus ou moins clés en main. Le terme résulte de la contraction des mots produit et logiciel (mot-valise).
2
Commercial Of-The Shelf
équipe de personnes compétentes et de confiance pour réaliser la tâche. Si cette option n'est
pas viable, alors le meilleur conseil que je puisse vous donner est d'arrêter tout jusqu'à ce que
vous ayez les moyens de le faire.

Au Commencement
Au début de chaque projet, vous devez choisir le processus adapté à la situation donnée. Tout
d'abord il vous faut faire le choix entre acheter et réaliser, et si vous décidez d'acheter alors
vous devez modifier vos processus métier pour être en phase avec ceux de la solution choisie.
Casper Jones rapporte que si vous devez modifier plus de 25 pourcents du système, alors il
reviendrait moins cher, à long terme, de développer une solution spécifique. Il recommande
aussi d'éviter de modifier plus de 15 pourcents d'un progiciel. Si l'éditeur est hostile à l'idée de
vous aider à modifier son logiciel, alors la recommandation passe à 5 pourcents. Ensuite,
prenez une version initiale de votre processus et redimensionnez la selon les cas. Par exemple,
vous devrez probablement suivre un processus différent selon qu'il s'agit d'un logiciel à 500 $
ou à 500.000$ -- votre processus n'est pas à taillé une fois pour toutes.

Supposons que vous ayez décidé d'acheter, la prochaine question à vous poser est de savoir si
la solution a déjà été choisie. Idéalement, tout achat d'une solution toute prête devrait se faire
sur des critères techniques, financiers et opérationnels, mais en réalité ces décisions sont
souvent politiques. Dans ce cas il ya très peu d'intérêt à évaluer différentes solutions. Cela
reste vrai même si vous voulez produire suffisamment de documentation pour laisser croire
que vous avez suivi le processus pour sélectionner la solution déjà choisie – ce n'est pas
seulement un formidable gâchis, c'est aussi une question d'éthique.

Si vous êtes réellement dans la position de pouvoir choisir entre différents produits, alors vous
devez choisir par les exigences. Cela ne signifie pas que vous devez avoir des spécifications
détaillées, mais il vous faudra sûrement plus qu'une série d'histoires d'utilisateur écrites sur
des petites fiches. Cette nécessité de prendre une décision à partir d'exigences peut laisser
croire que l'on ne peut pas être agile pour choisir une solution sur étagère, alors que c'est tout
le contraire. L'approche agile est de reconnaitre qu'il vous faut une spécification des exigences
et que donc vous devez fournir le travail minimal nécessaire pour l'obtenir. Donc, il ne vous
faut pas un document de spécification de 50 pages mais juste de 5 à 10 pages.
En plus de comprendre les exigences métier, voici quelques éléments à considérer pour vos
spécifications:
• Les exigences techniques doivent refléter la vision de l'architecture technique et métier
de votre entreprise. Le logiciel que vous achetez doit s'intégrer dans votre
environnement global – il ne fonctionne pas en vase clos.
• Vous devez demander à l'éditeur quelles sont les stratégies d'adaptation qu'il supporte.
La façon dont vous modifierez le code et les données est absolument critique pour le
développement et la maintenance.
• Identifiez les stratégies d'intégration supportées par le logiciel. Ce dernier va devoir
interagir avec vos différents systèmes existant, et ceux-ci ne supporteront que
certaines stratégies spécifiques d'intégration.
• Demandez le taux de réussite de l'éditeur. Allez-vous acheter un logiciel que 90% des
entreprises éprouvent des difficultés à déployer ?
• Vous devez définir vos attentes en termes de qualité. Le logiciel est-il fourni avec une
suite de tests de régression complète ? Si ce n'est pas le cas, c'est un sérieux problème
pour une équipe agile qui s'attend à cet atout.

Une fois que vous avez défini vos exigences, vous devez identifier les différents logiciels. La
première étape est de faire une recherche en ligne pour identifier les candidats potentiels. Pour
les gros logiciels vous pouvez envoyer une demande d'information (RFI) aux éditeurs et leur
demander de noter leur logiciel selon les exigences définies, une étape qui peut prendre du
temps mais peut réduire votre coût global. Beaucoup d'entreprises veulent avoir le choix
parmi au moins trois logiciels, mais ce n'est pas toujours réaliste. Dans beaucoup de cas, il
existe une voir deux (si vous avez de la chance) solutions viables. Ajouter des candidats non
pertinents à votre liste vous fait perdre du temps à vous mais aussi au vendeur.

Une fois que vous avez réuni toutes les informations sur les candidats potentiels, vous devez
analyser et classer vos différentes options. C'est là que les soucis commencent pour de
nombreuses entreprises car elles recherchent la décision parfaite, alors qu'il leur suffit de
prendre une bonne décision– atteindre la décision parfaite prend du temps et coûte cher, là où
une bonne décision est plus rapidement atteinte et à moindre coût. Si, par exemple, vous
passez trois mois à comparer cinq logiciels et vous vous décidez pour le C. Vous achetez donc
le C et deux mois plus tard une nouvelle version de A sort qui est maintenant légèrement
meilleure que C. Le malheur a frappé, votre décision n'est plus parfaite! Qu'une nouvelle
solution sorte de la mêlée arrive continuellement, ne vous faites pas prendre dans le tourbillon
de la prise de décision.

Un point important à noter est qu'une fois l'analyse des différentes options viables est faite,
vous savez à peu près quelle solution va répondre le mieux à vos besoins. Donc, au lieu
d'investir du temps et de l'argent pour "cuisiner" les produits, vous feriez mieux de choisir la
meilleure option et prouver qu'elle répond à vos besoins. Cette stratégie s'avère payante car si
une solution sort de la mêlée, pour peu que l'analyse ait été correctement réalisée, il est fort
probable qu'il s'agisse de la solution que vous aller retenir. Si plusieurs solutions tiennent la
corde d'après votre analyse, alors peut importe celle par laquelle vous allez commencer. Si
vous avez les ressources disponibles, vous pouvez vouloir tester plusieurs solutions en
parallèle, mais cela augmentera les délais du projet pour pouvoir faire les différentes revues
avant de choisir le logiciel "parfait".

Le prouver avec un logiciel qui fonctionne
Dans la méthode Unified Process, la phase d'Elaboration a pour but premier de prouver que
l'architecture tient la route en faisant réaliser par une petite équipe, généralement le cœur de
votre équipe de développement, un squelette de bout en bout de votre système. On fait cela en
réalisant juste ce qu'il faut des fonctionnalités décrites par les exigences les plus difficiles
techniquement. Lorsque l'on passe aux solutions sur étagère, le but est d'installer le produit et
de faire le minimum de ce qu'il faut pour l'intégrer dans le cas techniquement le plus difficile
afin de valider qu'il s'adapte bien à votre environnement comme promis. C'est durant la phase
de Construction que l'on va mettre de la chair sur ces os.

Pour rester le plus agile possible, n'oubliez pas de faire le strict nécessaire mais sans plus –
l'Elaboration devrait prendre une ou deux semaines, et non quelques mois ou années. Si
l'intégration avec votre système de comptabilité est critique, alors faites ce qui est nécessaire
pour pouvoir connecter les deux systèmes et permettre l'échange des données importantes
entre eux. Bien qu'à terme vous deviez échanger 2000 types de données entre ces systèmes,
vous pouvez prouver que le logiciel s'intègre correctement en partageant uniquement 50 types
de données. Ne vous inquiétez pas, vous vous occuperez du partage des 1200 autres types
durant la phase de Construction (par une approche itérative vous vous rendrez compte que
vous n'aviez pas besoin de tout ce que vous pensiez). Souvenez vous que vous avez juste
besoin d'avoir un bon ressenti quant à l'intégration du logiciel, pas d'une validation complète,
aussi essayez toujours de ne faire que le strict minimum durant l'Elaboration.

Les 50 types de données sont souvent choisis par rapport à leur sémantique – choisissez les
éléments qui sont cruciaux pour la réussite de votre entreprise. Si le logiciel ne supporte pas la
sémantique de vos données, et si vous n'arrivez pas à traduire dans les sémantiques supportées
par le logiciel ce que vous voulez, ou si vous ne voulez pas modifier votre manière de
travailler pour vous adapter au logiciel, vous vous apercevez alors que ce logiciel ne
correspond pas à vos besoins. Dans ce cas, vous devez passer au logiciel suivant de votre liste
s'il en reste un. Si ce n'est pas le cas alors vous devez abandonner votre idée ou construire le
système vous-même.

L'un des points architecturaux important à valider durant la phase d'Elaboration est de valider
la pertinence des stratégies d'adaptation du produit. Modifiez-vous le comportement du
logiciel par des fichiers de configuration ou des tables ? Devez vous mettre à jour certaines
portions spécifiques du code source ? Pouvez-vous modifier le schéma de base de données
pour y ajouter vos propres types de données ? Comment sont gérées les mises à jour de
l'éditeur? Vous avez heureusement identifié ces stratégies durant la phase d'Inception mais il
vous faut maintenant prouver qu'elles fonctionnent.

Agilité à petite échelle
Une fois que vous arrivez à la phase de Construction vous voilà vraiment dans un monde
agile. Vous priorisez le travail à réaliser pour adapter la solution, chaque étape produisant un
logiciel fonctionnel qui réalise les fonctions prioritaires. Puisqu'on part d'un produit existant,
chaque fonctionnalité réalisée durant une itération correspond à une fonctionnalité de la
solution adaptée à vos besoins. Cela implique soit une modification du logiciel en lui-même
soit une intégration supplémentaire dans votre système existant -- vous devrez accéder aux
données restantes dans votre système de comptabilité des centaines de fois par itération avant
que votre travail soit terminé.
Faites attention car vous êtes sur une pente savonneuse lorsque vous adaptez la solution, car
dans une approche itérative il est tentant d'ajouter une itération de plus pour la mettre
d'aplomb. Ce que je veux dire par là c'est que votre responsable produit doit suivre la
recommandation de Casper Jones – si vous devez modifier plus de 15% de la solution alors
vous avez probablement un problème – aussi restreignez vous de modifier le produit jusqu'à e
qu'il réponde parfaitement à vos besoins. D'après moi, si vous avez besoin d'un produit parfait
alors il ne faut pas en acheter un mais le faire vous-même.

Un point important est de suivre les stratégies de modification supportées par le vendeur – si
vous vous en éloignez, vous vous retrouverez au final à posséder le code et vous aurez des
difficultés à appliquer les mises à jour du produit. Une grosse part du travail se fait autour de
la sémantique des données, que ça soit par la mise en place de code de transformation ou par
le remaniement de vos systèmes et sources de données pour se conformer à la sémantique du
produit.

Les agilistes font au minimum des tests de régression durant le développement, et dans le
meilleur des cas, développent suivant une approche pilotée par les tests. Cela pose problème
si votre logiciel n'inclut pas une suite de tests de régression, même si on doit se poser la
question de pourquoi choisir un logiciel difficilement testable. Cela étant dit, si le vendeur ne
fournit pas une suite de tests adéquate il va vous falloir couvrir le logiciel avec un ensemble
de tests en mode boite noire. Il peut être intéressant de s'associer à l'éditeur dans ce cas, voir
de lui revendre les tests par la suite afin de rentrer dans vos frais.

La phase de Transition est la même que pour un développement classique. Vous devez
finaliser vos efforts de tests, corriger les derniers défauts, annoncer la sortie du système,
former le personnel, éventuellement faire une phase de pilotage ou le faire tourner en parallèle
des systèmes existants, et enfin le passer en production. J'ai décris une approche agile de cette
étape dans mon article The Agile End Game.

Dernières remarques
Intégrer des logiciels est risqué. Au départ ça semble avoir du sens d'un point de vue métier
mais vous pouvez rapidement voir surgir les problèmes si la bureaucratie prend le contrôle.
En appliquant les stratégies disciplinées de l'agilité à la mise en place de solutions sur étagère
vous augmentez vos chances de succès. Ces stratégies se basent sur la création d'une équipe
de confiance pour faire le travail, leur donner les moyens pour le faire véritablement, faire le
strict minimum pour pouvoir prendre les décisions qui doivent être prises, et adapter juste ce
qu'il faut la solution pour qu'elle réponde à vos besoins.

L'approche agile à la mise en œuvre de produits tiers inquiète de nombreuses personnes, car
elle diffère drastiquement de la stratégie traditionnelle. En bref, si votre entreprise n'est pas
capable de monter une petite équipe pour avoir une première idée sur un produit en une
semaine ou deux, alors il y a peu de chances que vous soyez capable de mettre en œuvre une
solution complète. Nous savons que la stratégie traditionnelle ne fonctionne pas très bien,
alors pourquoi ne pas tenter le coup avec une approche agile ?