Tribunes

La Wii RUP : les démarches agiles

Passer du Playmobil au Lego : un nouveau terrain de jeu pour les utilisateurs du SI (5ème épisode sur 6). Avez-vous déjà essayé d'assembler 2 Playmobils ? C'est la quadrature du cercle permanente pour les utilisateurs et les informaticiens à chaque nouveau projet informatique, et inévitablement on rachète une nouvelle boite, plus jolie, plus complète que la précédente mais avec les mêmes bonshommes de base.

PublicitéLe but du jeu : aller vite à l'essentiel L'idée phare de l'approche agile est de réaliser des projets rapides à forte valeur ajoutée, d'une manière très interactive, en se concentrant sur les besoins essentiels. Comme la Wii a révolutionné le monde du jeu vidéo en passant de l'approche statique « canapé » à l'approche agile « Wiimote », la méthode agile bouleverse le traditionnel cycle en V pour une approche des projets moins formelle et plus réactive. On ne peut pas parler de l'agilité sans évoquer Scrum, méthode agile basée sur la notion de mêlée (scrum donc), largement en vogue, qui propose un jeu de rôles prédéfini (Scrum Master, Product Owner) et des outils pour conduire les sprints (Product backlog : liste des besoins, Sprint Backlog : tableau de suivi de l'exécution). On peut citer d'autres méthodes itératives comme UP (Unified Process), XP (eXtreme Programming) ou la vieillissante RAD (Rapid Application Developement). La règle du jeu : une méthode agile pour combiner agilité métier et agilité SI Aujourd'hui, les métiers ont besoin d'être agiles pour pouvoir s'adapter en permanence à des demandes nouvelles (nouveau produit, nouvelle stratégie, fusion-acquisition, nouvelle réglementation, , etc.) avec souvent un enjeu fort sur le délai de mise en oeuvre. L'approche BPM sert en partie ce besoin en permettant aux utilisateurs de bien maîtriser leur processus, et donc leur évolution. Pour servir ce besoin d'agilité métier, l'entreprise requiert un Système d'Information structurellement agile. C'est ce qu'apporte une architecture SOA. La méthode agile permet ensuite de combiner agilité métier et agilité technique en proposant une méthodologie de projet adaptée : - cycles de réalisation raccourcis (sprints de quelques semaines), - travail MOA/MOE commun en mode plateau, - définition progressive de la solution. La méthode agile peut servir deux types de problématiques: - un 1er niveau « quick and dirty », pour faire du jetable tactique, - un 2nd niveau « développement rapide » pour produire rapidement des applications composites. Que gagne-t-on ? Ciblage, vitesse, dialogue, tout est mieux Un des objectifs majeurs de la méthode agile est de réduire les incompréhensions entre utilisateurs et informaticiens. Adieu les cahiers des charges formels de 100 pages décrivant une montagne de fonctions à réaliser, la méthode agile permet une construction progressive du besoin en traitant les fonctions demandées dans l'ordre décroissant des priorités. Il simplifie notamment le travail de la MOA à qui on ne demande plus une description formelle et exhaustive de son besoin, mais à qui on propose une méthode interactive pour le définir. Optimiser les relations entre MOA et MOE constitue un gain majeur. Le besoin originel est mieux compris, mieux cerné et servi plus rapidement. On réalise au final des applications moins chères, car concentrées sur le périmètre utile et facilement adoptées par les utilisateurs. On combat efficacement la résistance au changement sur un nouvel outil trop complexe. Le mode « plateau » (tout le monde regroupé physiquement au même endroit) permet une proximité et une facilité d'échange qui permettent l'atteinte des objectifs et qui sont autant d'atouts pour la suite du projet : le dialogue est déjà présent, les utilisateurs clés ont participé activement à la construction de l'application et vont logiquement la promouvoir. Dans un monde idéal : le « droit de retouche » permis aux utilisateurs par l'agilité Des cycles projets raccourcis, un besoin réduit à son périmètre essentiel, des utilisateurs satisfaits : une approche agile bien menée semble plébisciter l'usage de la Wii et renvoie au placard la bonne vieille méthode en V. Finalement, est-ce vraiment une bonne idée de demander à des utilisateurs de donner une vision exhaustive d'une nouvelle application sous forme d'un Cahier des Charges pesant et formel ? Est-ce que le vrai besoin et les vraies priorités ne sont pas noyés dans la masse d'information ? Le concept d'application informatique reste très théorique : il s'agit d'aider l'utilisateur à mieux manipuler son information au quotidien, vaste programme ! Ne devrait-t-on pas accorder forcément « un droit de retouche » à l'utilisateur ? La méthode agile répond parfaitement à cette carence de la méthode en V, en permettant aux utilisateurs et aux informaticiens d'élaborer ensemble et progressivement la meilleure solution. A chaque étape, on montre, on échange, on ajuste, en re-priorisant intelligemment à chaque fois. Dans la vraie vie : tout peut-il être agile ? Puisque la méthode est si efficace, on se dit finalement : pourquoi ne pas généraliser cette approche à l'ensemble des applications du Système d'Information ? Et on touche là les limites de l'agilité : - les problématiques d'industrialisation et d'exploitabilité sont peu ou pas traitées du tout. L'agilité suppose un socle technique pré-existant qui a déjà résolu tous ces problèmes, - l'agilité n'est qu'un « pattern organisationnel », comme pouvait l'être par exemple la norme ISO 9001. Elle n'impose pas de règles sur la qualité de la production. Il peut être utile alors de la coupler avec un outillage de type intégration continue, et d'adopter une approche TDD (Test Driven Development) pour la réalisation de l'application, - L'agilité ne laisse pas le temps de « raisonner générique » ou de construire des modèles structurants. Elle produit très peu de composants réutilisables. Il parait donc difficile de traiter en mode agile la mise au point de briques structurantes, comme par exemple un référentiel de services, un référentiel MDM, ou un Infocentre. Ces composants nécessitent en effet une approche et une réflexion transverses, qui impactent l'ensemble des objets métier du Système d'Information, difficile dans ces conditions de converger en quelques semaines seulement. En synthèse : nager agile en surface, garder quand même les bouteilles pour le fond En synthèse, l'emploi d'une méthode agile offre réellement de belles perspectives pour améliorer la réactivité du Système d'Information aux demandes métier et apporter une vraie efficacité pour réconcilier informaticiens et utilisateurs dans la durée. Il est préférable de limiter la méthode agile à son périmètre d'excellence : les applications « de surface » (ou IHMs), et garder en parallèle une approche traditionnelle conception-réalisation pour les couches basses du Système d'Information.

Article rédigé par

Rémi Moebs, Senior Manager chez Sopra Group Atlantique
Responsable de la cellule « Architecture et Solutions Collaboratives » au sein de la Division Business Consulting de Sopra Group Atlantique Consultant et agitateur technologique depuis 12 ans sur les sujets Web, Web 2.0, KM et collaboratif, e-commerce, Architecture agiles et distribuées.