Le secteur des SSII (Sociétés de

(1)

L

e secteur des SSII (Sociétés de Service en Informatique) vit actuellement une crise profonde, structurelle. Il est confronté subite- ment à un durcissement du marché, comme jamais auparavant il n’en avait fait l’expérience. Ceci l’entraîne inexorablement vers une ère d’industrialisation. Cette " révolution indus- trielle " du marché des services va, dans les cinq prochaines années, selon le Gartner Group, être compa- rable à celles qu’ont connus, en d’autres temps, les secteurs du textile et de la métallurgie.

Les symptômes avant coureurs sont là : réorganisations, réductions des coûts, restructurations, plans sociaux, délocalisations (évidente du fait de la dématérialisation du produit : pas de problèmes de logistique comme dans le cas de l’industrie lourde, etc.) et fu- sions/acquisitions. L’éclatement de la bulle Internet et des Télécoms n’a fait que mettre à jour des dysfonctionne- ments déjà existants depuis le début des années 90.

Le bouleversement est grand et la profession se voit contrainte de chan- ger de façon de faire. Encore fondée principalement sur une culture d’as-

velles méthodologies de développe- ment propres au monde du service informatique. Elles se réclament du qualificatif, un peu pompeux, il est vrai, "d’Agiles ". Agile par opposition aux méthodes employées auparavant principalement fondées sur la notion de prédictibilité. Au paradigme de prédiction, ces méthodes proposent le pragmatisme et l’adaptation.

Dans cet article, il ne sera question que des méthodes agiles que je connais : à savoir, le " Feature Driven Development " (FDD), le " Two Tracks Unified Process " (2TUP), " l’Extreme Programming " (XP) et bien que ce produit soit propriétaire, le " Rational Unified Process " (RUP).

Il serait bien difficile pour moi de parler de l’ensemble des méthodes agiles, elles sont trop nombreuses. Il ne sera pas non plus question de fournir une description détaillée de chacune de celles que je viens de citer ci-dessus, car j’en serais bien in- capable, préférant en laisser le soin à d’éminents confrères (3).

Mon propos est davantage de fournir un retour d’expérience afin de déga- ger les points forts et faibles de cha- sistance technique, d’obligation de

moyens, et de déve- loppements " sur mesure, elle doit, désormais, déve- lopper au " forfait " avec obligation de résultats et suivant une démarche qui génère de la valeur ajoutée

Jusqu’à présent, les projets n’étaient que rarement profitables et s’ils l’étaient, c’était parce qu’on avait su faire payer le prix réel au client.

D’après une étude américaine menée en 1994 sur 8000 projets (1), 16 % d’entre eux n’ont pas respecté les dé- lais et le budget initial, et pire, 32 % n’ont jamais abouti. L’étude du Stan- dish Group pour 1998 montre une amélioration par rapport à 1996, puisque le taux d’échec des projets tombe de 40% à 28%. En revanche, encore près de la moitié des projets sont en retard et/ou hors budget, ce qui laisse un quart des projets pleinement réussis. Il faut développer aux moindres coûts pour rester compéti- tif, avec une qualité de livraison irré- prochable et dans les délais les plus courts, imposés par les contraintes de

" Time To Market (2) " que les clients subissent eux-mêmes.

C’est dans ce cadre économique que sont apparues et apparaissent de nou-

Les méthodologies informatiques Agiles

L’utilisation de méthodes de développement adaptatives s’inscrit dans une logique d’amélioration des performances glo- bales des projets. Dans le domaine informatique, cette recherche s’illustre par le recours aux méthodes dites " Agiles ".

Jean Guillaume Lalanne nous livre ici un retour d’expérience sur l’utilisation de ces méthodes.

Jean Guillaume Lalanne Architecte d’information Cap Gemini Ernst & Young Jeanguillaume.lalanne@cgey.com

1) Source : http://extremeprogramming.free.fr/page.php?page=historique 2) Rapidité à livrer un produit, un service au marché

(3) Jean-Pierre Vickoff : http://www.rad.fr/

(2)

cune d’elles par comparaison (comparaison avec les méthodologies

" Merisiennes ", dites classiques, mais également comparaison entre elles).

