VALTECH Livre Blanc Agile v2 2011

TRANSITION VERS L'AGILIT
L'CHELLE D'UNE ORGANISATION
MATRISE, VALEUR, SOUPLESSE
LIVRE BLANC
TRANSITION VERS LAGILIT

LCHELLE DUNE ORGANISATION
DEUXIME EDITION - 2011
AVANT-PROPOS
Cre 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 ...
REMERCIEMENTS
Ce 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.
SOMMAIRE
SOMMAIRE
1. 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 ?
11
12 14 15
2.
LAgilit par la pratique

2.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
19
20 22 25 28 32 34 36 40 43
3.
Le marketing digital Agile

3.1. La vision du produit 3.2. Personas, vous avez dit Personas ? 3.3. La dmarche crative 3.4. Agilit et Exprience Utilisateur
45
47 48 49 56
4.
La transformation vers lAgilit

4.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
61
62 63 64 70 74
5.
Les difficults surmonter

5.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

81
82 84 86 90 97 98
7
6.
Glossaire des pratiques Agiles

6.1. Dfinitions 6.2. Abrviations
105
106 108
7.
Rfrences bibliographiques
109
SOMMAIRE
SOMMAIRE
SOMMAIRE
Table des figures
FIGURE1 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
FIGURE12 FIGURE13 FIGURE14 FIGURE15 FIGURE16
FIGURE17
FIGURE18
FIGURE19 FIGURE20 FIGURE21
Table des tableaux

TABLEAU1 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 110
9
SOMMAIRE
10
1
LES 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 :
aa
12
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 incrmental

permettant une quipe de sadapter au contexte ainsi quaux changements qui ne manquent pas de survenir au cours dun projet.
Limplication du client
dans 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 terme

qui 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 quipes

qui 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 oprationnel

13 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.
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 INTERACTIONS

plutt quau processus et aux outils
PRIORIT DONNE LA PRODUCTION DE FONCTIONS

plutt qu la documentation
PRIORIT DONNE LA COLLABORATION AVEC LE CLIENT

plutt qu la ngociation contractuelle
PRIORIT DONNE LADAPTABILIT ET LACCUEIL DVENTUELS CHANGEMENTS

plutt 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 aa
HUBERT GILLON
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
SPRINT #03 BURNDOWN

REMAINING WORKING HOURS
400 350 300 250 200 150 100 50 0

7 8 9 10 11 14 15 16 17 18 21
100
80
60
40
COMPLETED TASKS %
20
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 Owner

Workday 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
18
2
LAGILIT PAR LA PRATIQUE
19
OULERETOURDEXPRIENCEDEVALTECH
2. LAGILIT PAR LA PRATIQUE
2.1
TMOIGNAGE DUN COACH AGILE VALTECH

Agile, 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 TDR

Comme 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
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 continue

Votre 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.2
TUDE DOPPORTUNIT
Ltude 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 cours

Cette 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 lexistant

Le 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 pratiques

Les 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.
FIGURE 3
Exemple de pratiques dingnierie et de pilotage de projet(Source:Valtech)
Rdaction dun document de synthse sur les pratiques retenues

Valtech 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 BACKLOG

Le 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.
CAPABILITIES Capa. Functional Capabilities Lot 1 Quotation management (Lot 1) 1 1 1 2 2 2 C2 Date import (Lot 2) 2 2 2 2
FIGURE 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
Medium
10
F1-3
User
F1-4 F2-1 F2-2 F2-3 F2-4
User User User
Medium
10
H User User
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
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.4
TEST DRIVEN REQUIREMENT : LA SPCIFICATION PAR LEXEMPLE

Le 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 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 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 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 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 initiales

Les 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 A

TABLEAU 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 .
Transformer une affaire en convention

Laction consiste pour le responsable (matricule 0002 li laffaire A) transformer laffaire A en convention.
AFFAIRES RSULTAT Nom de lAffaire Affaire A
TABLEAU 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 A

TABLEAU 3
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 convention

30
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 A

TABLEAU 4
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 exigences

Dornavant, 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 denseignements

Pour 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.
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 RETENIR
LeTestDrivenRequirement(TDR)proposede: > centrerladescriptionetlardactiondesbesoinsutilisateurssurdes exemples, > centrerlacollaborationentrelesquipesduprojetsurla comprhensionetlenrichissementdecesexemples, > privilgierladescriptionconcrtepluttquelamodlisationdansune dmarcheTDR, > affinerladescriptiondesfonctionnalitsdefaoncollaborativetout aulongduprocessusdedveloppement, > utiliserlestableauxpaspas,suitediffrentesactionsoprateur, permetdevisualiserconcrtementleschangementsdtat successifs.Ilsfacilitentlafoislacomprhensiondufonctionnelmais galementlidentificationdesscnariidetestslespluspertinents.
32
2.5
TDD, LE DVELOPPEMENT SOUS CONTRLE

Contexte
Le 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 client
Lobjectif du client consiste amliorer la qualit et la scurit des applications sans augmenter les cots de dveloppement.
Pratiques mises en uvre

Valtech 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 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 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 apportes
Test Driven Development
Les 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 automatiss

Lquipe 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.
Bnfices obtenus
ETIENNE CHARIGNON
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 RETENIR
LamiseenuvredespratiquesAgilesdeTDDpermetde: > restermatredelacomplexitdesdveloppementsraliss, > livrerdanslestempsetlebudgetimpartis.
2.6
SUIVI ET PILOTAGE AVEC LITERATION BACKLOG

LIteration 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 cas

dutilisation),
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 (exercice
collgial 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 PROGRESS
REMAINING WORKING HOURS
350 300
100
80 250 200 150 100 20 50 0 0 60
40
COMPLETED TASKS %
AUG.
AUG.
AUG.
AUG.
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 aa
FRDRIC TRMEAU
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.
LESSENTIEL RETENIR
> LIterationBacklogapourvocationdegrercourttermelensemble destchesidentifiesetestimesparlquipedeprojetsurchaque itration.Lamiseenplacedemesurespertinentespermet,jour aprsjour,desuivrelavancementreletdepiloterleprojeten consquence.
2.7
RETOUR DEXPRIENCE SUR LA GESTION DE PROJET

Contexte
Dveloppement 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 client
Les 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.

Les 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)
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) et
Anglais-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).
Les 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 apportes
Les solutions apportes sont :
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 obtenus
Les 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,
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.8
40
RETOUR DEXPRIENCE SUR LAUTOMATISATION DES TESTS

Contexte
LAgilit 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 client
La 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.

Les 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.
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
Solution apporte
Valtech 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 de

non-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 obtenus
42
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 VALTECH

Valtech 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
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 itrations successives 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 gestion de ces anomalies a diminu pour laisser place plus de fonctions implmentes.
La 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.
44
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 augmentent nettement.
3
LE 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.
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 CRATIVE
Les 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 linterface
La 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 conception
Conception en ateliers
Le 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.
Nanmoins, cest gnralement le consultant ou lergonome qui dirige les ateliers. Ces ateliers ont 3 objectifs :
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 piloter

Lobjectif 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 cinmatiques
On 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.
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 graphique

La reprsentation graphique donne tous les acteurs du projet accs une reprsentation proche de la ralisation finale. Elle a de limportance :
aa aa aa aa
52
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 graphique

Ce 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.
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 graphiques

Ces 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 graphique
La 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 graphique
54
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 graphique
La 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 contrle

Il 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 homogne

Le 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 progression
Avec 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 projets

Comme 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
Le concept graphique impacte le design du systme

Le 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 dinteraction

La 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 UTILISATEUR

Des points de convergence vidents
LAgilit 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.
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 Utilisateur

Tester, 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 Feedbacks

Moins 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 efficaces

Le 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 monotones

Une 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 valides

De 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.
60
4
LA 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 MOTIVATIONS
Un 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 clairs et solides ! Les enjeux et les motivations de la transformation vers lAgilit sont particuliers chaque entreprise, ils sont tablis sur la base dlments objectifs (parts de march, rductions de cots, meilleure ractivit, qualit des applications) et subjectifs (satisfaction des clients, qualit des relations dans les quipes, par exemple).
un niveau de dtail plus fin, on citera par exemple :
aa aa aa aa aa
rduire le dlai entre lexpression dune demande et la mise disposition de la solution, augmenter la qualit des applications, afin de matriser la charge de maintenance et de support, limiter les allers-retours entre la matrise douvrage et la matrise duvre loccasion des tests de validation, rendre lavancement des projets plus visible pour les directions oprationnelles en particulier, afin dadapter les documentations techniques produites aux besoins rels, pour contenir les cots et les dlais, faciliter les modifications de planning et de primtre de livraison, en cas denvironnement trs mouvant (produit innovant, besoins instables).
4.2
LE PROJET DE TRANSFORMATION
Une transformation Agile est avant tout un projet de conduite du changement, dont les ingrdients peuvent tre identifis comme :
aa aa aa aa aa aa
unevision (ambition, objectifs, horizon temporel, primtre, stratgie de changement), unetrajectoire (connaissance de ltat actuel, tapes intermdiaires, cible), unsponsor (de prfrence au plus haut niveau de lorganisation), unequipepluridisciplinaire (pour la conduite et limplmentation du changement), desmoyens (budget, infrastructure), unpilotage (progrs de la transformation, valuation des effets par rapport aux objectifs).
63
CADRAGE
DFINIR LE PROJET
RECUEILLIR DES MOTIVATIONS CLARIFIER LES OBJECTIFS DVELOPPER LA VISION SLECTIONNER LE PRIMTRE IDENTIFIER LES MOYENS CHOISIR LA DMARCHE FIXER LES PRIORITS
PILOTE
EXPRIMENTER
SLECTIONNER LES PROJETS ET ACTEURS RALISER LES PILOTES ANALYSER LES RETOURS DEXPRIENCE ... ET AJUSTER LA DFINITION DU PROJET
DPLOIEMENT ET OPTIMISATION EN CONTINU

TRANSFORMER
PLANIFIER LE DPLOIEMENT STRUCTURER ET DPLOYER LES PROCESSUS ET LES MOYENS (PILOTAGE, FORMATION, SUPPORT, OUTILS, ETC.) RALISER LES PROJETS ANALYSER LES RETOURS DEXPRIENCE PARTAGER LES EXPRIENCES GRER LES ATTENTES ET LES RSISTANCES OPTIMISER LES PROCESSUS, LES MOYENS ET LES OUTILS
FIGURE 11
Les tapes dune transformation Agile (Source:Valtech)
4.3
DFINIR LE PROJET : LE CADRAGE

