FORMATION ISAIP

1. FORMATION ISAIP Les Nouvelles Méthodologies de gestion de projet Source Bibliographique : Anne-Marie Hugues ALEXANDRE LEPRIEULT

2. Les nouvelles Méthodes • Avec l’apparition de la programmation orientée Objet et l’utilisation d’UML et des RADs de nouvelles Méthodologies ont vues le jours. • Certaines telles Merise Objet , RAD sont franco-françaises , d’autre comme RUP sont fortement liées à un éditeur d’atelier de génie logiciel (Rational/IBM) • D’autre enfin sont plus génériques comme 2TUP ,XP et DSDM Toutes ces méthodes sont regroupées sous le nom génériques de méthodes Agiles ALEXANDRE LEPRIEULT

3. Les nouvelles Méthodes • Les points communs de ces méthodes sont : • Elle sont itératives en oppositions avec les méthodes classiques qui sont linéaires et qui interdisent de revenir sur les étapes précédentes (ou tout au plus revenir d’un niveau) • Le client est partie intégrante de l’équipe projet • Elles font massivement appelles aux prototypes dans toutes les étapes • Elles utilisent UML et les RAD ALEXANDRE LEPRIEULT

4. Contexte • Les méthodes de gestion de projet informatique connaissent, au même titre que les technologies mises en œuvre, une remise en cause permanente. • La proportion importante d’échec des projets vient souvent alimenter des réactions plus ou moins constructives aux méthodes mises en œuvre. Les évolutions des architectures technologiques et des outils de développement y contribuent également pour part importante. • Ainsi, UML et Unified Process sont venues en réaction aux méthodes dites « merisiennes » (cycle en V, etc.) à la fois poussées par les technologies objet et les insuffisances de méthodes préconisant des cycles très longs. ALEXANDRE LEPRIEULT

5. Contexte • Les méthodes agiles n’échappent pas à la règle. Mais elles s’inscrivent dans une démarche plus radicale, que l’on pourrait résumer par « trop de méthode tue la méthode ». • De manière générale, leur but est d'augmenter le niveau de satisfaction des clients tout en rendant le travail de développement plus facile. Mais les véritables fondements des méthodes agiles résident plus précisément dans deux caractéristiques : ALEXANDRE LEPRIEULT

6. Les méthodes agiles sont "adaptatives" plutôt que prédictives • Si les méthodes lourdes tentent d’établir dès le début d’un projet un planning à la fois très précis et très détaillé du développement sur une longue période de temps, cela suppose que les exigences et spécifications de base restent immuables. Or, dans tous les projets, les exigences changent au cours du temps et le contexte évolue aussi. Par conséquent, si elles fonctionnent sur des projets courts et de petite taille, ces méthodologies sont trop réfractaires au changement pour pourvoir être appliquées à des projets plus importants. A l’inverse, les méthodes agiles se proposent de réserver un accueil favorable au changement : ce sont des méthodes itératives à planification souple qui leur permettent de s’adapter à la fois aux changements de contexte et de spécifications du projet. ALEXANDRE LEPRIEULT

7. Les méthodes agiles sont orientées vers les personnes plutôt que vers les processus • Les méthodes agiles s’efforcent de travailler avec les spécificités de chacun plutôt que contre la nature de chacun pour que le développement soit une activité plaisante où chacun se voit confier une part de responsabilité. • Nées en réaction aux méthodes traditionnelles, il existe une grande diversité de méthodes auxquelles ont peut donner le qualificatif d’agile. Avant de passer en revue les spécificités de chacune parmi les principales d’entre elles dans une seconde partie, essayons tout d’abord de dégager les principales caractéristiques communes à toutes ces méthodes, autrement dit : qu’est ce qui fait qu’une méthode de développement est une méthode agile ? ALEXANDRE LEPRIEULT

8. Priorité aux applications fonctionnelles sur une documentation pléthorique • Les partisans des méthodes agiles affirment la légitimité d’une certaine forme de documentation mais ils dénoncent les effets pervers d’une documentation pléthorique. En effet, l’écriture et le maintien à niveau de la documentation sont extrêmement consommateurs de ressources. Un document qui n’est pas mis à jour régulièrement devient très rapidement totalement inutile, voire même trompeur. Le manifeste est donc favorable aux documentations succinctes, ne décrivant que les grandes lignes de l’architecture du système mais régulièrement tenues à jour, et d’une documentation permanente du code lui-même. Le meilleur transfert des connaissances sur le système s’effectue de toute manière par la participation au travail de l’équipe ALEXANDRE LEPRIEULT

