VALTECH Livre Blanc Agile v2 2011

Embed Size (px)

Citation preview

TRANSITION VERS L'AGILIT

L'CHELLE D'UNE ORGANISATION

MATRISE, VALEUR, SOUPLESSE

LIVRE BLANC

TRANSITION VERS LAGILIT LCHELLE DUNE ORGANISATION

DEUXIME EDITION - 2011

2

AVANT-PROPOSCre en 1993 et cote sur lEurolist dEuronext, Valtech est une socit pionnire et leader dans le domaine de lAgilit, des technologies et du digital. Prsente linternational, Valtech forme et accompagne ses clients dans leurs projets de ralisation de plates-formes digitales critiques pour leur croissance. Valtech en propose une vision novatrice, par une mise en uvre intgre sur toute la chane de valeur digitale, avec pour finalit lacclration du Time to Market et donc du retour sur investissement.3

Valtech est prsent dans 8 pays (France, Royaume-Uni, Allemagne, Sude, Danemark, Etats-Unis et Inde) et a ralis un chiffre daffaires de 100 millions de dollars en 2009. Reconnu dans le Conseil, la Ralisation de projets ainsi que dans la Formation, Valtech prsente des rfrences de mise en uvre de lAgilit, telles que : APEC, AFPA, Club Med, Crdit Agricole, Dassault Aviation, EDF, Mappy, Orange, Pernod Ricard, RTE, Socit Gnrale, Thales ...

4

REMERCIEMENTSCe livre blanc est le fruit de la collaboration de la communaut Agile de Valtech. Cette nouvelle mouture enrichit ldition 2008 avec de nombreux retours dexprience lchelle dorganisations compltes. Elle tmoigne de lenvie permanente des consultants de Valtech de partager leur expertise et leur savoirfaire sur les mthodes Agiles.STEPHANE LABATI// Responsable de loffre Agile // Valtech

Merci en particulier Etienne Charignon, Hlne Granboulan, Gilles Mantel, Frdric Trmeau, Nathalie Lopez-Saussier, Thomas Beaugrand, Hubert Gillon, Elisabeth Ducarre, Stphane Labati, Patrick Le Go, Parijat Sinha, Craig Larman, Jean-Claude Grosjean et Laurent Moulager, qui ont partag leurs retours dexprience Agiles dans les domaines aussi varis que les pratiques dingnierie, la gestion des exigences, les tests, le pilotage de projet, la conduite du changement et ses facteurs humains, la contractualisation Agile, la qualit logicielle, le lean, la conformit aux standards, loffshore, lExprience Utilisateur ou la cration graphique. Lquipe ditoriale remercie galement tous les relecteurs qui, forts de leurs propres expriences, ont largement contribu amliorer la qualit de ce livre blanc. Enfin, Valtech remercie ses clients qui lui ont fait confiance en lassociant leurs dfis, renforant jour aprs jour son expertise et sa capacit les aider dans ladoption de lAgilit.

5

SOMMAIRE

SOMMAIRE1. Les mthodes Agiles pour les nuls 1.1. Pourquoi adopter les mthodes Agiles ? 1.2. Qui est concern ? 1.3. Quelles sont les pratiques Agiles les plus rpandues ?

1112 14 15

2.

LAgilit par la pratique2.1. Tmoignage dun coach Agile Valtech 2.2. tude dopportunit 2.3. Recueil des besoins dans le Product Backlog 2.4. Test Driven Requirement : la spcification par lexemple 2.5. TDD, le dveloppement sous contrle 2.6. Suivi et pilotage avec lIteration Backlog 2.7. Retour dexprience sur la gestion de projet 2.8. Retour dexprience sur lautomatisation des tests 2.9. Rsultats obtenus sur des projets raliss par Valtech

1920 22 25 28 32 34 36 40 43

6

3.

Le marketing digital Agile3.1. La vision du produit 3.2. Personas, vous avez dit Personas ? 3.3. La dmarche crative 3.4. Agilit et Exprience Utilisateur

4547 48 49 56

4.

La transformation vers lAgilit4.1. Enjeux et motivations 4.2. Le projet de transformation 4.3. Dfinir le projet : le cadrage 4.4. Experimenter : Le pilote 4.5. Transformer : Dploiement et optimisation en continu

6162 63 64 70 74

5.

Les difficults surmonter5.1. Les difficults couramment rencontres 5.2. La gestion du stress dans les quipes Agiles 5.3. La contractualisation Agile 5.4. Lexternalisation Agile 5.5. LAgilit face aux autres standards 5.6. Mettre de lAgilit dans une dmarche CMMI

8182 84 86 90 97 987

6.

Glossaire des pratiques Agiles6.1. Dfinitions 6.2. Abrviations

105106 108

7.

Rfrences bibliographiques

109

SOMMAIRE

SOMMAIRE

SOMMAIRETable des figuresFIGURE1 FIGURE2

Exemple de Burndown Chart Prsentation schmatique du processus de dveloppement Agile bas sur Scrum Exemple de pratiques dingnierie et de pilotage de projet Exemple de Product Backlog Gestion des priorits et de la complexit dans le Product Backlog Exemple de Burndown Chart Planning dtaill dune itration Planning dtaill dune semaine Planning dtaill dune journe Exemple de Persona Les tapes dune transformation Agile Une quipe de projet en relation avec son cosystme Laccompagnement dans la transformation Agile Mesure de maturit Agile Le plan de dploiement Tableau de Scrum avec les diffrents types dhistoires utilisateur Product Owner en train dexpliquer les nuances des fonctionnalits lquipe Accueil dun membre de lquipe onshore par ses homologues offshore Bangalore Espace de travail ouvert entour de tableaux blancs Cycle de Deming PDCA (Plan, Do, Check, Act) Les pratiques Agiles issues de XP et Scrum

16 17 24 26 27 35 37 37 38 48 63 65 72 73 74 92 94 95 96 98 106

FIGURE3 FIGURE4 FIGURE5

FIGURE6 FIGURE7 FIGURE8 FIGURE9 FIGURE10 FIGURE11

8

FIGURE12 FIGURE13 FIGURE14 FIGURE15 FIGURE16

FIGURE17

FIGURE18

FIGURE19 FIGURE20 FIGURE21

Table des tableauxTABLEAU1 TABLEAU2 TABLEAU3 TABLEAU4 TABLEAU5 TABLEAU6 TABLEAU7 TABLEAU8 TABLEAU9 TABLEAU10 TABLEAU11 TABLEAU12

TDR - Donnes initiales TDR - Affaire versus Convention TDR - Affaire versus Convention TDR - Validation de convention Contexte projet Dveloppement de la vision Les cls de la transformation Agile Critres de slection dun projet pilote Dispositif daccompagnement pour un projet Ordre dintroduction des pratiques Agiles Dispositif daccompagnement Rfrences bibliographiques

29 30 30 30 36 65 68 71 72 73 75 1109

SOMMAIRE

10

1LES MTHODES AGILES POUR LES NULS

11

OUENQUOICONSISTENTLESMTHODESAGILES ETPOURQUOILESADOPTER

1. LES MTHODES AGILES POUR LES NULS

1.1

POURQUOI ADOPTER LES MTHODES AGILES ?Les mthodes Agiles consistent en un ensemble de pratiques imagines pour pallier les difficults rencontres dans les cycles de dveloppement en cascade ou en V, encore omniprsentes.Les mthodes traditionnelles prnent un enchanement squentiel des diffrentes activits, depuis les spcifications jusqu la validation du systme, selon un planning prtabli. Elles visent mieux prdire la faon dont les choses devraient se passer. Malheureusement, cette vision rassurante est bien loin de la ralit des projets. Les activits dingnierie ne sauraient se succder strictement sans quaucun changement ne vienne perturber un planning qui na de dure de vie que le temps de le prononcer. La consquence est que plus de 80% des projets excuts selon ces mthodologies connaissent des retards, des dpassements budgtaires, quand ils ne finissent pas en chec total, pour navoir pas su satisfaire les attentes des clients.

Ces problmes sont lis plusieurs caractristiques fondamentales de ces anciennes mthodologies :

aa12

lerlejouparleclient : le client intervient principalement au moment du lancement du projet, quelques jalons majeurs parfois espacs de plusieurs mois, et surtout en fin de projet pour la rception et la recette du systme. Cet effet tunnel conduit une solution souvent inadapte et de pitre qualit. lemodecontractuelforfaitaire qui :

aa aa aa

a durcit les relations entre client et fournisseur, a rend le passagedetmoinlong et douloureux la fin du projet.unetropgrandestandardisation des activits dingnierie, dont lenchanement se rvle souvent inefficace. Formellement, les contrles davancement et de qualit ne peuvent tre mens que sur la base de documents dans les premires tapes, et bien des organisations sont devenues des usines produire de la documentation au lieu de produire de la valeur (fonctions logicielles) pour les clients et les utilisateurs. lepassagederelai entre les phases successives dans lesquelles uvrent des quipes diffrentes, gnralise une relation de type client-fournisseur et nencourage ni lempathie ni lesprit dquipe, bien au contraire. Chaque transition se traduit par une perte de temps, de savoir, dinformations ou de responsabilit.

A contrario, les mthodes Agiles prconisent :

Ladoption dun cycle itratif et incrmentalpermettant une quipe de sadapter au contexte ainsi quaux changements qui ne manquent pas de survenir au cours dun projet.

Limplication du clientdans le dveloppement, permettant au client et lutilisateur de donner leur feedback quant au devenir de lapplication en cours de dveloppement, annulant ainsi tout effet tunnel .

La dfinition dobjectifs court termequi permet de maintenir une pression constante mais supportable sur lquipe, 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.

La collaboration entre les personnes et lintgration des quipesqui combat les fameux passages de relais en rassemblant dans un mme espace toutes les nergies et la comptence de personnes centres sur lapplication raliser. Plus aucune barrire et des tches dfinies par lquipe au meilleur moment, cest--dire quand on en a besoin, plutt quau dbut du projet.