Dans les approches Agiles, la dfinition dun projet est porte par le Product Owner. Par similarit, le projet de transformation doit tre port par un sponsor, assist dautant dexperts de terrain que ncessaire pour dfinir un projet ambitieux, raliste et viable parce quaccept et comprhensible par toutes les parties prenantes.
Le cadrage du projet de transformation vers lAgilit est une activit stratgique. Il est port par la direction qui en est le sponsor. Valtech prconise une approche combine et concurrente en top-down et bottom-up.
Dvelopper la vision
La vision labore durant le cadrage doit rpondre aux interrogations suivantes 2:
INTERROGATIONS Le sponsor a-t-il le pouvoir de porter le changement ? Les managers sont-ils capables dimpulser le changement ? LMENTS DE RPONSE Le sponsor doit tre conscient de lensemble des enjeux. Un sponsor membre de la direction gnrale est un facteur de succs. Sil nen nest pas directement dtenteur, le sponsor doit au moins avoir la possibilit dintervenir sur le budget associ au projet de transformation. Les managers doivent tre les premiers convaincus, ils doivent : organiser des sminaires dinformation, tre forms aux nouvelles techniques de management. Lanalyse de la chane de valeur (analyse des processus) est un bon outil pour cerner le primtre souhaitable. La transformation concerne les processus de travail, mais galement lorganisation : il est en effet souvent ncessaire de remettre en cause les silos organisationnels constitus. Raliser une tude dcart entre le niveau actuel de comptence des quipes en place et la cible, du point de vue managrial, fonctionnel et technique. Rechercher les rsistances auprs des personnes. Une transformation est une priode dinstabilit qui suscite toujours des craintes et des rsistances (perte de qualification, changement de rle et de responsabilits, etc.) Communiquer largement et au plus tt sur les objectifs, qui ne doivent pas uniquement tre financiers ! Assurment le plus collaboratif possible : le changement est bas sur un certain volontariat au dbut (phase pilote), avant dtre tendu ventuellement de faon impose si ncessaire. Un dploiement en big-bang est difficilement envisageable. Valtech propose de raliser le dploiement selon un cycle itratif, dans un esprit damliorationcontinue. A lchelle de la transformation, on dfinit quelques jalons par an (par exemple trimestriellement) la fin desquels une rtrospective globale permet de faire le point sur les progrs raliss et les points de blocage lever.
Quel est le degr de changement souhaitable, raliste ?
64
Quelles sont les connaissances et les comptences disponibles et celles acqurir ?
Quelles sont les rsistances et les contraintes ?
Quel style de conduite du changement adopter ?
Quelle est la dmarche adopter ?
2.
Daprs Balogun et Hope Hailey 1998
Quels sont les critres de russite ou dchec ? Comment maintenir la dynamique de transformation dans le temps ?
TABLEAU 6
Ces critres sont directement issus des enjeux et des objectifs formuls ; le dveloppement de la vision doit aboutir la quantification de ces critres. Capitaliser les leons apprises durant les projets et partager les expriences en organisant des communauts internes. Impliquer fortement les organisations transverses (mthodes et outils, QA, PMO) qui deviennent, terme, les promoteurs du changement.
Dveloppement de la vision (SourceValtech)
La vision dtermine ltat atteindre en fin de projet, mais galement des tats intermdiaires (court, moyen et long terme) qui permettent de mesurer les progrs durant tout le dploiement.
Identifier le primtre
Envisager la transformation vers lAgilit de manire systmique
Marketing
Autres quipes support
Client Utilisateurs
PMO
EQUIPE PROJET
Exploitation
Ressources humaines Mthodes et outils Soustraitants
Help Desk
65
Achats
FIGURE 11
Une quipe de projet en relation avec son cosystme (SourceValtech)
Une quipe de projet de dveloppement logiciel ne travaille pas isolment du reste de lentreprise et de son environnement : les clients, les utilisateurs, le matre douvrage, les sous-traitants ventuels sont parties prenantes du projet. Ds lors, cet environnement est affect par le rythmeitratifduprojet, et par la ncessitderelationsdecollaboration plus troites. Lapproche Lean propose doptimiser le systme globalement, et ce nest pas sans raison !
Pourtreefficiente,unetransformationverslAgilitdoitdpasser lecadredelquipededveloppementetstendrelacration duncosystmeAgile.
Lapproche systmique est intimidante et parat hors de porte. Lexprience montre cependant que lon arrive trs vite aux frontires de lquipe projet. Nous avons constat de nombreuses reprises que la volont de participer au changement de la part des personnes relevant des organisations priphriques tait plus forte que prvu.
PATRICK LE GO
// Expert et coach Agile // Valtech
QUI ?
LES CHANGEMENTS MAJEURS
BNFICES
RISQUES, FREINS ET CONTRAINTES Les anciens chefs de projet ont du mal sadapter au partage du pouvoir de dcision. Il est initialement compliqu pour les quipes de sadapter au rythme itratif, surtout si les itrations sont courtes Les dveloppeurs voient comme une suspicion dincomptence le fait de devoir crire dabord les tests, tout en assurant, en plus, une couverture trs importante
Dveloppement itratif et livraisons incrmentales
Motivation porte par les retours des clients et des utilisateurs
quipe projet
Dveloppement orient par les tests
Organisation perue comme moins procdurire, offrant plus dimagination et de libert daction La qualit est sous contrle permanent
Auto-organisation Collaboration et esprit dquipe fort
66
Contractualisation Agile Rle de Product Owner : participation au planning ditration, dmonstration et rtrospective ditration Exigences formalises tout au long du projet (au lieu dun cahier des charges initialement complet)
Lvolutivit des besoins est prise en compte
Ncessite plus de disponibilit
Meilleure visibilit sur lavancement
Remise en cause du forfait classique cot, dlai et primtre figs
Client (Product Owner)
Possibilit offerte dintervention sur la planification (priorits, mise en production)
Difficult trouver le bon Product Owner
Qualit et adquation aux besoins
Tentation de la perfection : il faut savoir finir le projet : le client doit apprendre raisonner en termes de valeur livre, plutt quen liste de fonctions fournies
Rduction de la phase davant-projet
QUI ?
LES CHANGEMENTS MAJEURS Revues frquentes
BNFICES
RISQUES, FREINS ET CONTRAINTES
Utilisateur
Dploiement incrmental (optionnel)
Mise disposition de fonctionnalits plus tt que dans un projet classique
Ncessite plus de disponibilit.
Prproduction et Exploitation
Validation incrmentale intervalles rguliers
Mises en production plus frquentes. Obligation de plus de transparence sur lavancement, sur les difficults rencontres. La visibilit est donne au moins chaque itration. Signature de contrats Agiles Passage dun processus linaire bas sur des livraisons de documents, un processus itratif et incrmental, bas sur des livraisons de code oprationnel. Acquisition et dploiement de nouveaux outils pour lenvironnement de dveloppement et le suivi de projet
Meilleure visibilit sur les dveloppements, anticipation plus aise des adaptations des environnements
Ncessite la disponibilit rcurrente (potentiellement chaque itration) des quipes et des environnements. La planification des activits est trs dpendante des projets.
Soustraitants
Limitation des erreurs et dfauts constats tardivement, ce qui rduit les risques pour le sous-traitant. Moins de ngociations contractuelles en cours de projet, ce qui rduit les tensions entre les parties.
Lobligation de transparence est souvent antagoniste des pratiques des projets au forfait
Mthodes etoutils
Modernisation des approches et outils.
Un des risques est de construire un nouveau standard dtaill et rigide, et doublier les aspects essentiels que sont lamlioration et ladaptation continue.
67
La ngociation sur un volume de fonctionnalits (mesur en points) est plus simple que la ngociation sur une liste de fonctions. Les contrats Agiles gagnantgagnant apparaissent moins protecteurs que les contrats au forfait. Il est inhabituel de sengager sur un contrat pour lequel le primtre fonctionnel est reconnu variable.
Achats
Modification de la forme et de lesprit des contrats.
Ressources humaines
Redfinition des missions, nouvelles descriptions de postes, prise en compte des changements organisationnels, modification des principes de rmunration variable, etc.
Alignement clair des dfinitions de rle sur les missions des intervenants Agiles. Le rle oprationnel du management intermdiaire est amplifi.
La priode de transition peut tre complexe grer, les quipes Agiles et non encore Agiles tant soumises des rgimes diffrents.
QUI ?
LES CHANGEMENTS MAJEURS Abandon du contrle davancement sur les phases classiques (spcification, conception, dveloppement, tests) au profit dun suivi par fonctions livres, adaptation des tableaux de bord de suivi de projet. Gestion Agile du portefeuille de projet avec utilisation de KANBAN 3
BNFICES
RISQUES, FREINS ET CONTRAINTES
Participe la ractivit de lorganisation (gestion de portefeuille). Le changement de mthodes de travail et des repres classiques est dstabilisant. Le temps dadaptation aux nouveaux indicateurs et aux outils, peut tre consquent.
PMO
Meilleure implication dans les projets, et rapprochement avec les besoins des clients/utilisateurs. La qualit est ladquation aux attentes du client plutt que la conformit au cahier des charges : les comptes-rendus de dmonstration deviennent un lment cl. Prise en compte de nouveaux indicateurs, issus de lusine de dveloppement logiciel
TABLEAU 7
Assurance Qualit
Meilleure implication dans les projets, le rle du QA est revaloris.
Ncessite la remise en cause des savoir-faire
Lassurance qualit devient plus technique que la seule vrification de documents.
Les cls de la transformation Agile(SourceValtech)
68
Identifier les moyens 3

En dehors des moyens organisationnels ddis au projet de transformation (sponsor global qui porte la vision, pilote le projet de transformation, planifie le dploiement et en value les progrs et les rsultats), la transformation Agile ncessite un accompagnement par des experts qui permettent de dpasser rapidement le stade du faire Agile pour parvenir au stade du tre Agile .
3.
Visuellement, un KANBAN se prsente comme un tableau qui porte en colonnes les tapes dun processus (par exemple tude dopportunit, pr-tude, dveloppement, qualification, dploiement), et pour chaque tape le nombre maximum de tches que lon peut raliser en parallle (en fonction de la capacit des quipes). Chaque item (ici un projet) est matrialis par une carte que lon dplace dune colonne lautre ds quune tape est franchie.
Ces experts, gnralement externes, ont pour vocation intervenir :
aa aa aa aa aa aa aa aa aa aa
auprs du sponsor, pour la mise au point de la vision et la qualification des objectifs gnraux, auprs de la directioninformatique, et autres directions fonctionnelles (directions mtier, marketing, achats, etc.), pour la quantification des moyens, la planification du dploiement, le choix des moyens daction, les rorganisations potentielles, auprs des niveauxdemanagement intermdiaires (responsables dquipe, de dpartement), pour faciliter leur transition vers les nouvelles modalits de suivi et les nouvelles modalits daction (meneur-facilitateur au lieu de dcideur-gestionnaire), auprs des quipesdedveloppement, ils sont en charge de la transformation sur les aspects processus et sur les pratiques de planification, destimation, de suivi davancement et de communication au sein de lquipe, auprs des quipesdedveloppement, pour la mise en uvre des pratiques techniques telles que les tests unitaires, la spcification par les tests, lintgration en continu, auprs du responsabledeproduit (Product Owner) et des utilisateurs, pour les accompagner dans leurs nouveaux rles et faciliter la communication et la collaboration avec les quipes de dveloppement, auprs des entitsresponsables des processus support (mthodes et outils, production), pour faciliter les transformations ncessaires.
Des moyens internes doivent galement tre mobiliss pour amplifier et prenniser la transformation : des championslocaux sont recruts sur la base du volontariat, pour entraner les projets pilotes. Ce sont des oprationnels qui ont la fibre Agile, une exprience pralable et qui souhaitent participer activement la transformation des communautsAgiles, constitues dacteurs en provenance des diverses organisations. Lobjectif des communauts est de recueillir et formaliser les expriences ralises par les diffrents projets, en extraire les meilleures pratiques, partager les observations et rsultats et ventuellement proposer de nouveaux axes damlioration. des coachsAgilesinternes, forms par exemple loccasion des premiers projets par les coachs externes, ils ont vocation amplifier le mouvement de transformation. Leur connaissance intime de lentreprise est un atout mais ils doivent avoir la capacit de remettre en cause les processus tablis !
69
Comme pour tout programme de transformation, la communication est un lment essentiel toutes les tapes. Le sponsor global et les sponsors locaux sont responsables de la communication de cet aspect.
Acqurir les savoir-faire par les apports de formateurs, coachs etmentorsexternes,etpartagerlessuccsetleschecspardes communautsinternespouramplifierlatransformation.
4.4
EXPERIMENTER : LE PILOTE
La dclinaison rapide du changement au niveau oprationnel, pour le rendre palpable est essentielle : ltape pilote doit dmarrer assez rapidement, mme si tous les dtails dimplmentation ne sont pas connus. La ralisation des projets pilotes est ncessairement une priode daccompagnement fort et de mutations progressives : il faut exprimenter, adapter les solutions, vaincre les rsistances, recueillir les rsultats. La priode pilote est loccasion de mettre en place les structures de relais internes (communauts, sponsors locaux) et les moyens ddis (wiki, forum, sminaires priodiques) pour le partage des expriences et la propagation des nouveaux savoir-faire. Ltape pilote permet de dtecter concrtement les apports positifs et les difficults dues lorganisation et aux processus en place, ces informations sont utilises pour affiner le plan projet (quel processus ou organisation modifier en premier lieu, comment) La phase pilote stend sur quelques mois, et peut concerner plusieurs projets de dveloppement.
70
Slection des projets pilotes et conditions de lancement