9. Priorité de la collaboration avec le client sur la négociation de contrat • Le succès d’un projet requiert un feedback régulier et fréquent de la part du client. Un contrat qui spécifie les exigences, le planning et le coût d’un projet a priori relève d’une vision utopique d’une projet informatique. La meilleure manière de procéder pour le client est de travailler en étroite collaboration avec l’équipe de développement, pour lui fournir un feedback continu qui assure un meilleur contrôle du projet. Ainsi, des modifications de spécifications peuvent intervenir très tard dans le cycle de développement du projet. C’est en définitive une solution répondant réellement aux attentes du client qui est réalisée et non une solution répondant aux exigences d’un contrat établi a priori. Nous le verrons en synthèse, ce point ne reste pas simple à mettre en œuvre. Cela nécessite bien sûr une grande maturité du client et du prestataire de service afin d’établir une réelle relation de confiance, ainsi qu’une bonne compréhension de la réalité opérationnelle du projet par les juristes en charge du dossier. ALEXANDRE LEPRIEULT

10. Priorité de l’acceptation du changement sur la planification • C’est la capacité à accepter le changement qui fait bien souvent la réussite ou l’échec d’un projet. Lors de la planification, il est donc nécessaire de veiller à ce que le planning soit flexible et adaptable aux changements qui peuvent intervenir dans le contexte, les technologies et les spécifications. • En effet il est très difficile de penser dès le début à toutes les fonctionnalités dont on aimerait disposer et il est très probable que le client modifie ses exigences une fois qu’il aura vu fonctionner une première version du système. ALEXANDRE LEPRIEULT

11. "Notre priorité est de satisfaire le client en lui livrant très tôt et régulièrement des versions fonctionnelles de l’application source de valeur" • Les méthodes agiles recommandent de livrer très tôt, dans les premières semaines si possible une version rudimentaire de l’application puis de livrer souvent des versions auxquelles les fonctionnalités s’ajoutent progressivement. De cette manière, le client peut décider à tout moment la mise en production de l’application, dès qu’il la considère comme assez fonctionnelle. A chaque version (release), un feedback de la part du client est nécessaire pour permettre soit de continuer le développement comme prévu, soit d’opérer des changements. De cette manière, les changements dans les spécifications interviennent tôt dans le processus de développement et sont moins problématiques. ALEXANDRE LEPRIEULT

12. RAD • Le RAD (Rapid Application Development) est né dans les années 80 à la suite d'un double constat. D'une part, le manque de concertation entre les informaticiens en charge de la réalisation d'un projet et les utilisateurs conduit souvent à la réalisation d'applications mal adaptées aux besoins. D'autre part les méthodes classiques de conduite de projet sont inadaptées à la vitesse des évolutions technologiques et la durée des projets est beaucoup trop longue. • Les objectifs premiers du RAD sont de conduire à l'amélioration de la qualité des développements tout en réduisant les délais et en facilitant la maîtrise des coûts. Pour cela, il est nécessaire d'associer méthodologie et relations humaines. Le RAD est fondamentalement une méthode basée sur la communication. • Les concepts du RAD ont été définis par James Martin avant d'être repris et adaptés au contexte français par Jean Pierre Vickoff dès 1989. • A ses début, le RAD a souvent été qualifié de "chaotique" et considéré comme une "absence de méthode" plutôt que comme une méthode. Si le RAD a souffert d'une si mauvaise image, c'est avant tout lié à la notion de rapidité qu'on a souvent tendance à considérer, à tort, comme incompatible avec celle de qualité. Pour éviter ce malentendu, Jean Pierre Vickoff propose de traduire RAD par "développement maîtrisé d'applications de qualité approuvée par les utilisateurs". ALEXANDRE LEPRIEULT

13. Les acteurs du RAD • Dans un projet RAD, la répartition des rôles est très structurée. Comme dans une approche classique, l'ensemble de l'organisation s'appuie sur un principe fondamental : la séparation des rôles opérationnels et des responsabilités entre d'une part la maîtrise d'ouvrage (MOA) qui représente l'utilisateur et à ce titre détermine les fonctionnalités à développer et leur degré de priorité. ALEXANDRE LEPRIEULT

