Livre Blanc

www.valtech.fr

Adoption des mthodes Agiles dans les projets IT

Plus de matrise, plus de valeur, plus tt et plus vite

A propos de Valtech Technology

Valtech Technology est une division du groupe Valtech, socit internationale spcialise dans la formation, la ralisation de projets, le conseil en technologies, en e-business et en management. Valtech Technology est lun des leaders en France dans limplmentation des mthodes de dveloppement Agiles (SCRUM en particulier). Par son double savoir-faire de conseil et de conduite de projets informatiques, Valtech Technology apporte aux entreprises lexpertise et lexprience des architectures et de lindustrialisation des dveloppements. Spcialis dans l'adoption des mthodes Agiles, Valtech dispose de plusieurs centres de services, notamment un centre de dveloppement offshore en Inde Bangalore. Impliqu de bout en bout dans la ralisation des projets, Valtech Technology est lun des seuls cabinets de conseil et de service faire concrtement le lien entre le conseil et la ralisation de projets. Cr en 1993 et ct sur lEurolist dEuronext, le groupe Valtech emploie aujourdhui plus de 1 100 salaris travers le monde (Etats-Unis, Europe et Asie) et a ralis un chiffre daffaires de 106,7 millions deuros en 2007.

Remerciements
Je profite de ces quelques lignes pour remercier lensemble des consultants de VALTECH TECHNOLOGY qui se sont beaucoup investis durant ces 6 derniers mois sur la publication de ce Livre Blanc Agile. Ces efforts runis ont permis de mettre en avant notre matrise des mthodes Agiles ainsi que nos nombreuses expriences terrain. Je tiens remercier particulirement Elisabeth DUCARRE, Etienne CHARIGNON, Frdric TREMEAU, Gilles MANTEL, Hlne GRANBOULAN, Nathalie LOPEZ et Stphane LABATI qui ont su synthtiser leurs retours dexprience dans des domaines aussi varis que les pratiques Agiles, la gestion des exigences, le test, la conduite de projet, la qualit, le Lean et le CMMI. Enfin, nos remerciements vont galement nos clients qui, par leur confiance, ont accept de nous associer leurs dfis, renforant jour aprs jour notre expertise et notre capacit les aider dans ladoption de lagilit. Hubert GILLON, Delivery Manager, Valtech Technology.

LIVRE BLANC labor par la communaut Agile de Valtech Technology, forte de 30 consultants, seniors et experts, sous la direction de Hubert GILLON, Delivery Manager, responsable de lactivit projet offshore. Toute reprsentation ou reproduction intgrale ou partielle, faite sans le consentement de Valtech Technology, de ses ayants droits, ou ayants cause, est illicite (Loi du 11 Mars 1957, article 40, alina 1).

Sommaire
1. Vision................................................................................................. 4
1.1 Pourquoi adopter les mthodes Agiles ?.............................................................. 4 1.2 Qui est concern ?. .............................................................................................. 6 1.3 Quelles sont les pratiques Agiles les plus rpandues ?.......................................... 6 1.4 Comment adopter les mthodes Agiles ?. ............................................................ 7 1.5 Quels sont les acclrateurs de cette adoption ?.................................................. 8

2. Les mthodes Agiles pour les nuls ................................................. 10

2.1 Tmoignage dun coach Agile Valtech............................................................... 10 2.2 Rsultats obtenus sur des projets raliss par Valtech......................................... 12 2.3 Difficults couramment rencontres.................................................................. 13 2.4 Opportunits de loffshore. ................................................................................ 14

3. Success Stories................................................................................... 16
3.1 Opportunits d'adoption de l'agilit.................................................................. 16 3.2 TDR au cur des spcifications......................................................................... 19 3.3 Retour dexprience sur la gestion de projet...................................................... 25 3.4 Pratique de recueil de besoin - le Product Backlog............................................. 29 3.5 Pratique de gestion de projet - lIteration Backlog. ............................................. 32 3.6 Retour dexprience sur lautomatisation des tests............................................. 34 3.7 TDD au cur des dveloppements. ................................................................... 36

4. Lagilit faon Lean . ..................................................................... 39 5. Lagilit face aux standards Qualit................................................... 42

5.1 Qualit du produit ou des processus : Agilit ou ISO ?....................................... 42 5.2 Mettre de lagilit dans une dmarche CMMI.................................................... 43

6. La contractualisation Agile, une affaire de bon sens........................... 47

6.1 A quoi sert un contrat ?..................................................................................... 47 6.2 Une ncessaire rvolution des mentalits........................................................... 48 6.3 Rgles de collaboration client-fournisseur.......................................................... 48 6.4 Mthodes et outils permettant de travailler de manire transparente. ................ 49 6.5 Flexibilit pour tenir compte des changements fonctionnels.............................. 50 6.6 Ralisme du contrat Agile.................................................................................. 50

ZOOM Pratiques Agiles.......................................................................... 52 Glossaire............................................................................................... 55 Documents de rfrence......................................................................... 55

Table des figures

Figure 1 : Figure 2 : Figure 3 : Figure 4 : Figure 5 : Figure 6 : Figure 7 : Figure 8 : Figure 9 : Exemple de pratiques dingnierie et de pilotage de projet. ............................... 18 Planning dtaill dune itration........................................................................ 26 Planning dtaill dune semaine........................................................................ 26 Planning dtaill dune journe......................................................................... 27 Exemple de Product Backlog............................................................................. 30 Gestion des priorits et de la complexit dans le Product Backlog. ..................... 31 Exemple de burndown chart dun Iteration Backlog..................................... 33 Cycle de Deming PDCA (Plan, Do, Check, Act). ................................................. 42 Les pratiques Agiles issues de XP et Scrum......................................................... 52

Table des tableaux

Tableau 1 : TDR - Donnes initiales.................................................................................... 21 Tableau 2 : TDR Affaire versus convention................................................................ 21 / 22 Tableau 3 : TDR Validation de convention....................................................................... 22 Tableau 4 : Contexte projet. ............................................................................................... 25 Tableau 5 : Documents de rfrence et bibliographie......................................................... 55

1.Vision
1.1 Pourquoi adopter les mthodes Agiles ?

80%

Dans plus de

des projets, la premire cause d'chec est le fameux cycle en cascade

Dans plus de 80% des projets, la premire cause d'chec est le cycle en cascade, qui prne un planning fixe et un enchanement strict des diffrentes phases, des spcifications jusqu' la validation logicielle. Cette vision rassurante est bien loin de la ralit des activits d'ingnierie qui ne sauraient se succder strictement sans qu'aucun changement n'intervienne pour perturber un planning qui n'a de dure de vie que le temps de le prononcer. Le rle jou par le client dans un tel cycle intervient principalement au lancement du projet, chaque jalon majeur, soit des moments pouvant tre espacs de plusieurs mois sur de gros projets, et surtout en fin de projet pour rceptionner et recetter le logiciel. Cet effet tunnel conduit un logiciel inadapt et souvent de pitre qualit. Cela est souvent renforc par le mode contractuel forfaitaire qui : durcit les relations entre client et fournisseur, rend le passage de tmoin long et douloureux la fin du projet.

De plus, le passage de relais entre les phases successives dans lesquelles uvrent des quipes diffrentes, gnralise une relation de type client-fournisseur et n'encourage pas l'empathie ni l'esprit d'quipe, bien au contraire. A chaque transition, une perte en ligne survient qu'il s'agisse de temps, de connaissance, d'information ou de responsabilit. Elle rend inefficace ce cycle jusqu' nos jours universel, et qui a nanmoins eu le mrite d'exister avant les autres et d'aider les organisations standardiser leurs activits d'ingnierie de dveloppement. Cette standardisation

a produit un nombre important de documents, rendus souvent plthoriques sur les projets, dtournant ainsi l'objectif premier qui est de raliser une application rpondant aux besoins d'un client, vers la production de documents complets, coteux laborer, et souvent inutiles. Elle a galement eu pour consquence de crer un rle qualit ayant pour fonction de vrifier l'application de ces standards ou rfrentiels applicables. A contrario, les mthodes Agiles prconisent l'adoption d'un cycle itratif et incrmental permettant un projet de s'adapter son contexte et aux changements inhrents la nature humaine, aux erreurs ou aux changements ne manquant jamais de survenir tout au long d'un projet. Ce type de cycle de vie facilite la prise en compte des changements. Il a comme autre avantage de permettre de faon rgulire ( chaque fin d'itration) et une frquence leve (2 4 semaines) de recueillir le feedback du client et/ou des utilisateurs quant au devenir de l'application en cours de dveloppement, annulant ainsi tout effet tunnel. Un autre avantage est le fait de fixer des objectifs court terme. Cela permet de maintenir une pression constante mais supportable sur l'quipe, alors quau dbut dun cycle en V chacun a limpression davoir suffisamment de temps devant lui et subit finalement une pression norme lapproche de la livraison. De plus, l'agilit prne la collaboration entre les personnes et l'intgration des quipes. Elle combat les fameux passages de relais en rassemblant dans un mme espace toutes les nergies et la comptence de personnes toutes centres sur l'application raliser. Plus de barrires donc, et des tches dfinies par l'quipe au meilleur moment c'est--dire quand on en a besoin, plutt qu'au dbut du projet. Enfin, les mthodes Agiles mettent l'accent sur l'importance de dvelopper le bon produit en limitant la documentation produire au strict ncessaire, et en concentrant l'essentiel de l'effort d'une quipe raliser une application de qualit, teste souvent, exempte d'anomalie et rpondant coup sr aux vrais besoins des utilisateurs par le feedback rgulier. Point besoin d'une personne ddie la qualit dans ce type de fonctionnement car toute l'quipe assure la qualit des activits par le partage, la collaboration, et l'industrialisation des processus centre sur leur efficacit, notamment grce l'automatisation du dploiement, des tests et des revues de code.

Le succs des projets Agiles renforce jour aprs jour l'engouement des DSI et des quipes informatiques pour des pratiques remettant l'application et l'homme au centre du sujet. Un projet n'est-il pas d'abord une aventure humaine vcue par des hommes pour d'autres hommes ? Hubert GILLON, Delivery Manager, VALTECH TECHNOLOGY

1.2 Qui est concern ?

Rappelons que lagilit est base sur les 4 grands principes suivants :  priorit aux personnes et aux interactions plutt que sur les processus et les outils,  focus sur le logiciel dvelopper plutt que sur sa documentation (on privilgie le code et sa qualit),  collaboration avec le client (feedbacks frquents) plutt que ngociation et suivi du contrat,  ractivit au changement qui consiste accueillir tout changement de faon positive plutt que de se rfugier derrire un planning dtaill initial qui est de fait, forcment faux. Forts de ces principes, on voit qu'une organisation, un dpartement, une business unit, un projet et mme une quipe peuvent adopter l'agilit avec succs. Mais qu'en est-il d'un projet dj dmarr ou en difficult ? L'Agilit peut galement dans ce cas, soit amliorer les rsultats dj obtenus, soit rsoudre bon nombre des causes des difficults vcues.

Elle va amener les personnes impliques :  mieux collaborer,  prendre du recul sur l'application en priorisant les actions et en remettant plat le chiffrage initial,  donner plus de visibilit aux clients et utilisateurs,  liminer l'effet tunnel induit par le cycle en V, en le remplaant par des itrations courtes et matrises. L'idal serait que toute l'organisation ait conscience de l'intrt de fonctionner diffremment et qu'elle mette dans sa stratgie l'adoption d'un ou plusieurs de ces principes. Hubert GILLON, Delivery Manager, VALTECH TECHNOLOGY

1.3 Quelles sont les pratiques Agiles les plus rpandues ?

Les pratiques Agiles les plus rpandues sont : limplication forte du client travers le rle de "Product Owner",  l'utilisation d'un "Product Backlog" pour tablir une vision terminaison des fonctions d'un produit et des priorits mtier associes,  l'utilisation d'un "Iteration Backlog" traduisant les fonctions d'un "product backlog" en tches priorises, chiffres (en heures) et assignes l'quipe projet,