La livraison dun produit oprationnel13 de bonne qualit parce que souvent test, dot de la seule documentation strictement ncessaire, et rpondant coup sr aux vrais besoins des utilisateurs puisquil est rgulirement soumis leur feedback.

1. LES MTHODES AGILES POUR LES NULS

1. LES MTHODES AGILES POUR LES NULS

Le succs des projets Agiles renforce jour aprs jour lengouement des DSI et des quipes informatiques pour des pratiques remettant lapplication et lhomme au centre du sujet. Un projet nest-il pas dabord une aventure humaine vcue par des hommes pour dautres hommes ?

// Delivery Manager // Valtech

HUBERT GILLON

1.2

QUI EST CONCERN ?Le Manifeste Agile propose 4 principes fondamentaux :

PRIORIT DONNE AUX PERSONNES ET AUX INTERACTIONSplutt quau processus et aux outils

PRIORIT DONNE LA PRODUCTION DE FONCTIONSplutt qu la documentation

PRIORIT DONNE LA COLLABORATION AVEC LE CLIENTplutt qu la ngociation contractuelle

PRIORIT DONNE LADAPTABILIT ET LACCUEIL DVENTUELS CHANGEMENTSplutt quau suivi dun plan originel

14

Forts de ces principes, on voit quune organisation, un dpartement, une business unit, un projet et mme une quipe peuvent adopter lAgilit avec succs. Mais quen est-il dun projet dj dmarr ou en difficult ? LAgilit peut galement dans ce cas amliorer les rsultats dj obtenus et faciliter la rsolution de bon nombre des difficults vcues. Elle va amener les personnes impliques :

aa aa aa aaHUBERT GILLON// Delivery Manager // Valtech

mieux collaborer, prendre du recul sur lapplication en priorisant les actions et en remettant plat le chiffrage initial, donner plus de visibilit aux clients et utilisateurs, liminer leffet tunnel induit par le cycle en V, en le remplaant par des itrations courtes et matrises.

Lidal serait que toute lorganisation ait conscience de lintrt de fonctionner diffremment et quelle mette dans sa stratgie ladoption dun ou plusieurs des principes Agiles.

1.3

QUELLES SONT LES PRATIQUES AGILES LES PLUS RPANDUES ?Il existe de nombreuses mthodes Agiles (XP, Crystal, FDD, Scrum...pour les plus connues) fondes sur les principes voqus ci-dessus. Chaque mthode apporte son propre lot de techniques et de pratiques, les unes concernant plutt le pilotage de projet, les autres, plutt lingnierie. LespratiquesAgileslesplusrpanduessontissuesdecesdiffrentesmthodes:

aa aa aa aa aa aa aa aa aa aa aa

limplication forte du client travers le rle de ProductOwner, lutilisation dun ProductBacklog pour grer dynamiquement les fonctions du produit raliser, et les priorits mtier associes ; le Product Backlog est labor en dbut de projet, et rvis autant que ncessaire, le ScrumMeeting, est une courte runion quotidienne (environ 15) qui rassemble tous les membres de lquipe de dveloppement. Cette runion permet aux personnes dchanger des informations sur lavancement des tches, signaler les problmes rencontrs et demander de laide si ncessaire, le RetrospectiveMeeting est une runion de fin ditration, focalise sur les vnements survenus et lanalyse causale des dysfonctionnements, des pertes de productivit et de qualit. Un ou deux axes damlioration seront privilgis de faon consensuelle et se traduiront par des tches dans le backlog de litration suivante, lIterationPlanning, en dbut ditration, permet lensemble de lquipe projet de dcouvrir la liste des fonctions implmenter, didentifier et destimer les tches de ralisation, la Vlocit est un indicateur qui mesure le volume de logiciel produit par lquipe au cours dune itration. Ce volume est estim pralablement pour chaque fonction (ou User Story), le BurndownChart est une reprsentation graphique de lavancement des travaux au cours dune itration : la courbe reprsente simplement le reste faire (en charge) tel quil est estim chaque jour par lquipe. Le point initial reprsente leffort total estim pour litration pour lensemble de lquipe, gnralement en heures, lIntgrationContinue 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 TestDrivenDevelopment (TDD) consiste crire les programmes de tests unitaires avant de programmer les fonctions elles-mmes, puis dadapter le code source test unitairement jusqu obtenir un code de qualit (Refactoring), le TestDrivenRequirement (TDR) permet de spcifier le logiciel par lexemple i.e. les exigences logicielles sont exprimes sous forme de cas de test, enfin le PairProgramming consiste programmer en binme dans le but dtre plus efficace en termes de conception, de revue de code et de transfert de comptences.

15

1. LES MTHODES AGILES POUR LES NULS

1. LES MTHODES AGILES POUR LES NULS

SPRINT #03 BURNDOWNREMAINING WORKING HOURS

400 350 300 250 200 150 100 50 07 8 9 10 11 14 15 16 17 18 21

100

80

60

40COMPLETED TASKS %

20

0

DEC

DEC

DEC

DEC

DEC

DEC

DEC

DEC

DEC

DEC

DEC

EFFORT BURNDOWN TARGET BURNDOWN COMPLETED TASKS %

FIGURE 1

Exemple de Burndown Chart (Source Valtech)

LESSENTIEL RETENIR> LesmthodesAgilesprconisentladoptionduncycleitratifet incrmental.16

> LAgilitprnelacollaborationentrelespersonnesetlintgration desquipes. > LesmthodesAgilesmettentlaccentsurlimportancededvelopper lebonproduit. 4PRINCIPESFONDAMENTAUX: > prioritauxpersonnesetauxinteractions, > prioritaudveloppementdesfonctions, > prioritlacollaborationavecleclient, > accueiletadaptationauchangement.

RELEASE PLANNING MEETING

SPRINT PLANNING MEETING

DAILY STATUS MEETING (DAILY SCRUM)

SPRINT DEMO AND REVIEW MEETING

Customer Product OwnerWorkday One day

Scrum Master

PRODUCT BACKLOG

WORKING SOFTWARE OTHER DELIVERABLES

SPRINT BACKLOG

Sprint 14-30 days

Scrum Team

FIGURE 2

Prsentation schmatique du processus de dveloppement Agile bas sur Scrum (SourceValtech)

17

1. LES MTHODES AGILES POUR LES NULS

1. LES MTHODES AGILES POUR LES NULS

18

2LAGILIT PAR LA PRATIQUE

19

OULERETOURDEXPRIENCEDEVALTECH

2. LAGILIT PAR LA PRATIQUE

2.1

TMOIGNAGE DUN COACH AGILE VALTECHAgile, cest pratique !LAgilit peut tre vraiment applique au quotidien loccasion de la ralisation de projets informatiques. Ce nest pas un doux rve inatteignable et dans bien des cas, cest mme assez facile.

// Consultant senior // Certified Scrum Master // Valtech

ETIENNE CHARIGNON

Les sceptiques vous diront peut-tre que lAgilit nest quun concept, un rve loign des ralits concrtes rencontres au quotidien. Nentendons-nous pas souvent des Oui, mais chez nous, a nest pas possible ! , ou des Oui, mais dans la vraie vie, ce nest pas comme a ! ? Ah, oui, mais pourtant, jexiste ! Avant de trouver des projets officiellement Agiles, jai fait pendant assez longtemps du dveloppement logiciel Agile en sous-marin et, les pratiques que jai pu mettre en place ont toujours apport normment au projet, voire le succs.

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 quon veuille bien sen donner la peine. La qualit est gratuite condition que lon veuille bien en payer le prix. Les pratiques que vous voudrez mettre en place feront gagner du temps sur le long terme, mais coteront quelque chose au dbut.20

Spcifications incrmentales et TDRComme on pourrait sy attendre, les pratiques de dveloppement sont bien plus simples mettre en place que celles qui font intervenir le client. Pour le faire lors dun projet sur lequel nous travaillons actuellement - nous avons planifi une itration zro de mise en route dune semaine, durant laquelle nous avons entre autres dfini la liste des scnarios dutilisation mais aussi mis en place FitNesse, un outil de TDR (Test Driven Requirement ) bas sur un wiki. Nousavonsconseillau clientdeneplusdtaillertoutessesexigencesfonctionnellesavantdedmarrer les dveloppements. A la place, nous lui avons demand la liste des scnarios dutilisation (le Product Backlog). Puis, pour chaque scnario, il a attribu une valeur mtier note entre 1 et 3. Nous en avons alors 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 sarrte pas l. Au dbut de chaque itration, nous choisissons les scnarios qui doivent tre raliss pendant litration et en dfinissons les critres dacceptation. Cest de cette manire que nous dtaillons les spcifications. Pour viter le gaspillage, les dtails ne sont pas prvusentirementlavance (pas de stock), mais seulement au moment o les dveloppeurs sont prts les recevoir.ETIENNE CHARIGNON// Consultant senior // Certified Scrum Master // Valtech

Ce flux tendu de spcification constitue la sve du processus Agile .

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:

aa aa

pour suivre le projet, on utilise lespost-itsurlesmurs, pour faciliter le travail en binme et la proprit collective du code, il est prfrable davoir un ensemble dordinateurs 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 quil est plus difficile de le faire lorsque les dveloppeurs sont parpills dans un open space.

Serveur dintgration continueVotre war room peut contenir une machineddielintgrationcontinue, 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 binme. En quelques minutes, vous installez un logiciel comme Hudson ou CruiseControl. Ce type de logiciel est capable daller 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 dexcuter une srie de tests et de mesures de qualit avec des outils tels que CheckStyle ou Cobertura. Il reste ensuite astreindreplusieursfoisparjourslesdveloppeursposterleur travailsurledptcentral (commit du code dans loutil de gestion des sources).

21

2. LAGILIT PAR LA PRATIQUE

2. LAGILIT PAR LA PRATIQUE

2.2