14. Les acteurs du RAD • D’autre part la maîtrise d'œuvre (MOE) qui apporte les solutions techniques aux problèmes posés par la maîtrise d'ouvrage. (Cette séparation des rôles est encore renforcée par la présence du Groupe d'animation et de Rapport RAD qui se charge d'organiser la communication du projet. Son rôle principal est de faciliter l'expression des exigences et de les formaliser en temps réel. ALEXANDRE LEPRIEULT

15. La maîtrise d'ouvrage • La maîtrise d'ouvrage a trois responsabilités principales: • Définir les objectifs et les exigences du système : le maître d'ouvrage, qui préside le comité de pilotage est responsable de la rédaction de documents de cadrage dans lesquels sont explicités les objectifs d'ordre stratégique, fonctionnel, technologique, organisationnel, ainsi que les contraintes de projet. Ces objectifs, classés par ordre de priorité servent de base pour la prise de décisions de pilotage. Le maître d'ouvrage spécifie aussi les exigences en déléguant leur mise en forme à diverses personnes compétentes : par exemple, les exigences fonctionnelles sont exprimées par des représentants d'utilisateurs et des experts fonctionnels. • Valider les solutions proposées et élaborées : en collaboration avec les personnes qui ont exprimé les exigences, le maître d'ouvrage vérifie que la ou les solutions proposées par la maîtrise d'œuvre permettent bien de satisfaire ces exigences. • Préparer et piloter le changement induit : il s'agit là d'opérations de sensibilisation, formation, communication ainsi que d'organisation. ALEXANDRE LEPRIEULT

16. MO: trois acteurs principaux • Maître d'ouvrage : prend des décisions sur les objectifs (produit, coût, délai) et les orientations du projet et décide in fine l'expression des exigences et la validation des solutions ainsi que les moyens à mettre en œuvre au sein de la maîtrise d'ouvrage. • Coordinateur de Projet Utilisateurs ou Maître d'Ouvrage délégué : coordonne et valide les activités de la maîtrise d'ouvrage. Réalise le suivi des objectifs (produits, coûts / charges, délais) et des activités de la maîtrise d'ouvrage. • Responsable de la cohérence et de la qualité fonctionnelle : supervise l'expression des exigences et de la validation des solutions, contrôle la cohérence des décisions prises dans les domaines fonctionnels. Supervise la vérification de la qualité fonctionnelle (point de vue utilisateurs) des solutions proposées et élaborées. ALEXANDRE LEPRIEULT

17. Maitrise d’œuvre • Elle a également trois responsabilités principales: • Proposer et réaliser la solution : cela passe notamment par la définition, et la mise en œuvre du planning et des moyens humains et logistiques nécessaires. • Livrer des "fonctionnalités" : on entend par fonctionnalités les produits finis mais aussi des produits intermédiaires et diverses informations qui permettront à la maîtrise d'ouvrage de préparer et de piloter le changement. Les dates de fourniture de ces différents livrables figurent au planning. • Respecter les directives du Plan d'Assurance Qualité : en même temps que la réalisation de l'application, la maîtrise d'œuvre réalise son suivi sur des critères tels que les fonctionnalités, la qualité, le planning, les coûts, la visibilité. ALEXANDRE LEPRIEULT

18. ME: trois acteurs principaux • Maître d'œuvre : propose des objectifs (coût, délai en particulier) et des orientations pour le projet. Décide in fine les propositions de solution et les solutions elles-mêmes qui seront élaborées. Décide des moyens et méthodes à mettre en œuvre au sein de la MOE. Se coordonne avec les MOE des autres projets et les sociétés extérieures participant à la MOE du projet • Pilote de Projet Informatique : coordonne les travaux de la MOE. Valide les propositions de solution et les solutions elles-mêmes élaborées par la MOE. Estime et met en œuvre les moyens MOE (planning de production, méthodes et outils) • Responsable par domaine : pilote et suit l'équipe de production d'un domaine. ALEXANDRE LEPRIEULT

19. Le Groupe d'animation et de Rapport RAD • Le groupe d'animation et de rapport (GAR) a pour responsabilités la préparation des réunions (convocation, logistique et suivi), l'organisation des séances de travail, la formalisation des exigences exprimées, la gestion des comptes-rendus, la planification et l'animation des focus. • L'animateur doit adopter une attitude directive sur la forme et non directive sur le fond. Il se garde d'émettre un avis personnel, de porter un jugement et de favoriser des opinions. Il n'ajoute rien au discours des participants et se contente de maintenir les discussions bien centrées sur le thème voulu et de canaliser les entretiens. Pour cela, il peut procéder par exemple par synthèse (résumer l'essentiel en le reformulant) ou par élucidation (forcer les gens, par le biais de questions, à aller jusqu'au bout d'une idée). • Le rapporteur doit être capable de produire une documentation automatisée et de la maintenir à jour. C'est tout d'abord un analyste concepteur, spécialement formé aux AGL (Ateliers de génie Logiciel). Lors des réunions portant sur la conception du système, il doit être capable de le modéliser en direct. Il est aussi responsable de la synthèse des comptes-rendus de réunion ALEXANDRE LEPRIEULT