l e "Scrum Meeting" appel galement "standup meeting", runion quotidienne (maximum 15 min et sans compte rendu) rassemblant une quipe de maximum 10 personnes ayant pour objectif de communiquer ce que chacun a fait le jour d'avant, les problmes rencontrs et les tches du jour prvues,  le "Retrospective Meeting" se focalise sur les vnements survenus et l'analyse causale des dysfonctionnements, des pertes de productivit et de qualit. Un ou deux axes d'amlioration seront privilgis de faon consensuelle et se traduiront par des tches dans le backlog de litration suivante,  le "Sanity Check", point mi parcours d'une itration formalisant l'avancement de la ralisation des fonctions d'un produit afin de savoir si les objectifs de l'itration en termes de livraison pourront tre atteints (en qualit et en quantit) et de dcider en consquence soit de rduire les objectifs en enlevant des fonctions de l'"iteration backlog", soit au contraire d'en ajouter,  l"Iteration Planning" en dbut d'itration, permet l'ensemble de l'quipe projet d'identifier, d'estimer, de planifier et de s'affecter les tches,  la Vlocit qui est la mesure de la capacit du projet (ou d'une quipe) livrer des fonctions en tenant compte de la capacit de production (taille de l'quipe et dure des itrations). Elle s'appuie souvent sur la taille des fonctions exprime en points de fonction, points de cas dutilisation ou poids de la srie de Fibonacci (1, 2, 3, 5, 8...),  lIntgration Continue consiste compiler, assembler, vrifier et tester lensemble du code source ds quun nouvel lment est mis disposition, soit idalement une plusieurs fois par jour,  le "Test Driven Development" (TDD) consiste crire les programmes de tests unitaires avant de programmer les composants eux-mmes, puis de refactorer le code source test unitairement jusqu obtenir un code de qualit,  le "Test Driven Requirements" (TDR) permet de spcifier le logiciel par lexemple i.e. les exigences logicielles sont dtailles sous forme de cas de test,  le "Pair Programming" consiste programmer en binme dans le but dtre plus efficient en termes de conception, de revue de code et de transfert de comptence.

1.4 Comment adopter les mthodes Agiles ?

Le fait de ne pas savoir de quelle faon dmarrer une migration vers l'agilit freine vraisemblablement de nombreuses entreprises ou DSI, malgr l'intrt vident qu'elle suscite. Voici la dmarche propose par Valtech.  Veille active : permet de tester sa motivation et sa dtermination vouloir adopter les mthodes Agiles partir de sminaires, de salons spcialiss, de lectures techniques ou commerciales...

1 ou plusieurs petits projets de 3 6 itrations pour commencer.

E  tude dopportunit dadoption de lagilit : consiste vrifier au sein de son organisation s'il est opportun de lancer une dmarche d'adoption en termes de stratgie, de connaissance, de disponibilit, de contraintes et de planning. Le recrutement ou le recours des personnes expertes de l'agilit amliorera grandement les chances de succs de la dmarche d'adoption.  Prparation du projet pilote : former aux mthodes Agiles (2 jours), former le "product owner" (2 jours), tablir les mtriques de suivi de l'adoption (1 jour) et tablir le "product backlog" du projet pilote (3 5 jours).  Projets pilotes (3 6 mois) : il s'agit de raliser 1 ou plusieurs petits projets de 3 6 itrations avec l'aide de consultants experts de l'agilit, en conseil ou mme en tant qu'oprationnel intgr l'quipe projet (cela est assurment plus efficace).  Rtrospective (1 2 jours) : un bilan des projets pilotes s'impose alors, destin recueillir les mtriques des projets et en faire la consolidation, analyser les vnements ayant eu un impact ngatif en termes de productivit, d'interface entre quipes distantes (nearshore ou offshore), de frais de structure et de suivi, pour ensuite dfinir un plan d'amlioration.  Planification du dploiement (1 jour) : un plan de dploiement doit tre labor afin d'orchestrer le dploiement des bonnes pratiques Agiles sur les diffrents projets. Il reste d'assez haut niveau (quelles pratiques sur quels projets et quelle chance) afin de laisser chaque projet libre de grer ses priorits de dveloppement via son backlog.  Dploiement de l'agilit dans l'organisation (1 2 ans) : si possible, ce dploiement doit tre guid par le ROI d'o l'importance d'avoir dfini et utilis des mesures dans les tapes prcdentes. A la fin de chaque itration de chaque projet, un "retrospective meeting" permettra de corriger les processus ne donnant pas satisfaction, en vritable outil d'amlioration continue de l'organisation devenue Agile.

1.5 Quels sont les acclrateurs de cette adoption ?

La meilleure faon dacclrer ladoption de lagilit est dliminer petit petit les freins cette adoption. Mis part l'incontournable rsistance au changement et les erreurs de mise en uvre et de dploiement, voici les freins que nous avons rpertoris.

Du point de vue du projet

 Le fait que le projet pilote choisi, ne soit pas un projet assez important mais un petit projet non significatif, qui ne permettra pas de rellement tirer des conclusions transposables aux futurs projets : le projet sera donc de taille significative et durera de 3 et 6 mois.

 Le manque de sponsor rel met en danger la prennit de la dmarche d'adoption qui, par moment, ncessite un soutien inconditionnel de la direction et des dcisions rapides : le "product owner" doit rellement tre impliqu et moteur sur le projet vu l'importance de son rle.  La communication insuffisante vers le management de l'organisation.  La non mise en place des rtrospectives, facteur incontournable de l'amlioration continue ncessaire au succs de l'adoption de nouveaux processus Agiles.

Du point de vue des conditions de travail

L'quipe est isole du reste de lorganisation durant toute litration. Lidal est que le product owner soit intgr lquipe : le scrum master est l pour viter toute perturbation extrieure. la disposition des lieux doit favoriser les changes : pas de cloison ni de box ( cubicle ). L'utilisation de tableaux blancs, de wiki, d'outils tels que Valtech Cockpit, RallyDev et TeamConcert, favorisent grandement la collaboration et l'efficacit des processus Agiles.  L'absence d'outil collaboratif permettant de partager en temps rel les informations projet dfavorise la collaboration au sein de l'quipe alors qu'il faut investir dans les actions destines crer un esprit d'quipe et faire travailler les gens entre eux d'une manire naturelle, constructive et efficace.  Le fait que certaines personnes interviennent temps partiel sur de multiples projets nuit la collaboration entre les acteurs. L'quipe doit tre ddie et compose de personnes comptentes et communicantes.

Du point de vue des processus

 Spcifier l'avance un ensemble d'exigences tue la collaboration entre le "product owner", l'analyste et le dveloppeur tout en rendant moins efficace le transfert de connaissance entre l'analyste et l'quipe de dveloppement.  Planifier toutes les itrations en dtail sur une longue priode de temps n'a aucun sens et constitue une perte de temps : seule l'itration courante doit l'tre, avec une bonne vision des objectifs pour les itrations suivantes.  Baser sa vision de l'avancement sur le % de tches termines plutt que sur le reste faire.  Ne pas crer de tests fonctionnels automatisables trop tt dans le cycle de vie.

Lessentiel retenir - Les mthodes Agiles prconisent l'adoption d'un cycle itratif et incrmental. - Lagilit prne la collaboration entre les personnes et l'intgration des quipes. - Les mthodes Agiles mettent l'accent sur l'importance de dvelopper le bon produit. - 4 grands principes : priorit aux personnes focus sur le produit collaboration avec le client ractivit au changement - Ladoption de lagilit doit tre guide par le ROI. - Llimination des freins ladoption est le meilleur moyen dacclrer cette adoption.

2. Les mthodes Agiles "pour les nuls"

2.1 Tmoignage dun coach Agile Valtech

Agile, cest pratique !

L'agilit peut se vivre au jour le jour sur des projets informatiques. Ce n'est pas un doux rve inatteignable et dans bien des cas, c'est mme assez facile. Les sceptiques vous diront peut-tre que l'agilit n'est qu'un concept, un rve loign des ralits concrtes rencontres au quotidien. N'entendons-nous pas souvent des "oui, mais chez nous a n'est pas possible !", ou des "oui, mais dans la vraie vie ce n'est pas comme a !" ? Ah, oui, mais pourtant, jexiste ! Avant de trouver des projets officiellement Agiles, j'ai fait pendant assez longtemps du dveloppement logiciel Agile en sous-marin et, les pratiques que j'ai pu mettre en place ont toujours apport normment au projet, si ce n'est pas tout simplement le succs. Etienne CHARIGNON, Consultant senior, Scrum master certified, VALTECH TECHNOLOGY

10

Les pratiques comme le TDD (Dveloppement pilot par les tests : voir en annexe) ou les tests de recette automatiss sont faciles mettre en place condition qu'on veuille bien s'en donner la peine. Comme dit le proverbe la qualit est gratuite condition que l'on veuille bien en payer le prix . Les pratiques que vous voudrez mettre en place vous feront gagner du temps sur le long terme, mais coteront quelque chose au dbut.

Spcifications incrmentales et TDR Valeur mtier not entre 1 et 3, difficult technique note de 1 13 suivant la suite de Fibonacci
Comme on pourrait s'y attendre, les pratiques de dveloppement sont bien plus faciles mettre en place que, par exemple, celles qui font intervenir le client. Pour le faire, sur un projet sur lequel nous travaillons en ce moment, nous avons planifi une itration zro de mise en route d'une semaine, durant laquelle nous avons entre autre dfini la liste des scnarii d'utilisation mais aussi mis en place Fitnesse, un outil de TDR (Test-Driven Requirement: voir en annexe) bas sur un wiki. Nous avons conseill au client de ne plus dtailler toutes ses exigences fonctionnelles avant de dmarrer les dveloppements. A la place, nous lui avons demand la liste des scnarii d'utilisation (le "product backlog"). Puis pour chaque scnario, il a attribu une valeur mtier not entre 1 et 3, et nous en avons estim la difficult technique note de 1 13 suivant la suite de Fibonacci. Un tel "product backlog" est ensuite plus facile manipuler que directement une spcification dtaille.

Mais le travail de spcification ne s'arrte pas l. Au dbut de chaque itration, nous choisissons les scnarii qui doivent tre raliss pendant l'itration et en dfinissons les critres d'acceptation. Cest de cette manire que nous dtaillons les spcifications. Pour viter le gaspillage, les dtails ne sont pas prvus entirement l'avance (pas de stock), mais seulement au moment o les dveloppeurs sont prts les recevoir. Ce flux tendu de spcification constitue la "sve du processus Agile". Etienne CHARIGNON, Consultant senior, Scrum master certified, VALTECH TECHNOLOGY

"War room"
La premire chose faire est de runir les gens dans un mme lieu, ddi au projet. La mise en place dautres pratiques sen trouve grandement favorise : pour suivre le projet, on utilise les post-its sur les murs,  pour faciliter le travail en binme et la proprit collective du code, il est prfrable d'avoir un ensemble d'ordinateurs non affects individuellement, mais ddis un type de tche : dveloppement, bureautique... De plus, il est indispensable que les postes de dveloppement soient homognes. Ds que vous aurez mis en place tous ces lments vous aurez votre "war room". Il est vident qu'il est plus difficile de le faire lorsque les dveloppeurs sont parpills dans un "open space".

11

Serveur d'intgration continue

Votre "war room" peut contenir une machine ddie l'intgration continue car il est assez facile de librer une machine pour la ddier cette activit tant donn que les dveloppeurs travaillent chaque fois que ncessaire en binmes. En quelques minutes, vous installez un logiciel comme Hudson ou CruiseControl. Ce type de logiciel sera capable d'aller lui-mme chercher le code source dans le dpt de votre systme de gestion de version (par exemple Subversion ou ClearCase), de le compiler et d'excuter une srie de tests et de mesures de qualit avec des outils tels que CheckStyle ou Cobertura. Il reste ensuite astreindre plusieurs fois par jours les dveloppeurs poster leur travail sur le dpt central (opration appele "Commit").

2.2 Rsultats obtenus sur des projets raliss par Valtech

Valtech est la premire socit en France, en 2002, avoir propos une formation de conduite de projet dans un contexte itratif et incrmental ( lpoque sur la base de Unified Process). Mais trs vite, cette dmarche utilise sur les projets de lpoque a t remplace par la dmarche SCRUM, plus Agile et moins contraignante du point de vue de la documentation projet et des livrables. Cette adoption a t renforce par lintervention en 2003, en France mais galement en Inde dans notre centre de dveloppement Bangalore, de Monsieur Craig Larman, auteur de nombreux ouvrages de rfrence en matire de processus dingnierie logiciel et dagilit. Il a eu la responsabilit de dployer lensemble des principes Agiles sur la totalit des projets, jusqu la rorganisation complte des bureaux organiss en cubicals , transforms en espaces de travail ouverts. Il a galement certifi Scrum Master lensemble des chefs de projet, et a initialis la mise en place de nouveaux outils tels que Valtech Cockpit, la plateforme collaborative Valtech, utilise sur les projets encore aujourdhui.

12

Cet lectrochoc a t rellement salutaire car les rsultats sur les projets ont t grandement amliors sur diffrents plans.  Le Respect des dlais : le time boxing et le fait de procder par sprints successifs a permis aux quipes projet daugmenter leur productivit.  La Qualit des livraisons : les anomalies tant corriges au fur et mesure, avec une priorit plus importante que les fonctionnalits livrer, la charge de travail de gestion de ces anomalies a diminu pour laisser place plus de fonctions implmentes.

L  a Confiance de nos clients : tout nos clients sont rests fidles et possdent des quipes Bangalore dont le nombre saccrot chaque anne. De plus, de nouveaux clients intresss par loffshore et lagilit nous ont mis en comptition sur des Proof of concept avec la clef de nouveaux projets sur des domaines jusque-l inexplors par Valtech, comme par exemple celui de testeur de puces lectroniques.  La Satisfaction de nos collaborateurs : le fait de collaborer plus troitement avec des quipes distantes et dune culture diffrente a motiv de nombreux consultants, les incitant aller plus souvent en Inde ou faire des missions de conseil sur ladoption de lagilit dans un contexte onshore mais galement offshore.  Un Certain confort sur les projets : souvent le terme projet est synonyme de stress, dinsatisfaction, de pertes financires Avec la mise en place des pratiques Agiles, la matrise des projets saccrot, le feedback du client et des utilisateurs est rel, la qualit des livraisons et la productivit ont nettement augment.

2.3 Difficults couramment rencontres

Ladoption de lagilit est une dmarche dentreprise qui peut se limiter un projet. Cependant de la mme manire que le CMMI sadresse une organisation et non un projet unique, ladoption de lagilit peut galement avoir comme primtre, lensemble des projets dune organisation.

13

Une des premires difficults est le passage lacte qui suppose que le management soit convaincu des bienfaits dune telle approche pour les clients et pour les projets dlivrant les applications ou les produits. Hubert GILLON, Delivery Manager, VALTECH TECHNOLOGY

Autre difficult souvent rencontre, celle dadopter ltat desprit Agile, qui suppose de ne pas se contenter de faire son march dans les pratiques Agiles. En effet, ladoption de lagilit est laffaire de tous et non de certains acteurs qui mettraient en uvre telle ou telle pratique Agile, pensant que cela limiterait les risques dchec. En supposant que tout le monde soit convaincu de lintrt dadopter lagilit, la mise en uvre concrte des pratiques telles que planning games, rtrospectives et backlogs produit suppose une bonne matrise des concepts sous-jacents ainsi quune exprience concrte des projets.

20 personnes sur une itration de 4 semaines grent 1600 tches de 2 heures en moyenne

S  i lon prend lexemple des tches des backlogs ditration, il arrive trs souvent que les chefs de projet se retrouvent littralement noys par le nombre de tches grer. La raison en est que la granularit des tches gres est souvent bien trop fine, ce qui induit videmment un nombre draisonnable de tches : une quipe de 20 personnes dfinissant chaque itration de 4 semaines des tches de 2h en charge en moyenne, se traduit par 1600 tches !  Le fait de fonctionner en time boxing (dure ditration fixe quoiquil arrive et quelque soit le rsultat de litration), de livrer des documents partiellement raliss (contraire notre culture), ou didentifier 3 voire 4 amliorations raliser sur la prochaine itration lissue dune rtrospective, constituent autant de difficults et de piges quil faut tout prix viter, au risque de discrditer lagilit jamais. Aussi est-t-il trs important de faire intervenir un scrum master et des experts des pratiques Agiles pour se faire aider dans la mise en uvre de lagilit. La granularit des tches aurait oscill entre 4h et 2j par tche ce qui aurait conduit 5 fois moins de tches grer, le projet aurait t livr lheure, et le nombre damliorations aurait t de 1 par itration au maximum.

14
2.4 Opportunits de loffshore Ne grer que des tches de 4 heures 2 jours de charge

Ne retenir qu'une amlioration par itration au maximum

Valtech est implant en Inde depuis 2001 et possde aujourdhui un centre de dveloppement Agile Bangalore. Ce centre est mis contribution sur la trs grande majorit des projets.

Son utilisation est un succs aujourdhui grce la mise en place de lagilit qui a permis :  aux quipes distantes de mieux collaborer et de mieux communiquer,  damliorer la visibilit sur les projets,  de partager les estimations en utilisant systmatiquement des mthodes telles que Function Point et Use-case Point, et donc daboutir des engagements respectifs clairs,  de programmer des voyages frquents pour favoriser les transferts de connaissances et lapprentissage de la culture du pays distant,  de converger vers des modles dorganisation projet et une dfinition dacteurs cls tels que les Coordinateurs offshores en charge de faciliter la communication entre les quipes distantes,  de responsabiliser les quipes offshores par la mise en place localement de planning games, de scrum meetings et de rtrospectives,  de donner naissance un vritable esprit dquipe, renforc par des activits extra professionnelles permettant de crer les liens trs utiles lorsque surviennent certaines difficults ou certains problmes. Lutilisation de nouveaux outils collaboratifs tels que Valtech Cockpit, et la mise en place de lintgration continue entre les quipes distantes ont amlior la productivit en offshore et la comprhension mutuelle des comptences et des responsabilits de chacun. Hubert GILLON, Delivery Manager, VALTECH TECHNOLOGY On peut donc affirmer aujourdhui que lagilit constitue un outil rellement efficace pour favoriser lutilisation dquipes distantes en nearshore ou en offshore, capable de rduire la distance entre les hommes au niveau organisationnel, dmarche projet et outil, et de crer lesprit dquipe si bnfique la ralisation des projets informatiques.

15

Lessentiel retenir Pour tre Agile : - Ne pas dtailler toutes les exigences fonctionnelles avant de dmarrer les dveloppements. - Pour viter le gaspillage, les dtails ne sont pas prvus entirement l'avance. - Une machine est ddie l'intgration continue. - Il faut astreindre plusieurs fois par jour les dveloppeurs poster leur travail sur le dpt central - Il faut adopter ltat desprit Agile. - La mise en uvre concrte des pratiques telles que les planning games, rtrospectives et backlogs produit suppose une bonne matrise des concepts sous-jacents ainsi quune exprience projet concrte. Il est important de faire intervenir un Scrum master et des experts des pratiques Agiles pour se faire aider dans la mise en uvre de lagilit. Lagilit constitue un outil rellement efficace pour favoriser l'utilisation des quipes distantes en nearshore ou en offshore.

3.Success Stories
3.1 Opportunits d'adoption de l'agilit

Etude d'opportunit
L'tude d'opportunit de l'adoption de l'agilit par une organisation est le moyen idal pour s'initier en douceur au monde de l'agilit. Base sur l'coute et l'change, cette tude permet d'apporter une solution personnalise et adapte aux attentes et besoins du client.

16

L'objectif de cette tude n'est pas de faire un audit projet, mais plutt d'identifier les pertes d'nergies et les ventuels effets d'inertie de l'organisation projet ainsi que didentifier de nouvelles pratiques plus efficaces et plus Agiles. Les tapes de cette tude sont les suivantes :  tat des lieux sur les pratiques en cours,  rdaction d'un document de synthse sur l'existant,  adoption de pratiques adaptes au contexte du client,  rdaction et soutenance des pratiques retenues.

Droulement des tapes

Etat des lieux sur les pratiques en cours Cette tape se droule sous forme d'interviews et de workshops qui visent tablir la cartographie des pratiques en cours auprs d'un chantillon de personnes intervenant sur tout le cycle de vie d'un projet (matrise d'ouvrage, matrise d'uvre, cellule qualit, formateurs...). Cette collecte d'informations est organise par types dactivit projet telles que : le recueil du besoin, la gestion de projet, le transfert de connaissances, les spcifications logicielles (dossier d'analyse), la conception et l'implmentation, le test logiciel, la qualit logicielle, le dploiement et la mise en production.

17

Rdaction d'un document de synthse sur l'existant Le document de synthse des interviews a pour but de mettre en vidence de faon objective et anonyme les diffrentes remontes d'informations effectues lors de l'tape prcdente. Il fournit : l e primtre technique, fonctionnel et organisationnel du projet ou service candidat l'agilit,  les rles et responsabilits de chaque personne interviewe au sein de l'organisation projet ou service, l'tat des lieux de chacune des activits prcdemment cites, les acclrateurs ventuels l'adoption de l'agilit, les freins ventuels, les incontournables manquants (pratiques indispensables et pourtant absentes). Ce document sert de base un nouveau workshop d'change destin lanalyse dtaille et approfondie de ces freins et incontournables manquants. A ce stade, d'autres workshops plus cibls sont raliss afin didentifier les pratiques les plus utiles, en sappuyant sur un catalogue de pratiques Agiles.

Adoption de nouvelles pratiques Les pratiques identifies prcdemment sont synthtises dans un document o :  les risques et incontournables manquants sont rappels avec les pratiques Agiles associes,  les conditions d'entre pour la mise en place de toutes les pratiques sont identifies, la description et le mode opratoire de chaque pratique sont dtaills, les ventuels artefacts produits par chaque pratique sont identifis,  les consquences et impacts sur l'organisation et les processus actuels sont dcrits, les attendus oprationnels de la pratique sont dcrits. Il est important de prsenter les pratiques pressenties lensemble des acteurs et de les dcrire. Mais il faut galement discuter des impacts possibles sur lorganisation afin quun sous-ensemble de pratiques puisse tre retenu par le client. Frdric TREMEAU, Chef de projet senior, VALTECH TECHNOLOGY

Domaines d dingnierie prioritaires

18

Pratiques agiles Gestion de configuration logicielle Test logiciel Estimations logiciel Qualit logicielle Industrialisation des processus

Liste des pratiques retenues

PR01 Weekly meeting process PR02 Project organisation PR03 Estimation process PR04 Specification process PR05 Specification review PR06 Acceptance process PR07 Quality process PR08 Change management process PR09 Software configuration management process PR10 Iteration review process PR11 3 Planning process PR12 Knowledge transfer process PR13 Retrospection process PR14 Test plan process PR15 Test process PR16 Training PR17 Design review process

Pratiques projet prioritaires

PR01 Weekly meeting process PR02 Project organisation PR03 Estimation process PR04 Specification process PR05 Specification review PR06 Acceptance process PR07 Quality process PR08 Change management process PR09 Software configuration management process PR10 Iteration review process PR11 Planning process PR12 Knowledge transfer process PR13 Retrospection process PR14 Test plan process PR15 Test process PR16 Training PR17 Design review process

Figure 1 Exemple de pratiques dingnierie et de pilotage de projet (Source : Valtech Technology).

Rdaction d'un document de synthse sur les pratiques retenues Valtech produit le document final de l'tude synthtisant les attendus du client, la dmarche de l'tude et les pratiques retenues. Un plan d'action et une proposition de planning finalisent le document qui est prsent l'ensemble des acteurs impliqus dans l'tude. A l'issue de la soutenance, Valtech propose au client, soit :  une prestation de production d'artefacts issus des pratiques Agiles retenues,  une mission d'accompagnement dans la mise en uvre des nouvelles pratiques Agiles sur le projet,  une formation lagilit.

Lessentiel retenir - Lobjectif de ltude dopportunit est d'identifier les pertes d'nergies et les ventuels effets d'inertie de l'organisation projet ou service ainsi que didentifier de nouvelles pratiques plus efficaces et plus Agiles. - Ltude dopportunit est base sur des interviews et des workshops qui permettent de dfinir la cartographie des pratiques en cours, pour ensuite identifier les freins ladoption de lagilit, les incontournables manquants et les pratiques Agiles les plus utiles. - Un plan daction et une proposition de planning finalisent ltude dopportunit.

19

3.2 TDR au cur des spcifications

Le Test-Driven Requirement, ou spcification dirige par les tests, propose :  de centrer la description et la rdaction des besoins utilisateurs sur des exemples qui constitueront autant de futurs cas de tests de recette,  de centrer la collaboration entre les quipes du projet sur la comprhension et lenrichissement de ces exemples.

Le contexte documentaire et collaboratif

Pour un des leaders de services en ressources humaines, Valtech a mis en place la pratique TDR pour un logiciel de gestion qui avait t cr en 1 an avec UML. La stratgie de dveloppement avait t axe sur l'efficacit court terme plutt que sur la maintenabilit. Les activits projet taient confies des quipes distinctes (dveloppement / homologation / analyse-gestion de projet / MOA).

Aprs 6 mois dexploitation, le client avait constat les remarques suivantes.

++

Les fonctions majeures du logiciel taient oprationnelles. sans les partager avec les autres quipes.

 Chaque quipe disposait de ses propres documents, relatifs son activit,  Les volutions apportes aprs la mise en production taient ralises sans
tre spcifies, engendrant un manque de visibilit sur le contenu fonctionnel rel du logiciel et rendant difficile lintgration de nouveaux besoin.

 Le primtre de test dduit des spcifications tait incohrent avec les fonctionnalits dj implmentes. tait de moins en moins souvent ralise du fait de la difficult produire les cas de tests conduisant une baisse de qualit. grande autonomie de chaque quipe se faisait au dtriment de la communication.

 Lhomologation  La

20

Cest dans un tel contexte que Valtech a mis en place la pratique TDR.

Les enjeux du client

Compte tenu du constat ralis pour parvenir matriser les volutions logicielles, il a t dcid de modifier les pratiques de spcifications. Valtech a amen le client privilgier la description concrte plutt que la modlisation en incluant des exemples tels que ceux prsents ci-aprs.

Exemple de spcification TDR

Contexte de lvolution Il sagit de modifier le cycle de vie d'une affaire afin de mettre jour son tat lorsqu'une convention est cre, sans tre valide. Jusqu prsent, cest seulement lorsque la convention est valide que ltat de laffaire est mis jour.
N.B. : une affaire est une opportunit commerciale dtecte pour un compte donn, mais n'aboutissant pas immdiatement la signature d'une convention avec ce compte. Lorsque l'opportunit commerciale se concrtise, laffaire est transforme en convention. La convention est dfinitive partir du moment o elle est valide. Cette volution met donc en vidence la fois le cycle de vie des affaires, celui des conventions et celui des comptes.

Les donnes initiales Les "Comptes" et "Affaires" suivants ont t crs : COMPTES Nom du Compte BONJOUR Matricule Entit tat du Responsable Responsable Compte 0001 E1 1 (prospect sur affaire) Identifiant du Compte COMPT 01

21

AFFAIRES Nom de l'Affaire Affaire A Matricule Identifiant Responsable du Compte 0002 COMPT 01 tat du Compte 1 (ouverte) Commentaire Null

Tableau 1 TDR - Donnes initiales (Source : Valtech Technology). Laffaire est cre dans ltat par dfaut Ouverte tandis que le compte est cr dans ltat Prospect sur affaire . Transformer une affaire en convention Laction consiste pour le responsable (matricule 0002 li laffaire A) transformer laffaire A en convention. AFFAIRES - RSULTAT Nom de l'Affaire Affaire A Matricule Entit tat du Responsable Responsable Compte 0002 E1 2 (ferme) Identifiant du Compte Transforme en convention

Tableau 2 TDR - Affaire versus Convention (Source : Valtech Technology).

Laffaire est ferme car transforme en convention. Elle ne peut plus tre utilise pour crer une convention. COMPTES - RSULTAT Nom du Compte BONJOUR Matricule Entit tat du Responsable Responsable Compte 0001 E1 1 (prospect sur affaire) Identifiant du Compte COMPT 01

CONVENTIONS - RSULTAT Nom de la Convention Convention issue de lAffaire A Matricule Etat du Responsable Contrat 0002 4 (brouillon) Nom de l'Affaire Affaire A

Tableau 2 TDR - Affaire versus Convention (Source : Valtech Technology).

22

La convention nest pas encore valide do sa cration dans ltat brouillon . Ltat du compte reste inchang. Valider une convention Laction consiste pour le responsable (matricule 0002) valider la convention.

COMPTES - RSULTAT Nom du Compte BONJOUR Matricule Entit tat du Responsable Responsable Compte 0001 E1 2 (client) Identifiant du Compte COMPT 01

CONVENTIONS - RSULTAT Nom de la Convention Convention issue de lAffaire A Matricule Etat du Responsable Contrat 0002 1 (en cours) Nom de l'Affaire Affaire A

Tableau 3 TDR - Validation de convention (Source : Valtech Technology).

La validation de la convention entrane donc : le changement dtat du compte qui passe de prospect sur affaire client , le passage de la convention de ltat brouillon en cours .

Une double nouveaut : collaboration et format des exigences

Dornavant, la description des fonctionnalits est affine de faon collaborative tout au long du processus de dveloppement : initiation par la MOA, enrichissement par les analystes,  mise jour au fil des remarques des quipes de dveloppement et dhomologation.

23

Cette description sappuie sur des cas d'exemples qui sont : l es cas de tests des scnarii standards par la MOA, l es cas de tests des scnarii dexception (sans viser lexhaustivit mais plutt la vraisemblance) par lhomologation. Les tableaux utiliss pas pas dans notre exemple, suite diffrentes actions oprateur, permettent de visualiser concrtement les changements dtat successifs. Ils facilitent la fois la comprhension du fonctionnel mais galement lidentification des scnarii de test les plus pertinents. Finalement, lensemble des quipes projet a adhr la nouvelle approche TDR. Cette adhsion a t favorise par le fait que les cas de tests dcrits sous forme de tableaux taient lisibles par des non-informaticiens.

Un retour d'exprience riche denseignements

Pour en faciliter l'appropriation par les quipes, la mthode TDR a t introduite progressivement sans la nommer, en incluant des exemples dans les spcifications existantes. La dmarche TDR est lorigine des avances suivantes. 1. L  'quipe de dveloppement a pris le rflexe d'enrichir les exemples fournis dans la spcification TDR. Ces exemples ont t utiliss en intgration continue et en homologation. 2. U  ne grande partie des ambiguts dans la description des rgles mtier est dsormais leve avant le dbut des dveloppements. 3. L  e besoin se stabilise de plus en plus tt dans le cycle de cration dune fonctionnalit. 4. L  es erreurs de description ou dimplmentation sont dtectes plus tt et sont donc plus faciles rsoudre. 5. L  homologation se droule dsormais normalement.

Prochaine tape possible

24

La formalisation des spcifications selon lapproche TDR permet de produire facilement des spcifications excutables. Coupl un outil tel que FIT, Fitnesse ou GreenPepper, chaque exemple devient ainsi un cas de test automatique. Hlne GRANBOULAN, Analyste senior, VALTECH TECHNOLOGY

Lessentiel retenir - Le Test-Driven Requirement (TDR) propose de : centrer la description et la rdaction des besoins utilisateurs sur des exemples,   centrer la collaboration entre les quipes du projet sur la comprhension et lenrichissement de ces exemples. - Dans une dmarche TDR, il faut privilgier la description concrte plutt que la modlisation. - La description des fonctionnalits est affine de faon collaborative tout au long du processus de dveloppement. - Les tableaux utiliss pas pas, suite diffrentes actions oprateur, permettent de visualiser concrtement les changements dtat successifs. Ils facilitent la fois la comprhension du fonctionnel mais galement lidentification des scnarii de tests les plus pertinents.

3.3 Retour dexprience sur la gestion de projet

Contexte
Dveloppement d'une application de gestion pour le suivi et la traabilit des processus de fabrication pour un industriel franais de l'aviation.

Mode de dveloppement Taille du projet Dure du projet Outils utiliss

Duoshore avec une quipe de 5 analystes "'Onsite" sur site client et 25 dveloppeurs 'offshores' dans notre centre de dveloppement de Bangalore (Inde). 9000 homme.jours 2 ans WSAD, Wiki Confluence, Jira Tableau 4 Contexte projet.

25

Enjeux client
Les enjeux pour cette nouvelle application sont : d  'offrir un outil souple, robuste et facilement dployable, d  e faciliter le travail des utilisateurs par une interface intuitive et simple d'utilisation, d  'apporter une solution permettant de mieux matriser la traabilit des procds de fabrication, d  'accrotre l'inter-oprabibilit du systme avec les autres applications de gestion.

... 2 quipes Scrum ... ... 1 Product Backlog ... ... 1 outil collaboratif de type wiki ... ... 22 itrations de 4 semaines ...

Pratiques mises en uvre

Les pratiques mises en uvre sont : u  tilisation de la mthode d'organisation et de suivi Scrum sur les parties France et Inde (2 quipes Scrum), m  ise en place d1 Product Backlog, u  tilisation d 1 outil collaboratif de type wiki pour communiquer entre les quipes de dveloppement distantes et le client, m  ise en place d'un mode de livraison Inde / France bas sur de l'intgration continue (cf. Dtail d'une journe). Les diffrents points de synchronisation France / Inde et MOA / MOE y sont identifis ci-aprs.

26

Figure 2 Planning dtaill dune itration (Source Valtech Technology).

Figure 3 Planning dtaill dune semaine (Source Valtech Technology).

Figure 4 Planning dtaill dun jour (Source Valtech Technology). Principe de rpartition des responsabilits de la matrise d'uvre : Onsite (France) :  relation avec le client,  recueil des besoins, formalisation de documents d'analyses, suivi de la validation de ces documents,  transfert de connaissance avec les quipes offshores,  support fonctionnel aux quipes offshores,  mise en place et contrle des directives d'architecture du projet,  contrle des flux de traduction Franais Anglais (documents d'analyse) et Anglais Franais (document de conception), dveloppement de fonctionnalits non dlocalisables, vrifications des scnarii de test, coordination projet (car porteur de la responsabilit vis vis du client). Offsite (Inde) :  formalisation des documents de conception,  travaux de dveloppement,  laboration des scnarii de tests,  automatisation des tests, excution des tests manuels/automatiques, excution des contrles qualit (PMD, RSA et FindBugs).