TUDE DOPPORTUNITLtude dopportunit de ladoption de lAgilit par une organisation est le moyen idal pour sinitier en douceur au monde de lAgilit. Base sur lcoute et lchange, cette tude permet dapporter une solution personnalise et adapte aux attentes et besoins du client. Lobjectif de cette tude nest pas de faire un audit projet, mais plutt didentifier les pertesdnergie et les ventuels effetsdinertie de lorganisation projet, ainsi que didentifier denouvellespratiquesplusefficaces. Les tapes de cette tude sont les suivantes :

aa aa aa aa

tat des lieux des pratiques en cours, rdaction dun document de synthse sur lexistant, adoption de pratiques adaptes au contexte du client, rdaction et soutenance des pratiques retenues.

tat des lieux des pratiques en coursCette tape se droule sous forme dentretiens et de sances de travail qui visent tablir la cartographie des pratiques en cours auprs dun chantillon de personnes intervenant sur tout le cycle de vie dun projet (matrise douvrage, matrise duvre, cellule qualit, formateurs...). Cette collecte dinformations est organise par type dactivit projet telles que :

22

aa aa aa aa aa aa aa aa

le recueil du besoin, la gestion de projet, le transfert de connaissances, les spcifications logicielles (dossier danalyse), la conception et limplmentation, le test logiciel, la qualit logicielle, le dploiement et la mise en production.

Rdaction dun document de synthse sur lexistantLe document de synthse des interviews a pour but de mettre en vidence de faon objective et anonyme les diffrentes remontes dinformations effectues lors de ltape prcdente.

La synthse contient:

aa aa aa aa aa aa

la description des primtres technique, fonctionnel et organisationnel du projet ou du service, candidat lAgilit, la description des rles et responsabilits de chaque personne interviewe au sein de lorganisation projet ou service, la description de ltat des lieux de chacune des activits prcdemment cites, la liste des acclrateurs ventuels ladoption de lAgilit, lidentification des freins ventuels, les incontournables manquants (pratiques indispensables et pourtant absentes).

Ce document sert de base une nouvelle sance de travail au cours de laquelle les freinsetincontournablesmanquantssontanalyssendtail. A ce stade, dautres sances de travail plus cibles sont ralises pour identifierlespratiqueslesplus utiles, en sappuyant sur un catalogue de pratiques Agiles.

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 TRMEAU// Chef de projet senior // Certified Scrum Master // Valtech

Adoption de nouvelles pratiquesLes pratiques identifies prcdemment sont synthtises dans un document o :23

aa aa aa aa aa aa

les risques et incontournables manquants sont rappels avec les pratiques Agiles associes, les conditions dentre 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 lorganisation et les processus actuels sont dcrits, les attendus oprationnels de la pratique sont dcrits.

2. LAGILIT PAR LA PRATIQUE

2. LAGILIT PAR LA PRATIQUE

FIGURE 3

Exemple de pratiques dingnierie et de pilotage de projet(Source:Valtech)

Rdaction dun document de synthse sur les pratiques retenuesValtech produit le document final de ltude synthtisant les attendus du client, la dmarche, et enfin les pratiques retenues. Un plan daction et une proposition de planning finalisent le document qui est prsent lensemble des acteurs impliqus dans ltude. A lissue de la soutenance, Valtech propose au client, au choix :

24

aa aa aa

une prestation de production dArtefacts issus des pratiques Agiles retenues, une mission daccompagnement dans la mise en uvre des nouvelles pratiques Agiles sur le projet, une formation lAgilit.

LESSENTIEL RETENIR> Lobjectifdeltudedopportunitestdidentifierlespertesdnergies, lesventuelseffetsdinertieduneorganisationprojetoudunservice ainsiquedenouvellespratiquesplusefficacesetplusAgiles. > Ltudedopportunitestbasesurdesinterviewsetdesworkshops quipermettentdedfinirlacartographiedespratiquesencours.Cette tudepermetensuitedidentifierlesfreinsladoptiondelAgilit,les incontournablesmanquantsetlespratiquesAgileslesplusutiles. > Unplandactionetunepropositiondeplanningfinalisentltude dopportunit.

2.3

RECUEIL DES BESOINS DANS LE PRODUCT BACKLOGLe manque de visibilit sur le contenu final probable dun logiciel est prjudiciable au client mais galement aux quipes projet. Le Product Backlog contient cette description et permet entre autres :

aa aa aa aa aa

davoir une vision commune sur lensemble des fonctions ou cas dutilisation dfinissant le primtre du logiciel dvelopper, de comprendre lintrt et les enjeux des dveloppements pour les utilisateurs (appels galement acteurs), destimer lavancement 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 lidentification des tches du projet en les organisant autour des fonctions ou des cas dutilisation.25

Un Product Backlog a t labor, par exemple, chez un de nos clients dans le domaine de lassurance, pour formaliser de faon synthtique lensemble des fonctions attendues par les courtiers, et pour estimer la charge de ralisation de lapplication. La figure suivante prsente un extrait du tableau obtenu aprs deux jours de travail avec la matrise douvrage et la matrise duvre, ainsi quavec deux courtiers en assurance, futurs utilisateurs de lapplication.

2. LAGILIT PAR LA PRATIQUE

2. LAGILIT PAR LA PRATIQUE

CAPABILITIES Capa. Functional Capabilities Lot 1 Quotation management (Lot 1) 1 1 1 2 2 2 C2 Date import (Lot 2) 2 2 2 2FIGURE 4

FEATURES Feat. F1-1 F1-2 F1-3 F1-4 F2-1 F2-2 F2-3 F2-4 F2-5 F2-6 F2-7 Features 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 Actors User User User User User User User User User User User

C1

Exemple de Product Backlog (Source:Valtech)

Les fonctionnalits de haut niveau (Functional Capabilities) de la future application sont des regroupements de fonctions (User Features). Chaque fonction est identifie de faon unique pour pouvoir ensuite tre facilement rfrence. Un type dutilisateur est attribu chaque fonction. A la fin de cet exercice, les fonctionnalits de haut niveau sont groupes en lots de livraison. Une fois ce premier travail ralis, une priorit de dveloppement a t dtermine 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(Return on Investment), en livrant dabord les fonctions apportant le plus de valeur aux utilisateurs. Lextrait du tableau suivant donne une ide du rsultat.

26

FEATURES Feat. F1-1 F1-2 Features 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 Actors User User Complexity

PRIORITY Business Value Priority UCP

M

H

Medium

10

F1-3

User

F1-4 F2-1 F2-2 F2-3 F2-4

User User User

M

H

Medium

10

H User User

L

Medium

15

FIGURE 5

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

Un nombre de Use Case Points (UCP) a t attribu aux fonctions en raison de leur complexit, ceci afin de servir de base une estimation globale du projet.

FRDRIC TRMEAU// Chef de projet senior // Certified Scrum Master // Valtech

Finalement, nous avons t capables, en moins de 5 jours, de dcrire les besoins client sous la forme dun Product Backlog, didentifier lensemble des acteurs au sens UML, de dfinir les priorits dimplmentation, destimer la complexit des cas dutilisation et de chiffrer le projet dont la taille reprsentait 3.000 hommes.jours

27

LESSENTIEL RETENIR> Lemanquedevisibilitsurlecontenufinalprobabledunlogicielest prjudiciableauclientmaisgalementauxquipesprojet. > LutilisationduProductBacklogservletrsefficacecondition denmatriserlesconceptsetdedisposerdespersonnes comptentesethabilitesprendrelesdcisionsimpactantlefutur projet.

2. LAGILIT PAR LA PRATIQUE

2. LAGILIT PAR LA PRATIQUE

2.4

TEST DRIVEN REQUIREMENT : LA SPCIFICATION PAR LEXEMPLELe Test Driven Requirement (TDR) est fond sur le constat que dans bien des cas, il est plus efficace dexpliquer un comportement en dcrivant des exemples, plutt quen ralisant une spcification classique qui dcrit les mcanismes implmenter. Le Test Driven Requirement, ou spcification dirige par les tests, propose :

aa aa

de centrer la description et la rdaction des besoins utilisateurs sur des exemples qui constitueront autant de futurs cas de tests de validation, de centrer la collaboration entre les quipes du projet sur la comprhension et lenrichissement de ces exemples.

Le contexte documentaire et collaboratifPour un des leaders de services en ressources humaines, Valtech a mis en place la pratique TDR pour un logiciel de gestion qui avait t spcifi en UML. La stratgie de dveloppement avait t axe sur lefficacit court terme plutt que sur la maintenabilit. Les activits de projet taient confies des quipes distinctes (dveloppement / homologation / analyse-gestion de projet / MOA). Aprs 6 mois dexploitation, le client a formul les remarques suivantes: Les fonctions majeures du logiciel taient oprationnelles. Chaque quipe disposait de ses propres documents, relatifs son activit, sans les partager avec les autres quipes.28

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 besoins. Le primtre de test dduit des spcifications tait incohrent avec les fonctionnalits dj implmentes. Lhomologation tait de moins en moins souvent ralise du fait de la difficult produire les cas de tests, conduisant ainsi une baisse de qualit. La grande autonomie de chaque quipe se faisait au dtriment de la communication.

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

Les enjeux du clientCompte 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 TDRContexte de lvolutionIl sagit de modifier le cycle de vie dune affaire afin de mettre jour son tat lorsquune convention est cre, sans tre valide. Jusqu prsent, cest seulement lorsque la convention est valide que ltat de laffaire est mis jour. Une affaire est une opportunit commerciale dtecte pour un compte donn, mais naboutissant pas immdiatement la signature dune convention avec ce compte. Lorsque lopportunit 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.N.B.

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

29

AFFAIRES Nom de lAffaire Affaire ATABLEAU 1

Matricule Responsable 0002

Identifiant du Compte COMPT 01

tat du Compte 1 (ouverte)

Commentaire Null

TDR - Donnes initiales (Source:Valtech)

Laffaire est cre dans ltat par dfaut Ouverte tandis que le compte est cr dans ltat Prospect sur affaire .

2. LAGILIT PAR LA PRATIQUE

2. LAGILIT PAR LA PRATIQUE