20. LES ROLES • L'organisation du projet s'appuie sur un principe fondamental : la séparation des rôles et des responsabilités entre maîtrise d'ouvrage (MOA) et maîtrise d'œuvre (MOE). Cette dichotomie renforcée par la présence d’une instance d’animation RAD(Groupe d’Animation et de Rapport (GAR)) implique une véritable réingénierie des méthodes de conduite de projet et impose aux deux maîtrises une redistribution des rôles opérationnels et un apprentissage : • La maîtrise d’ouvrage représente l'utilisateur. Elle détermine les fonctions, leurs priorités et impose la " dynamique applicative ". • Elle utilise des formes de modélisation simplifiées pour représenter la vision de son travail [Henry, Monkam-Daverat 1995] et ses scénarios opérationnels (use case) [Jacobson 1993]. • La maîtrise d’œuvre s’affirme comme une force de " solution et de proposition " techniques. • Sous la pression des nouveaux types d'applications et des contraintes économiques, elle fusionne en un seul profil de concepteur-développeur les rôles de l'analyste et du programmeur [Bouchy 1994]. • Le Groupe d'animation et de Rapport RAD organise la communication du projet. Il facilite l’expression des exigences et réalise en " temps réel " leur formalisation. • Il se compose d'intervenants spécialisés en communication et en entretiens de groupe [Sary 1990]. Il dispose de matériels et de logiciels adéquats dans une salle dédiée. Il réalise " en direct " la synthèse (rapporteur-secrétaire) et la modélisation (rapporteur-modélisateur) à partir du discours utilisateur [Vickoff 1996]. • Je suis un dirigeant ou un cadre décisionnaireMes préoccupations sont : la stratégie, la visibilité et les résultatsJe suis cadre d'un service utilisateurMes préoccupations sont : l'adéquation de l'outil à mes besoins et les conditions de ma participationJe suis un chef de projet informatiqueMes préoccupations sont : le pilotage, la fiabilité, le budget, le délai ALEXANDRE LEPRIEULT

21. Les cinq phases d'un projet RAD • Initialisation (préparation de l’organisation et communication ) Cette phase, qui représente environ 5% du projet, définit le périmètre général du projet, établit la structure du travail par thèmes, recense les acteurs pertinents et amorce la dynamique du projet. • Cadrage (analyse et expression des exigences) C'est aux utilisateurs de spécifier leurs exigences et d'exprimer leurs besoins lors d’entretiens de groupe. Il est généralement prévu de 2 à 5 jours de sessions par commission (thème). Cette phase représente environ 10% du projet. • Design (conception et modélisation) Les utilisateurs participent à l’affinage et à la validation des modèles organisationnels : flux, traitements, données. Ils valident également un premier prototype ayant pour but de présenter l’ergonomie et la cinématique générale de l’application. 4 à 8 jours de sessions sont prévus par commission. Cette phase représente environ 25% du projet. ALEXANDRE LEPRIEULT

22. Les cinq phases d'un projet RAD • Construction (réalisation, prototypage) Durant cette phase, l’équipe RAD (SWAT) construit au cours de plusieurs sessions itératives l’application module par module. L’utilisateur participe toujours activement aux spécifications détaillées et à la validation des prototypes. Cette phase représente environ 50% du projet. • Finalisation (recette et déploiement) Cette phase, qui représente environ 10% du projet permet une livraison globale et le transfert du système en exploitation et maintenance. ALEXANDRE LEPRIEULT

23. RAD et modélisation • S'il se veut efficace, le RAD se doit d'être rapide et donc d'utiliser des techniques de modélisation rigoureuses mais simplifiées. Le RAD ne préconise pas de technique de modélisation particulière : il est tout à fait possible d'utiliser des modèles objets comme UML ou des modèles de Merise, à condition de les alléger pour n'en conserver que ce qui est strictement indispensable. • Dans le cadre d'une approche "classique" par le haut de type merisienne, tous les modèle d'abstraction merisiens ne sont pas utilisés. Dans le cas général, ne sont conservés que le modèle Conceptuel de Communication (MCC), la hiérarchie de fonctions (ou MCT), le modèle Conceptuel de Données (MCD), et le modèle Organisationnel de Traitements (MOT). • Dans le cas d’un développement orienté objet, il est préconisé d’employer la notation ULM. Les principaux modèles sont les suivants : modèle de Classes, modèle d’Etat, modèle des Cas d’utilisation, modèle des Interactions, modèle de Déploiement. ALEXANDRE LEPRIEULT

24. EXTREME PROGRAMMING (XP) • L’Extreme Programming (XP) est un processus de développement logiciel, c’est-à-dire un ensemble de pratiques destinées à organiser le travail d’une équipe de développement. Ces pratiques se focalisent sur la construction proprement dite du logiciel, en aval des phases préparatoires d’études d’opportunité ou de faisabilité. • XP est l'un des principaux représentants d'une famille émergente de processus : les processus dits "agiles", qui se démarquent des démarches traditionnelles en mettant l’accent sur le travail d’équipe et la réactivité. L’heure est à l’économie et à l’efficacité : « Quelles activités pouvons nous abandonner tout en produisant des logiciels de qualité ? ». Ou encore : « Comment mieux travailler avec le client pour nous focaliser sur ses besoins les plus prioritaires et être aussi réactifs que possible ? » ALEXANDRE LEPRIEULT