Les méthodes " Agiles " reposent sur quatre principes de base, qui privilé- gient (4) :

●La communication et l’interaction qui en résulte, à la contractualisation des spécifications.

●La compétence et l’implication des ressources, au respect de processus formel et d’une vision " outillée " à l’extrême des développements.

● La livraison de fonctionnalités réelles, à la production d’une docu- mentation pléthorique.

●L’acceptation du changement et la modification des priorités (" Time- Figure 1 : TUP (Two Track Unified Process)

Figure 2 : RUP (Rational Unified Process)

(4) Source : http://www.rad.fr/puma.htm - (5) Le projet est principalement contraint par une date limite. (6) Le projet est contraint par un nombre in- compressible de fonctionnalités à développer. - (7) " Release " pourrait être traduit par le mot livrable. Toutefois, livrable fait penser à la notion de document. Or, ceci ne correspond pas trop à la philosophie des méthodes agiles (XP en particulier).

Boxing " (5), " Task Boxing "(6)), au respect d’une planification figée.

Elles ont toutes été fondées toutes à partir de l’observation suivante : le développement informatique est plus que ardu. Il est difficile de comprendre ce que le client désire faire vraiment (ou faire faire en l’occur- rence). Il n’exprime jamais ses vrais besoins, car souvent, à un instant t, il les ignore lui-même. Si toutefois il ar- rivait à le faire, ces derniers évolue- ront de toute façon au cours du projet. Ils changent du fait même de la création du logiciel. C’est la logique du serpent qui se mord la queue.

Et même si l’on imagine, le cas où un jour, le client formalise correctement ses besoins et ses exigences, il n’en demeure pas moins que le dévelop- pement est, la plupart du temps, complexe : tout projet a ses spécifici- tés techniques et fonctionnelles, qu’il est difficile de prévoir. Un système informatique est un édifice souvent vaste et compliqué, ayant un nombre de degrés de liberté pratiquement illi- mité. Michel Pébereau*, PDG de BNP Paribas déclarait ainsi " l’informatique des entreprises, c’est un peu les cathédrales du Moyen Age, com- mencées en style roman et terminées

Figure 3 : une illustration concrète du décalage des représentations.

en gothique flamboyant. Les archi- tectes sont morts depuis longtemps et plus personne n’a les plans". Toute erreur ou changement peut générer, du fait de cette complexité, par effet do- mino, une surcharge de travail. Cette surcharge peut devenir exponentielle pour le projet.

Il est donc évident que l’ensemble des concepts, qui constituent les fondations des méthodes classiques, ne soit plus considéré comme réaliste par les chefs de projet :

● Le périmètre fonctionnel n’est jamais arrêté ;

●Il n’est donc jamais possible de dé- finir un planning précis et figé ;

●Et donc, pas davantage de se proté- ger de futurs risques de dérives de projet, en verrouillant les besoins fonctionnels et le planning.

Partant de ce constat, les méthodes agiles proposent un processus qui s’adapte aux multiples évolutions du contexte par une planification continuellement réévaluée.

Le principe d’itération pour les unes ou de " release " (7) pour les autres permet de définir une discrétisation

(3)

temporelle simple qui permet d’iden- tifier la " vitesse " et la consommation du projet, afin de pouvoir réajuster régulièrement tous les paramètres du pilotage projet.

On peut distinguer quatre étapes ma- jeures dans l’évolution des cycles de développement logiciel :

●Le cycle en cascade, c’est le plus simple et le plus connu : on analyse le problème, on conçoit une solution, on construit la solution, on teste cette dernière, on intègre et on déploie. La méthode est séquentielle et l’estimation de la durée du projet se résume à une addition des estimations tempo- relles de ces différentes étapes.

●Le cycle en spirale : puisque qu’il est évident que des erreurs sont faites durant les phases de conception et de construction, le cycle précédent n’est pas vraiment réaliste. Est alors apparu la notion d’itération. Itérer c’est effec- tuer une tâche en plusieurs passes.

Chaque passe améliore le résultat jusqu’à qu’une validation définisse que la tâche est achevée. L’idée est d’avancer lentement afin de ne pas laisser passer un bogue qui peut coû- ter très cher s’il est découvert que trop tard dans les phases avales. La notion de validation (ou retour client) apparaît au cours du projet. La diffi- culté de ce type de cycle réside dans le planning d’itérations non prévi- sibles par essence.

●Le cycle de développement itératif se calque sur le précédent, sauf qu’il ne considère pas l’itération comme exceptionnelle. Il part du principe que les itérations vont avoir lieu sans arrêt. Il faut donc essayer d’estimer leur nombre. Doucement, à chaque nouvelle itération, le développement devient meilleur et il est de moins en moins nécessaire de revenir sur ce qui a été fait.

●Le cycle de développement par livraison incrémentale : le problème avec la méthode précédente est qu’il faut beaucoup de temps avant de voir quelque chose finalisé. Ce cycle propose au contraire de livrer le logiciel plusieurs fois au client avec toujours

davantage de fonctionnalités (les plus importantes au début). La quantité d’analyse et d’architecture décroît au fur et à mesure des incrémentations.

Le problème avec ce type de mé- thode, c’est de savoir ce qui va guider le choix du contenu des incréments : une vision architecturale, la gestion des risques ou celle, économique, des fonctionnalités ?

● Les méthodes agiles partent du principe que le retour client et le retour sur le code déjà développé sont nécessaires et qu’il est dommageable de vouloir les éviter, bien au contraire. Il est préférable de livrer au client des incrémentations très brèves afin d’avoir un retour quasi continu.

Les fonctionnalités dans les incré- ments sont définies par le client. Une métaphore souvent employée et qui résume bien cet état d’esprit est celle des stocks de matières premières et de produits intermédiaires dans l’industrie. Tout comme ces derniers, un développement non livré au client peut être considéré comme un passif pour le projet. Il est absolument né- cessaire pour la bonne santé du projet de livrer au fur et à mesure les fonctionnalités que l’on a dévelop- pées. Il faut éviter à tous les niveaux du projet les effets tunnels. Dans le même ordre d’idée, toute activité support projet qui ne représente aucune valeur ajoutée pour le client doit être réduite à sa plus simple ex- pression.

Cette gestion temporelle du projet par itérations et par incréments est essen- tielle. Elle demeure le principal fon- dement de l’agilité. J’insiste sur ce point. Il m’apparaît maintenant clairement que l’utilisation de ces principes simples aurait pu, à coup sûr, sauver de l’échec un certain nombre de projets sur lesquels j’ai eu à inter- venir.

Toutefois, les méthodes agiles ne se limitent pas à cela. Elles proposent un grand nombre de bonnes pratiques, que je propose d’analyser par la suite, à la lueur de mon expérience.

Auparavant, il me semble utile de rappeler, historiquement, d’où pro-

viennent, pour la plupart, ces mé- thodes agiles. Elles sont le résultat de retour d’expérience d’un certain nombre de mouvances et techniques :

●La première et la plus importante à mon sens : la mouvance " Open Source ". Plus que l’aspect juridique (ouverture du code, licence particu- lière, etc.), cette mouvance a avant tout généré un grand nombre de pratiques (et d’outils associés) utilisées par des communautés virtuelles gi- gantesques afin de mener à bien des projets logiciels, internationaux et complexes. LINUX, APACHE, GNU sont les exemples qui viennent les premiers à l’esprit. On peut parler de réussites ! L’impact de cette mouvance sur les pratiques de développe- ment est aussi grand que celui des produits qui ont été développés sur l’informatique actuelle. Il est évident qu’une méthode comme XP (Extreme Programming) est le fruit de ce monde-là. Il n’est alors pas étonnant d’y retrouver des pratiques comme l’intégration continue (make, build de ANT), le test unitaire continu, la validation des exigences continue (" Issue Tracking "), le retour constant des utilisateurs (" mailing-list ", " bugzilla ", forum, sondages, FAQ), le partage du code (CVS, site collaboratif, distribu- tion code source), la notion de " release " rapide, etc. Il suffit de jeter un coup d’œil sur le site www.source- forge.net (créé au début des années 90 !) pour comprendre leur prove- nance.

● L’apparition du formalisme standard UML et d’autres formalismes métiers basés principalement sur XML a permis d’introduire une agilité plus grande dans la structuration de l’information que le projet doit gérer : information technique et/ou information fonctionnelle. Un meilleur formalisme permet une meilleure com- préhension entre les différents acteurs du projet, mais aussi une historisation plus évidente du contexte projet (bien plus évident que le sont des quantités de documents binaires comme WORD, EXCEL ou PDF, etc.).

Même si certains récusent cet accès de formalisme, il est le passage né-

(4)

(8) Notion de retour en arrière, d’amélioration continue du travail fourni. - (9) Lecture automatisée d’un document structuré.

(10) Notion de prototypage.

cessaire vers une automatisation de la gestion projet logiciel : le " refactoring " (8) ne cible pas uniquement le code, il cible tous les axes d’un projet. La description structurée au for- mat ASCII favorise le " parsing " (9) et donc le retour en arrière, l’améliora- tion continue. Une vision graphique de ce formalisme est toujours plus ef- ficace qu’une vision documentaire.

Le concept de MDA (" Model Driven Architecture ") participe à cet effort de formalisme. Il n’est toutefois qu’à ses débuts.

●Le concept objet : plus que le formalisme qu’il engendre, ce concept a énormément apporté dans la capitali- sation des bonnes pratiques logi- cielles (GoF, Design Pattern J2EE).

Pour la première fois, il a vraiment permis la réutilisation, première

étape vers l’industrialisation.

A présent, arrêtons nous quelques instants sur les grands principes qui constituent les méthodes agiles, afin de les confronter à l’expérience (le tableau ci-dessous en fournit, sous une forme synthétique, une description simple).

La notion de " Pair Programming " : Cette technique de développement est acceptable dans les premières étapes des itérations mais n’est pas conseillée dans le reste de la phase de production. C’est une dépense in- considérée qui peut coûter très cher sur la fin d’un projet. Néanmoins, l’intérêt est évident, et j’ai eu l’occa- sion de le vérifier, dans les phases d’analyses et de design (phase de prototypage, ou de " Proof of Con-

cept "(10)). En outre, elle permet de former de façon croisée les dévelop- peurs à tous les aspects de l’architecture. Comme dans une équipe de rugby où n’importe quel joueur blessé doit pouvoir être remplacé au pied levé, les développeurs doivent être polyvalents afin de pouvoir faire face à tout aléa durant le projet (ma- ladies, vacances, migration vers un autre projet,etc.). Le " Pair Program- ming " favorise cette agilité de l’équipe projet. Les développeurs sont d’ailleurs souvent demandeurs d’une telle pratique qui leur permet ainsi d’accroître leur champ de com- pétences.

" Test-First Design " :

Cette première notion rejoint le concept de prototypage ou de " Proof of Concept " cité ci-dessus. Ce sont

Principes “Agiles” Description rapide

Client sur site (On Site Customer) Pour une meilleure communication, les clients et les développeurs travaillent dans le même espace au- tant que possible.

Séance de Planification (Planning Game)

Le client définit les scénarios utilisateurs prioritaires. Les développeurs discutent le contenu de ces scé- narios, définissent les tâches techniques sous-jacentes, estiment ces tâches et y souscrivent.

Intégration Continue (Continuous Integration)

Le système est intégralement assemblé et testé une à plusieurs fois par jour.

Livraisons Fréquentes (Frequent Releases)

Le rythme des livraisons est de l'ordre de quelques semaines.

Rythme soutenable (Forty-Hour a week) L'équipe ne fait pas d'heures supplémentaires deux semaines de suite.

Tests de Recette Recette (Acceptance Tests)

Retour d'information rapide sur le système, en général automatisé, constitué à partir de critères de tests définis par le client.

Tests Unitaires (Unit Testing)

Tests automatisés écrits pour chaque classe, chaque méthode, et pour tout "ce qui pourrait casser" en gé- néral. Ces tests doivent passer à 100% continuellement.

Conception Simple (Simple Design) Le code doit passer tous les tests et répond aux critères de maintenabilité : concision, modularité, cohé- rence, lisibilité.

Métaphore (Metaphor) Une analogie utilisée comme modèle conceptuel du système en cours de développement.

Remaniement Continu (Refactoring) Ou re-factorisation de code pratiquée sans relâche : modification du code par laquelle on améliore sa conception sans en modifier le comportement.

Convention de Code (Coding Standard) Le code doit suivre une convention de nommage et de présentation afin d'être lisible par tous les membres de l'équipe.

Programmation en binôme (Pair Programming)

Le code de production est toujours écrit par deux développeurs : le pilote et le copilote. Les binômes changent au cours du projet.

Propriété collective du code (Collective Code) Ownership

Chaque développeur peut modifier chaque partie du code si le besoin s'en fait sentir.

(5)

d’excellents exercices pour clarifier les besoins fonctionnels (déterminer leurs impacts au plan technique), ap- préhender leur niveau de risque et leurs coûts éventuels. L’architecte doit être pleinement impliqué dans cette activité pour s’imprégner de la complexité du projet.

" On-Site Customer " :

Cela peut être une bonne méthode pour obtenir un feedback continu sur l’évolution des développements, pour partager la charge de documen- tation avec le client et surtout éviter toute " réunionite " qui mobilise trop de ressources pour des résultats souvent très limités. L’interaction avec l’utilisateur final doit être encadrée car les besoins de ce dernier peuvent rapidement ne plus correspondre à la solution achetée au début : le client achète une maison et il exige une ca- thédrale ! Chaque demande doit être

" priorisée " et évaluée en terme de coût.

" Coding Standards " :

Plus que les notions de convention de nom ou de codage, le concept sug- gère de toujours utiliser des standards techniques ou des bonnes pratiques métier. Il ne sert jamais à rien " de ré- inventer la roue ".

" Continuous Integration " :

Cette méthode est d’une grande uti- lité car elle permet à tous les déve- loppeurs de resituer leur travail dans l’œuvre plus globale qu’est le projet.

Il est question dans " l’Extreme Pro- gramming " de métaphore. On évite ainsi tout cloisonnement des déve- loppements. Les processus de test unitaire et de test de non régression assurent la consistance à tout instant de ce qui est intégré, si bien qu’une estimation de la qualité des livrables est toujours disponible.

" Collective Ownership " :

Cette notion est fortement liée à la précédente. Elle permet d’éviter éga- lement le cloisonnement du projet et de garder son agilité. Ceci n’est fai- sable que lorsqu’un système de gestion de configuration performant a été mis en place afin de tracer toute évolution. Ce type de système devient vite l’épine dorsale du projet.

Cette technique permet également de contraindre le développeur à suivre une convention de codage projet et à abandonner ces mauvaises habi- tudes. Elle participe au concept de polyvalence de l’acteur du projet. La rétention d’information n’a plus lieu d’être.

" Refactoring " :

Si l’idée est parfaitement acceptable pour du développement logiciel mono langage de programmation, elle ne peut en aucune manière se substituer à une démarche architecturale précise. C’est sûrement l’un des points de désaccord le plus évident entre des méthodes comme RUP, 2TUP et XP. En effet, la phase d’ini- tialisation du projet n’apparaît pas clairement dans le processus XP.

Avant tout commencement de " release " ou d’itération, il est forcément nécessaire de compter quelques jours, ne serait-ce que pour obtenir une vision commune avec tous les acteurs, en terme de périmètre, de risque et de budget.

Une exploration fonctionnelle et technique, ainsi qu’une planification sont effectuées une fois que l’on a es- timé que le projet a une forte proba- bilité de succès. XP est plus adapté pour des projets où les risques techniques sont minimes car bien connus (notion de " départ lancé "). C'est le cas des développements logiciels.

Dans un processus comme RUP, la phase d’architecture qui se trouve au niveau des " Elaborations Itérations "

permet de stabiliser les fondations de la solution.

XP insiste pour que les " releases "

soient fonctionnellement orientées, afin qu’elles fournissent une valeur ajoutée immédiatement appréciable par le client. La phase d’architecture n’est donc pas vraiment prise en compte en tant que telle ; elle est di- luée tout au long des différentes " releases ". L’idée de XP est de ne pas passer trop de temps à délivrer un travail qui ne représente aucune valeur ajoutée métier aux yeux du client.

C’est une vision réductrice qui omet de considérer que la réduction des risques est aussi une valeur ajoutée importante pour le client.

Il y a toujours toute une série de pro- blèmes d’environnement, de sys-

tèmes, de matériel qui ne peut être gérée seulement par la philosophie du " Refactoring ". Et XP ne les adresse pas correctement. Il est avant tout un processus de développement logiciel ; or il est évident que la plupart des projets informatiques dépas- sent ce contexte-là.

Le positionnement du projet dans le Système d’Information est incontour- nable afin d’assurer le respect de l’urbanisation et d’estimer les adhé- rences de la solution avec le système existant.

" Metaphor " :

Pour de grands projets, l’architecture peut difficilement se résumer à une simple métaphore. Néanmoins, il est toujours bon de communiquer les grandes lignes de cette architecture à l’ensemble de l’équipe projet afin de définir un objectif commun (dans le monde open source, il est question de " roadmap " (11)).

" Rapid release " :

C’est une excellente technique. Elle permet de rassurer rapidement le client et de lui fournir une grande vi- sibilité sur le projet. L’acceptation des utilisateurs est acquise plus tôt et le risque de rejet de l’outil est intégré rapidement dans le projet. En terme commercial, cette démarche est très appréciée du client car elle fournit une vision modulaire du produit. Il peut relier une " release " à un coût et donc souvent renégocier en interne les priorités de telles ou telles fonc- tionnalités : il acquiert un argumen- taire pour sa politique interne qu’une autre approche projet ne fait pas res- sortir. Pour l’équipe projet, cette dé- marche permet de communiquer le travail effectué en interne et chez le client. Le risque est d’investir énor- mément sur les premières " releases "

et de ne devenir rentable que sur les dernières (si le client ne souhaite pas poursuivre en milieu de projet pour une raison ou une autre, la santé éco- nomique du projet n’est plus assu- rée).

" Simple Design " :

XP est trop orienté vers une conception dirigée par les fonctions métiers.

Elle ne prend pas en compte une approche architecturale du type " Fra-

(11) La " roadmap " est la trajectoire à suivre pour atteindre l’objectif ou la cible

(6)

mework " (12) comme celle propo- sée par RUP et 2TUP. Il est dangereux de développer ainsi. Des problèmes peuvent n’apparaître que lorsque les releases seront intégrés entre elles. Il est alors trop tard pour agir.

" 40-hour week " :

Il est vrai que les développeurs ont tendance à travailler jusqu’à ce que leur programme fonctionne correctement en fin de journée. C’est une grossière erreur de penser que le chef de projet doit utiliser ce penchant pour optimiser les journée de déve- loppement. A terme, une telle dé- marche est fortement contre-pro- ductive. Le chef doit imposer des ho- raires fixes à son équipe afin de garder une fraîcheur d’esprit tout le long du projet. De nombreuses erreurs de jugement peuvent ainsi être évitées.

Les rôles de RUP :

RUP insiste sur la discrétisation des rôles afin de bien gérer les compé- tences sur le projet. XP simplifie cette discrétisation de 30 à 7 afin de pro- mouvoir la polyvalence des acteurs de l’équipe et d’éviter tout cloisonnement et étiquette.

Interlocuteur Maîtrise d’ouvrage (MOA)/Client ayant pouvoir de déci- sion :

Il est fondamental d’avoir des interlo- cuteurs ayant réellement une exper- tise client et/ou un pouvoir de décision. Il est trop fréquent de se heurter à des directions projet MOA à diverses têtes, qui contraignent trop souvent le chef de projet MOE (Maî- trise d’oeuvre) à faire l’utilisation du processus d’escalade hiérarchique, très coûteux en terme de temps, de communication projet et de motivation de l’équipe. Au même titre que les " Proof Of Concept " techniques et fonctionnels, il est utile de bien éva- luer en début de projet les ressources humaines MOA/client mises à dispo- sition.

Autonomie et organisation centrali- sée de l’équipe (motivation) : Les méthodes agiles s’inspirent clairement des méthodes de fonctionnement des équipes sportives : il est

d’ailleurs question du " SCRUM "

(13), allusion non dissimulée au rugby. Le fonctionnement interne de l’équipe projet doit être basé sur le principe du " Gagnant-Gagnant" : à savoir qu’un projet ne sera une réus- site pour le management que s’il est d’abord aussi une réussite pour l’ensemble des intervenants.

Comme nous avons pu le constater tout au long de cet article, les mé- thodes agiles apportent un grand nombre de nouvelles pratiques. La plupart de ces pratiques sont déjà des

" Best Practices " du monde " Open Source " ; en ce sens, elles ont déjà fait leur preuve. Toutefois, même si la majorité d’entre elles peuvent être considérées comme positives, toutes ne le sont pas. Un projet Open Source n’est pas sujet aux mêmes contraintes qu’un projet traditionnel.

Les concepts d’itérations et d’incré- mentations sont des concepts phares.

L’intégration continue, la gestion continue des exigences et la livraison rapide de verticalités produites sont également des notions incontour- nables. Leur apport est indéniable.

Les concepts de " Refactoring " et

" First-Design " sont plus sujets à cau- tion.

Le principal grief que l’on peut émettre à l’égard de ces méthodolo- gies - et il est d’importance - c’est qu’elles sont principalement portées par des équipes MOE. Or les équipes MOA chez les clients sont souvent des équipes non familiarisées avec les méthodes agiles. Historiquement, les chefs de projet MOA sont souvent d’anciens chefs de projet prestataires, qui ont capitalisé sur les méthodes qui étaient alors en cours. Il y a donc souvent, pour ne pas dire toujours, une différence de méthodologie entre la MOA et la MOE. Il est possible de faire abstraction de cela pour l’une ou pour l’autre des équipes. Toutefois ceci n’est plus possible lorsque la MOA et/ou le Client impose à la MOE, pour des raisons de qualité, la méthodologie maison. Cette dernière étant malheureusement souvent de type documentaire, " Merisien ".

Comment alors diriger un projet en

12) Concept très en vogue actuellement et issu principalement de " l’open source ". Il s’agit de la notion de socle technique et fonctionnalités trans- verses. - (13) “mêlée”

utilisant une méthodologie dite agile lorsque la culture du client est fortement empreinte d’une philosophie prédictive ? Le problème revient alors à s’adapter à la méthodologie client sans biaiser son agilité. La tâche peut vite s’avérer compliquée.

En particulier, comment faire accep- ter au client une démarche d’architecture et de " Proof Of Concept "

lorsqu’il attend une rédaction de spé- cifications fonctionnelles, techniques, générales ou détaillées ? Comment faire comprendre qu’une bonne analyse, une bonne conception ne sont pas synonymes de documents mais au contraire de développement ? Le bon fonctionnement de la " tuyauterie " de la solution ne peut être évalué si on se cantonne à la rédaction de spécifications.

Il n’y a sûrement pas de réponse toute faite à ce genre d’interrogations. Tou- tefois, il est certain que les bonnes pratiques introduites par ces mé- thodes agiles vont faire leur chemin et devenir des standards de facto que les MOA finiront par adopter à moyen terme. Ces méthodes répon- dent à des besoins et permettent de résoudre des problèmes. On aurait tort de les considérer comme des phénomènes de mode.

Bibliographie :

● " Extreme Programming Explained ", Kent Beck (Addison-Wesley).

●" Refactoring : Improving the design of exis- ting code", Martin Folwer (Addison-Wesley)

● " Extreme Programming Installed ", Ron Jef- fries (Addison-Wesley)

● " Agile Software development", Alistair Cockburn (Addison-Wesley)

● " The Rational Unified Process", Phillipe Kruchten (Addison-Wesley)

●"The ten essential of RUP", Leslee Probasco, (Rational Software Whitepaper)

●Site WEB sur l’Extreme Programming : - www.extremeprogramming.org - www.xp123.com

- www.xprogramming.com - http://xp-france.net

Glossaire :

MOA : Maîtrise d’ouvrage MOE: Maîtrise d’oeuvre