La slection des projets pilotes et des quipes de ralisation de ces projets doit favoriser la russite de lexprimentation, et tre reprsentative de la ralit de lactivit de lorganisation. Les critres de slection incluent :
CRITRE Le sponsor est rellement impliqu et disponible, il facilite la mise disposition des moyens Le Product Owner est rellement impliqu et disponible, il a la capacit de dfinir le produit dvelopper Le Scrum Master et les membres de lquipe sont motivs pour devenir Agiles , leur niveau de sniorit est suffisant pour valoriser lexprience COMMENTAIRES Le sponsor de lAgilit est une pice matresse de la transformation Le Product Owner est un rle difficile tenir, mais il est une pice matresse pour la russite du projet Durant la transformation, lquipe peut passer par des phases de doute et dchecs. La motivation est essentielle (cycle de Kubler-Ross) Obligatoire
Obligatoire
Obligatoire
CRITRE Le projet se prte une ralisation en itrations courtes (les fonctions peuvent tre dcoupes de faon tenir dans une itration, les dmonstrations sont significatives) Les conditions de lancement sont runies : le projet dmarre en mme temps que les activits de coaching une quipe pluridisciplinaire est constitue lenvironnement matriel est en place leffort de monte en comptence est inclus dans le budget du projet
COMMENTAIRES La capacit obtenir un retour rapide et frquent est une des cls du dveloppement Agile.
Obligatoire
La synchronisation du projet et de la transformation Agile vite un grand nombre de rsistances, et vite de perturber un projet qui aurait t lanc pralablement.
Obligatoire
Les contraintes lies lorganisation et lenvironnement sont limites.
Commencer les premiers pilotes en environnement simple (pas de soustraitance, quipe localise, pas de dpendance avec dautres projets), et complexifier progressivement durant lapprentissage Le niveau dimplication du Product Owner est li la valeur mtier apporte par le projet. La pression de lapprentissage en sus de la pression sur le projet peut conduire lquipe abandonner lexprience en cours de route Favoriser les projets de dveloppement, plus adapts une adoption Agile by the book Loutillage de la plateforme de dveloppement est en partie dpendant du langage (Java, C#, C++, etc.) Dure idale comprise entre 3 et 9 mois (pour obtenir des conclusions assez rapidement) quipe idale entre 5 et 10 personnes
Variable
Le projet pilote apporte une relle valeur mtier.
Important
Les risques4 du projet sont assez limits (dlais, qualit, budget, etc.) Le type de projet est reprsentatif (nouveau dveloppement, intgration, maintenance, dveloppement de services ou de composants) Les primtres fonctionnel et technique sont reprsentatifs.
Important
Important
Important
Le dimensionnement du projet est adapt (dure, effort)
Important
71
TABLEAU 8
Critres de slection dun projet pilote (SourceValtech)
La transformation dune quipe de projet en quipe Agile

54
PATRICK LE GO
// Expert et coach Agile // Valtech
Une des cls de la russite de la transformation Agile, lchelle dune quipe de projet, est de laisser lopportunit et le temps aux personnes qui la composent dexprimenter et dapprivoiser ltat desprit Agile. La recherche damliorations rapides ds la premire itration est absolument nfaste moyen et long terme.
4. noter quun fort niveau de risque est souvent prsent comme un discriminant absolu et rdhibitoire. Il faut cependant remarquer quune partie des risques classiques sont traits directement par les pratiques Agiles. A mditer ?
Schmatiquement, la transformation se droule selon les tapes suivantes :
FORMATION INITIALE
LES VALEURS
Scrum et pilotage Agile
TRANSFORMATION
LES PRATIQUES
Introduction progressive de pratiques dingnierie Evaluation rgulire de la maturit (GIPS) Pilotage du coaching par la maintenance dun backlog de transformation Coaching dquipe et transformation de lenvironnement selon les besoins
CONCLUSIONS
ANALYSE
Retrospective Partage des rsultats
INTENSIT DE LACCOMPAGNEMENT
MATURIT DE LQUIPE
dbutante
oprationnelle
autonome
ITRATIONS
FIGURE 13
...
...
...
Laccompagnement dans la transformation Agile(SourceValtech)
Il est essentiel que tous les acteurs du projet participent ensemble la formation initiale pour assurer que les valeurs et principes soient connus et partags par tous5; en intra-entreprise, ces sessions sont, en outre, riches dchanges sur les modes de fonctionnement courants, et les pistes de transformation commencent y tre labores avec lensemble des parties prenantes.
Le dispositif daccompagnement pour un projet 66

INTERVENTION Formation initiale Agile PUBLIC VIS Tous participants la transformation DURE ET RYTHME 2 jours par session de formation, en dbut de transformation Quelques journes dintervention par quipe au cours de la transformation 2 4 mois (au minimum 4 itrations) avec un niveau dintervention qui diminue au fil du temps (80% -> 10%) SUJETS TRAITS Valeurs et principes de lAgilit, concepts et pratiques du pilotage Agile de projet Intgration continue, dveloppement pilot par les tests (TDD), exigences excutables (TDR)6 Mise en place de lAgilit au sein dun projet : ltat desprit Agile , itrations, planification, estimation, indicateurs et tableaux de bord, qualit, etc. Dveloppement de spcifications Agiles (user stories), gestion du backlog, crmonies Scrum
72
Pratiques dingnierie Agile
Programmeurs, concepteurs, testeurs Scrum Master
Coaching dquipe de dveloppement
Dveloppeurs, testeurs, analystes, concepteurs, etc.
Coaching de Product Owner
Product Owner
1 2 mois, raison de quelques jours par itration
TABLEAU 9 5. 6.
Dispositif daccompagnement pour un projet (SourceValtech)
Voir le Manifesto Agile La connaissance des pratiques dingnierie est prfrentiellement transmise par lexemple pendant le dveloppement du projet (coding dojos, mentoring)
lchelle dun projet pilote, la dmarche de transformation est pilote de faon Agile : au dmarrage de la transformation, puis la suite de chaque rtrospective ditration, lquipe et le coach tablissent un backlog de transformation qui a toutes les caractristiques dun backlog de projet (les items sont estims, dcomposs si ncessaire, prioriss, transforms en tches). Pour faciliter la dmarche, les itrations de transformation sont calques sur celles du projet lui-mme. Pour mesurer la progression et la maturit de lquipe, Valtech a dvelopp son propre GPS quipe Agile qui reprsente le niveau dacquisition des pratiques et techniques Agiles, au moyen de plus de 200 points de mesure, regroups en 40 pratiques essentielles et projets sur 7 dimensions. Lordre dans lequel les pratiques sont introduites est variable car dpendant des besoins de lquipe et du projet. Le scnario suivant non exhaustif est une base de travail.
Collaborating
100
Releasing
80 60 40 20 0
Planning
Testing
Defining
Developing
Tracking
ADOPTION EVALUATION - 24/09 ADOPTION EVALUATION - 29/07 ADOPTION EVALUATION - 10/07

FIGURE 14
Fundamental maturity Functionnal maturity Fluid maturity
25-45 % 60-75 % 80-95 %
Mesure de maturit Agile (SourceValtech)
ORGANISATION
ENVIRONNEMENT
GESTION DE PROJET
INGNIERIE
quipe
pluridisciplinaire lquipe assigns 100% au projet est co-localise
Gestion de projet
visuelle (tableau blanc) configuration logicielle continue
Gestion du backlog de
produit
Histoires utilisateur et
critres dacceptation (user story cards) automatiss (refactoring) binme
Membres de
Gestion de la
Estimations relatives de release Plan Dfinition de done

et done done quotidiennes
73
Tests unitaires Remaniement du code Programmation en Standards de code Tests fonctionnels

automatiss automatis
Idalement, lquipe Participation du

responsable de produit (Product Owner)
Serveur dintgration Outils collaboratifs

(par exemple wiki)
Runions
Planning ditration Dmonstration Rtrospective Indicateurs :

burndown ditration, vlocit, release burnup, prdictibilit, suivi de la dette technique
Outillage de
reporting et de suivi davancement
Dploiement
TABLEAU 10
Ordre dintroduction des pratiques Agiles (SourceValtech)
4.5
TRANSFORMER : DPLOIEMENT ET OPTIMISATION EN CONTINU

Le dploiement grande chelle des pratiques Agiles est source potentielle de nombreuses transformations dans lentreprise. Nous abordons ici celles considres communment comme ncessaires.
Stratgie et organisation
La stratgie de dploiement vise construire progressivement des ensembles cohrents de plus en plus grands. La construction dcosystmes Agiles locaux (par dpartement, par ligne de produit, par zone gographique, par type de produit ou de technologie, etc.) favorise entre autres :
aa aa aa
une gestion Agile des responsabilits des personnes limitation de laffectation dune personne de multiples projets en parallle, constitution dquipes durables, une gestion Agile du portefeuille de projets, un retour dinvestissement rapide sur le cot de la transformation application directe de pratiques exprimentes dans le mme contexte.
ECOSYSTME AGILE / LEAN

ENVIRONNEMENT
Contrats Agile, optimisation de la relation Cross-fertilisation possible avec les partenaires Risques de rsistance de l'environnement externe
ENTREPRISE
74
OPTIMISATION GLOBALE
Facilitation par les nouveaux processus et l'organisation Vritable vision client Risque de re-normalisation trop forte des pratiques
LIGNE DE PRODUIT OU DEPARTEMENT
OPTIMISATION PARTIELLE
Partage de pratiques Meilleure gestion des ressources et du portfolio Mise en commun d'environnements techniques
PROJET
" Conflits " visibles avec les organisations transverses
OPTIMISATION LOCALE
Qualit, dlai l'chelle du projet Les succs permettent l'extension Potentiellement, des contraintes dues l'environnement
FIGURE 15
Le plan de dploiement (SourceValtech)
Le plan de dploiement est labor pour rpondre aux enjeux identifis lors du cadrage, et sappuie sur le contenu du portefeuille de projets pour slectionner les projets candidats prioritaires.
Le plan de dploiement tient galement compte de facteurs dterminants :
aa aa aa
la disponibilit des personnes mobilisables (quipe de support en formation, coaching, mentoring, mise en place des environnements techniques adquats), le temps ncessaire lapprentissage par les quipes de projet (3 6 mois pour les pratiques de dveloppement Agiles et de gestion de projet), le temps ncessaire ladaptation des processus et de lorganisation.
Enfin, le plan de dploiement doit tre revisit et mis jour priodiquement, par exemple sur une base trimestrielle.
Le dispositif daccompagnement pour la gnralisation

Le tableau ci-dessous rassemble les principales interventions identifies par Valtech dans des contextes varis ; les interventions, dans leur dtail (contenu, rythme, dure) sont trs dpendantes du niveau de service attendu, de la taille et de la complexit des organisations, et de lexprience pralable des personnes en place 7.
INTERVENTION PUBLIC VIS Sponsor, Pilotage de la transformation Responsables de domaines fonctionnels ou techniques, DSI ou dpartement R&D, Dpartements support Formation de coach interne ( Coach the coach ) Techniques de coaching Futurs coachs internes Approfondissement des pratiques Agiles Gestion du dploiement Agile Organisation dquipe (rduction des silos, quipes pluridisciplinaires, quipes durables) Management intermdiaire Pilotage de lactivit (indicateurs de performance) Rle du manager entraneur-facilitateur PMO, Coaching pour la gestion de portefeuille de projets Coaching et mise en place de pratiques
TABLEAU 11
SUJETS TRAITS tablissement de la vision Plan de dploiement Suivi du dploiement
75
Coaching de responsable dquipe
Gestion dun backlog de projets Mise en place de KANBAN Suivi et indicateurs davancement, tableaux de bord
Responsables dquipes
Responsables et oprationnels
Le reste de lcosystme
Dispositif daccompagnement (SourceValtech)
7.
Il est souvent bnfique de complter ce dispositif par des interventions de type coaching personnel pour faciliter la transition de manager gestionnaire en leader facilitateur
Agir sur lorganisation et sur les processus

Parmi les actions qui contribuent le plus significativement la russite dun programme dadoption de lAgilit, on peut citer :
aa
Larductiondessilosorganisationnelsauseindesquipestechniques (DSI,R&D). Une organisation en silos calqus sur le cycle en V est frquemment rencontre : des quipes de dveloppement sont soutenues par des architectes provenant dun autre dpartement, les rsultats tant tests par des ingnieurs en provenance dun troisime dpartement. Dans ce cas, chaque dpartement gre ses personnels et les alloue temporairement aux projets en fonction des besoins et surtout des disponibilits ! Ladoption des principes Agiles conduit considrer les silos comme autant de freins la communication directe, la poursuite dobjectifs partags, la mise en place dun planning favorisant la livraison au plus tt des fonctions.
>a Crerdesquipespluridisciplinairesintgres,co-localisesetstables
toutaulongduprojet
aa
LagestionAgileouleanduportefeuilledeprojets. Augmenter la valeur cre par les quipes de dveloppement tient entre autres deux facteurs :
a la priorisation des projets en fonction de leur valeur mtier. Les clients

doivent participer intensivement la priorisation du portefeuille de projets.
a La rduction du nombre de projets mens en parallle pour viter que les

ressources passent en permanence dun contexte de projet un autre. changementsdecontexte
>a Prioriserlesprojetsparlavaleurmtier,rduirelecotliaux
76
aa
Latransformationdurledemanagergestionnaireenleaderfacilitateur. Un des objectifs frquemment assign aux responsables dquipes est den optimiser le taux dutilisation. Dans le rle du facilitateur, le manager a pour objectif doptimiser la valeur cre. Dans ce cadre, le manager devient un point descalade lorsque lquipe rencontre des difficults, et son rle est dliminer ces difficults pour favoriser la production de lquipe.
>a Lesmanagersdeviennentdesacteursdelaproductiondevaleur,aulieu
dentredesgestionnaires
aa
LamiseenplacedecommunautsAgiles. Les communauts sont un vecteur organis pour assurer la mise en commun des pratiques, des questions et interrogations, des checs et russites des projets. Selon la taille de lorganisation, des communauts locales seront installes (par dpartement, localisation, ligne de produit, etc.) avec une communaut globale dont le but est de faire la synthse des ides.
>a Unecommunautestunlieudchangeetdegnrationdides.Elle
acclrelatransformation.
aa
Ladaptationdesprocessusetdelorganisation de lcosystme au rythme et lesprit des principes Agiles
a Lavalidation,laproduction : adapter lorganisation et la disponibilit
des environnements aux livraisons frquentes. Cela peut constituer un vritable changement, quand on constate que les environnements de validation sont trs souvent partags entre plusieurs projets concurrents (ils doivent tre rservs pour des crneaux fixes et dtermins longtemps lavance), et quil est courant que les quipes de production soient loignes du dveloppement.
a Lasous-traitance,contractualisation: les principes Agiles prennent
tout leur sens dans le contexte de projets o lincertitude et la variabilit rgnent. Dans ce contexte, les relations contractuelles et oprationnelles doivent tre adaptes pour permettre de la souplesse (contractualisation Agile), et pour assurer le bon niveau de transparence sur lavancement et les points de blocage : les contrats au forfait pur ne sont plus adapts ces exigences.
a Mthodesetoutils : le corpus mthodologique existant bas sur une
dmarche en cascade doit tre abandonn au profit de la culture Agile. Un objectif majeur est de concevoir un rfrentiel mthodologique simple, lger et flexible, de ne normaliser que ce qui est ncessaire, et de rvaluer les pratiques en permanence.
a Lacellulequalit,lvaluationdelaqualit : dans le mme temps le
rfrentiel mthodologique volue, lvaluation de la qualit passe du contrle de ladquation au processus (le projet suit-il les phases du cycle en V, la documentation est elle conforme au standard ?) et du contrle de ladquation aux exigences (le projet a-t-il fourni les fonctions telles que spcifies ?), une valuation de la qualit du service rendu (les fonctions fournies sont elles acceptes par le responsable du produit, sont-elles toutes utiles, nen manque-t-il pas dessentielles ?).
77
a Ressourceshumaines,valuationdelaperformance : alors que les
pratiques Agiles encouragent et ncessitent une approche collaborative, collective, les systmes de gestion de la performance des membres des projets sont souvent individualistes8. Ce domaine trs sensible il conduit au final dterminer le niveau de rmunration ou lavancement des personnes doit tre revu pour introduire des indicateurs de performance collective bass sur des critres tels que le nombre de fonctionnalits livres, la valeur mtier livre, ou des critres Agiles tels que la vlocit, ou la prdictibilit de lquipe
>a Creruncosystmeadaptestlepassageobligpourunretoursur
investissementsignificatif
8. Nous avons rencontrs des cas o la performance est mesure en nombre de lignes de codes produites, en nombre de dfauts dtects ou autres mesures, certes relativement simples acqurir, mais dont la valeur relle est trs faible !
Adapter linfrastructure et les environnements de travail

La plate-forme technique de dveloppement est un sujet essentiel, mais ce point ne sera pas dtaill ici car la littrature abonde de descriptions de ce quest un environnement de dveloppement Agile. Par contre, la ncessit damplifier la collaboration entre les membres dun projet apporte des changements notoires du cot des outils non techniques. Dans le cas dun projet dune demi-douzaine de participants, travaillant sur le mme site, avec un Product Owner proche et disponible, la conversation face face, lutilisation de Post-it et de schmas sur des tableaux muraux seront suffisants pour assurer la communication. En environnement distribu, avec une quipe plus importante il devient absolument ncessaire de disposer des outils qui vont fluidifier et scuriser les flux dinformation, et tenter de produire une certaine illusion de localit . Audel des systmes de mails ou de messagerie instantane (linformation nest pas toujours partage, les fils dinformation ne sont pas structurs ni archivs), une plate-forme collaborative doit tre installe. A minima, une telle plate-forme comprend des outils de partage/stockage de documents et informations digitales :
Rpertoirespartags, outils de gestion et de partage de contenu Sharepoint, documents Google.

78
Outilsdestockage et de structuration dinformations et de documents tels que les Wiki, forums, FAQ.
Outillagencessaire lagestionAgile duprojet (backlog, estimations et reste faire, iteration burndown, release burnup, vlocit, etc.). Loffre est aujourdhui trs toffe.
Pour remplacer les discussions en face--face, les outilsdetlcommunication sont amens voluer :
TlphoniesurIP, Skype (pour contenir les cots !)
Visioconfrence, ventuellement base de webcams, outils de confrence sur le Web (tel que Microsoft Office Live Meeting)
valuer les progrs et les rsultats

La transformation est value sur deux plans. Le premier plan est une mesure des progrs du dploiement ; le second plan est une mesure des effets de la transformation.
valuer lavancement du projet de transformation

Lapprciation de lavancement du projet de transformation est, par exemple, simplement ralise par comptage en nombre de projets ou dquipes, et par une cartographie des dpartements ou lignes de produits qui ont adopt lAgilit. Ensuite, des donnes plus subjectives sont recueillies par enqute auprs des diffrents intervenants des projets pour avoir leur perception des effets de la transformation : moral des quipes, perception du niveau de reconnaissance, apprciation sur les nouvelles conditions de travail. Enfin, si des communauts ont t mises en place, leur activit doit tre apprcie pour sassurer de leur utilit et du bon fonctionnement du dispositif : frquence des runions, assiduit, rsultats produits, qualit de la communication, etc.
Mesurer les effets de ladoption de la dmarche et des pratiques Agiles

Les rsultats escompts de la transformation seront mesurs en fonction des enjeux et des objectifs de dpart ; mme sil est complexe dtablir un ROI pour un tel projet, il nen reste pas moins quil aura une traduction conomique. La mesure de la rentabilit est trs hasardeuse lorsquelle est fonde sur des hypothses du type si nous avions fait le projet comme avant, il aurait cot X, mais il a en fait cot Y, donc le Retour sur Investissement est de X Y . Les bnfices apports par lAgilit sont mesurs par lapprciation des variations de la qualit de service. Du point de vue des clients, cela se traduit par :
79
une amlioration des dlais de mise disposition des fonctions (time to market), lutilit des fonctions dveloppes (plutt que le respect du cahier des charges initial), la visibilit sur lavancement tout au long du projet, une diminution des dfauts constats durant la validation et aprs la mise en production.
Pour lentreprise, en fonction des objectifs initiaux, la mesure de la russite est tablie par exemple par : la variation des parts de march, la diminution des cots de maintenance, la rduction des appels au support utilisateur (help desk).
Ces rsultats sont obtenus sur le moyen ou long terme, par la mise en place de tableaux de bords spcifiques et denqutes de satisfaction auprs dutilisateurs ou de clients. Enfin, une synthse est labore pour suivre la progression du nombre de projets russis, mitigs ou en chec et les comparer aux tudes publies (par exemple ltude du Standish group) ou la situation qui prvalait avant la transformation...
LESSENTIEL RETENIR
Nousrappelonslespointsessentielsdelatransformationvers lAgilit: > Identifierlesenjeuxetlesobjectifsdelatransformation(objectifsde lentreprise,facteursdesuccs), > Dfinirlavisionduchangement(primtre,roadmap,critresde succs), > Sassurerunsupportfortetconstantauplushautniveaude lorganisation(sponsor), > Acqurirlesmoyensdelatransformation(formation,mentoring, coaching,outillage), > Ancrerlatransformationdansladure(communauts,coachs internes,volutiondumanagementintermdiaire,transformationde lcosystme),
80
> Suivreleprojetavecuntableaudebordcomplet(couverture,effets conomiques,adhsiondespersonnes).
5
LES DIFFICULTS SURMONTER
81
OUCOMMENTPRVENIRLESRISQUESETLEVERLESRTICENCES
5. LES DIFFICULTS SURMONTER
5.1
LES 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.
HUBERT GILLON
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.
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 produits suppose une bonnematrisedesconcepts sous-jacents ainsi quune exprienceconcrtedesprojets.
aa
82
Si 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 : 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 2 heures 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.
aa
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 4 heures et 2 jours 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.
On peut donc affirmer aujourdhui que lAgilitconstitueunoutilrellementefficace 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.
LESSENTIEL RETENIR
PourtreAgile: > ilnefautpasdtaillertouteslesexigencesfonctionnellesavantde dmarrerlesdveloppements, > onneprvoitpasentirementlavancelesdtails,pourviterle gaspillage, > unemachineestddielintgrationcontinue, > ilfautastreindrelesdveloppeursposterplusieursfoisparjour leurtravailsurledptcentral, > ilfautadoptercollgialementltatdespritAgile, > lamiseenuvreconcrtedespratiquestellesquelesplanning games,rtrospectivesetbacklogsproduitsupposeunebonne matrisedesconceptssous-jacentsainsiquuneexprienceprojet concrte, > ilestimportantdefaireintervenirunScrumMasteretdesexperts despratiquesAgilespoursefaireaiderdanslamiseenuvrede lAgilit.
83
5.2
LA GESTION DU STRESS DANS LES QUIPES AGILES

Si lintrt des mthodes Agiles nest plus dmontrer, comme lindique le nombre croissant de projets de ce type, lexprience montre galement les risques de pression et de stress qui peuvent dcouler de ces pratiques. En tant quexpert, Valtech est confront ces problmatiques et souhaite avertir les quipes Agiles et les responsables des drives potentielles, mais surtout leur apporter des propositions et solutions concrtes.
La problmatique
Une des forces de lAgilit est de mesurer prcisment, court, moyen et long termes, lavancement et le reste--faire dun projet :
aa aa aa
tous les jours, lors de runions quotidiennes, toutes les 2 ou 3 semaines, lors de dmonstrations, rtrospectives et runions de planification ditrations, tous les 3 ou 4 mois, lors de livraisons de releases.
Cela implique pour chaque membre de lquipe un engagement de tous les instants. Si cette mthode permet damliorer la ractivit aux changements, grce aux mtriques utilises et la collaboration sans cesse favorise, elle peut dans certains cas devenir une source de pression et de stress pour lquipe ou pour lindividu.
84
Les drives et leurs consquences

Au travers de ses expriences, Valtech a constat des drives lies au manque de matrise du rythme sur les projets Agiles, en particulier celles exposes ci-aprs :
La recherche constante de la sur-performance

Lamlioration continue, vertu indiscutable dun processus Agile, est parfois confondue avec la sur-performance. En dautres termes, faire mieux ne signifie pas forcment faire plus . Ainsi, la mesure et le suivi de la vlocit dune quipe chaque fin ditration, peut entraner lquipe se fixer des objectifs toujours plus ambitieux dune itration une autre, sans tenir compte de sa capacit relle. Cela entraine terme un puisement de lquipe, une baisse de qualit et peut parfois se traduire par un accident de livraison ditration avec une vlocit proche de 0.
Un engagement individuel qui nuit lengagement de lquipe

Certains individus supportent mal de ne pas tenir leurs engagements personnels quotidiens. Dautres encore ont tendance comparer leurs performances individuelles celles des autres quipiers au lieu de se proccuper des objectifs communs et favoriser le travail en quipe. Cela se traduit par une baisse de motivation et de performance.
Une livraison impose primtre constant

Le Product Owner, le client ou le management pousse parfois lquipe Agile faire des livraisons des dates imposes (time boxing) et sans marge de manuvre sur le primtre fonctionnel livr. Lquipe perd alors de son autonomie de dcision, et est contrainte de dtriorer la qualit de lapplication en ralisant moins de tests par exemple. La pression en rsultant dsolidarise lquipe, et peut impacter la sant morale et physique de certains.
Quelques solutions
Afin dviter ces drives, Valtech a pu mettre en uvre des solutions permettant damliorer la collaboration entre les individus et donc de contribuer la russite des projets.
Un rythme rgulier soutenu et soutenable

Toutes les parties prenantes dun projet se doivent dinstaurer un rythme rgulier soutenu et soutenable et veiller son maintien, quitte se fixer des objectifs moins ambitieux court terme et privilgier la performance moyen et long termes, plutt que la performance trs court terme.
Des rtrospectives ouvertes et sincres

A la fin dune itration, chaque quipier doit voquer sincrement les problmes quil a rencontrs ; attention aux fausses rtrospectives qui ne mettent en exergue que des problmes superficiels. Afin dviter les non-dits et les rtrospectives difficiles quand la pression est trop forte, il est conseill de faire intervenir une personne externe au projet qui aura une vision plus objective et pourra mieux exprimer les problmatiques sous-jacentes.
85
Pas de sur-engagement
Une estimation de charge trop optimiste ou approximative peut provoquer de mauvaises surprises lors de la ralisation du projet. Les estimations doivent systmatiquement tre collectives, partages avec le client et se baser sur les rsultats constats lors des itrations prcdentes.
Pas dengagement contractuel aveugle

Un engagement contractuel rigide visant fixer lavance les dlais de livraison, les cots et le primtre fonctionnel dun projet, est souvent en dcalage avec les engagements oprationnels pouvant tre pris par une quipe Agile. Cela peut mener lchec du projet. Il faut au contraire veiller tablir des contrats
flexibles, permettant dune part la satisfaction des objectifs mtiers et dautre part ladaptation aux capacits de ralisation oprationnelles. Ces solutions peuvent aider les responsables projets viter les drives, un projet Agile, cest avant tout une histoire humaine, un travail dquipe bas sur lchange et la collaboration. Fort de ces expriences dans la mise en uvre des mthodes Agiles, Valtech propose ses clients un accompagnement par le coaching Agile permettant de mener terme leurs projets dans les meilleures conditions pour les quipes et donc pour le client.
LESSENTIEL RETENIR
PourtresrdeprenniserlamiseenplacedelAgilitdansune quipe,ilfautprendregarde: > maintenirunrythmesoutenumaissoutenable, > nepasdissimulerlesvraisproblmeslorsdesrtrospectives, > viterlesur-engagement, > donnerdelaflexibilitaucontrat.
5.3
86
LA CONTRACTUALISATION AGILE
Une volution inluctable pour toutes les parties prenantes de lentreprise.
Clients, juristes, intgrateurs et experts des mthodes Agiles jugent inluctable ladaptation des contrats aux nouvelles pratiques de ralisation Agiles. Ils commencent poser ensemble les fondements de nouveaux contrats flexibles rpondant au mieux aux exigences et contraintes de chaque partie prenante et de lentreprise.
NATHALIE LOPEZ-SAUSSIER
//Directeur Gnral Adjoint // Valtech Technology
Avec lintrt croissant des entreprises pour lutilisation des mthodes Agiles dans les projets IT, il est devenu ncessaire de faire voluer les contrats classiques en contrats Agiles adapts ces nouveaux principes et mthodes de collaboration. Outil indispensable et obligatoire, le contrat ne doit plus tre peru comme un frein mais comme un outil administratif et juridique destin accompagner les diffrentes parties et rpondant aux contraintes des mthodes Agiles.
Les attentes de chaque partie prenante

Prcurseur dans les mthodes Agiles, Valtech a t le premier mettre en place la contractualisation Agile dans ses projets. Si jusqu prsent la confiance des clients envers la socit a permis lacceptation de ces contrats, il sagit aujourdhui de proposer des standards de contrats Agiles, adapts diffrents contextes. Valtech a travaill avec des directeurs informatiques, des juristes, des intgrateurs, des experts Agiles indpendants afin didentifier les exigences des projets et les attentes des diffrents intervenants et de dterminer les volutions apporter aux contrats actuels. Comment concilier les exigences fonctionnelles et budgtaires du client avec les contraintes oprationnelles et financires du prestataire ? Comment faire collaborer les quipes du client et du prestataire autour dun projet qui volue au cours de son dveloppement ? Comment transcrire juridiquement ces diffrents lments permettant de rassurer et protger client et prestataire dans un mme objectif de russite du projet ? Comment faire adhrer les diffrents services concerns ce nouveau type de collaboration ? Malgr certaines divergences inhrentes la position de chacun, client/prestataire, ou sa fonction, technique/juridique, il merge un certain nombre de points daccord intgrer dans les contrats Agiles et ce, selon deux grands axes : les concepts et les dogmes.
Les nouveaux concepts intgrer dans un contrat Agile

Les mthodes Agiles tant principalement axes sur la collaboration et sur les hommes, les lments qui dterminent un projet Agile sont bass sur de nouveaux concepts redfinir afin que les diffrentes parties aient la mme vision du droulement du projet :
aa
Unitdevaleur: indispensable pour dterminer les priorits de dveloppement, la valeur des fonctionnalits du projet est dfinie en fonction des critres de priorit, dutilisation et de besoin dfinis par le client. Cette unit de valeur est spcifique chaque client et chaque projet. Les clauses contractuelles doivent permettre au client de dcider de larrt ou de la poursuite dun projet ds lors quun minimum dunits de valeur a t produit. Pointdecomplexit: en parallle, le point de complexit tablit le rapport entre les exigences du client et leffort de ralisation, afin de mesurer le bnfice de chaque fonctionnalit par rapport la tche que cela reprsente. Dans un contrat Agile, le prestataire sengage raliser un nombre de points de complexit dans un budget donn. Backlogdeproduit: volutif, ce rfrentiel contient la liste des besoins fonctionnels (et parfois techniques), ainsi que leur valeur et leur complexit. Transparenceetcollaboration:principe de base de la russite dun projet Agile, la relation entre les quipes du client et celles du prestataire ncessite un partage et un change quotidiens pour une collaboration sereine
87
aa aa aa
et efficace. La transparence se traduit contractuellement par un accs permanent aux indicateurs de pilotage court, moyen, long termes du projet (itration, release, Product Backlog, indicateurs de vlocit et de qualit). La devoir de collaboration doit tre explicite dans le contrat, principalement pour fiabiliser les estimations de complexit.
aa
Exploitabilitcontinue: chaque fin de priode (itration), les fonctionnalits livres sont oprationnelles et peuvent tre mises en production. Ainsi, leur utilisation immdiate permet de les modifier ou dadapter le dveloppement au fur et mesure de lavancement du projet.
Evolution des dogmes et fondamentaux contractuels bass sur la collaboration
Dans le contrat Agile, les engagements du prestataire et du client portent sur les mthodes de collaboration, les moyens, les outils, la qualit et la vlocit plutt quexclusivement sur le primtre du produit final, le dlai et le budget. Les projets sont caractriss par des notions dunit de temps, de lieu et de valeur plutt que par un objectif fixe et contraignant.
THOMAS BEAUGRAND
// Avocat spcialiste des contrats et des mthodes Agiles // Cabinet Staub & associs
Pour rpondre ces nouveaux aspects contractuels, ce sont les dogmes du contrat qui doivent tre adapts :
aa
88
Laralisationcontinueetledmarrageauplustt: la diffrence des projets classiques o les actions sont menes par phases successives (spcification, conception, dveloppement, tests, recette) avec les risques deffet tunnel et de litiges la livraison que cela peut entrainer, les projets Agiles sont construits et raliss par itrations courtes (2 3 semaines) fournissant des incrments fonctionnels dmontrables et favorisant la collaboration entre le client et le prestataire. Le client nest plus amen valider des documents intermdiaires techniques mais accepter directement une partie du produit final. Les actions se mnent de front et de faon continue, les modifications sont intgres et les priorits sont values au fur et mesure de la ralisation en fonction des notions de valeurs dfinies par le client. Ainsi, lengagement du prestataire est de fournir itrativement des fonctionnalits dmontrables ; celui du client est dassurer un flux continu de demandes et de valider le produit chaque livraison ditration.
aa aa
Lecopilotageetlecoworking: le projet est men sur la base dun vritable co-working qui inclut une relle collaboration entre les parties au niveau dcisionnel et oprationnel. Il ny a pas deffet navette entre les quipes du client et du prestataire puisquelles travaillent ensemble sur le projet et font le point tous les jours sur lavance du dveloppement et les dcisions de pilotage. Lengagementduprestatairesursonquipe: au-del des comptences de lquipe, le prestataire sengage sur la prennit et la flexibilit de son quipe (diminution de personnel ou monte en charge) afin de sadapter aux besoins du projet. Lentente entre les hommes et leurs comptences tant indispensable la russite du projet, le client a un droit de regard sur le choix des intervenants du prestataire.
Pour que les projets bnficient des innovations apportes par les mthodes Agiles, il est indispensable dintgrer ces notions dans le contrat, de mettre en avant mthodologies et outils de collaboration.
La contractualisation Agile : une volution culturelle

Si la contractualisation Agile est une notion compltement assimile pour Valtech et ses clients, cest effectivement une vritable volution culturelle qui doit tre mene dans les entreprises, que ce soit chez les clients ou chez les prestataires. Il sagit prsent de faire accepter un contrat flexible, o lengagement ne porte plus sur le triptyque primtre, dlai, budget souvent au dtriment de la qualit mais sur une combinaison subtile de la vlocit, du cotdupointdecomplexit, de la qualit, et de la mise en uvre de pratiquesitrativesetcollaboratives au service de la satisfaction client. De ce constat, il ressort la ncessit de mettre en place une communication accrue entre les services concerns, quils soient techniques, achats et/ou juridiques, avec une impulsion qui doit venir de la direction. La direction a effectivement la vision et lautorit ncessaires pour dterminer les objectifs communs aux diffrents intervenants et engager la socit. Fort de ces constatations et de limplication de ces partenaires, Valtech poursuit son action dans llaboration de contrats standards favorisant le dveloppement des mthodes Agiles.
89
LESSENTIEL RETENIR
PourtrecertaindeprenniserlamiseenplacedelAgilitdans unequipe,ilfautprendregarde: > maintenirunrythmesoutenumaissoutenable, > nepasdissimulerlesvraisproblmeslorsdesrtrospectives, > viterlesur-engagement, > donnerdelaflexibilitaucontrat.
5.4
LEXTERNALISATION AGILE
Fort du retour dexprience rsultant de ladoption des mthodes Agiles ds leur mergence et de la formation sur la transformation Agile reue de Craig Larman en 2003, Valtech a tendu les pratiques Agiles de Scrum et XP son centre de dveloppement offshore Bangalore, en Inde et a adopt des pratiques de collaboration distance qui ont grandement amlior le modle de dveloppement duo-shore. Ce chapitre prsente un aperu des pratiques Agiles dans le modle duo-shore de Valtech.
90
LApproche Valtech de la dlocalisation

Chez Valtech, nous sommes convaincus que la confiance est au cur de la russite de la dlocalisation Agile. Une fois la confiance tablie, les processus en place sont mieux accepts par toutes les parties prenantes. Les quipes Valtech ont introduit de nouvelles pratiques dans leurs activits quotidiennes, pour tablir un bon niveau de confiance dans lquipe de projet et avec les clients, sans compromettre les valeurs et les principes Agiles.
On citera par exemple:
aa aa aa aa
des modles contractuels fonds sur la valeur livre, une plus grande collaboration entre les quipes par la mise en place des runions quotidiennes inter-quipes (Scrum of scrums), de protocoles dquipes, de salles de runion virtuelles, de voyages (vers lInde et depuis lInde) et lutilisation partage de wikis et doutils de gestion du cycle de vie des applications, des dmonstrations et des livraisons frquentes, des rtrospectives auxquelles le client est associ, le dveloppement de matriel de formation ad-hoc pour optimiser la courbe dapprentissage des nouveaux membres au sein des quipes projets.
Les sections ci-dessous prsentent brivement certaines de ces pratiques.
Les modles de livraison

Le contrat Agile
La contractualisation Agile a t adopte dans le modle duo-shore. Outre les concepts intgrs dans les contrats Agiles prsents dans un chapitre prcdent, le dveloppement en mode duo-shore ncessite les adaptations suivantes :
aa aa aa aa aa
un budget de voyage est dtermin lors du lancement du projet, la facturation est base sur les units de valeur livres (estimes en points de complexit), plutt que sur des jalons classiques, la dsignation par le client dun Product Owner ddi au projet est imprative, la flexibilit des horaires de travail doit tre mutuellement accepte, en raison du dcalage horaire potentiel, le contrat tient compte des exigences de communication entre les quipes localises onshore et offshore, et tient compte des frais gnraux associs.
91
Cycles de nouvelles versions et itrations

Pour assurer une bonne prdictibilit de la vlocit de lquipe9, et assurer galement que la qualit des fonctions ralises sera acceptable, il est ncessaire de tenir compte de leffort ncessaire au transfert de connaissances et de comptences. Malgr les pratiques mises en place, le transfert de connaissance sur un sujet complexe prend plus de temps lorsque lquipe est distance, tout simplement parce que la communication directe est moins fluide (pas de conversations possibles la machine caf !)
9.
La vlocit mesure la quantit fonctionnelle construite et livre en tat oprationnel au cours dune itration par lquipe de projet.
Techniques de collaboration
Protocoles dquipes
Un protocole dquipe dcrit des rgles, gnralement simples, pour guider la ralisation dune activit de lquipe. Certains protocoles peuvent tre mis en place au dmarrage dun projet, et dautres sont issus de ladaptation de lquipe de nouvelles situations. Exemple 1 : une quipe a mis en place un protocole pour enregistrer les sessions de chat entre les membres de lquipe. Chaque session dbute par une ligne Objet et se termine par un Rsum . Une fois complte, la totalit de la conversation est publie dans le wiki de rfrence. Exemple 2 : une autre quipe a cr un protocole de gestion des anomalies. Lorsquun dfaut est dcouvert, il est ajout comme une tche sur le tableau blanc. Si aprs 4 heures dattente le dfaut nest pas corrig, il est considr comme une anomalie et gr en tant que tel. Exemple 3 : pour pallier une indisponibilit temporaire du client, une quipe offshore a cr un protocole qui lui permet de poursuivre la dfinition fonctionnelle de lapplication : des membres de lquipe offshore crivent des user stories, et les soumettent au client via le wiki du projet. Le client a alors 48 heures pour commenter ou valider la proposition. Exemple 4 : pour amliorer la lisibilit du tableau des tches, une quipe a dcid de regrouper les user stories en catgories, et chaque catgorie est caractrise par des cartes de couleurs diffrentes.
92
FIGURE 16
Tableau de Scrum avec les diffrents types dhistoires utilisateur (SourceValtech)
Les protocoles dquipe sont gnralement applicables localement (ils ne sont pas contractuels), car ils sont la traduction oprationnelle des rsultats des rtrospectives de fin ditration.
Outils lgers
Les outils collaboratifs comme un wiki et les outils de gestion de projet comme JIRA et Rally qui sont disponibles au travers daccs web, se sont avrs des moyens de communication plus efficaces que les outils de communication point-point, tels que les e-mails. Les outils de messagerie instantane comme Skype ou Google Talk offrent la possibilit, cot ngligeable, dtablir des communications directes avec des outils de partage de documents ou de vido confrence. Nous avons plusieurs outils pour amliorer la collaboration, la productivit et le contrle de qualit. Certains de ces outils ont t dvelopps par nous-mmes, dautres ont t dvelopps par nos prestataires. JIRA est utilis pour la gestion de projet, la collecte dindicateurs de performance, le suivi des exigences et des anomalies. LewikiConfluence est utilis comme plate-forme de partage dinformations pour tous les projets. Les informations concernant un projet (avancement, indicateurs), le produit (spcifications, architecture, etc.) ou lquipe (contacts, rles, etc.) sont publies dans le wiki et rendues accessibles tous les membres du projet ainsi quau client. Avec les fonctionnalits de gestion des versions des pages et des documents, et lenvoi de mails lorsque des modifications de contenu sont introduites, lutilisation dun wiki est extrmement efficace. Pour chaque projet, une Usine de Dveloppement Logiciel (Software Factory) est mise en place pour prendre en charge lintgration continue (utilisation de CruiseControl ou de Hudson), lautomatisationdelexcutiondestests,etlanalysestatiquedecode. ValtechQualitySuiteintgre de multiples outils danalyse de code statique (PMD, Checkstyle, Dependometer, Juca etc.), et fournit un mcanisme de gnration de rapport efficace concernant la qualit du code et la couverture de tests. Sallederunionvirtuelle : les quipes utilisent couramment des outils de vido confrence simples (webcam + casque et micro, ou tlphone + flux vido projet sur un cran) lors des runions avec les membres de lquipe. La qualit de la communication est trs grandement amliore. LoFAT est un wrapper pour Selenium et QTP visant rduire leffort requis par les testeurs pour crer et maintenir des scripts de test automatiss.
93
Structure dquipe
Pour une quipe de taille consquente (par exemple effectif > 20), il est prfrable de diviser lquipe en groupes pluridisciplinaires centrs sur des units fonctionnelles du produit. Dans cette organisation (feature team), chaque groupe est responsable du dveloppement et de lintgration dune unit fonctionnelle (feature). Chaque feature team est compose danalystes, de concepteurs-dveloppeurs, de testeurs, guids par un Scrum Master.
Le transfert des connaissances

La mise en place de principes Agiles de collaboration a galement amlior le transfert des connaissances dans le modle de dveloppement duoshore. Notamment : Les sessions de travail en binme (2 dveloppeurs, 2 testeurs ou 1 dveloppeur / 1 testeur, travaillant ensemble sur une mme tche) permettent le transfert des connaissances par la pratique, une meilleure gestion des risques associs au dpart de membres de lquipe. Il a t possible de maintenir la collaboration distance en utilisant des outils de communication optimiss pour le Web comme WebEx, Interwise ou bien en utilisant des outils de prise de commande de PC distance, tels que VNC ou RDC, en combinaison avec les mthodes de tlphonie sur le Web tels que Skype. La vidoconfrence sest galement avre tre un outil trs efficace pour assurer la collaboration rapide entre les quipes distribues. Une visite du site onshore par le Product Owner et par les architectes de lquipe onshore au dmarrage dun nouveau projet est le moyen le plus efficace pour partager la connaissance du domaine, des besoins fonctionnels et pour dvelopper larchitecture du produit. Une bon modle du domaine peut tre construit dans ces conditions, pour assurer la bonne comprhension des besoins techniques du projet.
FIGURE 17
Product Owner en train dexpliquer les nuances des fonctionnalits lquipe
Dimension culturelle
94
Traditionnellement le voyage se produisait une fois, au dbut du projet et plus tard, au cours du dploiement. Plusieurs fois, seulement un ou deux membres de lquipe offshore rendaient visite au client. Il ny a eu aucune tentative de comprendre les dimensions culturelles de lautre quipe. Nous avons fait une tentative pour rpondre cette proccupation en planifiant plus de voyages. Les voyages frquents nous ont aids approfondir la liaison entre les quipes. Les personnes qui voyagent participent aux activits culturelles et sportives, visitent les lieux historiques avec les membres dquipe pour mieux comprendre la culture du pays. Ces initiatives dinteractions informelles sur diffrents sujets nous aident comprendre la culture des autres.
PARIJAT SINHA
// Practice Head // Valtech India
La frquence des voyages du client sur le site de dveloppement (Product Owners ou autres parties prenantes) a une influence directe sur la qualit des applications produites. Le cot de ces dplacements est amorti par la rduction des gaspillages et des pertes defficacit.
FIGURE 18 Accueil dun membre de lquipe onshore par ses homologues offshore Bangalore.
Au cours des visites, la communication directe permet de rpondre rapidement des questions de dtail qui nauraient pas t abordes en communication distance , et permet de recentrer lensemble des participants sur la vision et les enjeux du projet. Les changes directs construisent lquipe, renforcent la collaboration, chacun tant conscient et au fait des proccupations et des attentes des uns et des autres.
Infrastructure
En bonne pratique, toutes les activits lies la mise en place de linfrastructure sont compltes au dmarrage dun nouveau projet avec toutes les activits dites de calibrage du projet, ce qui comprend le transfert des connaissances du produit. Dans la mthodologie Scrum adopte par Valtech, cette priode de calibrage porte le nom de litration de calibrage ou itration-0. Aucune livraison de nouvelle fonctionnalit du produit ne survient durant cette priode.
Les activits de mise en place de linfrastructure suivante sont compltes lors de litration 0 :
aa aa aa aa aa aa
mise en place dun dpt de code source commun pour onshore et offshore, mise en place dun serveur dintgration continue du code source qui soit compltement fonctionnel, cest--dire qui soit capable de dclencher une nouvelle construction chaque modification du code source, dexcuter les test unitaires, les tests fonctionnels et les outils danalyse de code statique, et de signaler les anomalies dtectes aux membres de lquipe, mise en place doutils de gestion de projet et dun wiki accessible tous les membres de lquipe et que chacun sache utiliser, chaque membre de lquipe possde deux moniteurs, mise en place dun espace de travail ouvert pour la circulation libre dinformations entre les membres de lquipe, vrification que toute information partage soit accessible par lquipe onshore, les clients, etc.
95
FIGURE 19
Espace de travail ouvert entour de tableaux blancs chez Valtech India
Le gaspillage selon la dfinition Agile

Les mthodologies Agiles, y compris Scrum, considrent comme du gaspillage toute tche qui napporte pas de valeur au client. Par exprience, nous identifions les tches suivantes comme du gaspillage :
aa aa
96
la cration de documents labors pour le suivi de conformit, concernant par exemple les revues de code. Ils sont avantageusement remplacs par des notes rapides ou des discussions entre dveloppeurs, la sur-qualit dans la documentation de conception, utilisation pousse dUML. Bien souvent, des schmas dessins au tableau, visibles de tous en permanence, sont appropris. La documentation ncessaire la maintenance peut tre labore aprs coup, la rdaction de comptes-rendus de runion (runion quotidienne, rtrospective). Le rsultat de la runion quotidienne est traduit en modifications du task board, les conclusions des rtrospectives peuvent tre incluses comme nouvelles tches, ou formalises en protocole dquipe, les runions mal prpares et qui naboutissent aucune conclusion en raison de labsence dagenda et dobjectif, la duplication dinformation, la production de multiples rapports davancement, chacun destin un lecteur diffrent (client, chef de projet, etc.) mais tous bass sur les mmes donnes, la mise en place dintermdiaires dans la communication entre lquipe et le client (fonction de coordinateur), la non adhrence au bon protocole pour toute forme de communication. Mcomprhension due aux assomptions et intentions qui ne sont pas transparentes,
aa aa aa aa aa aa
aa aa
la multiplication de systmes de contrle de version (par exemple, un pour les dveloppeurs onshore, un autre pour les dveloppeurs offshore ou pour le client), lutilisation de-mails et de rapports comme source primaire dchange dinformation.
LESSENTIEL RETENIR
> Aufuretmesurequelesquipescommenaientgagneren maturitdanslAgile,nousavonscommenctrouvernospropres modlesdetravail.Notreengagementonshore-offshoreest maintenantpilotparlesvaleursetlesprincipesAgiles.
5.5
LAGILIT FACE AUX AUTRES STANDARDS

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 dactivit. Il sagit de planifier et de dfinir les mthodes ncessaires la matrise des prestations et des produits, et de mesurer le niveau defficacit atteint. On traduit souvent cette approche par le concept de PDCA (Plan, Do, Check, Act). Ce mode de management est assez proche de la logique ditration 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 damlioration continue. Ensuite, la dimension majeure de lISO 9001 est son approche processus qui vise matriser lensemble des activits dun 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.
97
FAIRE LE TRAVAIL TEL QUE PRVU ET ENREGISTRER LES RSULTATS (PREUVES)
PRVOIR LES ACTIONS DEVANT TRE RALISES
VRIFIER LE TRAVAIL RALIS (REVUE, AUDIT)
AGIR EN EXPLOITANT LES COMPTES-RENDUS DE REVUE, LES RAPPORTS DAUDIT > PLAN DAMLIORATIONS
FIGURE 20
Cycle de Deming PDCA (Plan, Do, Check, Act) (Source:Valtech)
HUBERT GILLON
Agilit et ISO concourent rendre les pratiques de projet plus efficaces au bnfice des produits livrs et de la satisfaction client.
98
5.6
METTRE DE LAGILIT DANS UNE DMARCHE CMMI

Qui a dit inconciliable ?
On a souvent tendance opposer Agilit et CMMI en prtendant qutre Agile signifie faire limpasse sur tout processus prdfini qui constituerait un carcan nuisible la crativit et la productivit. Les dtracteurs des modles qualit tel que CMMI ont coutume daffirmer que mettre en place des pratiques Agiles cest assurer la qualit du produit, alors que se conformer un modle tel que le CMMI na pour effet que de rassurer ceux qui lappliquent.
Cest oublier un peu vite que le fondement du modle CMMI est dinciter une organisation samliorer de faon continue en structurant cet effort autour dun ensemble de processus et avec une approche progressive par niveau de maturit. Le cycle damlioration continue IDEAL (et plus gnralement toute dmarche de type PDCA) sous-jacent au modle CMMI se conforme donc bien au paradigme ditration prn par les mthodes Agiles. Par ailleurs, CMMIdfinitdesobjectifs(SpecificGoalsetGenericGoals)visant garantirquelaqualitdesproduitsralissnedpendepasdelhrosmedes quipesmaisdelefficacitdesesprocessus. Pour atteindre ces objectifs, CMMI propose un certain nombre dexigences structures par processus (Process Area), dcrivant le quoi faire , et non le comment faire . Il y a donc toute libert mettre en uvre des pratiques Agiles pour atteindre ces exigences.
Des pratiques CMMI Agiles ?

Si les agilistes taient dj confiants dans la conformit de leurs pratiques avec un grand nombre dexigences du modle CMMI, on constate aujourdhui que le SEI (Software Engineering Institute) tudie galement cette compatibilit, travers divers articles (CMMIorAgile:whynotembraceboth?) ou ouvrages (Integrating CMMIandAgileDevelopment). Certains Lead Appraisers ont acquis lexprience de la mise en uvre des pratiques Agiles et savent donc valuer une organisation de ce type. La couverture des pratiques Agiles vis--vis des exigences spcifiques du modle (Specific Goals) est analyse ci-dessous. Le niveau 2, focalis principalement sur les activits projet, est globalement satisfait par les pratiques Agiles Scrum et XP :
aa
REQM : ce domaine de processus est globalement couvert par :
a le rle central du Product Owner, qui permet dassurer la bonne
comprhension des exigences par lquipe de dveloppement lors des ateliers fonctionnels, de dfinir le besoin et de tracer les changements, des outils de Test Driven Requirement.
a le Product Backlog, partag entre lquipe et le Product Owner, il permet a la traabilit entre les exigences et les tests, grce aux techniques et
99
aa
PP:
a le Plan de Release, le Product Backlog et lIteration Backlog dtaillent la

dcomposition du travail, lestimation des charges et le planning, de lengagement des membres de lquipe,
a les runions de planification (Iteration Planning) permettent de sassurer a par contre, le plan de data management nest pas couvert explicitement
par les pratiques Agiles, mais lutilisation dun wiki favorise la bonne maitrise des informations.
aa
PMC: les runions de planification ditration, les scrum meetings, les runions de fin ditration et rtrospectives assurent le suivi et le contrle des activits projets.
aa aa aa aa
M&A: les informations davancement collectes lors des Scrum meetings, consignes dans literation backlog et consolides dans les indicateurs graphiques satisfont un certain nombre de pratiques de ce domaine. SAM : la slection et la gestion des sous-traitants ne sont pas du tout couvertes par les pratiques Agiles. Il convient pour cela dtablir des contrats flexibles innovants (Cf. supra) PPQA : ce domaine nest pas couvert par des pratiques Agiles de Scrum ou XP. CM : la mise en place dune usine logicielle et de lintgration continue implique de mettre en place un outil de gestion de configuration. Loutillage de la gestion des changements est galement souvent mis en place.
Par ailleurs, alors que le niveau 2 du CMMI tablit des pratiques projet, le niveau 3 vise linstitutionnalisation de ces pratiques dans lorganisation. Or les pratiques Agiles restent focalises au niveau projet et ne couvrent donc pas les domaines de processus organisationnels (OPF, OPD, OT). Citons les pratiques relatives lingnierie :
aa aa aa aa
100
RD : la plupart des pratiques du domaine sont couvertes avec la planification de litration, les ateliers fonctionnels avec une implication du Product Owner pour dtailler les fonctionnalits slectionnes pour litration et identifis les critres de validation. TS : les pratiques Agiles ne couvrent pas vraiment le processus de choix de la meilleure solution technique au travers de ltude de solutions alternatives. PI : lintgration continue couvre parfaitement cet objectif. VER,VAL : sont couverts par les pratiques de dveloppement (eXtreme Programming) et par les spcifications pilotes par les tests.
Cot gestion de projet, regardons :
aa
RSKM : il ny a pas de description explicite de gestion des risques dans Scrum ou XP. Cependant il est reconnu que les pratiques Agiles encouragent les quipes se concentrer sur les risques les plus critiques le plus tt possible, quil sagisse de risques techniques ou non. Il convient donc dajouter aux pratiques Agiles classiques une gestion des risques qui pourra tre mise en uvre lors des iteration planning ou de runions ddies
Les pratiques Agiles ne rpondent pas explicitement aux niveaux 4 et 5. On doit cependant mentionner que leur mise en place participe lamlioration continue des processus : lors des rtrospectives de fin ditration, des outils comme les 5 pourquoi ou le diagramme dIshikawa (Fishbone) sont utiliss dans la recherche de causes racine. Scrum apparait comme une force pour permettre la couverture de certaines pratiques gnriques (Generic Goals), par exemple pour assurer lengagement des parties prenantes (cas du Product Owner et de lquipe), pour assurer la planification et le suivi de certains domaines de processus grce aux backlogs.
Quest-ce quun Rfrentiel Qualit Agile ?

Tout dabord, rappelons que l Assurance Qualit au sens du CMMI couvre la fois les processus et le produit. Concentrons-nous ici sur le volet processus. LAssurance Qualit consiste sassurer que lorganisation se conforme systmatiquement aux dispositions du Rfrentiel Qualit , autrement dit au cadre mthodologique et aux procdures affrentes. Les mthodes Agiles introduisent un certain nombre de pratiques dont le succs passe par une application rigoureuse, comme par exemple les diffrentes crmonies Scrum : iteration planning, Scrum meeting, revue ditration, rtrospective. Le contrle qualit du processus incombe au Scrum Master, qui reste nanmoins avant tout un facilitateur dans la mise en place et ladoption des diffrentes pratiques Agiles. Le rfrentiel qualit :
aa aa
identifie les diverses mthodesetpratiquesappliques sans pour autant les re-dtailler. Il suffit pour cela de se rfrer labondantebibliographie 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, contient divers modlesdedocuments Organisation Agile ne signifie pas zro documentation mais en nombrerduit. Le principe est de ne produire que la documentation utile - qui apporte de la valeur - et au bon moment. Rdiger un volumineux dossier de conception noffre aucun intrt si lon se conforme dj des standards darchitecture et de codage. Lutilisation de frameworks peut aider imposer larchitecture et la rendre transparente. Il est par ailleurs relativement facile dautomatiser la vrification de telles rgles avec des outils danalyse statique. Par contre, il est important de garder trace des rflexions qui ont amen ces choix darchitecture et de frameworks, afin de transfrer la connaissance du projet et viter ainsi de se reposer plus tard les mmes questions.
101
Un vrai rfrentiel qualit Agile :
aa aa aa
dcrit un ensemble de pratiques et de procdures, contient uniquement les procdures qui ncessitent dtre dtailles afin dtre rellement exploitables, voit sa bonne applicationcontrleenpermanenceparlesScrumMasters.
Qui occupe la tour divoire de lEPG ?

Un autre des principes Agiles, prn en particulier par Scrum, consiste responsabilisertotalementlquipe en lui confrant le pouvoir dauto-organisation et dauto-dtermination. Par exemple, ce nest plus un chef de projet qui affecte les tches aux membres de lquipe, mais ces derniers qui se les approprient, en fonction de leurs comptences techniques ou fonctionnelles.
De mme, on attend de chacun, lors des rtrospectives, quil identifie les points damlioration possibles sur les processus en vigueur et fournisse, si possible, les solutions associes. Certains considrent considre quen appliquant le CMMI, on se repose sur quelques minents qualiticiens pour promulguer les bonnes pratiques respecter. Or ce cnacle, lEngineering Process Group (EPG), est en fait le rassemblement temporaire de certains membres des quipes projets, lgitims par leur exprience et porteurs de lensemble des retours dexprience de leur quipe. Toute lquipe projet participe ainsi lamlioration des pratiques dune organisation Agile.
LAgilit faon Lean

Sengager dans une dmarche damlioration continue Lean permet aux matrises douvrage (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
Les principes Lean

Lean est connu dans le monde automobile par lexprience Toyota, devenu le premier constructeur automobile, reconnu la fois pour la qualit et linnovation de ses produits. Tout le monde saccorde reconnatre que ce succs est d son systme de production Lean. Et les dboires de Toyota en 2009 ne tendent qu prouver limportance de ne pas droger aux principes noncs ci-dessous. Cette approche vise la fois
102
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 credelavaleur pour le client, sassurer que chaqueactivitdu processus apporte de la valeur ajoute ou est indispensable, raliser chaque activit justetemps et lademande, pour que ses rsultats soient utiliss sans dlai, rechercher la perfection, sappuyer sur ceux qui ralisent les activits pour rechercher des amliorations.
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.
Agile is Lean
On constate que les pratiques Agiles hrites des mthodes Scrum et eXtreme Programming servent directement les principes du Lean Software Development car tous se focalisentsurleproduit en visant la satisfactionclient.
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
// Extrait traduit de langlais // Agile Software Development with Srcum
aa
Favoriserlaconnaissance,ReporterladcisionetLivrerrapidement 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 lintgration continue des nouvelles fonctions leur rythme et en fonction des ressources disponibles, sans surcot ni surcharge de travail qui induisent de nombreuses sources derreur (Concept Lean Justintime). Un exemple concret de la mise en uvre du principe Construirelaqualit intrinsque (dcoulant du principe Rechercherlaperfection) peut se traduire par la technique TDD associe lautomatisation des tests, qui constituent une approche efficace damlioration 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 Stoptheline, en corrigeant les anomalies ds quelles sont dtectes, ce qui vite de gaspiller des ressources en poursuivant le dveloppement de lapplication sur des bases non fiables 100%. En effet, la priorit de correction des anomalies doit tre suprieure la priorit dajouter de nouvelles fonctions au logiciel. Lquipe dispose pour cela dune usine logicielle qui gnre quotidiennement une version excutable de lapplication en cours de dveloppement et excute les tests automatiss afin de dtecter au plus tt les anomalies potentielles.
aa
103
aa
aa
Enfin, le VisualManagementest un important concept Lean, largement soutenu dans les mthodes Agiles par une organisation de lespace de travail. Il permet toutes les parties impliques (dveloppeurs, testeurs, chefs de projets, reprsentants du mtier) de visualiser instantanment ltat davancement du projet, et ceci en termes simples : avertissement sonore ou lumineux pour alerter dun build cass , consolidation des divers indicateurs davancement (couverture de tests, anomalies en cours) sous forme de diagrammes et symboles de couleur sur un cran ou un tableau la vue de tous. Lensemble des pratiques cites ci-dessus rpondent galement au premier principe Eliminerlesgaspillages : rduire les retards (itrations courtes), se concentrer sur les dfauts (TDD), mieux comprendre les exigences (TDR), etc.
aa
LESSENTIEL RETENIR
> AgilitetISOserejoignentsurdesvaleurscommunesde planificationoprationnelleetdamliorationcontinue. > Touteorganisationsouhaiterendresesprocessusefficaceset efficients.CertainesdploientdespratiquesAgilespouramliorer leurractivitetleursatisfactiondubesoinclient.Dautresse focalisentsurlhomognisationetlerespectdeleursprocessusen mettantenuvreunedmarchedamliorationcontinuetelleque CMMI,ISOouLean.Laperformanceglobaledelorganisationpasse certainementparlacombinaisondesdeux. > CMMIimposedesobjectifsvisantgarantirquelaqualitdes produitsralissnedpendpasdelhrosmedesquipesmais delefficacitdesesprocessus.Pouratteindrecesobjectifs, CMMIproposeuncertainnombredepratiquesquisontdes recommandationssurlequoifaire,etnonsurlecomment faire.LespratiquesAgilesapportentunerponsecesexigences.
104
6
GLOSSAIRE DES PRATIQUES AGILES
105
6. GLOSSAIRE DES PRATIQUES AGILES
6.1
DFINITIONS
Agilit nest pas synonyme de dsordre, au contraire, le monde de lAgilit 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 leXtreme Programming), agrment dautres pratiques Agiles que nous utilisons rgulirement chez Valtech : - le cercle extrieur contient les pratiquesliesauclient, - le cercle intermdiaire contient les pratiquesdemanagement, - le cercle intrieur contient les pratiquesdedveloppement.
EQUIPE UNIQUE DEVELOPPEMENTS ITRATIFS PROPRIT COLLECTIVE DU CODE SPCIFICATIONS EXCUTABLES (TDR) DVELOPPEMENT PILOT PAR LES TESTS RGLES DE CODAGE
PROGRAMMATION EN BINME
CONCEPTION SIMPLE
SANCE DE PLANIFICATION
106
INTGRATION CONTINUE
REFACTORING PERMANENT MTAPHORE
RYTHME DURABLE
LIVRAISONS FRQUENTES
RTROSPECTIVE
FIGURE 21
Les pratiques Agiles issues de XP et Scrum (Source Valtech)
Cercle client
DveloppementItratif : lactivit de dveloppement est organise en cycles dont la dure est fixe une fois pour toute pour le projet. On appelle ces cycles des itrations ou sprints. Ils dfinissent le rythme du projet (heart beat).
EquipeUnique (wholeteam) : il sagit ici de casser le modle cloisonn SpcificateurDveloppeur-Testeur. Les participants dun projet de dveloppement forment une seule quipe ou tout le monde participe la hauteur de ses comptences, et dans le cadre dun rle identifi, vers un but commun. Il est important de souligner que cette pratique consiste aussi rassembler lquipe sur le plan gographique (dans la mesure du possible). Livraisonsfrquentes(SmallReleases) : 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 ditration, un temps est prvu pour rflchir au droulement de litration passe et pour chercher les moyens damliorer lefficacit pour les itrations futures. Sancedeplanification (Planninggame) : la structure des sances de planification est trs codifie, avec un certain nombre dtapes identifies raliser avec tous les membres de lquipe. Ces sances de planification reviennent cycliquement en dbut de chaque itration, dfinissant ainsi les spcifications de lapplication produire petit petit, plutt quen un seul grand coup de canon en dbut de projet. Cest lors de ces sances que lon dfinit ce que lon appelle dans Scrum le Sprint Backlog ou Iteration Backlog, partir de la liste des fonctions / scnarios rassembls dans le Product Backlog et qui suit lapplication ditration en itration. Testsclientautomatiss (TDRouCustomerTests) : on parle aussi de spcifications excutables ou Test Driven Requirement. Le client dfinit les critres dacceptation des scnarios fonctionnels sous forme de cas de test.
Cercle Management
Intgration Continue (Continuous Integration) : le systme dvelopp est intgralement assembl et test plusieurs fois par jour. Aujourdhui, cette pratique est grandement facilite par des outils ddis (Hudson, CruiseControl). Mtaphore (Metaphore) : lquipe doit rechercher et utiliser une analogie comme modlisation du systme dvelopper. Cette technique trs rpandue dans le monde informatique permet aussi lquipe de se construire un vocabulaire commun, notamment pour la communication entre les profils fonctionnels et ceux techniques. Proprit collective du code (Collective Code Ownership) : tout le code de lapplication est accessible en modification par tous les membres de lquipe. Il ny a pas de domaine rserv. Cette pratique qui a lavantage de rsoudre le syndrome de lautobus (quest-ce quon fait si une personne de lquipe se fait renverser par un autobus?), permet aussi de fluidifier le travail quotidien de lquipe. Elle suppose davoir 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) : lquipe se fixe des rgles de codage de manire ce que le code soit homogne et facilement lisible par tous.
107
Rythmedurable (SustainablePace) : cette pratique initialement intitule par les Amricains 40 heures par semaine et qui na jamais signifi grand chose dans la culture franaise, recommande de ne pas faire dheures supplmentaires plus de deux semaines de suite. Les membres de lquipe doivent tre en forme pour donner le meilleur deux-mmes. La gnralisation des heures supplmentaires est le flau des quipes mal organises. Loptimisation des processus apporte par ce type de mthode permet damliorer notablement la productivit sans augmenter la charge de travail.
Cercle Dveloppement
ConceptionSimple (SimpleDesign) : tout moment, le design de lapplication est le plus simple possible afin quil 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) : lactivit de programmation suit le processus suivant : crire un test > crire le code le plus simple qui puisse compiler > amliorer le code (refactoring) pour introduire labstraction ncessaire et liminer dventuelles duplications. Programmation en binme (Pair Programming) : elle se caractrise par le fait que le code est crit par deux personnes, un pilote et un copilote. Les rles au sein du binme et les binmes eux-mmes changent rgulirement, ce qui permet lquipe davoir une meilleure connaissance du code de lapplication. Refactoringpermanent (MercylessRefactoring) : pratique de dveloppement qui consiste amliorer le code sans en changer le comportement.
108
6.2
ABRVIATIONS
CMMI : DSI : LSD : MOA : MOE : PDCA: PMD : ROI RSA TDD TDR : : : : Capability Maturity Model Integration Direction des Systmes dInformation Lean Software Development Matrise dOuvrage Matre duvre Plan Do Check Act Outil danalyse des flux de donnes et de recherche des copier/coller, du code mort et des constructions complexes en Java Return On Investment (retour sur investissement) IBM-Rational Software Architect Test Driven Development Test Driven Requirement
7
RFRENCES BIBLIOGRAPHIQUES
109
7. RFRENCES BIBLIOGRAPHIQUES
RF. [Ref.1] [Ref.2] [Ref.3] [Ref.4] [Ref.5] [Ref.6] [Ref.7] [Ref.8]
DOCUMENT Agile Software Development with Scrum Implementing Lean Software Development, From Concept to Cash Gestion de projet : vers les mthodes Agiles Agile estimating and planning Gestion de projet Extreme Programming User stories applied Test-Driven Development Agile and Iterative development Coaching Agile Teams: A Companion for Scrum Masters, Agile Coaches, and Project Managers in Transition Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum The Fifth Discipline - The Art & Practice of the Learning Organization Gestion de Projet Agile, avec Scrum, Lean, eXtreme Programming, 3eme dition The Toyota Way: 14 Management Principles from the Worlds Greatest Manufacturer Agile Product Management with Scrum Creating Product that Customer Love The Enterprise and Scrum
AUTEUR Ken Schwaber Mary and Tom Poppendieck Vronique Messager Mike Cohn Jean-Louis Bnard Mike Cohn Kent Beck Craig Larman
DITEUR Pearson Education Addison Wesley Eyrolles Prentice Hall Eyrolles Addison-Wesley Professional Pearson Education Addison-Wesley Professional Addison Wesley
DITION 2008 2007 2007 2004 2004 2004 2003 2003
[Ref.9]
Lyssa Adkins
2010
[Ref.10]
Craig Larman, Bas Vodde Craig Larman, Bas Vodde Peter Senge Vronique Messager
Addison-Wesley
2010
[Ref.11]
Addison-Wesley Currency Doubleday Eyrolles
2008
[Ref.12]
1990
[Ref.13]
2010
[Ref.14]
Jeffrey K. Liker
McGraw Hill
2004
110
[Ref.15] [Ref.16]
Roman Pichler Ken Schwaber Alan Shalloway,
Addison-Wesley Microsoft Press
2010 2007
[Ref.17]
Lean-Agile Software Development: Achieving Enterprise Agility
Guy Beaver, James R. Trott
Addison-Wesley
2009
[Ref.18] [Ref.19] [Ref.20] [Ref.21]