25. EXTREME PROGRAMMING (XP) XP propose une réponse originale à ces questions, avec un ensemble de pratiques organisées autour des principes suivants • Le client (maîtrise d’ouvrage) pilote lui-même le projet, et ce de très près grâce à des cycles itératifs extrêmement courts (1 ou 2 semaines). • L’équipe livre très tôt dans le projet une première version du logiciel, et les livraisons de nouvelles versions s’enchaînent ensuite à un rythme soutenu pour obtenir un feedback maximal sur l’avancement des développements. • L’équipe s’organise elle-même pour atteindre ses objectifs, en favorisant une collaboration maximale entre ses membres. • L’équipe met en place des tests automatiques pour toutes les fonctionnalités qu’elle développe, ce qui garantit au produit un niveau de robustesse très élevé. • Les développeurs améliorent sans cesse la structure interne du logiciel pour que les évolutions y restent faciles et rapides. ALEXANDRE LEPRIEULT

26. OUVERTURE AU CHANGEMENT • Les démarches traditionnelles, basées sur la fameuse séquence « spécification > conception >réalisation > validation », concentrent la plupart des décisions en début de projet ALEXANDRE LEPRIEULT

27. OUVERTURE AU CHANGEMENT • L’objectif de cette approche est louable : le client veut des garanties sur ce qu’il obtiendra en fin de projet, et le chef de projet souhaite disposer des informations nécessaires à l’organisation de son équipe. • Malheureusement, les équipes qui évoluent dans un environnement changeant ou complexe savent à quel point il est difficile de s’en tenir aux décisions initiales. Le client réalise que ses besoins ont changé, ou bien l’équipe découvre en phase d’implémentation des erreurs de spécification ou de conception qui compromettent les plans de développement. Le changement s’impose donc tôt ou tard, mais voilà : cette organisation suppose l’absence de changement, et celui-ci se révèle bien vite très coûteux - suffisamment parfois pour compromettre la rentabilité du projet. • Mais puisque le changement est une composante incontournable de tout projet de développement logiciel, pourquoi ne pas l’accepter ? N’existe-t-il pas un moyen pour que les équipes de développement n’opposent plus de rigidité excessive aux demandes de leur maîtrise d’ouvrage ? ALEXANDRE LEPRIEULT

28. OUVERTURE AU CHANGEMENT • Les créateurs d’XP ont trouvé une réponse à ces questions en découvrant que certaines pratiques d’organisation d’équipe et de programmation, appliquées ensemble, permettent de rendre le logiciel extrêmement malléable à tel point qu’il devient plus avantageux de le faire évoluer progressivement que de chercher à le spécifier et le concevoir complètement dès le départ. • Partant de ce constat, ils ont conçu une démarche qui diffuse le processus de décision tout au long du projet grâce à l’enchaînement de cycles itératifs très courts. • Le grand gagnant de cette démarche est d’abord le client du projet. Plutôt que de voir son intervention cantonnée à la phase initiale de recueil du besoin, il intègre véritablement le projet pour en devenir le pilote. A chaque itération, il choisit lui-même les fonctionnalités à implémenter, collabore avec l’équipe pour définir ses besoins dans le détail, et reçoit une nouvelle version du logiciel qui intègre les évolutions en question. ALEXANDRE LEPRIEULT

29. OUVERTURE AU CHANGEMENT Cette démarche présente de nombreux avantages en termes de conduite de projet : • Le client jouit d’une très grande visibilité sur l’avancement des développements. • Le client utilise le logiciel lui-même comme support de réflexion pour le choix des fonctionnalités à implémenter .il peut en particulier intégrer très tôt les retours des utilisateurs pour orienter les développements en conséquence. • La première mise en production du logiciel intervient très tôt dans le projet, ce qui avance d’autant le moment à partir duquel le client peut en tirer des bénéfices. • L’ordre d’implémentation des fonctionnalités n’est pas guidée par des contraintes techniques, mais par les demandes du client. Celui-ci peut donc focaliser les efforts de l’équipe sur les fonctionnalités les plus importantes dès le début du projet, et ainsi optimiser l’utilisation de son budget ALEXANDRE LEPRIEULT