27

Difficults rencontres
Les difficults rencontres sont :  la contrainte d'entre sur le site et la planification longtemps l'avance ne permettent pas de faire intervenir des ressources offshores sur le site client,  l'obligation de planifier les runions et les workshops longtemps l'avance,  la clture de la documentation Word pour le client : en contradiction avec l'approche Wiki qui privilgie laccs en ligne pour tous,  la barrire de la langue (anglais) pour la matrise d'ouvrage,  le souhait du client de raccourcir la prise en compte des demandes de changement d'une itration l'autre,  le cycle initial de validation des livrables documentaires tait trop lourd et pas du tout adapt l'approche itrative,  les quipes Onsite et MOA ne communiquent que par mails.

Solutions apportes
Les solutions apportes sont :  face l'impossibilit de traiter les volutions : mise en place d'un volant de jours pour traiter les volutions : systme d'enveloppe,  pour rduire le nombre d'anomalies : mise en place d'un circuit d'intgration continue entre les dveloppements raliss en Inde et la plate forme d'intgration sur le site du client,  l'acclration de la prise en compte des demandes client : identification d'une provision de charges pour traiter les demandes de changement en cours d'itration (jusqu' la mi-itration),  la rduction du backlog d'anomalies : constitution d'une provision de charges pour laisser le temps l'quipe en Inde de corriger ses anomalies (interne / client) tout en produisant du fonctionnel,  le rapprochement physique des quipes Onsite avec la matrise d'ouvrage.

28

Bnfices obtenus
Les bnfices obtenus sont :  le volant de jours : fin des tensions concernant la qualification des anomalies / volutions,  la confiance accrue du client en la qualit des dveloppements,  la visibilit totale sur le contenu du produit et des itrations qui permet de planifier l'avance les avenants contractuels pour traiter les nouvelles fonctionnalits majeures,  le respect des engagements vis--vis des autres quipes impliques dans le processus d'ingnierie (autres quipes de dveloppement, intgration, qualification, tests de performances, ...),

r  duction du nombre d'anomalies grce une meilleure comprhension du fonctionnel par les quipes indiennes et la dcouverte au plus tt des anomalies (intgration continue),  nouvelles prises de commandes.

L'essentiel retenir Les pratiques Agiles peuvent tre appliques dans un environnement non Agile mme si celui-ci a de fortes contraintes. Il faut adapter ces mthodes au contexte du client en les adoptant de manire graduelle : une ducation pralable montrant les bnfices attendus et une mise en vidence rgulire des gains obtenus sont impratives. Les pratiques Agiles choisies et mises en place avec justesse permettent de prserver un des facteurs cls du succs du projet : la bonne collaboration entre les quipes du fournisseur et du client. N'oublions pas que cette collaboration entre quipes est au centre de la mthode Agile Scrum.

3.4 Pratique de recueil de besoin - le Product Backlog

Le manque de visibilit sur le contenu final probable d'un logiciel est souvent prjudiciable au client mais galement aux quipes projet. En effet, cette description permet entre autres :  d'avoir une vision commune sur l'ensemble des fonctions ou cas dutilisation dfinissant le scope du logiciel dvelopper,  de comprendre l'intrt et les enjeux des dveloppements pour les utilisateurs (appels galement acteurs),  d'estimer l'avancement du projet sur la base des fonctions ou cas dutilisation livrs au client,  de raliser facilement des macro-estimations en utilisant par exemple la mthode des use case points,  de prparer l'identification des tches projet en les organisant autour des fonctions ou des cas dutilisation. Selon Valtech, une bonne manire de rpondre ce besoin de visibilit, est d'utiliser un artfact fondamental la mthode Agile Scrum qui s'appelle le Product Backlog. Nous l'avons appliqu une fois de plus avec succs chez un de nos clients dans le domaine de l'assurance, pour formaliser de faon synthtique l'ensemble des fonctions attendues par les courtiers, et pour estimer la charge de ralisation de l'application. La figure suivante prsente un extrait du tableau obtenu aprs deux jours de workshop fonctionnel avec la matrise douvrage et la matrise d'uvre, ainsi que deux courtiers en assurance, futurs utilisateurs de l'application.

29

CAPABILITIES Capa. Functional capabilities 18

1 1 1 1 2 2 2 C2 Date import (Lot 2) 2 2 2 2 F1-1 F1-2 F1-3 F1-4 F2-1 F2-2 F2-3 F2-4 F2-5 F2-6 F2-7

FEATURES Lot Feat. Features Actors

Quotation creation from scratch Quotation creation from an existing version of quotation (same year) Quotation creation from an existing version of quotation (previous year) Quotation creation from a Petrus Program Select fields to import from loss files Import Loss with developments - vertical Import Loss with developments - horizontal Import Loss files without developments vertical Import the LDFs Import the indexes from the index database European Import the indexes from the index database US

User User User User User User User User User User User

C1

Quotation management (Lot 1)

30

Figure 5 Exemple de Product Backlog (Source : Valtech Technology).

On distingue donc les capacits de la future application avec pour chacune, une liste de fonctions appeles galement stories. Chaque fonction est identifie de faon unique pour pouvoir ensuite tre facilement rfrence. De plus, chaque fonction se voit attribuer un type d'utilisateur. A la fin de cet exercice, les capacits sont attribues des lots (appels galement releases). Une fois ce premier travail ralis, une priorit de dveloppement a t estime et affecte chaque fonction. Elle est calcule partir des estimations de complexit et de valeur mtier (classes en High, Medium and Low). Cette dmarche permet de limiter les risques en traitant en priorit les fonctions les plus complexes, et en majorant le ROI en livrant d'abord les fonctions apportant le plus de valeur aux utilisateurs. L'extrait du tableau suivant donne une ide du rsultat.

FEATURES Feat. Features 158

F1-1 F1-2 F1-3 F1-4 F2-1 F2-2 F2-3 F2-4 Quotation creation from scratch Quotation creation from an existing version of quotation (same year) Quotation creation from an existing version of quotation (previous year) Quotation creation from a Petrus Program Select fields to import from loss files Import Loss with developments - vertical Import Loss with developments - horizontal Import Loss files without developments vertical User User User User User User H User User M M

PRIORITY Actors Complexity Business Value 158 Priority UCP

Medium

10

Medium

10

Medium

15

Figure 6 Gestion des priorits et de la complexit dans le Product Backlog (Source : Valtech Technology).

31

Un nombre de UCP (use-case point) a t attribu aux cas dutilisation en fonction de leur complexit, en utilisant la mthode des use-case points, ceci afin de servir de base une estimation globale du projet.

Finalement, nous avons t capables en moins de 5 jours, de dcrire les besoins client sous la forme d'un product backlog, d'identifier l'ensemble des acteurs au sens UML, de dfinir les priorits d'implmentation, d'estimer la complexit des cas dutilisation et de chiffrer le projet dont la taille reprsentait 3.000 homme.jours. Frdric TREMEAU, Chef de projet senior, VALTECH TECHNOLOGY

L'essentiel retenir Le manque de visibilit sur le contenu final probable d'un logiciel est souvent prjudiciable au client mais galement aux quipes projet. Lutilisation product backlog peut se rvler trs efficace condition d'en matriser les concepts et de disposer des personnes comptentes et habilites prendre les dcisions impactant le futur projet.

3.5 Pratique de gestion de projet - lIteration Backlog

L'Iteration Backlog a pour vocation de grer court terme l'ensemble des tches identifies, estimes et affectes l'quipe projet sur chaque itration, afin de visualiser jour aprs jour l'avancement des travaux et d'atteindre les objectifs fixs pour l'itration. Les tches en constituent donc la matire premire. Sur les projets Valtech, les tches sont associes des fonctions ou des scnarii de cas dutilisation.

En dbut d'itration : La granularit des tches doit tre entre 4 et 6 heures

L  es tches sont identifies pour prendre en compte de nouvelles priorits de livraison et pour minimiser le nombre d'itrations ncessaires la livraison d'une fonction ou d'un cas dutilisation. La granularit des tches doit tre entre 4 et 16 heures.  Chaque tche se voit affecter les informations suivantes : -U  n Identifiant unique (pour la traabilit avec les fonctions ou cas dutilisation), -U  n Nom explicite non gnrique mais spcifique au contexte et au sujet trait, -U  n Responsable en charge de l'excuter, -U  ne Priorit (basse, moyenne ou haute) qui permet au responsable de dmarrer par les tches les plus prioritaires, -D  es Date de dbut et Date de fin estimes permettant de lisser dans le temps la charge estime pour la tche et de dduire la cohrence de l'affectation des tches l'quipe en termes de capacit de production, - Un Effort estim en heures par le responsable de la tche lui-mme, valid par l'quipe lors du planning d'itration (exercice collgial de planification ditration), -U  n Poids estim reprsentant une unit de taille logiciel, utilis pour la mesure de la vlocit de l'quipe (taille du logiciel qu'il est possible de livrer par unit de charge (h.j.)). Ce poids est estim en utilisant la suite de Fibonacci (1, 2, 3, 5, 8, 13). Nous nous limitons l'intervalle 1-13 car par exprience, une valeur suprieure est souvent synonyme d'incertitude.

