transition vers l’agilité à l’échelle d’une organisation deuxième edition - 201

transition vers l’agilité à l’échelle d’une organisation deuxième edition - 2012 2 3 Avant-propos Présent à l’international, Valtech est un groupe pionnier et leader dans le domaine de l’Agilité, des technologies, et du digital. Avec 1 500 collaborateurs, Valtech accompagne et forme ses clients en mode Agile dans la conception, la réalisation et l’optimisation de projets et de plateformes digitales critiques pour leur croissance. S’appuyant sur une expertise technologique reconnue, Valtech propose une vision novatrice et une mise en œuvre intégrée sur toute la chaîne de valeur digitale avec pour finalité l’accélération du « Time to Market », l’accroissement des revenus et du retour sur investissement pour ses clients. Créé en 1993 et coté sur l’Eurolist d’Euronext, Valtech est présent dans 8 pays (France, Royaume-Uni, Allemagne, Suède, Danemark, Etats-Unis, Inde et Corée) avec des nombreuses références de mise en oeuvre de l’Agilité, telles que : APEC, AFPA, Banque de France, Club Med, Crédit Agricole, Dassault Aviation, EDF, Mappy, Orange, Pernod Ricard, RTE, Société Générale, Taliance, Thales ... 4 5 remerciements Ce livre blanc est le fruit de la collaboration de la communauté Agile de Valtech. Cette nouvelle mouture enrichit l’édition 2008 avec de nombreux retours d’expérience à l’échelle d’organisations complètes. Elle témoigne de l’envie permanente des consultants de Valtech de partager leur expertise et leur savoir- faire sur les méthodes Agiles. Merci en particulier à Etienne Charignon, Hélène Granboulan, Nathalie Lopez- Saussier, Thomas Beaugrand, Hubert Gillon, Elisabeth Ducarre, Stéphane Labati, Patrick Le Go, Parijat Sinha, Craig Larman, Jean-Claude Grosjean et Laurent Moulager, qui ont partagé leurs retours d’expérience Agiles dans les domaines aussi variés que les pratiques d’ingénierie, 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, l’offshore, l’Expérience Utilisateur ou la création graphique. L ’équipe éditoriale remercie également tous les relecteurs qui, forts de leurs propres expériences, ont largement contribué à améliorer la qualité de ce livre blanc. Enfin, Valtech remercie ses clients qui lui ont fait confiance en l’associant à leurs défis, renforçant jour après jour son expertise et sa capacité à les aider dans l’adoption de l’Agilité. // Responsable de l’offre Agile // Valtech STEPHANE LABATI 6 7 SOMMAIRE sommaire 1. Les méthodes Agiles « pour les nuls » 11 1.1. Pourquoi adopter les méthodes Agiles ? 12 1.2. Qui est concerné ? 14 1.3. Quelles sont les pratiques Agiles les plus répandues ? 15 2. L’Agilité par la pratique 19 2.1. Témoignage d’un coach Agile Valtech 20 2.2. Étude d’opportunité 22 2.3. Recueil des besoins dans le Product Backlog 25 2.4. Test Driven Requirement : la spécification par l’exemple 28 2.5. TDD, le développement sous contrôle 32 2.6. Suivi et pilotage avec l’Iteration Backlog 34 2.7. Retour d’expérience sur la gestion de projet 36 2.8. Retour d’expérience sur l’automatisation des tests 40 2.9. Résultats obtenus sur des projets réalisés par Valtech 43 3. Le marketing digital Agile 45 3.1. La vision du produit 47 3.2. Personas, vous avez dit Personas ? 48 3.3. La démarche créative 49 3.4. Agilité et Expérience Utilisateur 56 4. La transformation vers l’Agilité 61 4.1. Enjeux et motivations 62 4.2. Le projet de transformation 63 4.3. Définir le projet : le cadrage 64 4.4. Experimenter : Le pilote 70 4.5. Transformer : Déploiement et optimisation en continu 74 5. Les difficultés à surmonter 81 5.1. Les difficultés couramment rencontrées 82 5.2. La gestion du stress dans les équipes Agiles 84 5.3. La contractualisation Agile 86 5.4. L ’externalisation Agile 90 5.5. L ’Agilité face aux autres standards 97 5.6. Mettre de l’Agilité dans une démarche CMMI® 98 6. Glossaire des pratiques Agiles 105 6.1. Définitions 106 6.2. Abréviations 108 7. Références bibliographiques 109 sommaire 8 9 Table des figures Figure 1 Exemple de Burndown Chart 16 Figure 2 Présentation schématique du processus de développement Agile basé sur Scrum 17 Figure 3 Exemple de pratiques d’ingénierie et de pilotage de projet 24 Figure 4 Exemple de Product Backlog 26 Figure 5 Gestion des priorités et de la complexité dans le Product Backlog 27 Figure 6 Exemple de Burndown Chart 35 Figure 7 Planning détaillé d’une itération 37 Figure 8 Planning détaillé d’une semaine 37 Figure 9 Planning détaillé d’une journée 38 Figure 10 Exemple de Persona 48 FIGURE 11 Les étapes d’une transformation Agile 63 Figure 12 Une équipe de projet en relation avec son écosystème 65 FIGURE 13 L ’accompagnement dans la transformation Agile 72 FIGURE 14 Mesure de maturité Agile 73 Figure 15 Le plan de déploiement 74 Figure 16 Tableau de Scrum avec les différents types d’histoires utilisateur 92 Figure 17 Product Owner en train d’expliquer les nuances des fonctionnalités à l’équipe 94 Figure 18 Accueil d’un membre de l’équipe onshore par ses homologues offshore à Bangalore 95 Figure 19 Espace de travail ouvert entouré de tableaux blancs 96 Figure 20 Cycle de Deming PDCA (Plan, Do, Check, Act) 98 Figure 21 Les pratiques Agiles issues de XP et Scrum 106 SOMMAIRE Table des tableaux Tableau 1 TDR - Données initiales 29 Tableau 2 TDR - Affaire versus Convention 30 Tableau 3 TDR - Affaire versus Convention 30 Tableau 4 TDR - Validation de convention 30 Tableau 5 Contexte projet 36 Tableau 6 Développement de la vision 65 Tableau 7 Les clés de la transformation Agile 68 Tableau 8 Critères de sélection d’un projet pilote 71 Tableau 9 Dispositif d’accompagnement pour un projet 72 Tableau 10 Ordre d’introduction des pratiques Agiles 73 Tableau 11 Dispositif d’accompagnement 75 Tableau 12 Références bibliographiques 110 sommaire sommaire 10 11 Les méthodes Agiles “ pour les nuls “ 1 Ou en quoi consistent les méthodes Agiles et pourquoi les adopter 12 13 Pourquoi adopter les méthodes Agiles ? Les méthodes Agiles consistent en un ensemble de pratiques imaginées pour pallier les difficultés rencontrées dans les cycles de développement en cascade ou en V, encore omniprésentes. Les méthodes traditionnelles prônent un enchaînement séquentiel des différentes activités, depuis les spécifications jusqu’à la validation du système, selon un planning préétabli. Elles visent à mieux prédire la façon dont les choses « devraient » se passer. Malheureusement, cette vision rassurante est bien loin de la réalité des projets. Les activités d’ingénierie ne sauraient se succéder strictement sans qu’aucun changement ne vienne perturber un planning qui n’a de durée de vie que le temps de le prononcer. La conséquence est que plus de 80% des projets exécutés selon ces méthodologies connaissent des retards, des dépassements budgétaires, quand ils ne finissent pas en échec total, pour n’avoir pas su satisfaire les attentes des clients. Ces problèmes sont liés à plusieurs caractéristiques fondamentales de ces anciennes méthodologies : a a le rôle joué par le client : le client intervient principalement au moment du lancement du projet, à quelques jalons majeurs parfois espacés de plusieurs mois, et surtout en fin de projet pour la réception et la recette du système. Cet « effet tunnel » conduit à une solution souvent inadaptée et de piètre qualité. a a le mode contractuel forfaitaire qui : – – durcit les relations entre client et fournisseur, – – rend le passage de témoin long et douloureux à la fin du projet. a a une trop grande standardisation des activités d’ingénierie, dont l’enchaînement se révèle souvent inefficace. Formellement, les contrôles d’avancement et de qualité ne peuvent être menés que sur la base de documents dans les premières é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. a a le passage de relai entre les phases successives dans lesquelles œuvrent des équipes différentes, généralise une relation de type client-fournisseur et n’encourage ni l’empathie ni l’esprit d’équipe, bien au contraire. Chaque transition se traduit par une perte de temps, de savoir, d’informations ou de responsabilité. 1.1 A contrario, les méthodes Agiles préconisent : L’adoption d’un cycle itératif et incrémental permettant à une équipe de s’adapter au contexte ainsi qu’aux changements qui ne manquent pas de survenir au cours d’un projet. L’implication du client dans le développement, permettant au client et à l’utilisateur de donner leur feedback quant au devenir de l’application en cours de développement, annulant ainsi tout « effet tunnel ». La définition d’objectifs à court terme qui permet de maintenir une pression constante mais supportable sur l’équipe, alors qu’au début d’un cycle en V chacun a l’impression d’avoir suffisamment de temps devant lui et subit finalement une pression énorme à l’approche de la livraison. La collaboration entre les personnes et l’intégration des équipes qui combat les fameux passages de relais en rassemblant dans un même espace toutes les énergies et la compétence de personnes centrées sur l’application à réaliser. Plus aucune barrière et des tâches définies par l’équipe au meilleur moment, c’est-à-dire quand on en a besoin, plutôt qu’au début du projet. La livraison d’un produit opérationnel de bonne qualité parce que souvent testé, doté de la seule documentation strictement nécessaire, et répondant à uploads/Ingenierie_Lourd/ livre-blanc-methodes-agiles-pdf.pdf

Tags
Ingénierie projet pratiques agile agiles développement
Documents similaires
  • 16
  • 0
  • 0
Afficher les détails des licences
Licence et utilisation
Gratuit pour un usage personnel Attribution requise
Partager