Transformer une affaire en conventionLaction consiste pour le responsable (matricule 0002 li laffaire A) transformer laffaire A en convention.AFFAIRES RSULTAT Nom de lAffaire Affaire ATABLEAU 2

Matricule responsable 0002

Entit responsable E1

tat du compte 2 (ferme)

Identifiant du Compte Transforme en convention

TDR - Affaire versus Convention (Source:Valtech)

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

CONVENTIONS - RSULTAT Nom de la Convention Convention issue de lAffaire ATABLEAU 3

Matricule Responsable 0002

tat du Contrat 4 (brouillon)

Nom de lAffaire Affaire A

TDR - Affaire versus Convention (Source:Valtech)

La convention nest pas encore valide do sa cration dans ltat brouillon . Ltat du compte reste inchang.

Valider une convention30

Laction consiste pour le responsable (matricule 0002) valider la convention.COMPTES RSULTAT Nom du Compte BONJOUR Matricule Responsable 0001 Entit Responsable E1 tat du Compte 2 (client) Identifiant du Compte COMPT 01

CONVENTIONS - RSULTAT Nom de la Convention Convention issue de lAffaire ATABLEAU 4

Matricule Responsable 0002

tat du Contrat 1 (en cours)

Nom de lAffaire Affaire A

TDR - Validation de convention (Source:Valtech)

La validation de la convention entrane donc :

aa aa

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 exigencesDornavant, la description des fonctionnalits est affine de faon collaborative tout au long du processus de dveloppement :

aa aa aa aa aa

initiation par la MOA, enrichissement par les analystes, mise jour au fil des remarques des quipes de dveloppement et dhomologation.

Cette description sappuie sur des cas dexemples qui sont : les cas de tests des scnarios standards par la MOA, les cas de tests des scnarios 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 scnarios 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.31

Une exprience riche denseignementsPour en faciliter lappropriation 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 :

aa

Lquipe de dveloppement a pris le rflexe denrichir les exemples fournis dans la spcification TDR. Ces exemples ont t utiliss en intgration continue et en homologation.

2. LAGILIT PAR LA PRATIQUE

2. LAGILIT PAR LA PRATIQUE

aa aa aa aa

Une grande partie des ambiguts dans la description des rgles mtier est dsormais leve avant le dbut des dveloppements. Le besoin se stabilise de plus en plus tt dans le cycle de cration dune fonctionnalit. Les erreurs de description ou dimplmentation sont dtectes plus tt et sont donc plus faciles rsoudre. Lhomologation se droule dsormais normalement.

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

LESSENTIEL RETENIRLeTestDrivenRequirement(TDR)proposede: > centrerladescriptionetlardactiondesbesoinsutilisateurssurdes exemples, > centrerlacollaborationentrelesquipesduprojetsurla comprhensionetlenrichissementdecesexemples, > privilgierladescriptionconcrtepluttquelamodlisationdansune dmarcheTDR, > affinerladescriptiondesfonctionnalitsdefaoncollaborativetout aulongduprocessusdedveloppement, > utiliserlestableauxpaspas,suitediffrentesactionsoprateur, permetdevisualiserconcrtementleschangementsdtat successifs.Ilsfacilitentlafoislacomprhensiondufonctionnelmais galementlidentificationdesscnariidetestslespluspertinents.

32

2.5

TDD, LE DVELOPPEMENT SOUS CONTRLEContexteLe contexte sannonce a priori dfavorable, voire hostile lAgilit : la mthodologie interne prne le cycle en V, totalement ancr dans la culture industrielle de lentreprise.

Le projet de 3 hommes.an dont il sagit concerne le dveloppement dune application Java stand alone avec une interface Swing et diverses autres parties crites en C++.

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

Pratiques mises en uvreValtech a aid le client mettre en place :

aa aa

une approche de dveloppement dirige par les tests (TDD), une dmarche dautomatisation des tests de recette.

Difficults rencontresLe 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 dun an de travail. Il a, ds lors, t impossible de faire raliser les tests par le client. Certaines parties de lapplication tant dveloppes en Java et dautres 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.33

Solutions apportesTest Driven DevelopmentLes composants crits en C++ tant des librairies utilises par le code Java et JUnit tant plus facile 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 rapide.

Tests de recette automatissLquipe de dveloppement a crit les tests de recette, au moyen dune librairie externe uispec4j, permettant de scripter des scnarios dutilisation de linterface graphique Swing. Par ailleurs, un simulateur sous MS Windows a permis de simuler les interactions de lapplication avec un quipement propritaire. Loutil AutoIt a t utilis pour piloter ce simulateur depuis la suite de tests en Java.

2. LAGILIT PAR LA PRATIQUE

2. LAGILIT PAR LA PRATIQUE

Bnfices obtenusETIENNE CHARIGNON// Consultant senior // Certified Scrum Master // Valtech

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.

LESSENTIEL RETENIRLamiseenuvredespratiquesAgilesdeTDDpermetde: > restermatredelacomplexitdesdveloppementsraliss, > livrerdanslestempsetlebudgetimpartis.

2.6

SUIVI ET PILOTAGE AVEC LITERATION BACKLOGLIteration Backlog a pour vocation de contenir lensemble des tches identifies et estimes par lquipe de projet pour litration en cours. Grce lestimation initiale et au reste--faire estim quotidiennement, une reprsentation graphique de lavancement est disponible en permanence (Iteration Burndown Chart) Sur les projets Valtech, les tches sont associes des fonctions ou des scnarios de cas dutilisation.

34

aa aa

Les tches sont identifies pour prendre en compte de nouvelles priorits de livraison et pour minimiser le nombre ditrations ncessaires la livraison dune fonction ou dun cas dutilisation. La charge associe une tche est gnralement comprise entre 4 et 16 heures. Chaque tche est dcrite par les informations suivantes :

a identifiant unique (pour la traabilit avec les fonctions ou casdutilisation),

a nomexplicite non gnrique mais spcifique au contexte et au sujet trait, a identification du membre de lquipe qui sest engag la raliser, a effort estim en heures par lquipe lors du planning ditration (exercicecollgial de planification ditration),

aa aa

Chaque membre de lquipe projet renseigne quotidiennement le reste-faire pour les tches dont il a la charge1. Le Burndownchart est mis automatiquement jour, imprim et affich dans lespace de travail de lquipe, il est galement accessible distance via un wiki (y compris par le client). Il prsente leffort restant accomplir en heures, pour finir les tches alloues litration, le pourcentage de tches termines et la courbe idale de reste--faire .

ITERATION PROGRESSREMAINING WORKING HOURS

350 300

100

80 250 200 150 100 20 50 0 0 60

40COMPLETED TASKS %

7

AUG.

6

AUG.

7

AUG.

8

AUG.

9

AUG.

10

AUG.

13

AUG.

14

AUG.

15

AUG.

16

AUG.

17

AUG.

20

AUG.

21

AUG.

22

AUG.

23

AUG.

24

IT04 BURNDOWN IT04 BURNDOWN COMPLETED TASKS % IT04 BURNDOWN TARGET

FIGURE 6

Exemple de Burndown Chart (Source Valtech) 35

En fin ditration, les mtriques suivantes sont releves et communiques lquipe ainsi quau client :

aa aaFRDRIC TRMEAU// Chef de projet senior // Certified Scrum Master // Valtech

le pourcentageduprimtredelitrationralis. Il est calcul par le rapport entre la taille du logiciel qui devait tre livr (poids Fibonacci) et la taille livre rellement, la Vlocit de litration, cest dire le cumul du nombre de points de chaque fonction termine (codage, test, etc.), et livre (dmontre, accepte par le client, prte pour un dploiement ventuel).

Le Burndown Chart est un outil trs puissant pour matriser, sur une priode courte, lavancement des travaux raliss par une quipe sur une priode courte dont les objectifs ont t exprims en tches raliser.

1.

Une alternative consiste nommer chaque semaine et tour de rle, un time tracker qui relve ces mtriques pour lensemble de lquipe.

2. LAGILIT PAR LA PRATIQUE

2. LAGILIT PAR LA PRATIQUE

LESSENTIEL RETENIR> LIterationBacklogapourvocationdegrercourttermelensemble destchesidentifiesetestimesparlquipedeprojetsurchaque itration.Lamiseenplacedemesurespertinentespermet,jour aprsjour,desuivrelavancementreletdepiloterleprojeten consquence.

2.7

RETOUR DEXPRIENCE SUR LA GESTION DE PROJETContexteDveloppement dune application de gestion pour le suivi et la traabilit des processus de fabrication pour un industriel franais de laviation.Duoshore avec une quipe de 5 analystes Onshore sur le site du client et 25 dveloppeurs offshore dans notre centre de dveloppement de Bangalore (Inde). 9 000 hommes.jour 2 ans WSAD, Wiki Confluence, Jira

MODE DE DVELOPPEMENT TAILLE DU PROJET DURE DU PROJET OUTILS UTILISS

36

TABLEAU 5

Contexte projet (SourceValtech)

Enjeux clientLes enjeux pour cette nouvelle application sont :

aa aa aa aa

offrir un outil souple, robuste et facile dployer, faciliter le travail des utilisateurs par une interface intuitive et simple dutilisation, apporter une solution permettant de mieux matriser la traabilit des procds de fabrication, accrotre linteroprabibilit du systme avec les autres applications de gestion.

Pratiques mises en uvreLes pratiques mises en uvre sont :

aa aa aa aa

utilisation de la mthode dorganisation et de suivi Scrum sur les parties France et Inde (2 quipes Scrum), mise en place dun Product Backlog commun aux deux quipes, utilisation dun outil collaboratif (wiki) pour la communication entre les quipes de dveloppement et le client, mise en place dun mode de livraison Inde / France bas sur de lintgration continue (cf. figure 8). Les diffrents points de synchronisation France / Inde et MOA / MOE y sont identifis ci-aprs.

FIGURE 7

Planning dtaill dune itration (Source Valtech) 37

FIGURE 8