30. LE CYCLE DE DÉVELOPPEMENT XP • L’Extreme Programming vise une réduction significative de la durée du cycle de développement, c’est-à-dire du temps qui s’écoule entre le moment où l’on décide d’implémenter une fonctionnalité et celui où l’on met en production une nouvelle version du logiciel qui intègre la fonctionnalité en question. • Dans un projet XP, ce temps correspond exactement à la durée d’une itération, c’est-à-dire typiquement deux semaines. Chaque itération reprend la structure suivante ALEXANDRE LEPRIEULT

31. LE CYCLE DE DÉVELOPPEMENT XP ALEXANDRE LEPRIEULT

32. LE CYCLE DE DÉVELOPPEMENT XP • Le premier jour de l’itération est consacré à la réunion de planification, au cours de laquelle le client et l’équipe conviennent de ce qui doit être implémenté au cours de l’itération. A la fin de cette journée, l’équipe dispose de la liste précise des tâches à réaliser. • Ensuite, l’équipe s’organise pour réaliser les tâches en question. Elle prend en charge le suivi des tâches, ainsi que les activités d’analyse du besoin, de conception, d’implémentation et de test correspondantes. Il est important de noter qu’il n’y a pas de changement de cap intermédiaire : l’équipe se focalise sur son objectif sans interruption jusqu’à la fin de l’itération. • Au terme des deux semaines, l’équipe met une nouvelle version du logiciel à disposition du client. Ce logiciel est robuste, testé, et sa structure interne est laissée aussi propre que possible pour que les prochaines évolutions y restent peu coûteuses. ALEXANDRE LEPRIEULT

33. LE CYCLE DE DÉVELOPPEMENT XP Cette organisation extrêmement réactive impose de nouvelles contraintes sur le fonctionnement de l’équipe, susceptibles de mettre en défaut les pratiques traditionnelles du développement logiciel. Par exemple : • Puisque le contenu fonctionnel du produit ne se décide précisément qu’au fur et à mesure des itérations, il n’est plus judicieux de faire reposer l’implémentation sur une conception définie en début de projet. Dans une démarche purement itérative, l’équipe doit être capable de faire émerger la conception tout au long du développement pour suivre les directions données par le client. • En termes d’organisation d’équipe, il n’est plus judicieux de séparer l’application en modules réservés à tel ou tel développeur puisque pour une itération donnée rien n’empêche le client de demander des fonctionnalités centrées sur un seul module. Tous les développeurs doivent donc être en mesure de travailler sur toute l’application. ALEXANDRE LEPRIEULT

34. LES PRATIQUES XP • Les pratiques XP sont pour la plupart des pratiques de bon sens utilisées par des développeurs et des chefs de projets expérimentés. On retrouve par exemple les tests unitaires automatisés, les livraisons fréquentes ou encore les relectures de code. • La première nouveauté d'XP consiste à pousser ces pratiques à l'extrême (d’où le nom de la méthode), ou comme le disent ses auteurs "tourner tous les boutons jusqu'à 10 !" L’équipe utilise des cycles de développement d’une ou deux semaines, les développeurs écrivent des tests unitaires pour chaque classe, ils se livrent à une relecture de code permanente via le travail en binômes, etc. • La seconde nouveauté d’XP consiste à organiser ces pratiques en un tout cohérent, de sorte que chaque pratique renforce les autres. Il en résulte une méthode complète, qui couvre tous les aspects du développement - de la relation avec le client jusqu'à l'écriture du code, en passant par les plannings et l'organisation de l'équipe. ALEXANDRE LEPRIEULT

35. principaux éléments du fonctionnement d’XP • Cycles itératifs pilotés par le client : Le projet progresse au rythme d’itérations très courtes, dont le contenu fonctionnel est déterminé par le client. • Travail d’équipe auto-organisé : L'équipe travaille réellement... en équipe. Les développeurs organisent eux-mêmes leur travail, interviennent sur l’ensemble du code, travaillent systématiquement en binômes, et synchronisent leurs développements plusieurs fois par jour. • Programmation pilotée par les tests : les développeurs écrivent des test automatiques pour chaque portion de code qu’ils conçoivent, et ils s’appuient sur ces tests pour affiner et améliorer sans cesse la conception de l’application sans craindre de régression. ALEXANDRE LEPRIEULT

36. Le rôle de « client XP » • Le pilotage du projet est assuré par un membre spécifique de l’équipe projet : le « client ». Le client détermine les fonctionnalités du logiciel, gère les priorités, définit les spécifications précises du produit en somme, ce rôle correspond à ce que nous nommons en France la maîtrise d’ouvrage du projet. Dans un projet XP, ce représentant de la maîtrise d’ouvrage rejoint le projet à plein temps. ALEXANDRE LEPRIEULT