32

Chaque jour :
C  haque membre de l'quipe projet renseigne son consomm et son reste faire pour les tches dont il a la charge. Une alternative consiste nommer chaque semaine et tour de rle, un time tracker qui relve ces mtriques pour lensemble de lquipe.  Un graphe Burndown chart est mis automatiquement jour, imprim et affich dans l'espace de travail de l'quipe accessible galement distance via un wiki (y compris par le client). Il prsente l'effort restant accomplir en heures, pour finir les tches alloues l'itration, les tches termines et la courbe idale de reste faire.

Ce graphe prend la forme suivante : Iteration #4 progress

350 300
Remaining working hours

100

80
Completed tasks %

250 200 150 100 50 0 20 60

40

6/8 7/8

8/8

9/8 10/8 13/8 14/8 15/8 16/8 17/8 20/8 21/8 22/8 23/8 24/8
IT04 Burndown Completed tasks %

IT04 Burndown

IT04 Burndown Target

Figure 7 Exemple de burndown chart dun Iteration Backlog (Source Valtech Technology). En fin d'itration, les mtriques suivantes sont releves et communiques l'quipe ainsi qu'au client :  le Schedule overrun reprsentant le % de retard de livraison de l'itration. Il vaut normalement 0% si le time boxing est respect,  l'Effort overrun reprsentant le dpassement d'effort ralis dans l'itration. Il vaut 0% si l'quipe n'a pas chang et que l'itration a dur le temps initialement prvu,  la Taille moyenne de l'quipe calcule par le consomm sur le nombre de jours travaills,  l'Avancement en % deffort, calcul par la formule universelle : Consomm/ (Consomm + Reste Faire),  le % du primtre de litration ralis. Il est calcul par le rapport entre la taille du logiciel qui devait tre livr (poids Fibonacci) et la taille livre rellement, l a Vlocit de l'itration, c'est dire le rapport entre la taille du logiciel livr et la charge consomme associe. Elle mesure la capacit de lquipe livrer un certain nombre de fonctions. Plus elle est leve et moins le projet durera longtemps. Le Burndown chart est un outil trs puissant pour matriser l'avancement des travaux raliss par une quipe sur une priode courte dont les objectifs ont t exprims en tches raliser. Frdric TREMEAU, Chef de projet senior, VALTECH TECHNOLOGY