TABLEAU 12
10 contract forms for your next Agile project Five dysfunctions of a team Agile software development Extreme Programming, embrace change, 2nd edition
Peter Stevens Patrick Lencioni Alastair Cockburn Kent Beck
Munich, 21-Oct-09
2009
Rfrences bibliographiques
111
Toute reprsentation ou reproduction intgrale ou partielle, faite sans le consentement de Valtech, de ses ayants droit, ou ayants cause, est illicite (Loi du 11 Mars 1957, article 40, alina 1).
7. RFRENCES BIBLIOGRAPHIQUES
L'Agilit est aujourd'hui reconnue comme l'une des solutions incontournables pour confrer aux entreprises la matrise et la souplesse ncessaires la cration rapide de valeur. Depuis 10 ans, Valtech accompagne des clients toujours plus nombreux dans leur transition Agile, l'chelle des projets ou de l'organisation. Entirement consacr l'Agilit, ce livre blanc prcis, ponctu d'interviews, de donnes chiffres, et de retours d'exprience s'adresse aux dcideurs qui s'interrogent sur les bnfices escompts et la dmarche de transformation. Il offre galement aux praticiens de l'Agilit un concentr des savoir-faire des experts Agiles de Valtech travers des exemples concrets et des conseils pratiques. Il donne ainsi les cls d'une transformation russie pour non seulement faire Agile mais aussi tre Agile .
www.valtech.fr

