High Quality
Open the downloaded document, and select print from the file menu (PDF reader required).
Progiciels en mode Agile
Les installations de progiciels
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
.
avecl’aimable autorisation de
.
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 êtreexplique comment adopter une approche agile pour les progiciels. C'est vraiment dommagecar les progiciels, que l'on appelle communément "solution sur étagère" (COTS
) sontcouramment rencontrés. Casper Jones, dans son livre
, estime que parmi les 500 plus grandes entreprises, les packages COTSrepré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, commentmettre en œuvre les stratégies agiles avec des progiciels ?LaFigure 1décrit le cycle de vie d'une solution sur étagère suivant la terminologie del'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 paraitsé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 lemanagement à exiger des niveaux élevés de bureaucratie ce qui ne fait qu'augmenter lesrisques 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 documentationsuperflue et les revues inutiles. La chose la plus importante à réaliser est de constituer une
1
n progiciel est un logiciel commercial vendu par un éditeur sous forme d'un produitcomplet, 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 quevous ayez les moyens de le faire.
Au Commencement
Au début de chaque projet, vous devez choisir le processus adapté à la situation donnée. Toutd'abord il vous faut faire le choix entre acheter et réaliser, et si vous décidez d'acheter alorsvous 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 ilreviendrait moins cher, à long terme, de développer une solution spécifique. Il recommandeaussi d'éviter de modifier plus de 15 pourcents d'un progiciel. Si l'éditeur est hostile à l'idée devous 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 sila solution a déjà été choisie. Idéalement, tout achat d'une solution toute prête devrait se fairesur des critères techniques, financiers et opérationnels, mais en réalité ces décisions sontsouvent politiques. Dans ce cas il ya très peu d'intérêt à évaluer différentes solutions. Celareste vrai même si vous voulez produire suffisamment de documentation pour laisser croireque vous avez suivi le processus pour sélectionner la solution déjà choisie – ce n'est passeulement 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 vousdevez choisir par les exigences. Cela ne signifie pas que vous devez avoir des spécificationsdé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 toutle contraire. L'approche agile est de reconnaitre qu'il vous faut une spécification des exigenceset que donc vous devez fournir le travail minimal nécessaire pour l'obtenir. Donc, il ne vousfaut 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 vosspé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 votreenvironnement 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 ledé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 quecertaines stratégies spécifiques d'intégration.
•
Demandez le taux de réussite de l'éditeur. Allez-vous acheter un logiciel que 90% desentreprises éprouvent des difficultés à déployer ?
•
Vous devez définir vos attentes en termes de qualité. Le logiciel est-il fourni avec unesuite 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 dutemps 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, ilexiste 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 devezanalyser et classer vos différentes options. C'est là que les soucis commencent pour denombreuses 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 doncle C et deux mois plus tard une nouvelle version de A sort qui est maintenant légèrementmeilleure que C. Le malheur a frappé, votre décision n'est plus parfaite! Qu'une nouvellesolution sorte de la mêlée arrive continuellement, ne vous faites pas prendre dans le tourbillonde 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 lieud'investir du temps et de l'argent pour "cuisiner" les produits, vous feriez mieux de choisir lameilleure option et prouver qu'elle répond à vos besoins. Cette stratégie s'avère payante car siune 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 lacorde d'après votre analyse, alors peut importe celle par laquelle vous allez commencer. Sivous 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 revuesavant 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 quel'architecture tient la route en faisant réaliser par une petite équipe, généralement le cœur devotre équipe de développement, un squelette de bout en bout de votre système. On fait cela enréalisant juste ce qu'il faut des fonctionnalités décrites par les exigences les plus difficilestechniquement. Lorsque l'on passe aux solutions sur étagère, le but est d'installer le produit etde faire le minimum de ce qu'il faut pour l'intégrer dans le cas techniquement le plus difficileafin de valider qu'il s'adapte bien à votre environnement comme promis. C'est durant la phasede 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. Sil'intégration avec votre système de comptabilité est critique, alors faites ce qui est nécessaire
Add a Comment