33

L'essentiel retenir L'Iteration Backlog a pour vocation de grer court terme l'ensemble des tches identifies, estimes et affectes l'quipe projet sur chaque itration. La mise en place de mesure pertinentes permet, jour aprs jour, de suivre l'avancement rel et de prendre les mesures correctrices, correctives et prventives appropries. Attention toute fois ne pas tomber dans l'excs de tracking avec des micro-tches infrieures 4 heures grer.

3.6 Retour dexprience sur lautomatisation des tests Contexte

L'agilit impose de nombreuses livraisons intermdiaires. Chacune de ces livraisons doit tre intgralement teste ; dans le cas contraire, la perte de contrle sur la qualit crot de manire exponentielle chaque itration. Un dpartement de la DSI d'une grande banque de finance souhaite mettre en place l'agilit au sein de ses quipes de dveloppement. Le dpartement a la responsabilit du dveloppement et de la maintenance d'un ensemble d'applications avec des technologies htrognes. Toutes les applications sont mises jour en mme temps en production une frquence trimestrielle. Chaque dploiement en production est prcd d'une campagne de tests utilisateurs de 2 3 semaines visant s'assurer de labsence de rgression dans l'ensemble des applications.

Enjeux client

34

La dure des campagnes de tests de non-rgression risque de masquer l'effet positif du dploiement des mthodes Agiles. Il est donc impratif de raccourcir la dure des campagnes et d'en acclrer la frquence.

Pratiques mise en uvre

Les pratiques mises en uvre sont :  automatisation des tests utilisateurs de non-rgression, c'est--dire des tests fonctionnels sollicitant l'interface graphique,

chec de tests unitaires en moins 5 min, chec de tests fonctionnels en moins d'une heure.
m  ise en place de tests continus dans le processus d'intgration continue sur tous les niveaux de tests, depuis les tests unitaires jusquaux tests utilisateurs. Les niveaux de tests sont dclenchs diffrentes tapes du cycle de vie du build afin de conserver un feedback optimal pour les quipes de dveloppement : chec d'intgration dtect en moins de 2 min, chec de tests unitaires en moins de 5 min, chec de tests fonctionnels en moins d'une heure.

Difficults rencontres
L  es tests utilisateurs de non-rgression, ceux qui sollicitent l'interface graphique, sont gnralement coteux automatiser et maintenir. La moindre modification d'une interface peut conduire l'chec d'un script automatis mme si les services sous-jacents n'ont pas t modifis :  les quipes de dveloppement n'ont pas toujours conscience de cette contrainte et introduisent des modifications sur l'interface sans reporter cette modification dans les scripts de tests automatiss,  les tests sont automatiss trop tt sur des pans fonctionnels non stables, ce qui en gnral entrane des cots prohibitifs de maintenance des scripts de test,  l'interface graphique utilise des composants qui se prtent difficilement l'automatisation des tests. Ceci est d'autant plus vrai que certains composants proviennent d'diteurs qui ne fournissent pas le procd de test de leurs composants,  le rfrentiel de donnes de l'environnement de tests est difficile contrler, les donnes proviennent de copies de la base de production. Les donnes de tests peuvent donc tre perdues ou altres et impacter le bon fonctionnement des tests de non-rgression.

Solution apporte
Valtech sest focalis sur :  ltude de compatibilit technique entre l'interface graphique et l'outil d'automatisation afin d'identifier les composants graphiques problmatiques et damener les dveloppeurs concevoir des interfaces testables,  ltude de ROI destine vrifier lintrt conomique de lautomatisation (plus un test est excut, plus lautomatisation est rentable court terme),  la dfinition de la stratgie d'automatisation visant : - choisir  quels tests automatiser pour maximiser la valeur des tests de non-rgression par rapport l'effort investi, -d  finir la faon de grer le rfrentiel de donnes.

35

Lautomatisation des tests dans un contexte itratif et incrmental nest pas une option, quel quen soit le prix. Cest une obligation . Gilles MANTEL, Directeur de projet, VALTECH TECHNOLOGY

NB : le fait ditrer implique de rejouer systmatiquement certains tests de non rgression. Cela rend conomiquement intressante lautomatisation de ces tests, condition toutefois que leffort dautomatisation li la technologie utilise ne soit pas rdhibitoire, do la ncessit de sen assurer.

Bnfices obtenus Avec l'automatisation, la dure d'un cycle de test utilisateur est de 2 heures.
Les campagnes de tests utilisateurs sont progressivement passes d'une frquence trimestrielle une frquence quotidienne. La dure d'un cycle de tests utilisateurs a t rduite de 1 semaine 2 heures. La notion de "campagnes de tests" perd progressivement de son sens pour laisser place la notion de "tests en continu".

36

L'essentiel retenir Les tests manuels peuvent tre compars une force de frottement : plus la vitesse et la pression s'accentuent sur un corps en mouvement, plus importants les frottements sont, rduisant lefficacit des efforts concds pour acclrer le mouvement.

3.7 TDD au cur des dveloppements Contexte