37. La phase initiale d’exploration • Le projet démarre par une phase d’exploration volontairement très courte (typiquement un mois maximum), qui a pour triple objectif de définir le contenu fonctionnel de l’application, établir un premier plan de développement pour le projet, et produire la toute première version du logiciel. • Au cours de cette phase, le client explore et définit le contenu fonctionnel qu’il souhaite voir implémenté dans le produit. Il établit ainsi une liste de fonctionnalités, qui prennent en XP la forme de « scénarios client ». • Un scénario client décrit en quelques mots un besoin particulier du client. Par exemple, pour un logiciel de gestion de carnet d'adresses le client pourrait écrire les scénarios suivants : • "Je rentre un nom ou prénom, et le logiciel affiche la liste de toutes les personnes qui possèdent ce nom ou ce prénom" • "Je peux exporter mon carnet d'adresses au format HTML." ALEXANDRE LEPRIEULT

38. Planification du projet La planification est réalisée au cours d’une réunion dédiée, qui réunit l’équipe et le client et se déroule comme suit : 1. Le client présente les différents scénarios à l’équipe, qui tente de se faire une idée de la charge de travail de chacun d’entre eux. 2. L’équipe donne pour chaque scénario une estimation de son coût d’implémentation, en « points » abstraits : tel scénario coûte 3 points, tel autre 1 point, etc. 3. L’équipe donne au client une estimation de sa « vélocité », c’est-à-dire du nombre de points de scénarios qu’elle s’estime capable de traiter en une itération – par exemple 10 points. Au tout début du projet cette vélocité est seulement estimée, mais après les premières itérations elle est réajustée en adoptant la règle suivante : la vélocité estimée pour une itération donnée correspond exactement au nombre de points effectivement traités à l’itération précédente. 4. Le client établit lui-même le plan de développement en affectant les différents scénarios aux itérations à venir, de sorte qu’à chaque itération la somme du nombre de points des scénarios choisis soit égale à la vélocité annoncée. ALEXANDRE LEPRIEULT

39. Première mise en production • Cette première mise en production intervient aussi tôt que possible dans le projet : il faut trouver le contenu fonctionnel minimal qui commence à avoir un sens pour les utilisateurs, quitte à faire preuve d’imagination en amenant par exemple le nouveau logiciel en complément d’un système existant dans le cadre d’une fonctionnalité bien précise. ALEXANDRE LEPRIEULT

40. Livraisons suivantes • Les mises en production s’enchaînent ensuite à un rythme régulier, toujours fixé par le client. L’objectif est d’obtenir un feedback très rapide sur le développement. en pratique toutes les une à six itérations selon la complexité de déploiement du produit. Le plan de développement est continuellement mis à jour si nécessaire pour tenir compte des événements suivants : • L’équipe de développement progresse à une vitesse différente de celle prévue (dans le bon ou le mauvais sens) • Le client décide de changer le contenu des itérations restantes. Il peut ainsi permuter des scénarios en fonction de nouvelles priorités, ou encore remplacer certains scénarios du plan par de nouveaux. ALEXANDRE LEPRIEULT

41. Tests de recette automatiques • Pour chaque scénario planifié, un ensemble de tests de recette est écrit. Ces tests ont pour but de vérifier de manière automatique (c’est-à-dire sans intervention ou interprétation humaine) chacune des fonctionnalités demandées par le client. Le client définit ces tests et participe éventuellement à leur implémentation, assisté pour cela d’un certain nombre de testeurs. • Ces tests peuvent prendre plusieurs formes. Il peut s’agir de jeux de données, sous forme par exemple de feuilles de tableur ou de fichiers XML, qui définissent une transformation effectuée par le logiciel : « pour telle entrée, le logiciel doit produire tel résultat ». Il peut s’agir également de scripts pour les cas plus complexes, ces scripts décrivant par exemple des séquences d’interactions de l’utilisateur avec l’interface graphique du produit. • Ces tests représentent dans un projet XP les spécifications détaillées de l’outil – des spécifications formelles, toujours en phase avec le développement. Dans un contexte « pur XP », ce sont les seules spécifications : il n’y a pas de document de spécifications à proprement parler. En pratique, cependant, des documents peuvent être exigés par l’organisation qui encadre le projet. Des documents synthétiques sont alors réalisés par le client. ALEXANDRE LEPRIEULT

42. Travail d’équipe auto-organisé • L’organisation d’une équipe XP s’éloigne de l’organisation traditionnelle d’une équipe de développement, dans lequel différents développeurs travaillent sur des parties distinctes de l’application, coordonnés par un chef de projet responsable de l’intégrité de l’ensemble. Ce schéma de séparation des activités fait place dans XP à un schéma d’intégration, ou de collaboration intensive. ALEXANDRE LEPRIEULT