Planning dtaill dune semaine (Source Valtech)

2. LAGILIT PAR LA PRATIQUE

2. LAGILIT PAR LA PRATIQUE

FIGURE 9

Planning dtaill dune journe (Source Valtech)

Principe de rpartition des responsabilits de la matrise duvre :

aa

Onshore (France) :

a relation avec le client, a recueil des besoins, a formalisation de documents danalyse, a suivi de la validation de ces documents, a transfert de connaissance vers les quipes offshore, a support fonctionnel aux quipes offshore, a mise en place et contrle des directives darchitecture du projet, a contrle des flux de traduction Franais-Anglais (documents danalyse) etAnglais-Franais (document de conception),

38

a dveloppement de fonctionnalits qui ne peuvent tre dlocalises, a vrifications des scnarios de test, a coordination globale du projet.

aa

Offshore (Inde) :

a formalisation des documents de conception, a travaux de dveloppement, a laboration des scnarios de tests, a automatisation des tests, a excution des tests manuels et automatiques, a excution des contrles de qualit du code (PMD, RSA et FindBugs).

Difficults rencontresLes difficults rencontres sont :

aa aa aa aa aa aa aa

la contrainte dentre sur le site et la planification longtemps lavance ne permettent pas de faire intervenir des ressources offshore sur le site client, lobligation de planifier les runions et les workshops bien en amont, la clture de la documentation Word pour le client : en contradiction avec lapproche Wiki qui privilgie laccs en ligne pour tous, la barrire de la langue (langlais) pour la matrise douvrage, le souhait du client de raccourcir la prise en compte des demandes de changement dune itration lautre, le cycle initial de validation des livrables documentaires est trop lourd et pas du tout adapt lapproche itrative, les quipes onshore et MOA ne communiquent que par mails.

Solutions apportesLes solutions apportes sont :

aa aa aa aa aa aa aa aa

face limpossibilit de traiter les volutions : lamiseenplacedunvolant dejours pour traiter les volutions : systme denveloppe, pour rduire le nombre danomalies : miseenplaceduncircuit dintgrationcontinue entre les dveloppements raliss en Inde et la plateforme dintgration sur le site du client, lacclration de la prise en compte des demandes client : identification duneprovisiondecharges pour traiter les demandes de changement en cours ditration (jusqu la mi-itration), la rduction du backlog danomalies : constitutionduneprovisionde charges pour laisser le temps lquipe en Inde de corriger ses anomalies (interne / client) tout en produisant du fonctionnel, le rapprochement physique des quipes onshore avec la matrise douvrage.

39

Bnfices obtenusLes bnfices obtenus sont : le volant de jours : findestensions concernant la qualification des anomalies / volutions, laconfianceaccrueduclient en la qualit des dveloppements, lavisibilittotalesurlecontenuduproduitetdesitrations qui permet de planifier lavance les avenants contractuels pour traiter les nouvelles fonctionnalits majeures,

2. LAGILIT PAR LA PRATIQUE

2. LAGILIT PAR LA PRATIQUE

aa aa aa

lerespectdesengagements vis--vis des autres quipes impliques dans le processus dingnierie (autres quipes de dveloppement, intgration, qualification, tests de performances...), rductiondunombredanomalies grce une meilleure comprhension du fonctionnel par les quipes indiennes et la dcouverte au plus tt des anomalies (intgration continue), nouvellesprisesdecommandes.

LESSENTIEL RETENIR> LespratiquesAgilespeuventtreappliquesdansunenvironnement nonAgilemmesicelui-ciadefortescontraintes.Ilfautadapterces mthodesaucontexteduclientetlesadapterprogressivement:une ducationpralablemontrantlesbnficesattendusetunemiseen videncerguliredesgainsobtenussontimpratives. > LespratiquesAgileschoisiesetmisesenplaceavecjustesse permettentdeprserverundesfacteursclsdusuccsduprojet: labonnecollaborationentrelesquipesdufournisseuretcellesdu client.Noublionspasquecettecollaborationentrequipesestau centredespratiquesAgiles!

2.840

RETOUR DEXPRIENCE SUR LAUTOMATISATION DES TESTSContexteLAgilit permet de nombreuses livraisons intermdiaires. Chacune de ces livraisons doit tre intgralement teste ; dans le cas contraire, la perte de contrlesurlaqualitcrotdemanireexponentiellechaqueitration. Un dpartement de la DSI dune grande banque de finance souhaite mettre en place lAgilit au sein de ses quipes de dveloppement. Le dpartement a la responsabilit du dveloppement et de la maintenance dun ensemble dapplications avec des technologies htrognes. Toutes les applications sont dployes en production simultanment, trimestriellement. Chaque dploiement en production est prcd dune campagne de tests utilisateurs de 2 3 semaines visant sassurer de labsence de rgression dans lensemble des applications.

Enjeux clientLa dure des campagnes de tests de non-rgression risque de masquer leffet positif du dploiement des mthodes Agiles. Il est donc impratif de raccourcir la dure des campagnes et den augmenter la frquence.

Pratiques mises en uvreLes pratiques mises en uvre sont :

aa aa

automatisation des tests utilisateurs de non-rgression (tests fonctionnels sollicitant linterface graphique), mise en place de tests automatiss dans le processus dintgration 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 construction (build) pour offrir un niveau de ractivit optimal aux quipes de dveloppement : chec dintgration dtect en moins de 2 min, chec de tests unitaires en moins de 5 min, chec de tests fonctionnels en moins dune heure.

Difficults rencontres

aa

Les tests utilisateurs de non-rgression, ceux qui sollicitent linterface graphique, sont gnralement coteux automatiser et maintenir. La moindre modification dune interface peut conduire lchec dun script automatis, mme si les services sous-jacents nont pas t modifis : les quipes de dveloppement nont pas toujours conscience de cette contrainte et introduisent des modifications sur linterface, 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 tests, linterface graphique utilise des composants qui se prtent difficilement lautomatisation des tests. Ceci est dautant plus vrai que certains composants proviennent dditeurs qui ne fournissent pas le procd de test de leurs composants, le rfrentiel de donnes de lenvironnement 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.

aa aa aa

41

2. LAGILIT PAR LA PRATIQUE

2. LAGILIT PAR LA PRATIQUE

Solution apporteValtech sest focalis sur :

aa aa aa

ltudedecompatibilittechniqueentrelinterfacegraphiqueet loutildautomatisation, afin didentifier les composants graphiques problmatiques et damener les dveloppeurs concevoir des interfaces testables, ltudedeROI, destine vrifier lintrt conomique de lautomatisation (plus un test est excut, plus lautomatisation est rentable court terme), ladfinitiondelastratgiedautomatisation visant :

a choisir quels tests automatiser pour maximiser la valeur des tests denon-rgression par rapport leffort investi,

a dfinir la faon de grer le rfrentiel de donnes.

Lautomatisation des tests dans un contexte itratif et incrmental nest pas une option. Quel quen soit le prix, cest une obligation.

GILLES MANTEL// Directeur oprationnel // Valtech

Le fait ditrer implique de rejouer systmatiquement certains tests de nonrgression. 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.N.B.

Bnfices obtenus42

Les campagnes de tests utilisateurs sont progressivement passes dune frquence trimestrielle une frquence quotidienne. La dure dun cycle de tests utilisateurs a t rduite de 1 semaine 2 heures. La notion de campagne de tests perd progressivement de son sens pour laisserplacelanotiondetestsencontinu.

LESSENTIEL RETENIR> Lestestsmanuelspeuventtrecomparsuneforcedefrottement: pluslavitesseetlapressionsaccentuentsuruncorpsen mouvement,plusimportantssontlesfrottements,rduisant lefficacitdeseffortsconcdspouracclrerlemouvement. > Lautomatisationdestestsrduitcesforcesdefrottementetvite ainsilchauffementetlusuredudispositif.

2.9

RSULTATS OBTENUS SUR DES PROJETS RALISS PAR VALTECHValtech est la premire socit en France avoir propos en 2002 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 Craig Larman, auteur de nombreux ouvrages de rfrence en matire de processus dingnierie logicielle et dAgilit.Valtech a eu la responsabilit de dployer lensemble des principes Agiles sur la totalit des projets, jusqu la rorganisation complte des bureaux prcdemment organiss en cubicles et transforms en espaces de travail ouverts. Il a galement certifi Scrum Master lensemble des chefs de projet et a initi la mise en place de nouveaux outils tels que Valtech Cockpit, la plate-forme collaborative Valtech, utilise sur les projets aujourdhui.

43

2. LAGILIT PAR LA PRATIQUE

2. LAGILIT PAR LA PRATIQUE

Cet lectrochoc a t rellement salutaire car les rsultats sur les projets ont t grandement amliors sur diffrents plans:

Le respect des dlaisLe time boxing et le fait de procder par itrations successives a permis aux quipes projet daugmenter leur productivit.

La qualit des livraisonsLes anomalies tant corriges au fur et mesure, avec une priorit plus importante que les fonctionnalits livrer, la charge de gestion de ces anomalies a diminu pour laisser place plus de fonctions implmentes.

La confiance de nos clientsTout 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.

44

La satisfaction de nos collaborateursLe 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 projetsSouvent 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 augmentent nettement.

3LE MARKETING DIGITAL AGILE

45

OUPOURQUOIETCOMMENTMETTREDELAGILIT DANSLADMARCHEDECRATIONGRAPHIQUE

3. LE DIGITAL MARKETING AGILE

Le monde sacclre. Proposer le bon produit ou service la bonne personne, dans le bon contexte dachat, au bon moment est la cl de russite dun projet de marketing digital. Support par des plates-formes technologiques de plus en plus complexes et des supports dexpriences de plus en plus riches et sophistiqus, le marketing digital est un vecteur de rentabilit fort pour les annonceurs et sinscrit clairement dans leur exigence de retour sur investissement et dimage.LUBOMIRA ROCHET//Directeur Gnral Adjoint // Valtech

46