Le contexte sannonce a priori dfavorable, voire hostile l'agilit : la mthodologie interne prne le cycle en V, totalement ancre dans la culture industrielle de lentreprise.

Ce projet industriel de 3 homme.ans dont il s'agit concerne le dveloppement dune application java "stand alone" avec une interface Swing et diverses autres parties crites en C++.

Enjeux client
Lobjectif du client consiste amliorer la qualit et la scurit des applications sans augmenter les cots de dveloppement.

Pratiques mise en uvre

Valtech a aid le client mettre en place :  une approche de dveloppement dirige par les tests (TDD),  une dmarche dautomatisation des tests de recette.

Difficults rencontres
Le projet de dveloppement a suivi le cycle classique en V. Valtech est intervenu partir de la phase de dveloppement (le bas du cycle en V) et a ainsi hrit dun document de spcification, fruit de plus d'un an de travail. Il a, ds lors, t impossible de faire raliser les tests par le client. Certaines parties de l'application tant dveloppes en Java et d'autres en C++, deux environnements de dveloppement diffrents et deux outils de tests unitaires ont t utiliss - Eclipse et Visual Studio dune part, JUnit et CPPUnit dautre part. Cela a induit un double effort de mise en place des frameworks de tests unitaires. La couverture des tests unitaires sur la partie C++ sest avre difficile calculer.

37

Solutions apportes
Test Driven Development Les parties en C++ tant des librairies utilises par le code java et JUnit plus faciles utiliser, le code C++ a majoritairement t test depuis lenvironnement Java avec JUnit. Malgr tout, certains tests ont d rester dans la partie C++, de manire garder un feedback court. Tests de recette automatiss L'quipe de dveloppement a crit les tests de recette, au moyen dune librairie externe uispec4j, permettant, de "scripter" des scnarii d'utilisation de l'interface graphique Swing. Par ailleurs, un simulateur sous MS Windows a permis de simuler les interactions de l'application avec un quipement propritaire. Loutil AutoIt a t utilis pour piloter ce simulateur depuis la suite de tests en java.

Bnfices obtenus

Le projet a t livr le jour prvu, sans augmentation des cots. Lquipe de dveloppement sest montre trs flexible vis vis des diverses modifications de spcification, le tout sans perte de qualit ni apparition de rgression. Etienne CHARIGNON, Consultant senior, Scrum master certified, VALTECH TECHNOLOGY

L'essentiel retenir La mise en uvre des pratiques Agiles de TDD permet : de rester matre de la complexit des dveloppements raliss, de livrer dans les temps et le budget impartis.

38

4. Lagilit faon Lean

Lean et Agilit ne sont pas antinomiques dans le monde du dveloppement logiciel, bien au contraire ! En effet, s'engager dans une dmarche damlioration continue Lean permet aux matrises d'ouvrage (MOA) et aux directions informatiques de concrtiser les bnfices des mthodes Agiles en conciliant de faon optimale leurs impratifs de qualit et de ractivit. Elisabeth DUCARRE, Expert LEAN et CMMI, VALTECH TECHNOLOGY

Lean est connu dans le monde automobile par l'exprience Toyota, devenu le premier constructeur automobile, reconnu la fois pour la qualit et l'innovation de ses produits. Tout le monde s'accorde reconnatre que ce succs est du son systme de production Lean. Cette approche vise la fois : amliorer la qualit et les dlais,  rduire les cots en tirant le meilleur parti des ressources tant humaines que matrielles, viter toute forme de gaspillage. Le Lean est bas sur les principes fondamentaux suivants : dterminer ce qui cre de la valeur pour le client, identifier le flux de valeur, le rendre continu, rechercher la perfection. Ces principes ont t, eux-mmes, dclins dans Lean Software Development ([Rf.2]) par les principes suivants : liminer les gaspillages, favoriser la connaissance, construire la qualit intrinsque, reporter la dcision, livrer rapidement, respecter les personnes, optimiser le systme dans son ensemble. Pour rpondre ces principes, il est facile de constater que les mthodes Agiles et les pratiques associes sont trs appropries.

39

Lean Software Development considre toutes les mthodes Agiles comme valides pour appliquer le Lean Thinking au monde du logiciel, et en particulier le dploiement de la mthode Scrum. Jeff SUTHERLAND, Coinventeur avec Ken Schwaber de la mthode Scrum.

 Favoriser la connaissance , Reporter la dcision , Livrer rapidement peuvent se traduire par la segmentation en itrations courtes des projets Agiles, ce qui apporte aux entreprises clientes la prdictibilit dont elles ont besoin sur la disponibilit des fonctionnalits en cours de dveloppement. Elles peuvent ainsi planifier l'intgration continue des nouvelles fonctions leur rythme et en fonction des ressources disponibles, sans surcot ni surcharge de travail qui induisent de nombreuses sources d'erreur (Concept Lean Just in time ). Un exemple concret de la mise en uvre du principe Construire la qualit intrinsque (dcoulant du principe Rechercher la perfection ) peut se traduire par la technique TDD associe l'automatisation des tests, qui constitue une approche efficace d'amlioration de la qualit au plus tt dans le cycle de dveloppement. Cela permet de savoir immdiatement si ce qui est produit possde le bon niveau de qualit et de corriger les dfauts au plus tt. Nous rpondons galement au concept Lean Stop the line , en corrigeant les anomalies ds qu'elles sont dtectes, ce qui vite de gaspiller des ressources en poursuivant le dveloppement de l'application sur des bases non fiables 100%. En effet, la priorit de correction des anomalies doit tre suprieure celle dajouter de nouvelles fonctions au logiciel.

40

Enfin un important concept Lean est le Visual Management , axe largement soutenu dans les mthodes Agiles par une organisation de l'espace de travail, qui permet toutes les parties impliques (dveloppeurs, testeurs, chefs de projets, reprsentants du mtier) de visualiser instantanment l'tat d'avancement du projet, et ceci en termes simples. Grce aux mthodes Agiles, les dveloppeurs sont en mesure de gnrer quotidiennement une version compile de l'application en cours de dveloppement, afin de dtecter au plus tt les anomalies potentielles. Le rsultat de la compilation est visible (par exemple par l'allumage d'une lampe, un avertisseur sonore ou un cran color bien situ en fonction du rsultat) et permet de ragir au plus vite. L'ensemble des informations de suivi de projet sont affiches grce des codes couleurs, sur un ou plusieurs tableaux la vue de tous (nombre de fonctions testes et valides, nombres d'anomalies en cours de rsolution, etc...). L'ensemble des pratiques cites ci-dessus rpondent galement au premier principe Eliminer les gaspillages : rduire les retards (itrations courtes), se concentrer sur les dfauts (TDD), mieux comprendre les exigences (TDR), etc... Enfin, un des principes des mthodes Agiles est de se focaliser sur le produit plutt que sur la documentation.

En conclusion, ce petit aperu montre que les pratiques Agiles sont un support efficace au dploiement d'une dmarche Lean. Lean met le produit au coeur de son concept, ce qui permet une fois de plus, de faire converger ces deux approches.

L'essentiel retenir - Le Lean est bas sur les principes fondamentaux suivants : dterminer ce qui cre de la valeur pour le client, identifier le flux de valeur, le rendre continu, rechercher la perfection. - Grce aux mthodes Agiles, les dveloppeurs sont en mesure de gnrer quotidiennement une version compile de l'application en cours de dveloppement, afin de dtecter au plus tt les anomalies potentielles. - Les pratiques Agiles sont un support efficace au dploiement d'une dmarche Lean.

41

5. Lagilit face aux standards Qualit

5.1 Qualit du produit ou des processus : Agilit ou ISO ?

Les mthodes Agiles se dcrivent souvent par une approche peu formelle o le focus est mis sur la collaboration entre les personnes et sur le produit raliser. A contrario, les mthodes ISO sont souvent qualifies de procdurires voire de contraignantes vis vis des rgles applicables, et plus orientes processus que produit. Ceci semble les opposer, pourtant ... Le management par la qualit vise dfinir des objectifs qualit au niveau de lentreprise qui se dclinent ensuite par nature d'activit. Il s'agit de planifier et de dfinir les mthodes ncessaires la matrise des prestations et des produits, et de mesurer le niveau d'efficacit atteint. On traduit souvent cette approche par le concept de PDCA (Plan, Do, Check, Act).

42

Prvoir les actions devant tre ralises

Faire le travail tel que prvu et enregistrer les rsultats (preuves)

Agir en exploitant les comptes rendus de revue, les rapports daudit plan damliorations

Vrifier le travail ralis (revue, audit)

Figure 8 Cycle de Deming PDCA (Plan, Do, Check, Act) (Source : Valtech Technology).

Ce mode de management est assez proche de la logique d'itration en Agile avec notamment sa planification des itrations, ses bilans ditration pour en mesurer les rsultats et ses rtrospectives pour dcider des amliorations raliser dans les itrations futures. Agilit et ISO se rejoignent donc sur des valeurs communes de planification oprationnelle et d'amlioration continue. Ensuite, la dimension majeure de l'ISO 9001 est son approche processus qui vise matriser l'ensemble des activits d'un organisme en cohrence avec la politique qualit de sa Direction et les exigences mtier et rglementaires pour satisfaire

au mieux les clients. Les mthodes Agiles apportent cette mme dimension de matrise projet et produits avec galement une forte implication des clients. Agilit et ISO se retrouvent donc nouveau sur ces valeurs. Agilit et ISO ne sont pas opposables car elle ne se contraignent pas et concourent mme rendre les pratiques projet plus efficaces au bnfice des produits livrs et de la satisfaction client. Hubert GILLON, Delivery Manager, VALTECH TECHNOLOGY

5.2 Mettre de lagilit dans une dmarche CMMI Qui a dit inconciliable ?
On a souvent tendance opposer Agilit et CMMI en prtendant qu'tre Agile signifie faire l'impasse sur tout processus prdfini qui constituerait un carcan nuisible la crativit et la productivit. Les dtracteurs des modles qualit tel que CMMI ont coutume d'affirmer que mettre en place des pratiques Agiles c'est Assurer la qualit du produit, alors que se conformer un modle tel que le CMMI n'a pour effet que de Rassurer ceux qui l'appliquent. C'est oublier un peu vite que le fondement du modle CMMI est d'inciter une organisation s'amliorer de faon continue en structurant cet effort autour d'un ensemble de processus et avec une approche progressive par niveau de maturit. Le cycle d'amlioration continue IDEAL (et plus gnralement toute dmarche de type PDCA) sous-jacent au modle CMMI se conforme donc bien au paradigme d'itration prn par les mthodes Agiles. Par ailleurs, CMMI impose des objectifs ( generic goals et specific goals ) visant garantir que la qualit des produits raliss ne dpende pas de l'hrosme des quipes mais de l'efficacit de ses processus. Pour atteindre ces objectifs, CMMI propose un certain nombre de pratiques qui sont des recommandations sur le quoi faire , et non sur le comment faire . Il y a donc toute libert mettre en uvre des pratiques Agiles pour atteindre ces objectifs.

43

Des pratiques CMMI Agiles ?

Divers travaux ont cherch apparier pratiques du CMMI et pratiques Agiles sans montrer d'incompatibilit notoire. Parmi les points d'achoppement potentiels, on trouve par exemple la traabilit bidirectionnelle . Une ide reue est que, pour tre conforme au CMMI, il soit ncessaire dassurer une traabilit totale entre les exigences, le produit final et tous les produits intermdiaires du travail. Pour cela, des outils industriels tels que Doors et Reqtify, savrent indispensables.

Nanmoins, il est tout fait possible dtre conforme au CMMI en assurant cette traabilit uniquement entre les exigences et le produit final grce Aux outils de gestion de configuration, ds lors quils : - intgrent une gestion des demandes de changement : native (IBM Rational UCM avec ClearCase et ClearQuest ou la nouvelle offre Team Concert), ou via une interface (Subversion + Trac par exemple), - offrent un pont direct avec la gestion des exigences (Serena Dimensions CM+RM).  A l'emploi de techniques et d'outils de Test Driven Requirements (une fixture dans Fitnesse ou Greenpepper).

Qu'est-ce qu'un Rfrentiel Qualit Agile ?

Tout d'abord, rappelons que l' Assurance Qualit au sens du CMMI couvre la fois les processus et le produit. Concentrons-nous ici sur le volet processus . L' Assurance Qualit consiste s'assurer que l'organisation se conforme systmatiquement aux dispositions du Rfrentiel Qualit , autrement dit au cadre mthodologique et aux procdures affrentes.

44