VALTECH Livre Blanc Agile v2 2011

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VALTECH Livre Blanc Agile v2 2011

Uploaded by

Copyright:

Available Formats

TRANSITION VERS L'AGILIT

L'CHELLE D'UNE ORGANISATION

MATRISE, VALEUR, SOUPLESSE

TRANSITION VERS LAGILIT

DEUXIME EDITION - 2011

LAgilit par la pratique

Le marketing digital Agile

La transformation vers lAgilit

Les difficults surmonter

Glossaire des pratiques Agiles

FIGURE3 FIGURE4 FIGURE5

FIGURE6 FIGURE7 FIGURE8 FIGURE9 FIGURE10 FIGURE11

FIGURE12 FIGURE13 FIGURE14 FIGURE15 FIGURE16

FIGURE19 FIGURE20 FIGURE21

Table des tableaux

1. LES MTHODES AGILES POUR LES NULS

POURQUOI ADOPTER LES MTHODES AGILES ?

A contrario, les mthodes Agiles prconisent :

Ladoption dun cycle itratif et incrmental

La dfinition dobjectifs court terme

La collaboration entre les personnes et lintgration des quipes

La livraison dun produit oprationnel

1. LES MTHODES AGILES POUR LES NULS

1. LES MTHODES AGILES POUR LES NULS