Le marketing digital personnalis en temps rel sinscrit aujourdhui dans la ralit des usages et des attentes, la fois des marques et de leurs clients. Mais qui dit temps rel et Web 2.0, dit dialogue continu avec les diffrentes publics, intgration continue des feedbacks des utilisateurs, adaptation constante des objectifs et des stratgies marketing en fonction des changements dans lcosystme de la marque. Cette ncessaire ractivit en temps rel impose une vraie rflexion sur les mthodologies de gestion des projets marketing et plus gnralement sur lorganisation du dpartement marketing lui-mme. LAgilit, qui place lutilisateur au cur de sa mthodologie, privilgie loprationnel sur la documentation plthorique, favorise lchange et la collaboration avec lcosystme et prne la ractivit permanente plutt que le suivi strict dun plan, prend tout son sens dans ce contexte. Lapplication des principes et des pratiques Agiles au mtier du marketing vient donner aux directions marketing les outils de leur efficacit et de leur pertinence, en les aidant dvelopper leurs produits et excuter leurs campagnes plus vite et de manire plus volutive. Les quipes marketing organises en mode Agile peuvent ainsi travailler de manire ultra collaborative au dveloppement et lamlioration des sites web, des produits ou des services, en tenant compte du feedback des utilisateurs.

3.1

LA VISION DU PRODUIT tout produit est ncessairement associe une vision, fixant le cap, donnant du sens et dcrivant ce quon entrevoit pour le produit court, moyen ou long terme. La vision du produit est donc cruciale, structurante ; elle sera le socle de toute lExprience Utilisateur du produit. Parfois peu dtaille, souvent pose en raction un problme et pilote en termes dobjectifs, la vision du produit naura de sens que si elle est porte et partage avec les quipes, pour tre en mesure de fdrer et de se projeter efficacement dans le futur. Construire la vision, la partager puis la porter : trois vrais challenges relever, notamment pour les Product Owners des projets Agiles, qui utilisent des pratiques hautement collaboratives. La vision synthtique est indispensable et, de surcrot, facile mettre en uvre. On peut, selon les contextes et les objectifs, laccompagner de lune voire des deux techniques Product Box. La vision synthtique ou Elevator Statement (daprs Moore) est la technique simple et efficace par excellence. Elle permet de structurer, en peu de temps, la vision du produit. Son format est le suivant : POUR : [ public concern par le produit ] QUISOUHAITENT : [ formulation du besoin des cibles ] NOTREPRODUITEST : [ ce quest le produit ] QUI : [ le bnfice majeur, lutilit de la solution ] LADIFFERENCEDE :[ pratique actuelle, concurrence ] PERMETDE : [ lments diffrentiateurs majeurs ]

47

Lue voix haute, la vision synthtique ne doit pas excder deux minutes. Elle trouve facilement sa place au sein du radiateur dinformations du projet. La mthode des Personas (cf. Encart) pourra venir complter admirablement les deux premiers lments de la vision, ceux relatifs la cible ( Pour ) et leurs buts ( Qui souhaitent ).

aa

La ProductVisionBox (daprs Highsmith) qui permet au dmarrage dun projet de construire la vision et la partager, de manire ludique, avec lquipe charge de concevoir le produit mais aussi ceux chargs de le vendre. Lquipe cre une bote, reprsentation visuelle, concrte du logiciel ou du service quelle est cense dvelopper : un nom, une image, un slogan, quelques arguments pour vendre le produit puis sur lautre face, par exemple, le dtail contenant plus de fonctionnalits ou encore les prrequis.

3. LE DIGITAL MARKETING AGILE

3. LE DIGITAL MARKETING AGILE

aa

La ProductBox (daprs Hohmann) qui offre une forte connotation Exprience & Etude Utilisateurs . Latelier de travail Product Box est rsolument orient clients, tourn vers les utilisateurs du produit final dont on rcolte le feedback. Ils creront en groupe une bote pour le produit dont ils simuleront ensuite la vente. Latelier se joue gnralement dans une dynamique collective. Plus il y aura de botes, mieux ce sera !

3.2

PERSONAS, VOUS AVEZ DIT PERSONAS ?Un Persona, cest un utilisateur-type, une reprsentation fictive des utilisateurs cibles, quon peut utiliser pour fixer des priorits, guider nos dcisions de conception dinterface et tester les scnarios dinterface les plus prioritaires. Cette mthode, invente par Alan Cooper en 1999 dans son best-seller The InmatesAreRunningtheAsylum, permet doffrir une vision commune et partage par lquipe des utilisateurs dun produit, en insistant sur leurs buts, leurs attentes et leurs freins potentiels, et en proposant un format des plus engageants. Les Personas suscitent en effet de lempathie, un vritable investissement motionnel : ils prennent trs vite une place de choix sur le radiateur dinformations du projet Agile. Les rles Utilisateurs , lmentscls des user stories, adoptent volontairement un format trs synthtique, et restent avant tout sur la relation utilisateur / systme : ni lments fictifs, ni scnario, ni travail denqute. Exemple : En tant que recruteur, je peux dposer une offre demploi pour recevoir plus de candidatures. Sur la base de grandes catgories dutilisateurs (rles ou segments marketing pralablement identifis), puis dateliers de travail et dentretiens utilisateurs, la mthode des Personas va donc plus loin, en affinant, en dtaillant puis en personnifiant les rlesutilisateurs.

48

FIGURE 10

Exemple de persona(SourceJean-ClaudeGrosjeanwww.qualitystreet.fr)

La cible du futur produit va donc trs vite merger au travers dun nombre restreint de Personas et surtout dun Persona primaire, celui pour qui on construit le produit. La mthode des Personas est une dmarche avant tout collaborative qui va mobiliser toute lquipe : les Personas se construisent collectivement au cours de plusieurs ateliers de travail. Cette construction devra imprativement sappuyer

sur des donnes issues dentretiens (parties prenantes et futurs utilisateurs) voire de lobservation directe des cibles, et sur lpluchage de diverses sources (support, presse, tudes externes, concurrence ) : cest la spcificit et la force de la mthode ! Des lments de contexte, les buts et comportements et leurs impacts sur le produit : voici au final les constituants de base dun Persona, travaills de manire collaborative dans un mode Agile

3.3

LA DMARCHE CRATIVELes paragraphes suivants ont pour but de clarifier le rle de la cration graphique dans un projet. En effet, la phase de cration ne consiste pas simplement mettre en couleur des lments prfabriqus pendant les spcifications fonctionnelles ou ergonomiques. La rponse graphique a un primtre plus large, qui complte et enrichit le projet grce des solutions daffichage, de prsentation ou de composition.

Conception de linterfaceLa conceptualisation de linterface est avant tout la reprsentation visuelle dun concept. Ce concept est labor par plusieurs personnes qui travaillent en collaboration. La taille de cette quipe est bien entendu variable selon la complexit du projet. Elle est constitue gnralement de :

aa aa aa

Un directeur artistique (DA) et/ou un directeur de cration (DC), Un ergonome, Un consultant fonctionnel ou, consultant mtier, dans certains cas.49

Ateliers de conceptionConception en ateliersLe concept gnral de linterface nest pas labor de manire cloisonne. Lquipe de conception sassocie au Scrum Master et au Product Owner pour travailler en ateliers. Il est galement souhaitable dassocier, lorsque cest possible, des utilisateurs finaux de loutil ou lapplication qui seront raliss. Ces ateliers sont organiss comme des runions Agiles, cest--dire que toutes les personnes prsentes sont reprsentatives de lquipe et chacune a droit la parole.

3. LE DIGITAL MARKETING AGILE

3. LE DIGITAL MARKETING AGILE

Nanmoins, cest gnralement le consultant ou lergonome qui dirige les ateliers. Ces ateliers ont 3 objectifs :

aa aa aa aa aa aa aa aa

aider concevoir le concept visuel et graphique grce au directeur artistique, orienter linterface vers les besoins utilisateurs et selon les attendus clients grce la prsence des deux reprsentants, contrler, orienter ou comprendre la faisabilit pour le Scrum Master et le Product Owner.

Ensemble, ils vont dfinir les points qui permettront de concevoir le concept et passer en revue : la comprhension mtier, les fonctionnalits, la comprhension de lutilisateur, lExprience Utilisateur attendue, les reprsentions visuelles et graphiques.

Ces ateliers, organiss trs tt dans le projet, permettent de proposer une reprsentation visuelle et graphique trs rapidement, et cela augmente le niveau de comprhension pour toute lquipe. Par exemple, durant ces ateliers, on va concevoir des Personas, donner une attention particulire une reprsentation graphique, dessiner les liens entre les actions pressenties, ou certaines interactions particulires Les points traits en atelier le sont avec un niveau de dtail variant selon la nature des projets. Ainsi, sur certains projets, les quipes peuvent tre amenes traiter des points particuliers lis la technologie (applications mobiles, interfaces tactiles...) ou des contextes particuliers (niveaux dexprience des utilisateurs, contexte dutilisation) Dans tous les cas, ils sont grs par des priorits et un niveau de complexit associ.

50

Donner des priorits et les piloterLobjectif principal est bien entendu de rpondre de manire positive lutilisateur final. Tout doit tre mis en uvre pour lui proposer une interface simple comprendre, intuitive. Il ne faut jamais perdre de vue que cette interface devra offrir lutilisateur une rponse efficace et adapte son besoin Le groupe de travail constitu pour ces ateliers est amen envisager diffrentes hypothses de reprsentation et de modlisation de linterface.

Dans un premier temps, plusieurs thmes sont abords, tels que :

aa aa aa aa aa aa

le type dinterface attendu (aspects graphiques, style), la simplification de linterface, notamment dans le cas de refontes (raccourcis envisags, simplification des tches), les interactions attendues avec lutilisateur (mthode de saisie, environnement de saisie, niveau de prcision), les impacts techniques (faisabilit).