43. Responsabilité collective du code • Chaque développeur d’une équipe XP est susceptible de travailler sur toutes les parties de l'application, sans être bloqué par une éventuelle spécialisation initiale. Cette liberté d’action s’accompagne toutefois d’une responsabilité : chaque membre de l’équipe est garant de la qualité de l’ensemble de l’application – en particulier, chacun a le devoir de laisser le code qu’il parcourt aussi clair et propre que possible, pour faciliter le travail de ceux qui y intervienvront par la suite. ALEXANDRE LEPRIEULT

44. Travail en binômes • Les développeurs d’une équipe XP travaillent quasiment tout le temps en binômes, c’est-à-dire à deux sur un même poste. L’idée n’est en aucun cas d’avoir une personne qui code pendant que l’autre la surveille, mais au contraire d’aboutir à un dialogue permanent par lequel les deux membres du binôme sont engagés à 100% dans leur tâche. ALEXANDRE LEPRIEULT

45. Stand-up meetings • Chaque jour, toute l’équipe se réunit pour un « stand-up meeting » d’une quinzaine de minutes • les participants se tiennent d’ailleurs tous debout (d’où le nom) pour éviter que cela ne traîne. A l’occasion de cette réunion, tous les membres de l’équipe prennent la parole pour faire un point sur l’avancement de l’itération, et surtout pour organiser la journée de travail à venir. ALEXANDRE LEPRIEULT

46. Le rôle du coach • Dans un contexte où l’équipe s’organise elle-même en définissant et en choisissant ses tâches, le rôle de chef de projet tel que nous le connaissons devient inadéquat. L’activité de coordination de l’équipe est prise en charge par un « coach », qui est davantage un facilitateur qu’un donneur d’ordres. Le but du coach est en effet de former l’équipe aux pratiques XP, et ensuite de travailler en permanence sur les pratiques de l’équipe pour améliorer son fonctionnement et l’amener à l’autonomie. • Les fonctions hiérarchiques et administratives du chef de projet font l’objet dans XP d’un rôle particulier : le « manager ». Le manager est le patron de l’équipe, il s’assure qu’elle dispose des moyens nécessaire à son fonctionnement, fait l’interface avec le reste de l’organisation, et vérifie enfin que les résultats sont bien là. ALEXANDRE LEPRIEULT

47. PROGRAMMATION PILOTÉE PAR LES TESTS • La démarche extrêmement itérative proposée par XP n’est viable que si l’équipe est en mesure de garder la maîtrise technique de l’application, c‘est-à-dire de faire en sorte que les modifications du code restent longtemps faciles et rapides malgré les nombreuses évolutions. • Cette maîtrise n'est pas le fruit du hasard, elle est le résultat d’une discipline de développement qui s’appuie sur les pratiques suivantes : ALEXANDRE LEPRIEULT

48. PROGRAMMATION PILOTÉE PAR LES TESTS • Mise en place intensive de tests unitaires • En complément des tests de recette, qui servent à prouver au client que le logiciel remplit ses objectifs, XP utilise intensivement les tests unitaires de non-régression. Ces tests sont écrits par les développeurs en même temps que le code lui-même, pour spécifier et valider le comportement de chaque portion de code ajoutée. • Quasiment chaque classe de l'application possède une classe jumelle de test. Lorsque des développeurs doivent ajouter une nouvelle méthode à la classe applicative, ils commencent par ajouter à la classe de test un ensemble d'assertions qui décrivent le comportement de la méthode à ajouter. La méthode n'est implémentée qu'ensuite, pour que ces tests passent. Il est important de noter que les tests s'exécutent sans aucune interprétation de la part du développeur : les assertions en question doivent vérifier automatiquement si le code testé fonctionne ou non. • Les classes de tests ne sont pas jetées après usage : elles sont gérées par un framework dédié qui permet de les exécuter individuellement ou en totalité. La batterie de tests de l'application ne cesse donc de s'enrichir, et forme avec le temps un filet de sécurité qui permet aux développeurs d’effectuer des modifications dans le code existant sans crainte de régression. • Ces tests sont lancés à longueur de journée par les développeurs - en fait, à chaque compilation. Tous les tests unitaires doivent passer à 100% dans l’environnement d’un binôme avant tout report de modifications dans la version d'intégration du logiciel. ALEXANDRE LEPRIEULT

49. La démarche RAD DSDM • La méthode s'applique bien dans le cadre de petites applications de gestion, n'ayant pas de cycle de vie d'une trop longue durée ALEXANDRE LEPRIEULT

50. DSDM • 0 Etude de Faisabilité ; • 1 Etude du Business ; • 2 Modèle Fonctionnel Itératif ; • 3 Conception et Réalisation Itératives • 4 Mise en OEuvre ALEXANDRE LEPRIEULT