// Delivery Manager // Valtech

QUI EST CONCERN ?

PRIORIT DONNE AUX PERSONNES ET AUX INTERACTIONS

PRIORIT DONNE LA PRODUCTION DE FONCTIONS

PRIORIT DONNE LA COLLABORATION AVEC LE CLIENT

PRIORIT DONNE LADAPTABILIT ET LACCUEIL DVENTUELS CHANGEMENTS

QUELLES SONT LES PRATIQUES AGILES LES PLUS RPANDUES ?

1. LES MTHODES AGILES POUR LES NULS

1. LES MTHODES AGILES POUR LES NULS

SPRINT #03 BURNDOWN

400 350 300 250 200 150 100 50 0

EFFORT BURNDOWN TARGET BURNDOWN COMPLETED TASKS %

Exemple de Burndown Chart (Source Valtech)

RELEASE PLANNING MEETING

SPRINT PLANNING MEETING

DAILY STATUS MEETING (DAILY SCRUM)

SPRINT DEMO AND REVIEW MEETING

Customer Product Owner

WORKING SOFTWARE OTHER DELIVERABLES

Sprint 14-30 days

Prsentation schmatique du processus de dveloppement Agile bas sur Scrum (SourceValtech)

1. LES MTHODES AGILES POUR LES NULS