Les mthodes Agiles introduisent un certain nombre de pratiques dont le succs passe par une application rigoureuse, comme par exemple les diffrentes crmonies Scrum : planning de litration, runions dquipe quotidiennes, revue ditration, rtrospective. Le contrle qualit incombe au Scrum Master qui reste nanmoins avant tout un facilitateur dans la mise en place et ladoption des diffrentes pratiques Agiles. Sa sensibilit processus se double donc gnralement de comptences techniques pour aider la mise en place des outils, support de ces pratiques (Test Driven Requirements, Intgration Continue...).

Le rfrentiel qualit dun projet Agile peut tenir dans un simple classeur et non, remplir quelques armoires de dossiers poussireux et jaunis mais en parfait tat parce que personne n'ose jamais y toucher. Stphane LABATI, Expert CMMI, VALTECH TECHNOLOGY

Le rfrentiel qualit.  Il identifie les diverses mthodes et pratiques appliques sans pour autant les re-dtailler. Il suffit pour cela de se rfrer l'abondante bibliographie qui existe sur le sujet. Chaque projet Scrum pourra simplement indiquer la dure de ses itrations puis utiliser les outils communs de gestion de backlog et de suivi des risques.  Il contient divers modles de documents Organisation Agile ne signifie pas zro documentation mais en nombre rduit. Le principe est de ne produire que la documentation utile - qui apporte de la valeur - et au bon

 Organisation Agile ne signifie pas zro documentation

moment. Rdiger un volumineux dossier de conception n'offre aucun intrt si l'on se conforme dj des standards d'architecture et de codage. L'utilisation de frameworks peut aider imposer l'architecture et la rendre transparente. Il est par ailleurs relativement facile d'automatiser la vrification de telles rgles avec des outils d'analyse statique. Par contre, il est important de garder trace des rflexions qui ont amen ces choix d'architecture et de frameworks, afin de transfrer la connaissance du projet et viter ainsi de se reposer plus tard les mmes questions. Un vrai rfrentiel qualit Agile :  dcrit un ensemble de pratiques et de procdures,  contient uniquement les procdures qui ncessitent dtre dtailles afin dtre rellement exploitables,  voit sa bonne application contrle en permanence par les Scrum Masters.

Qui occupe la tour d'ivoire du SEPG ?

Un autre des principes Agiles, prn en particulier par Scrum, consiste responsabiliser totalement l'quipe en lui confrant le pouvoir d'autoorganisation et d'auto-dtermination. Par exemple, ce n'est plus un chef de projet qui affecte les tches aux membres de l'quipe, mais ceux-ci qui se les approprient, en fonction de leurs comptences techniques ou fonctionnelles. De mme, on attend de chacun, lors des rtrospectives, qu'il identifie les points d'amlioration possibles sur les processus en vigueur et fournisse, si possible, les solutions associes. D'aucun considre qu'en appliquant le CMMI, on se repose sur quelques minents qualiticiens pour promulguer les bonnes pratiques respecter. Or ce cnacle, le Software Engineering Process Group (SEPG), n'est rien d'autre que le rassemblement temporaire de quelques membres des quipes projets, lgitims par leur exprience, sous rserve videmment qu'ils aient collect au pralable les remarques de tous les membres de leurs quipes. Il s'agit donc l encore d'une certaine forme d'auto-dtermination.

45

Toute lquipe projet participe lamlioration des pratiques et constitue, ce titre, le SEPG dune organisation Agile. Stphane LABATI, Expert CMMI, VALTECH TECHNOLOGY

Quapporte le CMMI au-del des pratiques Agiles ?

A travers les rtrospectives, la mthode Scrum cherche amliorer de faon continue ses pratiques, mais en se focalisant uniquement sur le primtre du projet, mme si certaines amliorations touchent lorganisation autour du projet. Une dmarche CMMI vise faire bnficier de ces amliorations l'ensemble de l'organisation et pas seulement le projet qui les a suscites. De plus, gnraliser les amliorations l'organisation entire apportera globalement plus de valeur que doptimiser localement un projet. Finalement, mettre en place des pratiques Agiles dans le cadre dune dmarche CMMI sert les objectifs damlioration continue du Lean Thinking, tout en prservant lorganisation des gaspillages lis une sur-formalisation des processus.

46

Lessentiel retenir - Agilit et ISO se rejoignent sur des valeurs communes de planification oprationnelle et d'amlioration continue. - CMMI impose des objectifs visant garantir que la qualit des produits raliss ne dpend pas de l'hrosme des quipes mais de l'efficacit de ses processus. Pour atteindre ces objectifs, CMMI propose un certain nombre de pratiques qui sont des recommandations sur le quoi faire , et non sur le comment faire . - L' Assurance Qualit consiste s'assurer que l'organisation se conforme systmatiquement aux dispositions du Rfrentiel Qualit , tandis que le Contrle qualit incombe au Scrum Master qui reste avant tout un facilitateur dans la mise en place et ladoption des diffrentes pratiques Agiles. - Un vrai rfrentiel qualit Agile : dcrit un ensemble de pratiques et de procdures, contient uniquement les procdures qui ncessitent dtre dtailles, voit sa bonne application contrle en permanence par les Scrum Masters.

6.  La contractualisation Agile, une affaire de bon sens

Inspirs des mthodes Agiles, nos contrats Agiles visent construire un climat de confiance durable entre le client et le fournisseur, sur la base de trois engagements pris en commun :  celui de collaborer pour atteindre l'objectif commun de livraison du logiciel attendu,  celui d'tre transparent sur les capacits, les performances et les difficults rencontres,  celui de s'adapter aux changements mtier du client, induits par un march de plus en plus volutif. L o le contrat au forfait fixe les objectifs et les modalits d'application, le contrat Agile dfinit les objectifs et les modalits de collaboration. Nathalie LOPEZ, Directeur gnral adjoint, VALTECH TECHNOLOGY

6.1 A quoi sert un contrat ?

47
Le contrat est un outil indispensable pour la conduite des projets informatiques. Entre un client et un fournisseur, il sert :  partager les risques,  se protger des tentatives de l'un pour exploiter l'autre,  dfinir l'objectif vis, les exigences fonctionnelles, technologiques et de pilotage. Dans de nombreux cas, cet outil est aussi double tranchant, notamment lorsqu'il s'agit d'un contrat complet ou rigide qui cherche anticiper de manire dfinitive, sans qu'on ait besoin d'y revenir, tous les scnarii possibles du projet et les rponses appropries.

Typique des contrats de projets informatiques au forfait, cette approche se rsume essayer de fixer par avance les dlais, les cots, le primtre fonctionnel et le niveau de qualit du projet. Tout changement de l'une de ces donnes impose une rengociation contractuelle qui dtourne les intervenants de l'objectif oprationnel et induit alors des tensions entre le client et le prestataire. Le projet au forfait constitue donc un frein au changement et ne permet pas au client de s'adapter facilement aux besoins du march, ce qui est pourtant vital pour lui. Plus important encore, le contrat au forfait retire la fois au client et au fournisseur toute possibilit relle de pilotage, c'est dire d'ajustement en fonction de la ralit rencontre sur le terrain. De faon assez paradoxale, c'est le contrat qui est aux commandes, et qui condamne aussi bien le client que le fournisseur une relation insatisfaisante, voire l'chec.

6.2 Une ncessaire rvolution des mentalits

48

La contractualisation Agile prend le contre-pied de cette approche : au lieu de chercher tout prvoir ds le dpart, le contrat Agile vise tablir et maintenir un dialogue constant au service du projet et tout au long de la vie de celui-ci. Nathalie LOPEZ, Directeur gnral adjoint, VALTECH TECHNOLOGY

L o le contrat au forfait strict se rvle tre un obstacle, le contrat Agile sait n'tre qu'un moyen d'atteindre l'objectif principal d'un projet, livrer aux utilisateurs finaux l'application qu'ils attendent. La mise en uvre d'un contrat Agile passe ainsi par une rvolution des mentalits, aussi bien ct client que ct fournisseur. L'un et l'autre ont apprendre travailler ensemble, crer et maintenir un climat de confiance par un dialogue transparent et constant.

6.3 Rgles de collaboration client-fournisseur

Un contrat Agile doit dj tre le rsultat d'une relle collaboration, qui se traduit par la formalisation :  des pratiques de collaboration entre le client et son fournisseur,  des moyens de restitution des lments de pilotage de son projet informatique,  des possibilits de rajustement de ses objectifs en fonction des nouveaux besoins ventuels.

Pour l'entreprise cliente, des seuils d'anomalies trs faibles, de lordre de 20, se traduiront forcment par un gain de temps

Tout d'abord, le client et le fournisseur tablissent ensemble la liste des fonctionnalits qui feront l'objet du contrat et la rajuste au fur et mesure du projet. C'est aussi en commun, qu'ils dfinissent l'ordre de priorit de chaque fonctionnalit base sur sa valeur ajoute mtier et qu'ils font une estimation de sa complexit. La constitution de l'quipe projet est aussi le rsultat d'une collaboration. Ct client, elle sera compose au minimum d'un responsable produit. Mais le client doit aussi tre pleinement impliqu dans la slection des ressources ct fournisseur. C'est galement par le dialogue que le client et le fournisseur dfinissent les indicateurs de bonne marche du projet. Dans ce domaine, la meilleure stratgie consiste privilgier des indicateurs qualit car la qualit fait levier sur la productivit. Pour l'entreprise cliente, des seuils d'anomalies trs faibles, de lordre de 20, se traduiront forcment par un gain de temps dans toutes les tapes futures de la vie de l'application en dveloppement comme en maintenance. Enfin, le fournisseur s'engage sur un niveau de qualit adapt au besoin de son client, plutt que sur une productivit beaucoup plus arbitraire. En effet, la productivit est un critre plus contractuel par nature et plus difficile mesurer et expose retomber dans le pige de dfiance des contrats classiques au forfait.

49

6.4  Mthodes et outils permettant de travailler de manire transparente

Travailler en toute transparence vise crer et maintenir la confiance, ainsi qu' viter tout rapport de force dsquilibr. Lorsque le contrat est sign, client et fournisseur s'engagent travailler ensemble en toute transparence. Cela ncessite une bonne matrise des pratiques Agiles :  le fournisseur dlivre intervalles rguliers (itrations de 2 4 semaines) un jeu de fonctionnalits exploitables par le client,  chaque itration, client et fournisseur choisissent en commun le primtre de livraison, en tenant compte des priorits mtier,  les indicateurs et outils d'avancement sont partags et permettent d'ajuster le niveau de qualit et d'acceptabilit des livrables : l'effet bote noire est ainsi supprim,  le client voit son produit se construire progressivement chaque itration en ayant conscience des risques et des difficults rencontres, mais aussi en mesurant l'efficacit des quipes. Certains contrats Agiles subdivisent le projet en itrations courtes de 2 4 semaines, qui font l'objet de mini-forfaits.

Mini-forfaits de 2 4 semaines

Chaque itration aboutit la livraison au client d'une ou de plusieurs fonctionnalits exploitables et pouvant faire l'objet d'une recette partielle. Ce n'est qu' l'acceptation de ce livrable que le fournisseur sera rmunr pour le travail effectu durant l'itration. La contractualisation Agile prserve ainsi la relation client-fournisseur de tout rapport de force. A chaque fin d'itration, les deux parties analysent ensemble la qualit et la vitesse d'excution du projet. Puis elles valuent en toute transparence leur capacit atteindre l'objectif fix pour l'itration suivante. Le contrat Agile fait ainsi passer la relation client-fournisseur d'un mode perdant-perdant dans lequel le client est insatisfait et le fournisseur peine rentabiliser sa contribution, un mode vritablement gagnant-gagnant .

6.5  Flexibilit pour tenir compte des changements fonctionnels

50

Dans un contrat Agile, le client est d'abord libre de changer d'avis, ou plus exactement de faire voluer le primtre fonctionnel selon son besoin ou pour saisir une opportunit technologique. Ni le client, ni le fournisseur ne reste prisonnier d'un cahier des charges qui peut tre trs vite dpass. Tout au long du projet, le client peut intgrer de nouveaux besoins fonctionnels et supprimer des fonctionnalits potentiellement inutiles. Le fournisseur s'engage sur sa capacit et sa ractivit prendre en compte les changements en se basant sur des pratiques d'ingnierie appropries : usine logicielle, architecture et suivi de projet Agile. Les impacts oprationnels et financiers de chaque volution sont partags de manire permettre au client de faire des choix en termes mtier et financier.

6.6 Ralisme du contrat Agile

Outre qu'il permet au client de rester matre de son projet de bout en bout, le contrat Agile prsente le double avantage de renforcer la confiance au fur et mesure des itrations livres et acceptes, et de maintenir le niveau de qualit attendu, la rmunration du fournisseur tant directement lie la satisfaction du client. Le contrat Agile est beaucoup plus raliste, car chaque itration, client et fournisseurs peuvent tenir compte des progrs raliss et des difficults rencontres pour rvaluer sans attendre l'adquation des ressources et des objectifs.

