En poursuivant votre navigation sur ce site, vous acceptez l’utilisation de cookies pour vous proposer des services et offres adaptés à vos centres d’intérêts.FERMER  x
Pour en savoir plus et paramétrer les cookies...

Méthodes agiles, ils y trouvent leur compte

Elles voulaient en finir avec le mythe des spécifications figées du cahier des charges. Ce qui les a poussées tout droit vers les méthodes agiles. Retour d'expérience de quatre pionnières.

' Notre planning était extrêmement serré. Le périmètre de nos fonctionnalités n'était pas encore bien défini. Et nous voulions atteindre la qualité rapidement. Pour toutes ces raisons, les méthodes traditionnelles de développement ne convenaient pas ', se souvient Eric Hennetier, DSI adjoint de M6. En mars 2007, pour développer son extranet publicitaire, la chaîne privée opte pour les méthodes de développement agiles. Elle ne le regrettera pas. Et multiplie aujourd'hui les projets de ce type. A la différence des approches en cascade ou en V, ces méthodes sont pilotées par les cas d'utilisation et les itérations.
A l'image de M6, certaines entreprises commencent à succomber à cette gestion de projet incrémentale. La raison de cette conversion ? Le périmètre des projets, relativement fluctuant. Il l'était par exemple chez Vidal Software, qui a réactualisé son dictionnaire de médicaments en se calant sur les exigences gouvernementales, en perpétuelle évolution. Ou encore chez le ' cost killer ' Alma Consulting, qui rénove son outil de suivi de missions en pistant les gisements d'économie sans cesse fluctuants. Mouvant, le périmètre l'était également chez un établissement financier (préférant garder l'anonymat), désireux de refondre ses outils de salle de marché, mais dont les courtiers n'avaient pas circonscrit les fonctionnalités.

Une collaboration quasi quotidienne avec le métier

Premier constat partagé par les quatre entreprises : le succès de leur projet tient à la proximité des équipes informatiques avec les utilisateurs. Une proximité assurée par le product owner (selon la terminologie Scrum, une méthode agile adaptée à la gestion de projet) ou chef de produit. Celui-ci est affilié à l'équipe tout au long du développement. ' Chez nous, cette personne a été déterminante pour établir un ordre de priorité des tâches. Mais également pour faire le pont avec les équipes métier dès que nous avions des doutes dans les développements. C'est une très grande avancée, car dans les projets traditionnels, il est très compliqué de récupérer des informations auprès des fonctionnels ', explique Olivier Rigal, responsable du pôle étude de la DSI d'Alma Consulting.
Si l'apport du product owner ne fait aucun doute, la question de son implication fait débat. Idéalement, il partage 100 % de son temps avec l'équipe. Mais ce degré varie quasiment du tout au presque rien selon les entreprises. Dans l'établissement bancaire, le chef produit déjeunait quotidiennement avec les équipes techniques. A M6, ' la maîtrise d'ouvrage a consacré 50 % de son temps au projet durant huit mois, se rappelle Eric Hennetier. C'était le minimum pour qu'il puisse concevoir avec les équipes de développement tous les tests de recette et d'intégration intervenant à chaque itération '. Chez Vidal et Alma Consulting, le chef de produit n'est intervenu qu'en début et en fin d'itération. ' Mais sa présence se renforce de plus en plus, poursuit Olivier Rigal, d'Alma. Pour cela, le nôtre a dû diluer sa charge de travail au quotidien. ' De la disponibilité et de l'engagement du product owner dépend en grande partie le bon succès du projet. ' Nous avons déjà connu des cas de dérive où, par peur de déranger la maîtrise d'ouvrage, le rôle du product owner était plus ou moins occupé par un membre de la DSI ', rapporte David Gageot, directeur technique de Valtech, prestataire de Vidal. Ce dévoiement de la méthode agile fait retomber le projet dans le travers des méthodes traditionnelles.
Il est vrai que cette implication intense de la maîtrise d'ouvrage ?" qu'il s'agisse du product owner ou des tests réalisés par les utilisateurs en fin d'itération ?" n'est pas toujours facile à vendre en interne. D'autant que cet investissement des métiers semble, au final, plus important que celui engagé dans les approches classiques. ' Le nombre de jours-hommes est équivalent ', conteste Gilles Laborderie, responsable du secteur média chez Octo Technology, prestataire de M6. ' Seulement, dans un cas, la maîtrise d'ouvrage se concentre sur la rédaction du cahier des charges et la réception du projet final, dans l'autre, son investissement est lissé tout au long du projet. '

Une charge de travail clairement identifiée

L'autre grand atout remonté par les entreprises concerne la visibilité du projet. ' Ces nouvelles méthodes ne résolvent pas les problèmes. Elles permettent en revanche de les mettre tout de suite en évidence. En imposant notamment une communication permanente des membres, qui vaut tous les reportings du monde ', explique Jean-Laurent Favre, directeur de Vidal Software, et Scrum master du projet. Traditionnellement, ce suivi relève du chef de projet qui assigne des tâches à l'aide de diagrammes de Gantt en essayant de les faire tenir dans le planning du projet. Avec les méthodes agiles, ce modèle vole en éclat : ' Pour chaque itération, nous utilisons un tableau pour hiérarchiser le backlog, c'est-à-dire les différentes fonctionnalités à développer, indique Olivier Rigal. A côté de ce premier backlog, nous en déclinons un autre, de tâches cette fois-ci. Ainsi qu'une courbe de burn down. ' Avec celle-ci, l'équipe visua lise la charge de travail qu'il reste à accomplir au cours de l'itération. Elle est calculée à partir de coefficients attribués aux tâches, selon leur priorité. ' Tout le monde comprend une ' courbe de Reste à faire ' dirigée vers le bas. Administrativement, la panoplie des outils agiles est très légère ', poursuit-il.
L'ensemble de ces outils est exploité quotidiennement lors du stand-up meeting, qui permet d'exposer la situation de chacun. ' Au cours de cette réunion de dix minutes, chaque membre de l'équipe explique debout ?" pour rester dans la dynamique ?" ce qu'il a fait la veille, ses avancés et ses points de blocages ', indique Achille, un des membres de l'équipe ayant développé l'application pour la salle de marché. Mais pour lui, la visibilité va au-delà de la gestion du temps ou de l'avancement des équipes, puisque la méthode s'enquiert également de la validité des développements. ' Une anomalie en production est tout de suite identifiée grâce à l'échec d'un ou plusieurs tests unitaires ', poursuit-il. A noter que ces tests sont écrits avant même le code, et forment ainsi une sorte de cahier des charges et de documentation. ' C'est une posture intellectuelle peu évidente à intégrer, surtout pour les jeunes développeurs. '
La transparence appréciée par les équipes de développement l'est tout autant par les utilisateurs. Car ces derniers peuvent toucher et tester les livrables produits à l'issue de chaque itération. Par ailleurs, cette méthode incrémentale de développement offre à tout moment une porte de sortie. Un argument apprécié des directions générales : ' Comme nous ne connaissions pas le nombre exact d'itérations, le budget que nous demandions à notre direction était nécessairement moins précis que lorsque nous contractualisions au forfait. Mais nous lui avons assuré qu'à tout moment, en cas de trop gros écarts, nous pouvions stopper les développements sans pour autant condamner le projet ', précise Eric Hennetier, de M6.

Des interprétations très opposées

L'adhésion aux méthodes agiles suppose de se conformer à un certain nombre de bonnes pratiques. Et, là encore, leur respect varie énormément selon les entreprises. En fait, seuls M6 et l'établissement financier ont appliqué la quasi totalité des pratiques d'eXtreme Programming (XP), une méthode de développement qui peut se résumer en 13 points (voir encadré ci- contre) et qui, comme son nom l'indique, tolère peu de compromis. Les deux autres entreprises se sont, elles, conformées aux directives organisationnelles de Scrum, moins rigides. ' Par souci de pragmatisme, chaque structure renonce à certains points. Tout dépend de la taille et des moyens des équipes, avance David Gageot, de Valtech. Mais avec le temps, elles doivent s'efforcer de s'améliorer en respectant un maximum de pratiques. '
Ainsi, chez Vidal, on ne pratique pas la programmation en binôme, censée renforcer le partage de connaissance et éviter l'appropriation du code. ' C'est une pratique complexe. Il est fatigant de travailler avec quelqu'un à côté de soi. Et le rythme n'est pas le même que quand on est seul ', lance Jean-Laurent Favre, le directeur de Vidal Software. Alma Consulting, pour sa part, ne pratique pas encore les réunions quotidiennes. Mais, par contre, aucune des entreprises rencontrées ne transige sur la pratique des tests unitaires, l'un des fondements des méthodes agiles.

Un travail de conviction indispensable

Les vertus de ces méthodes ne doivent pas faire oublier le travail de conviction à mener en amont du projet. ' Il est nécessaire de faire tomber le mur qui sépare maîtrise d'?"uvre et maîtrise d'ouvrage, un mur bâti sur les échecs passés ', rappelle Bernard Notarianni, d'Octo Technology, qui a encadré les équipes de M6 en tant que coach (selon la terminologie XP). Olivier Rigal, d'Alma, confirme et complète : ' Les métiers étaient au départ peu réceptifs aux changements que nous leur proposions, car ils n'avaient pas véritablement conscience des défaillances des méthodes traditionnelles. Comme s'ils y étaient habitués... ' Pour vendre les méthodes agiles en interne, il a donc vanté les mérites de l'itération. En expliquant aux utilisateurs qu'ils n'avaient pas à détailler tout le spectre de leurs besoins, et que ces derniers pouvaient même être réorientés au fil du temps. D'autres difficultés sont naturellement apparues au cours des projets menés. M6, par exemple, a négligé la composante déploiement. ' C'est pourquoi au cours des projets suivants, nous avons associé les équipes d'intégration dès les premières itérations ',rapporte Eric Hennetier. L'établissement financier avait commis exactement la même erreur. Mais les écueils les plus courants relèvent des rapports humains. ' L'organisation des méthodes agiles implique des membres de l'équipe qu'ils s'expriment en public et s'octroient des tâches. Or dans le groupe, certains sont effrayés par les responsabilités et la prise d'initiative. D'autres manquent de souplesse et cherchent à respecter à la lettre le planning, sans trop réfléchir ', rapporte Jean-Laurent Favre, de Vidal.
De la même façon, Achille, dans un autre projet qu'il a mené par la suite, a vu le stand-up meeting totalement dévoyé de sa fonction : ' C'était devenu un lieu pour les règlements de compte. Le chef de projet en profitait pour chercher les coupables des dysfonctionnements constatés. ' Mais en dépit d'inévitables difficultés, le bilan de ces méthodes reste extrêmement positif. Pour preuve, tous les projets évoqués ici ont fait des petits dans les quatre entreprises.
Alors pourquoi ces méthodes pénètrent-elles si difficilement les DSI ? Certes, elles n'ont pas encore fait leur preuve sur les gros projets. Mais au-delà de la taille ou de la culture du changement, certains pointent l'inertie des méthodes traditionnelles : ' C'est bien connu, la plupart des sociétés de services font leur marge sur les avenants ', lance Achille, lui-même ancien salarié de SSII. ' Pourquoi changeraient-elles en investissant véritablement sur la qualité ? ' Même ressenti pour David Gageot, de Valtech : ' Les géants de l'intégration n'ont pas intérêt à pousser ces méthodes. Ils préfèrent recevoir un chèque en blanc sur une année plutôt que de prendre le risque de voir leur client stopper le projet à chaque fin d'itération. '

Une approche par itérations

agrandir la photo

A l'issue d'une itération (les projets en comptent souvent une quinzaine), l'équipe de développement délivre une application certes incomplète mais, en théorie, de très bonne qualité. Cette application est testée et approuvée par les utilisateurs qui définissent, avec l'équipe informatique, les prochaines fonctionnalités à développer. Dans la méthodologie Scrum, le product owner gère le backlog de produits, et le Scrum master fait appliquer la méthodologie en s'assurant du bon avancement du projet.

Un meilleur dialogue

Olivier Rigal, responsable du pôle étude de la DSI d'Alma Consulting Group
' Les utilisateurs n'ont pas à détailler tous leurs besoins d'une seule traite '

Champs d'application : rénovation de l'outil interne de suivi de mission de réduction de coûts.
État : en déploiement.
Calendrier : production prévue pour avril 2008.
Prestataire : Xebia pour le conseil, la formation et le développement
Equipe : de 4 à 5 personnes

Des délais raccourcis

Eric Hennetier, DSI adjoint de M6
' Avec les méthodes agiles, nous cassons l'effet tunnel qui entache souvent les projets traditionnels '

Champs d'application : développement d'un extranet publicitaire
État : en production.
Calendrier : de mars à septembre 2007.
Prestataires : Octo Technology (conseil, formation et encadrement) et Sphere pour les équipes de développement.
Équipe : 6 personnes.

eXtreme Programming en 13 points

1. Client sur site

En théorie, un représentant des métiers accompagne et oriente l'équipe de développement chaque jour. En pratique, cette présence est rarement quotidienne.

2. Jeu du planning

Pratiquée en début d'itération, cette réunion voit l'utilisateur indiquer les fonctions qu'il désire. Les développeurs en estiment la charge en jours-hommes et font choisir à l'utilisateur les ' stories ' (cas d'utilisation) à implémenter.

3. Intégration continue

Ou usine de développement. A chaque modification apportée au code archivé dans le référentiel, tout le projet est recompilé sur une machine dédiée. Celle-ci joue tous les tests, puis déploie le projet sur le serveur d'homologation.

4. Petites livraisons

On parle ici d'itérations de quelques semaines et non plus de délais de plusieurs mois.

5. Rythme soutenable

Le développeur doit avoir une vie sociale et équilibrée pour conserver une bonne productivité. Pas plus de sept à huit heures de travail par jour.

6. Tests de recette

Développeurs et fonctionnels écrivent ensemble ces tests calés sur les stories de chaque itération. Ils constituent le véritable juge de paix de celle-ci.

7. Tests unitaires

Chaque modification du code est soumise à ces tests pour identifier au plus vite les anomalies. Ils sont de préférence écrits avant le code.

8. Conception simple

Le code produit ne doit pas être générique. Le développeur doit s'en tenir à la seule tâche de la journée, et non anticiper sur les autres.

9. Utilisation de métaphores

Elles facilitent la compréhension entre développeur et fonctionnels.

10. Refactoring

Les équipes remanient le code, et améliorent ses fondements. Sans changer ni les contrats, ni les services qu'il rend.

11. Appropriation du code

Il appartient à toute l'équipe. Chaque membre est autorisé à le modifier pourvu que les tests réussissent.

12. Convention de nommage

Le code devant être compris par toute l'équipe, l'emploi de normes communes pour décrire les variables, les méthodes ou les objets est indispensable.

13. Programmation en binôme

Deux têtes valent mieux qu'une pour résoudre les problèmes. Les développeurs partagent un poste. Ces paires peuvent changer quotidiennement. Difficile à appliquer en pratique.

L'avis du consultant : Guillaume Bodet, directeur technique de la SSII Xebia

' Les méthodes agiles suppriment les liens hiérarchiques '

' Dans une organisation agile, les rôles traditionnels d'analyste fonctionnel, d'architecte ou de responsable de base de données n'existent plus formellement. Toutes les compétences sont diluées dans l'équipe, et partagées par ses membres. Même la fonction de chef de projet est revue : elle est délestée d'une partie de sa composante planification, de loin la plus consommatrice. Cette nouvelle approche est donc difficilement applicable dans les structures très hiérarchisées. '

' Les grands éditeurs s'y sont convertis '

' Chez les utilisateurs, l'informatique est uniquement vu comme un centre de coût. Peu d'entreprises mesurent donc son ROI. Il devient donc compliqué de les convaincre d'améliorer celui-ci avec les méthodes agiles. En revanche, les grands éditeurs les adoptent pour leur projets internet. C'est le cas de Google, deBay et de Microsoft. '

envoyer
par mail
imprimer
l'article


@01Business_fr sur
à lire aussi
SUR LES MÊMES THÈMES
Violation de brevets : la justice américaine exempte Apple d'une lourde amende
Le pilote de la French Tech prend en charge l’innovation de la Société Générale
01 Replay : Coup de pouce à la startup LuckyCart
Evasion fiscale: l'OCDE relève les défis posés par l’économie numérique
La société grenobloise Vi Technology lève 15 millions d'euros
La Société Générale organise un hackathon sur les objets connectés
Assises du financement : le numérique en première ligne
Loi antiterroriste : le PRISM à la française en débat à l’Assemblée Nationale
Opérateurs : Iliad pourrait hausser son offre sur T-Mobile
Microsoft rachète le créateur de Minecraft pour 2,5 milliards de dollars
Autopartage: Wattmobile et Zipcar à la conquête de Paris face à Autolib
Alibaba revoit à la hausse son prix d’introduction à la Bourse
Awox, concepteur d'objet connecté, rachète Cabasse dans la hi-fi
Netflix enfin déployé en France et bientôt sur la Bbox
HP, Blackberry, Google, Business & Decision... Les rachats IT de la semaine
MAAF, Publicis, CHU Nantes... Les contrats IT de la semaine
Paris cherche à taxer Netflix… sans résultat
Le réseau social français Wizbii lève 1,6 million d'euros
La BPCE innove en lançant le paiement par Twitter entre particuliers
En attendant Apple Pay, le marché français des terminaux NFC décolle