1. LES MTHODES AGILES POUR LES NULS

2. LAGILIT PAR LA PRATIQUE

TMOIGNAGE DUN COACH AGILE VALTECH

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

Spcifications incrmentales et TDR

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

Serveur dintgration continue

2. LAGILIT PAR LA PRATIQUE

2. LAGILIT PAR LA PRATIQUE

tat des lieux des pratiques en cours

Rdaction dun document de synthse sur lexistant

Adoption de nouvelles pratiques

2. LAGILIT PAR LA PRATIQUE

2. LAGILIT PAR LA PRATIQUE

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

Rdaction dun document de synthse sur les pratiques retenues

RECUEIL DES BESOINS DANS LE PRODUCT BACKLOG

2. LAGILIT PAR LA PRATIQUE

FIGURE3 FIGURE4 FIGURE5

FIGURE6 FIGURE7 FIGURE8 FIGURE9 FIGURE10 FIGURE11

FIGURE12 FIGURE13 FIGURE14 FIGURE15 FIGURE16

FIGURE19 FIGURE20 FIGURE21

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

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

Exemple de Product Backlog (Source:Valtech)

TDR - Donnes initiales (Source:Valtech)

TDR - Affaire versus Convention (Source:Valtech)

TDR - Affaire versus Convention (Source:Valtech)

TDR - Validation de convention (Source:Valtech)

Contexte projet (SourceValtech)