Ddj Architecture & Design Agile Package Implementations

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

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

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 ?

Ddj Architecture & Design Agile Package Implementations

by Emmanuel Hugonnet on Mar 10, 2009

Accessibility

Tags

Upload Details

Usage Rights

1 Embed 2

Statistics

Ddj Architecture & Design Agile Package Implementations — Document Transcript