Dans un second temps, chaque point trait est hirarchis, et des priorits sont attribues: On dtermine les priorits en fonction de tous les paramtres qui impactent le projet : dveloppements techniques, planning, budget, complexit de ralisation On hirarchise selon les mmes paramtres, et on prend en compte la faisabilit, les risques sur les innovations, et tous les points particuliers lis aux contraintes graphiques.

Une fois cette tape termine, la conception des cinmatiques et les travaux de cration graphique lis lergonomie peuvent dbuter.

Dcomposer en cinmatiquesOn distingue 3 types de composants ergonomiques pour lesquels la cration graphique va tre reprsente. Du plus dtaill au plus gnral :

aa aa aa

une tche : cest une action utilisateur, compose dune ou plusieurs actions simples, permettant daccomplir un objectif unique, un scnariodusage (ou cas dusage) : cest un ensemble de tches dpendantes qui permettent lutilisateur datteindre un objectif identifi, une cinmatique : cest un ensemble de scnarios permettant laccomplissement de tches dans des cas dusage. Ces actions utilisateurs peuvent tre transversales et/ou interdpendantes les unes avec les aux autres. lintrieur dune cinmatique, on retrouve plusieurs scenarios, et plusieurs tches dans chacun des scnarios.51

Lobjectif de dcomposition en cinmatiques est didentifier et de rpertorier les scenarios dusage les plus importants. Le scnario est simul sur un document de story-board et sert identifier une ou des tches que lutilisateur doit accomplir. les cinmatiques peuvent intgrer un certain nombre de tches qui comportent des niveaux de priorit diffrents.N.B.

3. LE DIGITAL MARKETING AGILE

3. LE DIGITAL MARKETING AGILE

La cinmatique est matrialise par un story-board qui prsente les crans de manire filaire, sans habillage graphique (wireframe). Cette reprsentation donne des indications sur les contenus et la position des lments de la page. Une attention particulire est donne aux cinmatiques et aux scnarios qui prsentent des priorits diffrentes. Exemple: une cinmatique de saisie et denregistrement dun profil utilisateur, comporte des lments de faible niveau de complexit (les coordonnes, le nom), mais elle peut aussi comporter des tches plus complexes (interfaage avec un annuaire, vrifications diverses ) Cette tape est capitale pour la reprsentation des donnes, elle est immdiatement suivie de la ralisation de la reprsentation graphique.

Limportance davoir une vision graphiqueLa reprsentation graphique donne tous les acteurs du projet accs une reprsentation proche de la ralisation finale. Elle a de limportance :

aa aa aa aa52

pour le client, afin de valider ses hypothses et la conformit avec ses attentes, pour lutilisateur, afin danticiper la prise en main et participer lamlioration, pour lquipe de dveloppement, afin de conceptualiser le rsultat final.

Obtenir une reprsentation graphique de linterface trs tt dans le projet permet : dapporter une dimension rarement anticipe par les quipes au dpart du projet : elle cristallise des ides, des concepts, des intentions, grce la mise en forme et la reprsentation visuelle de formes, de couleurs, de styles qui seront employs. de donner un style, un aspect visuel qui aura un impact sur le niveau de qualit. Ce style pourra tre ludique ou plus technique, comporter des orientations plus textuelles, simuler ou sinspirer dinterfaces tactiles. Ce style, formalis graphiquement, est la synthse visuelle de toutes les ides qui sont issues des ateliers. de contribuer faire voluer les besoins, grce lapport dides innovantes et diffrenciatrices. de fournir des rponses visuelles des complexits fonctionnelles : une image vaut parfois mieux quun long discours !

aa aa aa

La reprsentation graphique apporte naturellement des solutions visuelles et interactives qui orientent les solutions techniques et modifient les dveloppements ou les fonctionnalits. Lassociation des interactions avec linterface est primordiale pour la ralisation dune application efficace.

Intgrer la cration graphique dans les projets Agile.La cration graphique est une tape risque dans un projet :

aa aa aa aa

risque motionnel li la qualit de la cration, risque de valider une ligne graphique non approprie, ce qui bloquera les dveloppements, difficults de ralisation des interactions complexes, difficults de mise en production de certaines solutions et les retards que cela peut engendrer.

Dans tous les cas, ce risque se matrialise souvent par une dsynchronisation entre les tches de production graphique et les tches de production technique. Avec une approche Agile, ces risques sont limits pour 3 raisons :

aa aa aa

la cration est prpare et planifie en amont du dveloppement, les tches de ralisation et de conception de la cration graphique sont dcomposes dans le backlog au mme titre que les tches de dveloppement (dfinition des priorits, indice de complexit), lintervention des quipes graphiques est itrative et permanente tout au long du dveloppement (et pas simplement au dbut).

53

Le processus de cration graphiqueCe processus comporte quatre phases qui sont pralablement prsentes au donneur dordre et aux quipes. Chacune des phases apporte un lot de rponses aux problmes de linterface et permet de progresser vers la phase dacceptation. Pour assurer la russite du projet, des compromis sont ncessaires : il faut choisir les lments raliser parmi ceux proposs. Nanmoins, il ne faut pas perdre de vue que cette approche doit permettre aussi de fournir des rponses plus facilement.

3. LE DIGITAL MARKETING AGILE

3. LE DIGITAL MARKETING AGILE

La reprsentation graphique entrane ncessairement des jugements de valeur parfois assez tranchs, il est pourtant indispensable, ce stade, de suivre le cheminement qui sera propos par le directeur artistique. Les choix dinterfaces doivent dpasser les prises de position trop motives (Jaime, je naime pas).

La dmarche de cration consiste raliser successivement :

Des pistes graphiques

Une ligne graphique

Un concept graphique

La charte graphique

Les pistes graphiquesCes pistes servent avant tout dfricher des concepts ou des ides, et ne sont pas forcement complmentaire entre elles. (On ne recompose pas une interface avec plusieurs pistes diffrentes). Elles sont matrialises par des planches de recherche sur des crans type ou des crans qui font tat du processus. Ces crans contiennent la reprsentation des objets ou des interactions envisages.

La ligne graphiqueLa ligne graphique est avant tout un choix dides, de concepts et dtats desprit plutt que rellement une des pistes prsentes initialement. Ainsi le DA ne va pas ncessairement recomposer une ligne finale par association des pistes initiales, mais plutt recomposer et enrichir une rponse en tenant compte des remarques reues.

Le concept graphique54

Avec le concept graphique, on aborde une dimension plus technique car les objets crs sont destines tre utilises par les infographistes pour produire les lments ncessaires aux dveloppements.

La charte graphiqueLa charte graphique est un document de synthse qui est finalis lissue du projet. Une charte nest par dfinie en amont, mais de manire itrative au cours du dveloppement.

Des points de contrleIl est important malgr cette dcomposition structure, de se rserver des points de contrle qui vont agir comme des garde-fous de la cration.

Conserver une interface graphique homogneLe processus itratif permet une dcomposition de la cration graphique dans le projet Agile. Cest un point positif qui facilite son intgration avec les dveloppements. Cependant cette dcomposition entrane une fragmentation de la ligne graphique et limite la vue globale de linterface. Pour cette raison, il est indispensable danticiper le rsultat final en positionnant des tapes de consolidation et dhomognisation. Ces tapes seront intgres durant toute la ralisation. On peut anticiper ces tapes de consolidation ds la premire restitution et de manire planifie, mais il est tout fait possible de se rserver des consolidations sur demande, en fonction de lavancement ou face un problme rencontr. Ce travail de consolidation de linterface graphique ne doit pas attendre lultime itration. La consolidation rgulire permettra en revanche de se replacer dans le contexte des scnarios et den vrifier la cohrence, tant du point de vue de linterface graphique, que des interactions qui en dcoulent.

Rythmer la progressionAvec le jeu des priorits et des ajustements tout au long du processus Agile, il est ncessaire de faire concider les tches du backlog avec les avances relles des dveloppements pendant litration. Les cratifs ne sont pas prsents plein temps avec lquipe de projet, les points de synchronisation cration/dveloppements techniques doivent tre positionns lors de la planification des itrations.

Des interlocuteurs graphiques qui voluent selon les projetsComme nous lavons vu dans les paragraphes prcdents, les phases amont sont prises en charge par le directeur artistique, avec pour rsultats un concept et une ligne graphique globale.Les tches de dclinaisons graphiques sont ensuite confies aux infographistes, sous le contrle du directeur artistique. Le DA reste linterlocuteur privilgi pour la partie graphique. Une fois la production graphique dmarre, il est aussi linterlocuteur qui travaille en tandem avec lergonome pour mettre au point les solutions appropries lies aux interactions ou aux reprsentations graphiques. Lorsque le projet le ncessite et notamment sur les interfaces riches, il est intressant davoir un ergonome possdant une double comptence technique et graphique pour la ralisation des dclinaisons et des interactions de linterface. La double comptence facilite les changes avec les membres de lquipe en charge du dveloppement. Exemple : dans le cas dun projet trait en Flash ou Flex, lergonome ralise linterface graphique sur la base des lments produits par les infographistes, tout en sinterfaant avec les donnes du socle technique.55

3. LE DIGITAL MARKETING AGILE

3. LE DIGITAL MARKETING AGILE

Le concept graphique impacte le design du systmeLe concept est indispensable pour bien apprhender linterface au sens large. Le concept graphique dfinit des formes, des styles, des couleurset tous les lments indispensables au bon fonctionnement des interactions entre lutilisateur et le systme. Mais bien que la reprsentation soit purement graphique, elle influence les solutions techniques. Le concept graphique ne sapplique pas en fonction de pages isoles, mais en fonction de chemins utilisateurs dans lesquels il agit, interagit et progresse.

