Traduction de l'article de Scott Ambler pour le Doctor Dobb's Journal sur le déploiement de progiciel en mode Agile

1. 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 quot;solution sur étagèrequot; (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 équipe de personnes
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

2. 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 ?

3. • 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 quot;cuisinerquot; 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 quot;parfaitquot;.
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

4. 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.

5. 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 ?