Le contrat Agile repose sur un triple engagement mutuel du client et du fournisseur : collaboration, visibilit et flexibilit qui le rend particulirement adapt la conduite de projets offshore et multisite. Nathalie LOPEZ, Directeur gnral adjoint, VALTECH TECHNOLOGY

En effet, plus les quipes appeles collaborer sont loignes, plus grande est limportance de maintenir le dialogue et la confiance. Le fournisseur s'engage, mais la visibilit sur l'ensemble du projet lui permet de conserver l'autonomie qui lui est ncessaire pour garantir la qualit et la rentabilit de sa contribution. Quant au client, il reste tout moment le seul matre de son projet, sans craindre des rapports de force dsquilibrs avec ses fournisseurs.

Lessentiel retenir - Le contrat est un outil indispensable pour la conduite des projets informatiques. - Lapproche contractuelle forfaitaire se rsume essayer de fixer par avance les dlais, les cots, le primtre fonctionnel et le niveau de qualit du projet. - Avec la contractualisation Agile, le client et le fournisseur apprennent travailler ensemble, crer et maintenir un climat de confiance par un dialogue transparent et constant. - Le contrat Agile formalise : les pratiques de collaboration entre le client et son fournisseur, les moyens de restitution des lments de pilotage projet informatique,  les possibilits de rajustement des objectifs en fonction des nouveaux besoins ventuels. - Dans un contrat Agile, le client est libre de faire voluer le primtre fonctionnel selon son besoin ou de saisir une opportunit technologique. - Le fournisseur Agile s'engage sur sa capacit et sa ractivit prendre en compte des changements. - Les impacts oprationnels et financiers de chaque volution sont partags. - Le contrat Agile est beaucoup plus raliste car chaque itration, client et fournisseurs peuvent tenir compte des progrs raliss et des difficults rencontres.

51

ZOOM Pratiques Agiles

Agilit n'est pas synonyme de dsordre, au contraire, le monde de l'agilit comprend un certain nombre de mthodes trs formalises tel que Scrum ou Extreme Programming (XP) pour ne citer que les plus connues. Voici un schma qui est inspir de la reprsentation en 3 niveaux de Ron JEFFRIES (un des fondateurs de l'Extreme Programming) agrment d'autres pratiques Agiles que nous utilisons rgulirement chez Valtech :  le cercle extrieur contient les pratiques lies au client,  le cercle intermdiaire contient les pratiques de management,  le cercle intrieur contient les pratiques de dveloppement.

52

Figure 9 Les pratiques Agiles issues de XP et Scrum (Source Valtech Technology).

Cercle Client
Dveloppement Itratif : l'activit de dveloppement est organise en cycle dont la dure est fixe une fois pour toute pour le projet. On appelle ces cycles des itrations ou sprints. Ils dfinissent la pulsation cardiaque du projet.

Equipe Unique (whole team) : il s'agit ici de casser le modle cloisonn Spcificateur-Dveloppeur-Testeur. Les participants d'un projet de dveloppement forment une seule quipe ou tout le monde participe la hauteur de ses comptences, et dans le cadre d'un rle identifi, vers un but commun. Il est important de souligner que cette pratique consiste aussi rassembler l'quipe sur le plan gographique (dans la mesure du possible). Livraisons frquentes (Small Releases) : les livraisons sont effectues souvent, toutes les 2 4 semaines. Cette pratique permet de rduire notamment les difficults parfois rencontres au moment de la mise en production. Rtrospective : chaque fin d'itration, un temps est prvu pour rflchir au droulement de l'itration passe et chercher les moyens d'amliorer l'efficacit pour les itrations futures. Sance de planification (Planning game) : la structure des sances de planification est trs codifie, avec un certain nombre d'tapes identifies raliser avec tous les membres de l'quipe. Ces sances de planification reviennent cycliquement en dbut de chaque itration, dfinissant ainsi les spcifications de l'application produire petit petit, plutt qu'en un seul grand coup de canon en dbut de projet. C'est lors de ces sances que l'on dfinit ce que l'on appelle dans Scrum le Sprint Backlog ou Iteration Backlog, partir de la liste des fonctions / scnarii rassembls dans ce que l'on appelle, le Product Backlog, et qui suit l'application d'itration en itration. Tests client automatiss (TDR) (Customer Tests) : on parle aussi de spcifications excutables ou Test Driven Requirements. Le client dfinit les critres d'acceptation des scnarii fonctionnels sous forme de cas de test.

53

Cercle Management
Intgration Continue (Continuous Integration) : le systme dvelopp est intgralement assembl et test plusieurs fois par jour. Aujourd'hui, cette pratique est grandement facilite par des outils ddis (Hudson, CruiseControl). Mtaphore (Metaphore) : l'quipe doit rechercher et utiliser une analogie comme modlisation du systme dvelopper. Cette technique trs rpandue dans le monde informatique permet aussi l'quipe de se construire un vocabulaire commun, notamment pour la communication entre les profils fonctionnels et techniques. Proprit collective du code (Collective Code Ownership) : tout le code de l'application est accessible en modification par tous les membres de l'quipe. Il n'y a pas de domaine rserv. Cette pratique qui l'avantage de rsoudre le syndrome de l'autobus (qu'est ce qu'on fait si une personne de l'quipe se fait renverser par un autobus), permet aussi de fluidifier le travail quotidien de l'quipe. Elle suppose d'avoir une communication trs dveloppe sur les dtails techniques de

ralisation. Les tests unitaires intensifs et la programmation en binme soutiennent cette pratique de manire significative. Rgles de codage (Coding Standard) : l'quipe se fixe des rgles de codage de manire ce que le code soit homogne et facilement lisible par tous. Rythme durable (Sustainable Pace) : cette pratique initialement intitule par les amricains "40 heures par semaine" qui n'a jamais signifi grand choses dans la culture franaise, recommande de ne pas faire d'heures supplmentaires plus de deux semaines de suite. Les membres de l'quipe doivent tre en forme pour donner le meilleur d'eux-mmes. La gnralisation des heures supplmentaires est le flau des quipes mal organises. L'optimisation des processus apporte par ce type de mthode permet d'amliorer notablement la productivit sans augmenter la charge de travail.

Cercle Dveloppement
Conception Simple (Simple Design) : tout moment, le design de l'application est le plus simple possible qui puisse rpondre aux exigences rencontres jusque l. La simplicit ne sous-entend pas de prendre des raccourcis sur la qualit. Le code doit tre concis, modulaire, cohrent, lisible et doit passer tous les tests. Dveloppement Pilot par les Test (TDD) (Test-Driven Development) : l'activit de programmation suit le processus suivant : Ecrire un test -> Ecrire le code le plus simple qui puisse compiler -> refactorer pour introduire l'abstraction ncessaire et liminer d'ventuelles duplications. Programmation en binme (Pair Programming) : elle se caractrise par le fait que le code est crit par deux personnes, un pilote et un co-pilote. Les rles au sein du binme et les binmes eux mme changent rgulirement ce qui permet lquipe davoir une meilleure connaissance du code de lapplication. Refactoring permanent (Mercyless Refactoring) : pratique de dveloppement qui consiste amliorer le code sans en changer son comportement.

54

Glossaire
CMMI DSI MOA MOE PDCA
Capability Maturity Model Integration Direction des Systmes dInformation Matrise dOuvrage Matre duvre Plan Do Check Act

PMD  Outil d'analyse des flux de donnes et de recherche des copier/coller,

du code mort et des constructions complexes en Java.

ROI RSA TDD TDR

Return On Investment (retour sur investissement) IBM-Rational Software Architect Test Driven Development Test Driven Requirements

55

Documents de rfrence
Rf. Document AUTEUR
Ken Schwaber

EDITEUR
Pearson Education

EDITION
2008 2007 2007 2004 2004 2004 2003 2003

Rf. 1 Agile Software Development with Scrum Rf. 2 Implementing Lean Software Development, From Concept to Cash

Mary and Tom Addison Wesley Poppendieck Vronique Messager Rota Mike Cohn Jean-Louis Bnard Mike Cohn Kent Beck Craig Larman Eyrolles Prentice Hall Eyrolles Addison-Wesley Professional Pearson Education Addison-Wesley Professional

Rf. 3 Gestion de projet : vers les mthodes Agiles Rf. 4 Agile estimating and planning Rf. 5 Gestion de projet Extreme Programming Rf. 6 User stories applied Rf. 7 Test-Driven Development Rf. 8 Agile and Iterative development

Nos rfrences
ABN AMRO - Airbus - Alcatel - ATP - Atx - Audi - Axalto - Bech - Bruun - Betfair - BMW - BofA Brasserie Kronenbourg - Bull - Cap Gemini - Carrefour - Casino - Cofinoga - Continental Dagens Nyheter - DanBolig - Danisco - Dassault - Dyrup - Ecco - EDS - EMSI - European Commission Falck Alarm - Fedex Kinkos - Fortum Power & Heat - France Tlcom - GFU Softec - Grundfos - Hedra IBM - Iflex Solutions - JC Decaux - JPCM - Karolinska Institutet - KG Knutsson - Kungliga Tekniska Hgskolan - Kuoni Scandinavia - L&G - La Poste - LIFFE - A Little World - London Underground Louis Vuitton Malletier - LVMH (Kami, Sephora, Vuitton, Dior) - MACIF - MAE - Man Investments Metro - Mindlance Inc - Mindtree consulting - Nationwide - NESA - Novo Nordisk - Omgeo Orange - PBS - Pegasus Solutions - Peugeot Citron Automobile - Predica - Rigshospitalet - Sanef SG - Siemens - Skanska - Softlab - Sony Ericsson - Statskontoret - Sydbank - Telia Sonera Thales Avionics - Thyssen - Krupp - T-Mobile - Travelocity - UBS - Unisys - United Biscuits - Vivarte - Voca Vodafone - Warner Chappel Music Inc

France Paris Siege social du groupe 80, avenue Marceau 75008 Paris Tl. : + 33 (0)1 53 57 71 00 Paris, La Dfense Cur Dfense A 92931 Paris la Dfense Cedex Tl. : + 33 (0)1 41 88 23 00 Puteaux 11, quai de Dion Bouton 92800 Puteaux Tl. : + 33 (0)1 41 44 65 30 Toulouse Immeuble Tersud Btiment B 5, avenue Marcel Dassault 31500 Toulouse Tl. : + 33 (0)5 62 47 52 00 Allemagne Dsseldorf Bahnstrae 16 40212 Dsseldorf Tl. : + 49 (0)211 179237-0 Frankfort Werner-Heisenberg - Strae 2 63263 Neu-Isenburg Tl. : + 49 (0)6102 88468-0 Hambourg Kurze Mhren 1 / Spitalerhof 20095 Hamburg Tl. : + 49 (0)211 179237-0 Munich Zweigstrae 10 80336 Mnchen Tl. : + 49 (0)89 893242-0

Danemark Aarhus Longhjevj 1, True 30-32 8381 Tilst Tl. : + 45 32 88 20 00 Copenhague Kanonbdsvej 10 1437 Kbenhavn K Tl. : + 45 32 88 20 00 Etats-Unis Bryan-College Station 700 University Drive East Suite 104 College Station, TX 77840 Tl. : +1 (979) 595 99 20 Dallas 5080 Spectrum Drive Suite 700 West Addison, Texas 75001 Tl. : + 1 (972) 789 12 00 Houston 17240 Huffmeister Road Cypress, TX 77429 Tl. : +1 (832) 497 10 40 New York 100 Wall Street Suite 2215 New York, NY 10005 Tl. : + 1 (212) 688 99 00 Raleigh 8601 Six Forks Road Suite 400 Raleigh, NC 27615 Tl. : + 1 (919) 878 66 90

Inde Bangalore 30/A, 1st. Main Road J. P. Nagar 3 rd. Phase Bangalore - 560 059 Tl. : + 91 80 26 07 90 00 Royaume-Uni Londres 102 Aldersgate Street London EC1A 4JK Tl. : +44 (0)20 70 14 08 00 Manchester 9th Floor 8 Exchange Quay Manchester M5 3EJ Tl. : +44 (0)16 18 73 63 00 Cwmbran Springboard Innovation Centre Llantarnam Park Cwmbran Torfaen NP44 3AW Tl. : + 44 (0)16 33 64 78 75 Sude Stockholm Tegnrgatan 23 111 40 Stockholm Tl. : + 46 8 615 33 00 Core Soul 19F Gateway Tower 12 DongzaDong YongsanGu Seoul 140-709 Tl. : + 82 27 27 56 00

www.valtech.com