Design dinterface et design dinteractionLa cration graphique est une reprsentation visuelle. Mais la finalit nest pas une reprsentation fige et statique. Quelle que soit la technologie ou la plate-forme choisie, ce sont bien les interactions avec lutilisateur qui prvalent. Il est donc indispensable de penser la cration graphique du systme de manire itrative, y compris au niveau de chaque tche utilisateur. En effet, une action sur la page nentrane pas forcement un enchanement vers une autre page Lutilisateur peut tre amen actionner diffrents items sur lcran pour accomplir son action. Ce sont ces tats et ces interactions que la ligne graphique devra aussi anticiper. Dautre part il est frquent que des rponses graphiques apportent des solutions dorganisation lies au fonctionnel ou la technologie et entranent des changements durant une itration. Graphistes et dveloppeurs doivent donc tre particulirement lcoute lun de lautre et ne pas hsiter faire voluer leurs tches pour servir le projet.

56

3.4

AGILIT ET EXPRIENCE UTILISATEURDes points de convergence videntsLAgilit et lExprience Utilisateur ont beaucoup de points communs, dont le plus important est le facteur humain. Autre exemple : la recherche permanente du feedback (au travers notamment des pratiques tests) mais aussi la dfense de la simplicit, sont communes aux mthodes Agiles et la dmarche ergonomique. La conception centre utilisateur peut ainsi bnficier des conditions trs favorables offertes par lAgilit (des conditions rarement prsentes dans les cycles de dveloppement traditionnels).

Ces leviers forts sur lesquels les praticiens de lExprience Utilisateur vont pouvoir asseoir leur action sont les suivants :

aa aa aa aa aa

les livraisons frquentes (toutes les deux ou trois semaines), lactivit de validation en continu, le travail collaboratif, la coopration et limplication forte des clients et utilisateurs, tout au long du projet, laccent mis sur la simplicit.

Malgr tout, Scrum et les mthodes Agiles laissent encore largement de ct les lments relevant de lingnierie des exigences, de lergonomie ou encore de lExprience Utilisateur. Ce manque incontestable peut vite se transformer en faiblesse, tant ces dimensions sont devenues cruciales pour assurer une bonne acceptation des produits par les utilisateurs finaux. Lintgration efficace des spcialistes de lExprience Utilisateur dans les projets Agile est donc aujourdhui plus que ncessaire. Celleci passe en premier lieu par :

aa aa aa

la diffusion de lExprience Utilisateur au sein de lquipe, la dfense des utilisateurs, de leur activit et de leurs buts (notamment grce la technique des Personas), un rel effort autour de lavision du produit.

Ce nouvel lan vers lExprience Utilisateur passe aussi par la dfinition de guidelines et recommandations ergonomiques, et par lutilisation doutils de prototypage lgers. Autant dlments source de valeur pour lquipe, les clients et les utilisateurs finaux.57

Vers une dmarche Agile UX Mme si leffort relatif lExprience Utilisateur se poursuit tout au long du projet, notamment au travers de laccompagnement des quipes de dveloppement et des tests utilisateurs, lessentiel de lactivit Agile UX doit senclencher ds les premires itrations. Ces premires itrations seront le moment idal pour dfinir les cibles de lapplication concevoir, avec la technique des Personas, dans le prolongement des user stories. Une fois la cible dfinie, la conception graphique et ergonomique de lapplication pourra se poursuivre au fil de leau, essentiellement autour des cinmatiques (enchanement des crans de lapplication) et dune activit de storyboarding, cest--dire le prototypage rapide des crans, dans une approche toujours plus collaborative, au plus juste, et avant tout en support du Product Owner.

3. LE DIGITAL MARKETING AGILE

3. LE DIGITAL MARKETING AGILE

Le cycle de vie Agile impose pour autant aux spcialistes de lExprience Utilisateur dadapter leur dmarche. Celle-ci va donc se faonner autour de six rgles essentielles : 1 soutenir le travail danalyse et de priorisation du reprsentant des utilisateurs ou de lquipe mtier (Product Owner), 2 faire juste ce quil faut de recherche utilisateur, de modlisation et de travail sur linterface, notamment au dbut du projet, 3 travailler sur plusieurs modes la fois : a. lanticipation et la conception du contenu des itrations futures (le plus souvent une ou deux itrations maximum), b. laccompagnement de lquipe sur le contenu, les user stories en cours, que lquipe doit livrer la fin de litration, c. le test auprs dutilisateurs finaux, par exemple du contenu de litration prcdente, livr par lquipe, 4 proposer plus de ractivit, sur le recueil et la restitution du feedback (par des tests moins formels, progressifs et adapts), 5 faire du prototypage rapide (adapt au contexte et aux destinataires, toujours au plus juste et toujours source de valeur), 6 jouer un maximum sur le volet participatif et sur la facilitation en multipliant les ateliers de travail collaboratifs.

58

Tester toujours plus lExprience UtilisateurTester, mesurer, tester encore Tester lExprience Utilisateur en permanence, cest se lancer dans une dmarche damlioration continue, et laffiner au fur et mesure du cycle projet ou du cycle de vie produit (logiciels, applications web, mobiles, sites internet). Cest ainsi sinspirer de nouvelles mthodes, comme le Guerilla Usability Testing , pour plus de feedback et de valeur. Les pages daccueil, les parcours clients et tunnels de conversion, les fiches produit, les processus mtier, le design, tout est testable, quel que soit leur degr de maturit: version oprationnelle, concepts, esquisses, pistes graphiques, prototypes haute fidlit ou mme prototypes papier Et lAgilit avec ses cycles itratifs et ses livraisons incrmentales et rgulires offre des contextes trs appropris (ex : RITE encadr) pour ces mesures ponctuelles.

Lide, dornavant, est daller au devant des utilisateurs, et des clients, et de profiter de toutes les situations dans un contexte o la mobilit gagne du terrain tant donn que les situations dusage voluent, y compris pour les applications professionnelles.

Augmenter la frquence des tests, multiplier les FeedbacksMoins de participants, moins de tches mais plus de tests en variant les techniques utilises, celles qui ncessitent des participants, sans oublier celles dites expertes (benchmark, valuations expertes, activits dexploration). Dans cette approche, on garde lesprit Agile en privilgiant les notions: Action,Juste cequilfautdeformalisme et Collaboration, notamment en passant plus de temps avec les quipes (workshops, pair designing). La Guerilla Usability se propose par exemple dinitier la dmarche de test en interne avant de sorienter trs vite vers la cible du produit en utilisant les contacts clients, lentourage, les rseaux sociaux, les mailing lists, et ou profitant de formulaires placs sur le site ou de toutes ces occasions au cours desquelles on peut croiser ses clients, comme les salons professionnels. Comment faire des tests dergonomie avec de vrais utilisateurs dans un contexte Agile ?UtiliserleRITE(Rapid Iterative Testing and Evaluation). Lideestsimple: les modifications sont effectues ds quunproblmeestdtect aveccertitudeetquelasolutionestclaire. Autrement dit, une modification peut soprer suite au passage du premier participant et tre teste, vrifie avec les suivants : une valeur relle et immdiate. Ne chez les quipes de dveloppement Microsoft (Games Studio), la mthode RITE innove dans la pratique des Tests Utilisateurs et rpond parfaitement aux exigences et la ralit des projets daujourdhui.

Des Tests Utilisateurs plus efficacesLe RITE se distingue des Tests Utilisateurs classiques sur la restitution du feedback mais aussi, et surtout, sur son traitementet sa vrification.59

Des Tests Utilisateurs moins monotonesUne srie de tests avec 8, parfois 12 ou jusqu 16 participants, sur une mme application, selon un mme protocole peut devenir lassante. La mthode RITE, en rupture avec ce modle fig, permet de se sortir dune routine dans laquelle on peut vite tomber.

Des Tests Utilisateur tout aussi validesDe la rigueur sur le choix des profils tests, un plan de test bien cadr, des scnarios de test, un protocole verbal ( Penser voix haute ), un facilitateur la mthode RITE na rien envier aux Tests Utilisateurs classiques . RITE repose sur une chelle de dcision pour qualifier les problmes rencontrs, et dterminer sils seront rsolus et tests immdiatement.

3. LE DIGITAL MARKETING AGILE

60

4LA TRANSFORMATION VERS LAGILIT

61

OUPOURQUOIETCOMMENTGNRALISERLESPRATIQUES AGILESLENSEMBLEDELENTREPRISE

4. LA TRANSFORMATION VERS LAGILIT

Pour une organisation, le fait de devenir Agile participe crer la capacit dadaptation, rapide et permanente, au contexte dans lequel elle volue. Souvent confine aux quipes techniques, voire limite aux quipes de dveloppement logiciel, la mise en uvre des valeurs et des principes Agiles doit tre tendue bien au-del de ces horizons pour apporter la valeur attendue. Fort de lexprience de projets ambitieux de transformation vers lAgilit, Valtech considre que ce type de projet doit tre envisag de faon systmique : lorganisation, les ressources humaines, la technologie, les processus de dveloppement et certains processus support sont concerns. Une fois la transformation dcide, et pour en garder lesprit et le rythme, la vision de lobjectif doit tre dfinie et porte par le bon niveau de lorganisation (sponsor). La transformation doit tre mene comme un projet (stratgie, acteurs et indicateurs). Le projet de transformation lui-mme est gouvern de faon Agile (itrations, frquents retours dexprience, solutions mergentes, etc.). Finalement, le rsultat des expriences successives est prennis et amplifi (dissmination des leons apprises, formation de coachs internes, mise en place de communauts). Au-del de la transformation des quipes de dveloppement, ce chapitre fait le point sur la transformation grande chelle dune organisation.

PETER SENGE// Extrait tarduit de langlais // The Fifth Discipline: The art and practice of the learning organization

Une organisation apprenante est une organisation qui se nourrit de la varit des expriences, des comptences et des savoirs individuels, grce une culture qui encourage les dbats, les dfis et les mises en doute, au travers dune vision commune ou dune intention partage.

62

4.1

ENJEUX ET MOTIVATIONSUn projet de transformation, quel quil soit, remet en cause des organisations, des processus, mais surtout remet en cause la faon dont les hommes et les femmes travaillent, collaborent, spanouissent et adhrent aux projets de lentreprise. Dans les transformations dampleur, la priode dincertitude et dinstabilit peut tre longue et difficile supporter : les motifs et les enjeux de la transformation doivent tre c