Les méthodes agiles en développement informatique : Fondements théoriques et retours d expérience

Transcription

1 Les méthodes agiles en développement informatique : Fondements théoriques et retours d expérience

2 Sommaire Préface... 3 Introduction... 5 Partie I : Les fondements théoriques... 7 Chapitre I : La méthode Scrum... 9 Les principes... 9 Les rôles... 9 Les outils Les modes opératoires Le modèle de développement Chapitre II : La méthode Extreme Programming Les principes Les rôles Les outils Les modes opératoires Le modèle de développement Chapitre III : La méthode de Développement Lean Les principes Les rôles Les outils et les modes opératoires Le modèle de développement Partie II : Retours d expérience Chapitre IV : Retours sur l adoption de certains modes opératoires agiles en entreprise Les tests unitaires et l intégration continue Le développement itératif La programmation en paire Les réunions quotidiennes Le client sur le site Les outils collaboratifs et de support au management Chapitre V : Retours sur l adoption des modes opératoires agiles dans un environnement géodistribué Les défis Les recommandations des praticiens Chapitre VI : Retours sur la question d un choix de méthode ou d un degré d agilité Analyse des risques et choix d hybridation Un levier de changement culturel Présentation d un cas de mise en œuvre d'une démarche «agile» Conclusion Bibliographie

3 Préface Pascal Buffard Président du CIGREF & Président d AXA Group Solutions La mutation des Grandes Entreprises au sein du monde numérique génère de profonds changements sur leurs stratégies, leurs modèles d affaires et leur gouvernance. Ces transformations modifient l image de l entreprise, ses modes de management, ses leviers de croissance, ses processus de création de valeur ; elles impactent les compétences des collaborateurs et induisent un nouveau type de leadership entrepreneurial. La fluctuation des grandes économies mondiales oblige aujourd hui les entreprises à relever un double défi. Elles doivent en premier lieu engager des projets de transformation leur permettant de préserver leur compétitivité en développant les nouveaux produits et services qu attendent leurs clients. Ces projets de transformation sont aussi le moyen d entrer de plein pied dans l ère de l entreprise numérique 1. Les technologies numériques - par leurs incidences sur les systèmes d informations modernes - sont en effet à la source de fabuleux gains de productivité dans tous les processus de l entreprise. Mais leur influence ne s arrête pas là : elles favorisent le développement de nouveaux modèles d affaires, l enrichissement des produits et des services, Dans beaucoup de secteurs, le numérique offre de nouvelles pistes de création de valeur. Dans le même temps, les entreprises doivent intégrer un fort degré d incertitude dans leurs perspectives et leurs plans de développements. La transformation de l entreprise dans le monde numérique implique de gérer les ruptures, grâce notamment à l innovation et au développement de nouveaux produits et services. Cette perspective a d ailleurs été mise en avant par la Fondation CIGREF, faisant apparaître un nouveau système productif, L Accéluction 2. Ce dernier est un mode de production caractérisé à la fois par l extension du champ de la production de valeur à de multiples espaces et l instantanéité des échanges transactionnels, c est- à- dire gouvernés par une logique de marchés, ou organiques, gouvernés à des degrés divers par la reconnaissance. Avec l introduction des technologies collaboratives et sociales, ce n est plus l information, mais la manière dont les salariés organisent leur travail qui est modifiée. Le développement d une vision stratégique commune et partagée sur le numérique passe alors par la diffusion d une culture numérique, au- delà de la seule optimisation des systèmes. Cette conviction est partagée par les auteurs de cet ouvrage, qui montrent, en accord avec les résultats de la Fondation CIGREF, que la diversité des pratiques collaboratives, l évolution du management de projets et la conciliation entre impératifs de sécurité et facilitation de la collaboration, sont des composantes centrales de l entreprise de cigref.org/l- entreprise- numerique- quelles- strategies- pour cigref.org 3

4 L avènement de l entreprise numérique 3 renforce ainsi significativement le poids de la composante SI dans l ensemble des projets. Cet accroissement de périmètre des projets «Système d Information» implique aussi une complexité plus grande et la nécessité de la contrôler. Les défis de la fonction SI face à la transformation de l entreprise dans le monde numérique sont en ce sens stratégiques et organisationnels, plus que technologiques. En effet, les technologies sont déjà présentes, et tout l enjeu aujourd hui est de réussir à la fois leur intégration dans les systèmes et leur usage, et ce de manière souple, agile et ouverte. La transformation numérique touche aussi à l agilité de l entreprise. Si l infrastructure et l architecture du SI sont concernées, c est surtout en termes d organisation que cela se joue : passer d une logique de produits à une logique de services nécessite d agir sur les processus, de les améliorer, avec la promesse de plus d efficacité et d une réduction ainsi que d une optimisation des coûts. In fine, l entreprise devra évoluer vers une «industrie» de transformation des processus internes pour offrir en externe un modèle «agile et efficace» de services. Mais la fonction SI se doit également d assurer l excellence opérationnelle et de gérer les risques, maintenant ainsi la cohérence du SI. L amélioration de la productivité interne consiste alors à faire cohabiter un SI «lourd» traditionnel de back office et un SI souple, basé sur le concept moderne de l ATAWAD Any Time, AnyWhere, Any Device (N importe Quand, N importe Où, Sur N importe quel Terminal). Pour cela, une grande efficience dans les modes de travail et dans le partage des connaissances est nécessaire. Dans ce cadre, l application des méthodes agiles décrites dans cet ouvrage sera un vecteur efficace dans l élaboration de services évolutifs répondant aux demandes des clients de la fonction SI. Les auteurs nous proposent ainsi de revenir aux fondements qui portent l agilité dans le développement au travers de trois méthodes judicieusement retenues parmi le large panel de contributions sur ce sujet. L ouvrage présente alors les moyens par lesquels ces méthodes répondent aux enjeux forts rencontrés par l organisation, lui conférant ainsi la capacité de reconfigurer son offre en réponse à l évolution de la demande client, et de faire évoluer les processus métiers. Penser la «transition numérique» de nos entreprises, c est savoir harmoniser vitesse, innovation et efficacité collective ; c est pouvoir concilier performance économique et environnement organisationnel ; c est vouloir mobiliser les valeurs d engagement, de coopération et de confiance! Ce livre expose parfaitement ces enjeux et propose de répondre à ces problématiques en fournissant aux collaborateurs de la Fonction SI tous les outils permettant d accroître la compétitivité de l entreprise par une parfaite maîtrise du déploiement des méthodes agiles, élément clé pour faire face aux défis apportés par la transformation numérique des entreprises. 3 et- cultures- numeriques.org 4

5 Introduction Les méthodes «agiles» ont formellement reçu leur nom en 2001 avec la publication d un manifeste, «Manifesto for Agile Software Development», signé par dix- sept experts du domaine du développement informatique. La thèse qui y est défendue est celle de nouveaux modes de management de projet logiciel plus «agiles», «légers», que les méthodes alors en vigueur. L «agilité» invoquée renvoie à la capacité que ces méthodes sont censées donner aux équipes de développement informatique de s adapter aux changements et contourner les difficultés rencontrées dans la conduite de projets rendue de plus en plus complexe dans des marchés mouvants et fortement concurrentiels. Les dix années qui ont suivi la publication du manifeste ont connu un foisonnement de la littérature tant académique que professionnelle sur ce thème. Les colloques, conférences ou séminaires animés par chercheurs, cabinets conseils ou communautés de professionnels, ont contribué par ailleurs à nourrir ce qui est devenu un nouveau paradigme, une nouvelle doctrine de management de projet : «les méthodes agiles». Qu en est- il aujourd hui de ce paradigme? Les retours d expérience d entreprises ayant mis en œuvre des méthodes agiles se fondent désormais sur un temps de déploiement suffisamment long pour que l on puisse en tirer des enseignements stables et dépasser les premières hypothèses formulées sur ce sujet. Pour autant, le terme d agilité apparaît désormais quelquefois galvaudé, ne pointant plus un ensemble de caractéristiques données mais une dynamique d intentions à partir de laquelle sont nées nombre d imprécisions. C est dans la perspective de ce constat que cet ouvrage a été défini : repréciser les fondements théoriques des méthodes agiles, rendre compte de retours d expérience d entreprises. Le parti- pris analytique est engageant : il est de dépasser les discours produits sur ces méthodes en référençant aux principaux travaux de recherche publiés sur les thèmes concernés, l intégralité de l argumentaire de l ouvrage. Cet ouvrage vise à rendre visible, auprès des professionnels, les recherches le plus souvent empiriques, réalisées sur les méthodes agiles en développement informatique. Mais l ouvrage se destine également aux chercheurs qui pourront y trouver une synthèse des travaux réalisés sur le thème. L objectif assigné à cet ouvrage a orienté son format et sa structure. Le format renvoie à une présentation simplifiée de revue de la littérature. Les auteurs auxquels nous nous référons pour fonder les arguments développés dans ce livre sont donnés dans le corps du texte et à travers une bibliographie étendue en fin de manuscrit. L ouvrage s articule en deux parties. La première est l occasion de revenir sur les caractéristiques clefs des principales méthodes constitutives du mouvement agile. La deuxième expose les défis observés auxquels doivent faire face les entreprises engagées dans le déploiement de méthodes agiles. La conclusion propose une relecture synthétique 5

6 de l ouvrage à l aune de ce qui constitue le fondement de l ensemble des méthodes agiles : le développement des compétences des acteurs des projets informatiques. «L agilité» qui permet aux équipes de développement informatique de s adapter aux changements des demandes du client, de contourner ou résoudre rapidement les difficultés rencontrées dans la conduite de projets, repose fondamentalement sur les compétences des membres d une équipe, qui, plus que préexistantes, sont acquises «in situ» dans les pratiques de développement des projets en cours. Ainsi, la thèse avancée dans cet ouvrage est que toutes les méthodes agiles, dans leur philosophie commune et dans la diversité des pratiques d ingénierie qu elles préconisent, participent à structurer les modes d apprentissage d une équipe projet. Comme nous le verrons, les principes de transparence et de communication entre les membres d une équipe, encadrés par des pratiques de debriefing systématiques, de codage réalisé par des binômes de programmeurs, de tests systématiques favorisent la création et le partage de connaissances dans l action. Les méthodes agiles, ensemble de «bonnes pratiques» de management de projet, préconisent des règles de jeu très strictes ; elles norment les contenus et durées des réunions, les rôles joués par les acteurs du projet, systématisent les tests, : elles «rigidifient» les modes de gestion en vue de favoriser la montée en compétences des acteurs projets et créer ainsi de «l agilité». 6

7 Partie I : Les fondements théoriques Le qualificatif «agile» est une appellation générique. En matière de développement informatique, il est utilisé pour nommer indifféremment un ensemble ouvert et en progression de méthodes parmi lesquelles (et par ordre chronologique d apparition) le «Rapid Application Development», la «Dynamic Systems Development Method», la «Scrum», le «Feature Driven Development», l «Extreme Programming», l «Adaptive Software Development» ou encore la méthode de Développement Lean. La plupart de ces méthodes ayant été conçues par essaimage ou en réponse aux méthodes précédentes, il apparait entre elles à la fois un grand nombre de similitudes et des éléments de complémentarité. Dans les années 2000, il fût néanmoins possible de classer l ensemble de ces méthodes sous le substantif commun d «agile» car toutes partageaient les valeurs minimales consignées par 17 éminents praticiens 4 dans un document qui fera date : le «Manifeste Agile». Les valeurs de l agilité en matière de développement informatique y étaient clarifiées ainsi par ces praticiens : «Il est nécessaire de valoriser : - Les individus et les interactions plutôt que les processus et les outils ; - L application fonctionnelle plutôt que la documentation compréhensive ; - La collaboration avec le client plutôt que la négociation des contrats ; - La réponse au changement plutôt que le suivi d un plan.» (Manifesto for Agile Software Development, 2001) Dans le présent ouvrage, nous avons choisi de concentrer notre attention sur trois méthodes agiles en particulier : la méthode Scrum, la méthode Extreme Programming et la méthode de Développement Lean. Ce choix a été guidé par un triple critère. Le premier renvoie au positionnement de l ouvrage. Notre objectif n est pas de produire un manuel descriptif ou un guide d utilisation précis sur l ensemble des méthodes agiles mais de questionner l appropriation, par les organisations, des principes fondamentaux et des modes opératoires communs à la plupart de ces méthodes. Pour cette raison, nous consacrons cette première partie de l ouvrage à une présentation 4 Kent Beck, James Grenning, Robert Martin, Mike Beedle, Jim Highsmith, Steve Mellor, Arie van Bennekum, Andrew Hunt, Ken Schwaber, Alistair Cockburn, Ron Jeffries, Jeff Sutherland, Ward Cunningham, Jon Kern, Dave Thomas, Martin Fowler et Brian Marick. 7

8 de trois méthodes, relativement détaillée mais non exhaustive et surtout orientée sur les facteurs critiques d adoption, facteurs qui seront ensuite discutés par l analyse des retours d expérience d entreprises ayant mis en œuvre ces méthodes. Le deuxième critère est celui de la complémentarité d approche entre les trois méthodes agiles retenues. En première approximation, il est possible de signaler que la méthode Scrum développe une conception de l agilité davantage portée par les équipes de développement quand la méthode Extreme Programming envisage plus radicalement l agilité au travers d outils et de procédures d ingénierie et de gestion. La méthode de Développement Lean complète ce panorama en défendant une posture davantage macroscopique de l agilité avec des modalités de mise en œuvre moins spécifiées. Le troisième critère de choix a trait à la diffusion des méthodes choisies dans la sphère professionnelle. En 2009 et en France, une enquête nationale sur les méthodes agiles 5 a montré que les méthodes agiles les plus utilisées en entreprise étaient la méthode Scrum (86% 6 ) la méthode Extreme Programming (52%) et la méthode de Développement Lean (14%). Comme nous l avons souligné, le mouvement agile se définit par un ensemble de méthodes emblématiques, elles- mêmes caractérisées par une série de principes fondamentaux qui se traduisent dans les organisations par la création de modes opératoires et d outils de gestion. Par souci de clarté nous souhaitons utiliser dans cet ouvrage une terminologie précise nous permettant de distinguer le «mouvement agile», des «méthodes agiles», des «principes agiles», des «modes opératoires agiles», des «outils agiles» et des «pratiques agiles». Le «mouvement agile» regroupe toutes les initiatives théoriques et empiriques sur le sujet. Les «méthodes agiles» qualifient les familles de procédures érigées en paradigmes de gestion et généralement connues sous une appellation popularisée en entreprise : la méthode Scrum, la méthode Extreme Programming, la méthode de Développement Lean. Les «principes agiles» sont les grandes règles de management sur lesquelles se fonde la promesse de l agilité dans l organisation. Toutes les méthodes agiles prévoient des «rôles» spécifiques attribués aux membres d une équipe projet visant les deux objectifs de qualité et de délais. Ces rôles, qui ne sont pas forcément doté d une autorité hiérarchique, aident à l animation de l équipe et renvoient à des missions de pilotage opérationnel, soutien technique des membres de l équipe par- delà celui de chef de projet. Les «modes opératoires agiles» visent à traduire les «principes agiles» sous une forme opérationnelle et facile d appropriation pour les praticiens concernés. Les «outils agiles» sont les instruments de gestion utilisés quotidiennement par les organisations qui mettent en œuvre des «méthodes agiles». Les «pratiques agiles» sont le résultat d une observation sur la manière dont les organisations se saisissent des substrats théoriques formés par les «méthodes agiles». Ainsi, les méthodes, les principes, les modes opératoires et les outils renvoient à une acceptation normative et structurante de ce que devrait être l agilité en organisation Le chiffre de 86% est à lire de la façon suivante : 86% des entreprises ayant recours aux méthodes agiles en développement informatique utilisent la méthode Scrum. 150 entreprises ont répondu à cette enquête. Le panel d entreprise considéré par l enquête est représentatif en termes de taille et de localisation géographique. 8

9 Chapitre I : La méthode Scrum Le terme «Scrum» fait référence à une pratique connue au rugby signifiant la «mêlée». La méthode Scrum fut popularisée après la publication en 2001 de l ouvrage de Ken Schwaber «Agile Software Development with Scrum» [1]. Avant la parution de cet ouvrage, H. Takeuchi et I. Nonaka écrivaient en 1986 un article intitulé «The New Product Development Game» dans lequel ils se référaient à la métaphore du scrum pour caractériser une approche de développement permettant d améliorer la cohésion de l équipe et la rapidité du processus de développement : «a rugby approach where a team tries to go to the distance as a unit, passing the ball back and forth- may better serves today s competitive requirements» [2]. La philosophie de base de la méthode Scrum, en référence à la «mêlée», renvoie à l idée d une équipe soudée, toujours prête à réorienter le projet au fil de son avancement. Les principes La méthode Scrum vise à créer un environnement fondé sur la transparence, le contrôle et l adaptation. La transparence consiste à s assurer que les avancées du projet informatique sont visibles des collaborateurs en charge du suivi des résultats. Le contrôle renvoie à un examen fréquent du processus de développement dans le but de déceler tout écart par rapport aux résultats attendus. L adaptation se traduit par des ajustements permanents en vue de réduire les risques de déviation. La méthode Scrum ne couvre aucune technique d ingénierie du logiciel. C est fondamentalement une méthode de management de projet qui s appuie sur le découpage de celui- ci en incréments, nommés «sprint», ainsi que sur l auto- organisation de l équipe projet. Chaque sprint commence par une estimation suivie d une planification opérationnelle. En principe, le sprint se termine par une démonstration de ce qui a été achevé. Avant de commencer un nouveau sprint, l équipe réalise une rétrospective : elle analyse ce qui s est passé durant le sprint afin de déceler d éventuels dysfonctionnements et de s améliorer au sprint suivant. Le sprint est d une période d un mois maximum. Une fois la durée choisie, elle reste constante pendant toute la durée du développement du projet. Les rôles Les membres d une équipe Scrum n ont pas de rôles prédéfinis. Ils sont pluridisciplinaires et capables de réaliser des activités variées (architecture, conception, développement, test, etc.). Toutefois, les responsabilités managériales sont réparties sur trois rôles : le product- owner, le scrum- master et l équipe Scrum. 9

10 Le product- owner (propriétaire du produit) est le représentant des clients et utilisateurs. Il est responsable de l identification des demandes à implémenter et de l optimisation du retour sur investissement. Il se doit de communiquer la vision du produit à l équipe de développement et détermine les fonctionnalités à développer en fixant la date de lancement du projet. Il est chargé de la maintenance et de la définition des items (fonctionnalités) dans le carnet du produit (product- backlog) ainsi que de leur priorisation. Les fonctionnalités du produit sont exprimées sous forme d histoires ( users stories ; explicité infra). Pour mener à bien son rôle, les décisions du propriétaire du produit (par exemple, l ordre dans lequel les fonctionnalités seront développées) doivent être respectées par l ensemble de l organisation. C est également lui qui, en accord avec l équipe, fixe les objectifs d un incrément (sprint) au début de celui- ci. Si, durant le sprint, les objectifs deviennent obsolètes, le propriétaire du produit a la responsabilité d annuler le sprint en cours. Ainsi, le propriétaire du produit ne peut être représenté par plusieurs personnes. Idéalement, le propriétaire du produit travaille dans la même pièce que l équipe. Il convient ici de préciser qu un product- owner ne peut par ailleurs jamais être un Scrum- master. Le Scrum- master (animateur d équipe) fait le relais entre le product- owner et l équipe Scrum. Il aide l équipe de développement à affronter les problèmes qu elle rencontre et à réaliser les objectifs fixés. Son rôle consiste à guider l équipe dans la mise en œuvre de la méthode Scrum et à s assurer que celle- ci adhère aux valeurs, aux règles et outils soutenus par la méthode. Le rôle du Scrum- master est celui de leader, de coach, au service de l équipe. Il arrive que le Scrum- master soit un membre de l équipe de développement mais pas toujours. L équipe Scrum est constituée de quatre à dix personnes au maximum. L équipe est auto- organisée et pluridisciplinaire. Il n y a pas de hiérarchie interne, toutes les décisions de l équipe étant prises collégialement. L objectif de l équipe est de livrer le produit par petits incréments ; dès lors, il existe à tout moment une version du produit potentiellement utilisable disponible. L auto- organisation ne veut pas dire auto- gestion sauf si l équipe a la maturité pour cela. Ainsi, dans certains cas, un cadre de gestion peut intervenir si une équipe ne fonctionne pas comme il faudrait. Bien que les membres d une équipe Scrum soient polyvalents, chacun est spécialisé dans une activité précise : l analyse d affaire, la programmation, le contrôle de la qualité, l interface avec les utilisateurs, l architecture, etc. Les outils La méthode scrum repose sur trois principaux outils de gestion : le carnet du produit (product- backlog), le carnet de l itération (sprint- backlog) et le graphique de progression (burndown chart). 10

11 Le Product- backlog (carnet de produit) est un document listant les fonctionnalités du produit à développer. Les items renseignés dans celui- ci peuvent renvoyer à des fonctionnalités, des bugs et défauts avérés dans des développements précédents, des tests, etc. Dans tout product- backlog, les éléments sont décrits, estimés (en points, nous y reviendrons) et priorisés par le propriétaire du produit. Les items de haute priorité sont décrits de façon plus détaillée que ceux de moindre priorité. Cela permet de minimiser les risques de retouches, principalement dus aux changements des demandes clients. Le niveau de priorité découle du risque, du besoin et de la valeur ajoutée de chaque item. Par ailleurs, le Product- backlog évolue avec le produit et peut être modifié en fonction des besoins. Seul le Product- owner est responsable du contenu du product- backlog. Le sprint- backlog (carnet de l itération) contient la liste des tâches à réaliser au cours de la prochaine itération. Les éléments du sprint- backlog sont découpés en tâches avec un niveau de granularité suffisant pour assurer la visibilité de l avancement du projet lors des réunions quotidiennes. Les tâches à réaliser sont sélectionnées par l équipe Scrum au cours de la planification de l itération. Seuls les membres de l équipe Scrum peuvent modifier le sprint- backlog durant l itération. Néanmoins, le propriétaire du produit peut influencer l équipe Scrum en l aidant à mieux comprendre la demande client ou en lui proposant des compromis. À mesure que l équipe Scrum termine une tâche, et en fonction de l expérience de réalisation de celle- ci, elle met à jour l estimation du travail restant pour le développement des autres éléments du carnet du produit. Le Burndown chart (graphique de progression) est un graphe permettant de visualiser l avancement des tâches au fil du temps. Au cours d une itération, cet outil permet de mettre en évidence la corrélation entre la quantité de travail restante à un moment donné et l avancement de l équipe projet. La création du graphe se fait en additionnant chaque jour les estimations des éléments qu il reste à réaliser. Un autre outil de gestion intangible mais qui semble améliorer la communication entre les membres d une équipe scrum mérite d être présenté : il s agit de la notion done ou «réalisé». En effet, l objectif de l équipe Scrum est de livrer, à la fin de chaque itération, un sous- ensemble du produit final. Des tests sont effectués en vue de vérifier la cohérence et le fonctionnement des incréments rassemblés. Dans cette perspective, chaque sous- ensemble doit être signalé comme «réalisé» avant d être ajouté à l incrément précédent. Mais, la terminologie done peut revêtir des sens différents selon la culture et pratiques des personnes impliquées dans un projet. A titre d exemple, si pour certains développeurs, la notion done implique que le code est propre, correctement remanié, compilé et testé, pour d autres personnes ce même terme peut signifier uniquement qu il est compilé. Ainsi, les fondateurs de la méthode Scrum insistent sur le besoin de clarification des termes utilisés lors du déroulement du projet pour éviter les incompréhensions et les conflits éventuels au sein de l équipe. Les modes opératoires La méthode Scrum repose sur un ensemble de modes opératoires en lien direct avec les problématiques de planification du projet et d organisation des équipes. Ils sont fondés sur différents 11

12 types de réunion : la réunion pre- sprint, la réunion sprint planning, les réunions quotidiennes (ou daily- scrums), la réunion post- sprint et la réunion rétrospective. La réunion pre- sprint est une réunion de planification du livrable permettant de discuter de la répartition des items du product- backlog sur les prochaines itérations. Durant cette réunion, l équipe Scrum cherche à comprendre comment transformer la vision du produit en un livrable qui permette de répondre, le plus efficacement possible, aux attentes des clients. Le plan de livraison est ainsi établi. Il reprend les objectifs du livrable, les éléments les plus prioritaires du carnet du produit, les fonctionnalités, les coûts, le budget et la date de livraison du produit. La réunion sprint planning est une réunion, en deux temps, organisée par le Scrum- master. Dans un premier temps, l équipe Scrum décide avec le product- owner, de l objectif de l itération et des scénarios de tests à réaliser. Le product- owner présente à l équipe les items du carnet du produit ayant la plus haute priorité. Dans un deuxième temps, le scrum- master et l équipe Scrum se réunissent pour se focaliser sur la manière dont l incrément sera implémenté : les différentes tâches à réaliser sont ainsi identifiées, estimées et priorisées. La granularité d'une tâche doit être d'environ un à deux jours de travail. Seule l équipe Scrum est capable d estimer le nombre d éléments du carnet à implémenter durant une itération. Le propriétaire du produit peut participer à cette seconde partie de la réunion afin de clarifier les items du carnet ou faire des compromis sur le produit si nécessaire. La réunion quotidienne (ou daily scrum) permet aux développeurs de faire un point de coordination sur les tâches en cours et sur les difficultés rencontrées. Elle dure quinze minutes, généralement au même endroit et au même moment de la journée. Le propriétaire du produit n assiste pas à cette réunion. Durant cette réunion, le scrum- master pose trois questions à chaque membre de l équipe : qu'as- tu fait hier? Quelles difficultés as- tu rencontrées? Et que vas- tu faire aujourd'hui? L objectif est de suivre de près les avancées de l équipe Scrum et de résoudre rapidement les problèmes lors de leur apparition. Les équipes utilisent des minuteurs pour ne pas dépasser les quinze minutes de la réunion. Le scrum- master s assure que les collaborateurs suivent les règles et respectent le timing de la réunion. La réunion quotidienne a un but de synchronisation pour l équipe et ne doit pas être envisagée comme une réunion de reporting d activité. C est le niveau quotidien du principe inspect and adapt de la méthode Scrum. Si un membre de l équipe a besoin de discuter d un sujet qui ne peut pas être couvert durant ces quinze minutes, il est recommandé qu il participe à une autre réunion nommée side- bar, qui suit le daily scrum. La réunion post- sprint se tient à la fin de chaque itération. Le travail de l équipe est présenté devant le product- owner. La durée de la réunion est limitée à quatre heures pour une itération d un mois. Pour des itérations plus courtes, le temps alloué à la réunion est calculé au prorata de la durée totale de l itération, en l occurrence deux heures pour une itération de deux semaines. La réunion post- sprint permet d évaluer l avancée du projet et sa conformité aux critères d acceptation définis par le product- owner. Ce dernier discute de l état actuel du product- backlog et identifie clairement ce qu il reste à compléter dans les prochaines itérations. La réunion rétrospective se déroule après la réunion post- sprint et avant la planification de la prochaine itération. L équipe Scrum et le scrum- master se réunissent pour évaluer a posteriori le 12

13 déroulement de l itération : l équipe Scrum évoque avec le scrum- master ce qui s est bien passé et ce qui s est mal passé. Ils identifient les améliorations à opérer dans les prochaines itérations. Durant cette réunion d une durée de trois heures - pour un sprint d un mois - l équipe est amenée à évoquer les points de succès et d échec du projet. Cette réunion est aussi une occasion pour le scrum- master d identifier les obstacles récurrents susceptibles de dégrader la performance de l équipe Scrum, notamment au plan des relations interpersonnelles, des processus et des outils. Le contrôle de l itération va ainsi permettre d établir une liste d actions à réaliser au cours des prochaines itérations. Le modèle de développement Le processus de développement débute par une définition du produit à développer. On postule que la vision de la solution évoluera avec l avancement du projet. Dans cette phase d avant- projet (pre- game), les demandes fonctionnelles et non fonctionnelles sont définies et répertoriées dans le product- backlog. Elles sont élaborées par le client, le marketing ou le développeur qui est représenté par le product- owner. A ce stade le nombre de scénarios, la date et les coûts de livraison ainsi que le contrôle des risques sont revus par l équipe de développement. Au cours de cette phase, l architecture du système est planifiée par l équipe Scrum à partir des éléments du product- backlog. Ensuite, l itération (sprint), dont la durée oscille entre deux et quatre semaines, est initiée par la réunion sprint planning au cours de laquelle le product- owner et l équipe Scrum vont négocier les scénarios à implémenter. Cette réunion ne peut excéder une durée de huit heures. Elle comporte deux volets de quatre heures chacun : le premier est consacré à la sélection des items du Product- backlog et le second consiste à définir et à estimer les tâches à réaliser. L estimation relève de la vélocité 7 de l équipe de développement et de ses expériences passées. Si le choix et la priorisation des fonctionnalités à implémenter incombent au product- owner, ils peuvent toutefois être modifiés par l équipe Scrum. Dans la phase de développement à proprement parler, la réunion quotidienne (daily scrum) d une durée de quinze minutes se tient entre les membres de l équipe Scrum et le scrum- master. Et, à la fin de l itération, la réunion post- sprint, d une durée de quatre heures se fait entre l équipe Scrum et le Product- owner. L équipe présente au product- owner le produit partiel en vue d avoir son retour sur les fonctionnalités développées. Après cette réunion, la réunion rétrospective de l itération se déroule entre l équipe Scrum et le Scrum- master et chaque membre est invité à s exprimer sur l itération passée. L ensemble de ces réunions relève ainsi des principes de transparence, de contrôle et d adaptation soutenus par la méthode Scrum. Enfin, la phase d après- projet (post- game) consiste à clôturer le projet et à livrer le produit complet et documenté. La méthode Scrum ne définit pas spécialement d unité pour les items des carnets de produit. Néanmoins certaines techniques se sont imposées de fait. Les items, fonctionnalités du produit, sont 7 La vélocité renvoie au nombre de scénarios que l équipe estime être capable de réaliser durant une itération. Elle peut être déterminée à partir de l expérience de l équipe sur le sujet, des projets antérieurs, etc. 13

14 souvent des users stories empruntées à la méthode Extreme Programming (voir Chapitre II). Ces histoires d utilisateurs sont estimées en points relatifs, sans unité. En pratique, l équipe prend un item représentatif et lui affecte un nombre de points arbitrairement, celui- ci devenant un référentiel pour estimer les autres items. L intérêt de cette démarche est d avoir une idée du travail requis pour développer chaque fonctionnalité, sans lui attribuer une valeur en jours que le directeur de produit serait tenté de considérer comme définitivement acquise. Une fois que tous les items du carnet du produit ont été estimés, on attribue un certain nombre d items à réaliser aux sprints successifs. Une fois un sprint terminé, on sait combien de points ont été réalisés : ceci permet de définir la vélocité de l équipe (soit, le nombre de points qu elle peut réaliser en un sprint). Scrum est une méthode qui s intéresse plus à l organisation des projets informatiques qu aux aspects ingénieriques du management de ceux- ci. Son approche incrémentale et basée sur les besoins priorisés du client lui confère une flexibilité extrême : le principe est de focaliser l équipe sur une partie limitée et maîtrisable des fonctionnalités à réaliser. Scrum n autorise pas toutefois l aspect adaptatif car la méthode ne propose pas de pratiques permettant de mesurer les modifications importantes à apporter et leurs incidences sur le planning de réalisation 14

15 Chapitre II : La méthode Extreme Programming La méthode Extreme Programming (XP) a été formalisée par Kent Beck dans un ouvrage paru en 1999, intitulé «Extreme Programming Explained: Embrace Change» [3]. Elle s est fortement nourrie du retour d expérience d un projet informatique de calcul de rémunération réalisé pour la société Chrysler et conduit notamment par K. Bent. Sans négliger l aspect gestion de projet, la méthode XP est plus orientée que la méthode Scrum sur la réalisation des applications informatiques, la programmation étant envisagée comme une discipline collective. Les principes de la méthode XP existent dans l industrie du logiciel depuis plusieurs années : l originalité est de les pousser à l extrême. A titre d exemple : la revue des lignes de codes est faite de façon continue ; les tests sont faits systématiquement avant chaque mise en œuvre ; la conception est remaniée tout au long du projet et l intégration est réalisée plusieurs fois par jour. Les principes La méthode Extreme Programming qualifie un ensemble d outils et de modes opératoires favorisant l apprentissage individuel et organisationnel, l amélioration continue et l adaptabilité des projets informatiques aux besoins clients. Comme la méthode Scrum, elle accorde une place centrale à la communication et aux retours d information. Par- delà, elle insiste sur la simplicité des lignes de codes et vise à développer les compétences informatiques de l équipe projet. Les partisans de cette méthode estiment que les problèmes majeurs rencontrés dans un projet de développement informatique sont le plus souvent imputables à un manque de communication au niveau de l équipe. Par ailleurs, les retours d informations, notamment ceux en provenance du client, doivent être encouragés pour faciliter les ajustements rapides de l équipe projet. La simplicité des lignes de codes et du design est quant à elle nécessaire pour améliorer la flexibilité et l adaptabilité du projet à coût réduit. Enfin, le développement des compétences de l équipe projet leur permet de changer de rôle et d intégrer plus facilement la vision du produit. Les rôles Plusieurs rôles sont attribués aux membres d une équipe de développement Extreme Programming. Le programmeur doit écrire les tests unitaires et développer les lignes codes en respectant le principe du simple design. L objectif d une itération est de mettre en œuvre les scénarios sélectionnés par le client sans envisager les prochaines évolutions. Le programmeur est amené à communiquer et à collaborer constamment avec les designers et le client. Le designer est responsable de la définition de l architecture de la solution en développement. Il aide également le client à écrire et à clarifier les scénarios utilisateurs. De surcroit, il analyse l usage actuel 15

16 de la solution et examine la question des besoins futurs des utilisateurs. Il spécifie, en amont, l interface utilisateur et se charge de son amélioration. Le client est chargé d exprimer ses besoins sous forme de scénarios et d écrire les tests fonctionnels. Il est également responsable de la priorisation des fonctionnalités à implémenter. Le testeur doit d une part assister les clients dans l écriture et l exécution des tests fonctionnels. Il doit également accompagner les programmeurs dans le développement des tests réalisés ex ante pour vérifier la conformité des fonctionnalités livrées. Le tracker juge de l avancement du projet. Il évalue les prévisions effectuées par l équipe de développement (en termes d efforts par exemple) et donne son avis sur leur pertinence dans le but d améliorer les prévisions futures. Il trace également la progression de chaque itération et évalue les possibilités de réaliser les objectifs fixés en prenant en considération le temps et les ressources disponibles. Le coach a un rôle de soutien technique pour les membres de l équipe Extreme Programming, en particulier au cours des premières itérations de livraison. Il guide également l équipe dans l application des pratiques et principes Extreme Programming. Le manager de projet peut être assimilé à un chef de projet. Il encourage la communication au sein de l équipe et coordonne la communication avec le client, les fournisseurs et le reste de l organisation. Il s occupe de la mise à jour du planning et rend compte au client sur la base des informations fournies par le tracker. Le chef de produit est responsable de la rédaction et du choix des scénarios utilisateurs. Il répond aux questions concernant les différents aspects du produit et assiste l équipe dans la priorisation des fonctionnalités à développer. Les outils La documentation utilisée dans le cadre de la méthode Extreme Programming se limite aux story- cards. Ces cartes donnent à voir les scénarios utilisateurs, leurs incidences estimées en termes de ressources et les tests associés. L équipe projet utilise par ailleurs des post- it pour visualiser l avancement du projet, décrire les idées d amélioration de la solution à développer et signaler les problèmes entravant le travail des développeurs. D autres outils complémentaires peuvent être mobilisés de manière opportuniste par les acteurs du projet. Ils s inspirent généralement des outils existants dans les entreprises industrielles lean. A titre d exemple, nous pouvons citer : 16

17 - - - le diagramme de Pareto pour identifier les causes les plus fréquentes de dysfonctionnement. Le diagramme de Pareto permet de lister, sous la forme d un histogramme, l origine des dysfonctionnements observés ; la méthode des cinq pourquoi pour cerner les causes racines d un problème. La méthode des «cinq pourquoi» consiste à poser 5 fois de suite la question : «Pourquoi le dysfonctionnement est- il survenu?». La répétition permet d aller à la cause racine du dysfonctionnement et de dépasser la première raison du problème, qui est souvent symptomatique ; ou encore les détrompeurs dont le but est d éviter les incompatibilités entre les parties du codes développées séparément. Les détrompeurs regroupent l ensemble des dispositifs techniques permettant d empêcher en amont l apparition d une non qualité ou le non respect d un standard de travail. Les modes opératoires La méthode Extreme Programming soutient des modes opératoires permettant d orienter la manière dont est géré le projet, de statuer sur la façon d opérer la programmation et d organiser les modalités de collaboration entre les acteurs du projet. Nous présentons ces modes opératoires en reprenant la classification établie dans l ouvrage de Beck et Andres [4]. Nous classons donc ces modes opératoires en fonction de leur intention : gestion de projet, programmation et collaboration (tableau 1). Tableau 1: Les modes opératoires de l Extreme Programming Gestion de projet Programmation Collaboration - Cycle de planification hebdomadaire, réunion hebdomadaire (planning game) et réunion quotidienne (stand- up meeting) - Livraison itérative et incrémentale. - Conception simple, incrémentale - Tests unitaires et fonctionnels - Construction rapide - Déploiement quotidien - Remaniement des codes - Intégration continue - Métaphore - Programmation en paire - Appropriation collective du code - Règles de codage - Client sur le site 17

18 Le cycle de planification hebdomadaire consiste à évaluer l avancement du projet par rapport aux attentes des parties prenantes, à identifier les scénarios à implémenter dans le prochain cycle et à décomposer ces derniers en tâches attribuables aux membres de l équipe. Les réunions hebdomadaires (planning games) se tiennent au début de chaque itération entre le client et l équipe de développement. Au cours de cette réunion, les demandes fonctionnelles sont déterminées par le client et sont matérialisées à travers des scénarios d utilisateurs ou user- stories. Les user- stories représentent les besoins fonctionnels. En général, les utilisateurs de l application finale écrivent les user- stories en utilisant leur propre terminologie. Les user- stories sont notées sur des story- cards. Les story- cards représentent les cartes sur lesquelles est marqué le scénario à implémenter avec une courte description de celui- ci. Ces cartes sont ensuite affichées sur un tableau visible par toute l équipe. A ce stade, l équipe évalue la charge de travail relative à chaque scénario en termes de points (le nombre de points est attribué en fonction de la difficulté du scénario) et communique au client une estimation de sa vélocité. Ensuite, conjointement avec le client, l équipe décide des scénarios à implémenter dans la prochaine itération. Les réunions quotidiennes (Stand- up meeting) durent quinze minutes et se déroulent le plus souvent dans un espace ouvert (de type plateau) occupé par les développeurs. Durant ces réunions, les développeurs sont amenés à partager leurs expériences concernant la journée précédente et ils décident collectivement des tâches futures à réaliser. Ces réunions servent également à planifier les séances de travail en binômes (pair programming). Les livraisons itératives et incrémentales consistent à implémenter au fil de l eau les nouvelles fonctionnalités au sein de la version précédemment développée. Pour y arriver, le projet a initialement était décomposé en plusieurs lots, chacun regroupant un ensemble donné de fonctionnalités. La conception simple et incrémentale implique d éliminer les duplications de lignes de codes et de redéfinir en continu le design pour aligner les nouveaux codes intégrés au besoin client. Les tests unitaires concernent chaque portion de codes. Ils sont écrits avant de commencer à coder et sont réalisés à chaque intégration. Bien que ces tests relèvent d une vision «micro» de l application, ils permettent de vérifier si la solution présente d éventuelles non conformités. Ces tests sont automatisés et exécutés en continu. Des modèles de tests unitaires, dits xunit, ont été développés pour certains langages de programmation 8 (JUnit pour le langage Java, CppUnit pour le langage C++, Pyunit pour Phyton, etc.). Les tests fonctionnels relèvent quant à eux de la responsabilité des clients. Ils sont rédigés et appliqués à chaque itération. Ces tests spécifient ce que l application est censée faire du point de vue du client. La fin d une itération a lieu lorsque tous les tests ont été exécutés. 8 L observation de nombreux projets montre qu il n existe pas de langage spécifique au développement agile. Les méthodes agiles, en particulier, Scrum et XP sont techno- agnostiques. 18

19 La construction rapide est fondée sur des tests automatiques, permettant d avoir un retour immédiat sur les codes développés. La construction rapide est une opportunité d accroitre la fréquence des retours d informations sur ce qui a été développé. Le déploiement quotidien consiste à mettre en production tous les jours les codes développés. Là encore, la mise en production quotidienne permet d avoir des retours d information immédiats sur la version produite. L intégration continue consiste à intégrer tous les jours les nouvelles lignes de codes développées au sein de la solution source, destinée à être complète et livrée à terme. Le remaniement des codes (refactoring) consiste à améliorer régulièrement la qualité du code sans en modifier le comportement. Il s agit de retravailler le code tout en gardant les mêmes fonctionnalités. Autrement dit, il s agit du nettoyage quotidien du code (élimination des duplications et amélioration de sa lisibilité). La métaphore est une histoire simple qui doit décrire le projet et ses fonctionnalités. Elle peut concerner l architecture, le fonctionnement du système, etc. Cette métaphore guide le processus de développement et aide l équipe à avoir une compréhension commune des éléments essentiels du projet. La programmation en paire consiste en la production des lignes de codes par binôme, où les deux personnes concernées travaillent sur une seule machine, un seul clavier et une seule souris. La rotation des paires se fait de manière quotidienne. Cette pratique facilite le partage d informations notamment au moment des phases d analyse, de conception et de tests, etc. L appropriation collective des codes signifie que les codes développés doivent être partagés par toute l équipe. Le corolaire de ce mode opératoire est que chaque développeur peut apporter des modifications au code à n importe quelle occasion. Cette pratique responsabilise l équipe à l égard de l ensemble des codes développés. Le client sur le site est invité à répondre aux questions de l équipe projet, à exécuter les tests d acceptation et à s assurer de la conformité des versions développées. Sa présence est fortement souhaitée lors des réunions hebdomadaires organisées par l équipe Extreme Programming. Les règles de codage ont vocation à éviter la présence de versions multiples, en particulier pour ce qui concerne les sources des codes. Il est indispensable d avoir une base unique de codes qui permet de réduire la complexité de la solution et facilite l intégration des nouveaux codes. Le modèle de développement La méthode Extreme Programming, focalisée sur la partie programmation du projet, propose un modèle de développement itératif avec une structure à deux niveaux : d abord des itérations de livraison puis des itérations de développement. Les premières consistent à livrer des fonctionnalités 19

20 complètes au client tandis que les secondes portent sur les scénarios qui contribuent à la définition d une fonctionnalité. Le processus de développement est déclenché par une phase d exploration des besoins durant laquelle le client élabore les scénarios qu il souhaite intégrer dans la première livraison. En parallèle, l équipe se familiarise avec les outils et les pratiques qui seront utilisés au cours du projet. Une phase de planification (de quelques jours) est organisée entre l équipe de développement et le chef du produit pour identifier les scénarios à implémenter dans la première itération de livraison. Celle- ci ne doit pas excéder les deux mois. L itération de livraison est ensuite découpée en plusieurs itérations de développement de courte durée (une à trois semaines). La première itération de développement consiste à élaborer l architecture du système général en se basant sur les scénarios capables de renforcer la structure globale du système. Le chef du produit décide des scénarios à implémenter dans chaque itération. Ensuite, les tests unitaires sont écrits et automatisés et les codes sont développés. Par ailleurs, les tests fonctionnels écrits par le client sont exécutés à la fin de chaque itération de développement. L itération de livraison prend fin lorsque tous les scénarios retenus sont développés. Il convient de préciser qu au cours du projet, les scénarios, les estimations et les tests écrits sur les story- cards constituent l unique source de documentation. 20

21 Chapitre III : La méthode de Développement Lean Le terme Lean signifie littéralement mince en référence à l objectif de réduction du nombre de ressources à mobiliser pour produire le bien, le service ou la solution informatique souhaitée. La méthode de Développement Lean est le résultat d un exercice de transposition des principes du Lean Manufacturing aux activités de développement informatique. Le Lean Manufacturing désigne l ensemble des principes managériaux directement inspirés du Toyota Production System. Considéré dans le discours de beaucoup d industriels comme un paradigme de gestion performant et dominant, les tentatives d exportation du modèle lean au- delà du secteur automobile ont été nombreuses. Les méthodes de Développement Lean participent de cette exportation d un modèle initialement conçu pour l industrie automobile. Les principes La méthode lean, dans l industrie ou dans le secteur informatique, vise à éliminer toutes les formes de gaspillage dans l organisation. «This is a management system for the absolute elimination of waste All we are doing is looking at the timeline from the moment a customer gives us an order to the point when we collect the cash» [5]. Les gaspillages sont définis comme l ensemble des opérations qui ne contribuent pas directement à l amélioration de la satisfaction du client. Pour pouvoir éliminer ces gaspillages, la méthode de Développement Lean va insister sur deux principes fondamentaux : la réactivité face aux dysfonctionnements et le développement des compétences des collaborateurs. La capacité de l organisation à rendre visible et à traiter rapidement les problèmes de son processus de développement réduit les gaspillages en raison de l effet positif et immédiat des contre- mesures mises en place pour éviter que le dysfonctionnement ne se reproduise. Le «développement» des collaborateurs est un pari sur l apprentissage individuel et organisationnel, perçu un comme moyen d anticiper et donc d éliminer ex ante les sources majeures de gaspillage dans les projets informatiques. Les rôles La méthode de Développement Lean assigne un rôle contre- intuitif au chef d équipe et aux collaborateurs en charge de la production des lignes de codes. En vertu du principe de réactivité de l organisation face aux dysfonctionnements, il incombe au chef d équipe de favoriser les remontées d information sur les difficultés rencontrées par les développeurs. Les dysfonctionnements étant susceptibles de dégrader sensiblement la satisfaction client en termes de délai ou de qualité, le chef d équipe doit prioriser son activité à la faveur de cet exercice exigeant la résolution immédiate des problèmes rencontrés par son équipe. Le pilotage de l activité de développement par le chef d équipe ne doit donc pas procéder d une macroanalyse le conduisant à réajuster ses ressources pour tenir ses objectifs de délais et de qualité ; il l oblige à une attitude proactive dans la résolution des problèmes dès leur apparition. 21

22 Le chef d équipe occupe un rôle central dans le développement des compétences de ses collaborateurs. Il est en charge de leur montée en compétences. A ce titre, il incombe au chef d équipe d animer les chantiers d amélioration des processus de développement au cours desquels les développeurs sont amenés à proposer des améliorations sur le processus. L expérimentation des solutions envisagées est conduite et contrôlée par les développeurs eux- mêmes. L apprentissage se crée ainsi par l expérimentation. Le chef d équipe encadre à distance l expérimentation des solutions à l étude et s assure qu elle donne lieu à un apprentissage dont le résultat se matérialise le plus souvent par la création d un nouveau standard de développement. Par delà leur implication dans les chantiers d amélioration, les développeurs sont invités à respecter strictement des standards de développement. Sans standard, l exercice d identification des dysfonctionnements devient un exercice d appréciation subjective sur ce qui pourrait relever (ou pas) d un problème pour le client. Les standards objectivent la présence d un dysfonctionnement dans le processus. Le respect des standards par les développeurs devient ainsi central et sera facilité par le fait que les développeurs ont préalablement participé à leurs définitions au cours des chantiers d amélioration. Le non respect d un standard devant entrainer par définition un dysfonctionnement, il est souhaitable de rendre visible tous les écarts aux standards de manière à pouvoir être réactif au moment de l apparition d un dysfonctionnement. Les outils et les modes opératoires Les outils de la méthode de Développement Lean ont été pensés pour être au service de ses modes opératoires. Ils sont moins structurants que ceux en vigueur dans la méthode Scrum et Extreme Programming. Ils n orientent pas de facto les comportements mais les accompagnent. Pour cette raison, nous choisissons de mêler la présentation des outils et des modes opératoires de la méthode de Développement Lean. Par ailleurs, les modes opératoires de la méthode de Développement Lean étant centrés sur l élimination des gaspillages dans le processus de développement, nous les discutons en reprenant les principales sources de gaspillages dans les projets informatiques. Le tableau (2) illustre les sept sources de gaspillage identifiées dans le secteur de l industrie automobile et transposées au domaine du développement informatique par Mary et Tom Poppendieck dans leur ouvrage «Implementing lean software development: from concept to cash» [5]. 22

23 Tableau 2: Les sept sources de gaspillage [5] Les «gaspillages» dans l industrie automobile Production excessive (Overproduction) Attente (Waiting) Transports inutiles (Transportation) Processus supplémentaires (Extra processing) Stock et en- cours de production (In- process inventory) Mouvements inutiles (Motion) Production défectueuse (Defects) Les «gaspillages» en développement informatique Trop de fonctionnalités (Extra features) Retards (Delays) Transfert (Handoffs) Reprogrammation (Relearning) Travail partiellement fait (Partially done work) Changement de tâches (Task switching) Défauts non détectés par les tests (Defects) En développement informatique, la production excessive se manifeste par la conception de fonctionnalités supplémentaires et d éléments de documentation inutiles. Comme dans l industrie automobile, la surproduction constitue une forme sensible de gaspillage induisant des augmentations de coûts et des complications techniques au niveau du système développé : tests supplémentaires, maintenance, obsolescence des codes, etc. Les modes opératoires fondés sur la planification et la documentation extensive semblent ainsi générer des coûts additionnels : coûts de qualification et de maintenance de codes inutiles, documentations obsolètes, etc. Afin de pallier ces dysfonctionnements, l approche de Développement Lean préconise une approche «en flux tirés» : les activités doivent être déclenchées en fonction des besoins exprimés durant les phases précédentes. Elle promeut des pratiques d échanges fréquents entre les acteurs métiers ainsi que l utilisation d outils de management visuel dans le but de favoriser une vision partagée des besoins. L adoption d un style de développement itératif et la mise en place d un système pull 9 doivent également aider les équipes à produire la «quantité» exacte des demandes en termes de spécifications, de codes et de documentation. L attente constitue une deuxième forme de gaspillage : elle se traduit par des retards dans le développement et la livraison des produits. Elle se manifeste par des acteurs inoccupés, en situation d attente d informations précises, de décisions hiérarchiques, de validation de résultats ou de ressources momentanément indisponibles. Comme le montre [6], ces délais d attente peuvent être dus à plusieurs éléments : la multiplicité des canaux de communication et de décideurs, la conduite simultanée de plusieurs projets, la mobilisation de ressources communes, l indisponibilité des informations recherchées ou encore aux relations d interdépendance entre les phases du projet. 9 Ce système initialement adopté chez Toyota consiste à tirer la production par la demande. 23

24 Les transports inutiles dans l industrie prennent la forme de déplacements physiques de pièces ou de personnes. Ils engendrent des interruptions ou ralentissements dans la chaîne de production, des pertes de pièces et des goulots d'étranglement. En développement informatique, les «déplacements» inutiles concernent surtout les allers- retours d informations numériques et échanges de documents entre les membres d une équipe, pouvant entraîner une perte considérable d informations. Prenons pour exemple une activité de développement bloquée par le transfert d une demande au service marketing, et la décision de celui- ci. Si cette demande doit passer par différents acteurs (chefs de projets, architectes, etc.) avant d être traitée, l information risque de s égarer avant d atteindre son destinataire, engendrant ainsi des retards. Il apparaît donc légitime de chercher à réduire le «trajet» de la demande en diminuant le nombre d acteurs «décideurs» et en clarifiant les rôles au sein de l équipe projet. Dans cette perspective, la méthode de Développement Lean favorise la collaboration par l organisation de réunions quotidiennes, la programmation en paire, le partage collectif des codes et le management visuel (matérialisé par des tableaux de bord partagés, des post- it, des graphes, etc.). Les processus supplémentaires dans le développement informatique se manifestent par des arrêts et reprises d un même travail ainsi que par des activités redondantes. La reprise d une tâche suspendue engendre des pertes de temps significatives et une baisse de productivité de l équipe. Elle nécessite des efforts supplémentaires de la part de l acteur concerné pour se remettre dans les conditions initiales de travail alors qu il s était déjà impliqué dans d autres tâches. Ces formes de gaspillage peuvent être dues d une part, au manque de communication et de vision globale du projet et d autre part, à l absence de stratégies de priorisation des demandes. Les risques de «retravail» augmentent dans un environnement où l on accorde une place primordiale aux phases de planification et d étude, principalement dans le cadre de projets de grande taille. Dans de tels contextes, le processus de décision est long voire redondant en raison du grand nombre d acteurs et du nombre d échelons hiérarchiques impliqués dans les projets. De même, l instabilité des équipes et l intervention d acteurs transverses (dans le cas de structure d organisation matricielle où certains acteurs sont affectés à différents projets) les conduisent à délaisser une tâche au profit d une autre, entraînant des arrêts et reprises d un même travail. L élimination de ce type de gaspillage peut être envisagée par une restructuration des projets et une recomposition des équipes. Pour [5, 7], les cycles courts de développement, le remaniement des codes, l implication du client et l intégration continue sont autant de pratiques professionnelles qui peuvent réduire le «retravail». Une cinquième forme de gaspillage que l on retrouve dans les projets de développement informatique concerne les en- cours de production et les stocks. Dans l industrie automobile, cette forme de gaspillage renvoie aux stocks inutiles qui occupent un espace, génèrent des coûts de maintenance et masquent les dysfonctionnements éventuels du processus de production. En développement informatique, ce type de gaspillage concerne le travail partiellement effectué, la documentation excessive et les codes non implémentés. La communication permanente entre les membres de l équipe de développement et la création d un environnement centré sur le partage d information doit permettre de réduire la documentation et de clarifier les besoins réels du client. Cependant, certaines entreprises exigent d avoir une traçabilité sur les spécifications et les codes, ce qui oblige à les documenter. Dans de telles situations, il est recommandé de convertir les 24

25 spécifications requises en des tests exécutables et de recourir à des outils de type framework for integrated tests 10 permettant de disposer d une mémoire sur les codes testés [5]. La multiplication des réunions, l excès de procédures, les déplacements physiques et la réalisation de diverses tâches simultanées constituent une autre forme de gaspillage : les mouvements inutiles ou motion. L éclatement géographique des membres d une équipe, par exemple, accroît les probabilités de déplacement des acteurs entre les sites. La mise en place d outils technologiques performants pourrait être une solution efficace pour améliorer la qualité de la communication, assurer un partage rapide de documents et par conséquent réduire les coûts engendrés par les déplacements physiques (taxi, train, hôtel, séjour, etc.). Enfin, le dernier type de gaspillage caractéristique des développements informatiques concerne les défauts non repérés dans les codes. Les tests unitaires réalisés avant le codage constituent ce qu on appelle dans l industrie automobile les détrompeurs ou mistake- proofing. Ils permettent de montrer si les codes fonctionnent comme prévu. Si le test- driven development permet de réduire le nombre de défauts dans le système, il n empêche pas complètement leur apparition. L attitude du chef d équipe et de ses développeurs, centrée sur une attention permanente concernant la qualité du processus devient alors prépondérante pour détecter rapidement les défauts, analyser les causes racines et standardiser les bonnes pratiques jusqu à ce qu elles soient remplacées par d autres meilleures pratiques : principe de l amélioration continue. De même, les tests fréquents et l intégration continue des codes permettent de déceler rapidement les erreurs et de vérifier continuellement le fonctionnement de l ensemble des codes développés et intégrés. Le modèle de développement La modèle de développement Lean est d abord itératif et incrémental. Les délais de livraison sont un facteur de positionnement concurrentiel fort pour les entreprises du secteur informatique. Le principe de développement itératif et incrémental permet, outre la vérification rapide de la version fonctionnelle développée, d optimiser les temps de réponse aux demandes des clients. Souvent les sociétés de développement informatique ont du mal à conjuguer la rapidité de développement et la qualité des produits livrés. Sortir de ce dilemme repose sur la compétence des développeurs en termes d expertise technique (maîtrise du code) et sur l aptitude des chefs d équipe à s impliquer dans la résolution immédiate des dysfonctionnements et dans l animation des chantiers d amélioration continue. Finalement, quatre caractéristiques mentionnées par MacCormack dans [5] pourraient résumer le modèle de Développement Lean : (1) les livraisons rapides et minimales de fonctionnalités testées par le client ; (2) les constructions quotidiennes et les retours d information rapides que l on obtient suite aux tests d intégration, (3) une équipe ou un chef d équipe expérimenté capable de prendre les 10 Il s agit d un outil open source qui automatise les tests fonctionnels des clients. Il intègre le travail des analystes, des clients, des testeurs et des développeurs. 25

26 bonnes décisions au bon moment et (4) une architecture modulaire permettant l intégration facile de nouvelles fonctionnalités. Sur ce dernier point (4), il est utile de signaler que le modèle de Développement Lean adresse très directement la question de l optimisation du moment auquel doivent être prises les décisions. Les décisions doivent être reportées jusqu à la collecte maximale d informations. Les décisions doivent être réversibles et facilement modifiables. Dans cette perspective, le développement itératif vise à surmonter les phases d analyse et d anticipation paralysantes pour s appuyer sur des solutions concrètes améliorant les prises de décisions. Dans un processus de développement instable et complexe (qui caractérise désormais une large majorité de projets informatiques), il est indispensable que l équipe dispose d un ensemble d options alternatives lui permettant de retarder les prises de décisions irréversibles. Pour Taiichi Ohno, les plans élaborés au départ d un projet sont susceptibles d être fortement modifiés : une planification très détaillée génère plus d inconvénients (activités de replanification, changement de l attribution de responsabilité de lot, ) que d avantages en termes de management efficace d un projet informatique. 26

27 Partie II : Retours d expérience Une enquête internationale 11, réalisée en 2010 auprès de managers de projets informatiques, pointe la question de l efficacité des méthodes agiles. Les managers interrogés dans le cadre de cette étude ont déclaré «très importante» : la portée de ces méthodes pour l amélioration des délais de mise sur le marché (37%) ; leurs capacités à supporter la gestion du changement des priorités (36%) ; leur performativité pour la gestion de la qualité des logiciels livrés (24%) et la visibilité dans la conduite des projets (17%). Pour autant, il ressort également de cette étude des constats d échec dans l adoption de ces méthodes, expliqués par le manque d expérience des équipes en développement agile (14%), une inadéquation avec la culture d entreprise (11%), la difficulté à faire coexister les méthodes agiles avec celles déjà existantes (10%) et le manque de soutien de la hiérarchie (8%). Les méthodes agiles, dans leur portée managériale, portent ainsi en elles une forte ambigüité imputable d un côté au consensus qu elles réussissent à créer sur le plan des objectifs recherchés et de l autre, aux difficultés fréquentes d adoption de certains modes opératoires agiles dans des contextes spécifiques. Il devient donc intéressant de prolonger la première partie de cet ouvrage par une discussion détaillée sur l intérêt perçu par les organisations des principaux modes opératoires agiles (chapitre 4), sur les difficultés d appropriation qu elles posent dans le contexte spécifique d équipes géodistribuées (chapitre 5), et enfin sur la question du degré d agilité que les entreprises peuvent viser à travers la mobilisation de certaines méthodes agiles et leur combinaison avec des approches plus classiques (chapitre 6)

28 Chapitre IV : Retours sur l adoption de certains modes opératoires agiles en entreprise La présentation des méthodes Scrum, Extreme Programming et Développement Lean a permis de mettre en évidence plusieurs caractéristiques structurantes sur lesquelles se fonde le mouvement agile : les tests unitaires et l intégration continue ; le développement itératif ; la programmation en paire ; les réunions quotidiennes ; le client sur le site et enfin, les outils de collaboration et de support au management (le story- board, le product- backlog et les outils d analyse collective des causes racines des problèmes). En pratique, l adoption de ces modes opératoires et de ces outils peut être perçu positivement ou au contraire susciter un certain de nombre de réserves. Nous reprenons là chacune de ces caractéristiques clefs et discutons de leur perception en entreprise ainsi que des éventuelles difficultés d adoption. Les tests unitaires et l intégration continue Deux modes opératoires, valorisés par la méthode Extreme Programming, ont fait l objet de nombreux écrits : les tests unitaires et l intégration continue. Pour rappel, les tests unitaires sont des tests écrits pour chaque classe ou portion de codes et réalisés à chaque intégration ; quant à l intégration continue, elle vise à ce que le système, dans son intégralité, soit régulièrement et fréquemment assemblé puis testé. Selon certains experts en développement informatique, ces deux modes opératoires sont indispensables pour garantir la qualité des codes et augmenter les chances de réussite du projet [5, 8]. Beaucoup de travaux de recherche [5, 9, 10, 11, 12, 13, 14], fondés sur des études de cas d entreprises, montrent que le développement piloté par les tests améliore la transparence et la qualité des codes produits et procure un feedback rapide sur les codes développés. Ils soulignent que les tests unitaires permettent en effet de réduire les coûts liés à la découverte tardive des anomalies. Quant à l intégration continue, elle permet de résoudre les erreurs dès leurs apparitions et d éviter ainsi les problèmes résultant des intégrations réalisées à la fin du projet [15]. Par ailleurs, ces deux modes opératoires s avèrent, en pratique, des mécanismes de communication essentiels pour les équipes distribuées [16]. Toutefois, certaines études de cas montrent que la pratique des tests unitaires et de l intégration continue présente des limites. D une part, l écriture des tests n est pas une tâche facile à réaliser pour les développeurs peu expérimentés [17]. Ces derniers ont du mal à imaginer et à élaborer les tests unitaires avant le développement des fonctionnalités. D autre part, la création d un environnement de tests intégrés nécessite beaucoup d efforts techniques particulièrement lorsque les équipes sont distribuées et/ou utilisent des outils de programmation différents [18, 19]. 28

29 Ces deux modes opératoires rappellent deux outils visuels de signalement de problèmes déployés dans l industrie automobile chez Toyota : le Poka- Yoke 12 et l Andon 13. Si ces pratiques se trouvent au cœur de la démarche de résolution des problèmes, leur efficacité n est pas toujours garantie en fonction des contextes. Leur mise en place demeure insuffisamment étudiée, en particulier dans le cas de structures larges où plusieurs équipes, rattachées à différentes directions, sont amenées à travailler sur un même projet. En effet, le développement conduit par les tests exige que les développeurs aient une vision très précise des spécifications à développer. Or, souvent, dans une structure complexe, les personnes chargées de la définition des spécifications sont éloignées des équipes de développement, ce qui augmente le risque d une mauvaise compréhension des exigences. Le développement itératif Les trois méthodes agiles présentées dans cet ouvrage (Scrum, Extreme Programming et Développement Lean) plébiscitent un mode de développement itératif et incrémental. Ce style de développement procure des retours d informations rapides sur les versions développées de la solution informatique [10, 20, 21], facilite le suivi du projet [22], améliore l apprentissage organisationnel [10, 22]. Il permet par ailleurs de répondre aux besoins évolutifs des clients [17, 23]. Le mode itératif permet de pallier les difficultés inhérentes à des demandes clients difficiles à spécifier. Chaque itération permet de fournir une version concrète d une partie du logiciel permettant au client de mieux identifier ses propres besoins [23]. Certains praticiens soulignent que les itérations fréquentes, intégrant la voix du client, contribuent à de bons résultats au niveau du développement [7]. Des cycles courts de développement poussent les développeurs à réfléchir davantage à la priorisation des codes à implémenter, minimisant de cette façon les gaspillages tels que les codes inutiles, le travail partiellement effectué, les coûts de maintenance, etc. Le mode itératif participerait également à améliorer l aptitude des équipes de développement à estimer la charge. Ces dernières maîtrisent mieux leurs plannings et leurs engagements à l égard de leurs clients [24]. De plus, l implémentation d un ensemble minimum de fonctionnalités réduit la complexité des codes [5] et permet de pallier rapidement et à moindre coût, les problèmes rencontrés [15, 18, 25]. Dans cette même optique, la conception incrémentale constitue un moyen efficace pour minimiser le nombre de décisions prises en amont ainsi que la quantité de fonctionnalités à implémenter [4, 5]. En contrepartie, la coordination des différentes itérations menées en parallèle est difficile à gérer, d autant plus lorsque les équipes sont géodistribuées [10, 26]. Il semble donc important de réduire au maximum les interdépendances entre les équipes travaillant simultanément sur différentes itérations. De fait, la division du travail en modules indépendants peut faciliter la gestion des 12 Le Poka Yoke est un dispositif technique permettant d identifier ex ante une probabilité forte de non qualité ou le non respect d un standard de travail. 13 L Andon est une corde d alerte, située généralement au- dessus de chaque opérateur, qui permet d envoyer un signal visuel et/ou sonore à son superviseur pour l avertir de la présence d un problème sur la chaîne de production. 29

30 itérations. De même, des réunions régulières entre les responsables des différentes équipes s avèrent cruciales pour suivre l avancement du projet et améliorer la synchronisation des itérations. La programmation en paire La programmation en paire est l un des modes opératoires agiles les plus étudiés. Elle veille à ce que la production de codes se fasse en binôme, par deux collaborateurs travaillant ensemble sur une seule machine, un clavier et une souris. Pour certains, cette pratique est un moyen de collaboration très utile en particulier lorsque les membres des équipes de développement travaillent sur une base unique de codes [27]. De ce point de vue, la programmation en binôme facilite l apprentissage mutuel [9], améliore le partage de connaissances tacites [28], accélère le processus de développement et contribue à une meilleure qualité de codes [17]. Elle renforce également la confiance mutuelle entre les acteurs projets et permet de réduire les coûts de programmation [29] ainsi que les besoins en formation [30]. Dans une étude menée en 2005 auprès de 122 collaborateurs utilisant la programmation en paire [31], il ressort que 72 % des personnes interrogées estiment que cette pratique accélère le processus de développement de la solution. Cependant, le travail en binôme est parfois perçu par certains développeurs comme une pratique générant une forme accentuée de fatigue [9, 27]. Cette pratique de collaboration pourrait diminuer la productivité de l équipe lorsque l écart de compétences entre les personnes travaillant ensemble est grand [17, 18, 32]. Certains mettent en avant un blocage culturel de la part d informaticiens habitués à beaucoup d autonomie et au travail individuel. En outre, cette pratique est difficile à mettre en place lorsque les acteurs ne sont pas tous sur un même lieu géographique. Les réunions quotidiennes Les réunions quotidiennes semblent renforcer le travail collaboratif [18, 33], le partage d informations [17] et la résolution collective des problèmes [34, 35]. Ce type de réunions permet d avoir des clarifications rapides sur l avancement du projet et assure un meilleur contrôle du projet en temps réel [36]. La communication en face à face occupe une place centrale dans les processus de développement agiles. Les échanges fréquents entre les membres d une équipe favorisent la création d un esprit d équipe, accélèrent et facilitent le transfert des idées. Il est donc évident que les équipes de taille réduite soient privilégiées car elles constituent un cadre idéal pour communiquer en direct, réduisant ainsi la documentation inutile [12]. Certains travaux ont souligné la rigueur et la discipline que nécessite ce type de réunions : respect des horaires, disponibilité des personnes [22]. Ces réunions sont difficiles à mettre en œuvre au sein d équipes de grande taille [22, 37], géodistribuées [38, 39] et transverses [6]. Leur durée fixe limitée à quinze minutes contraint le nombre de participants. Dans cette perspective, les équipes de grande taille doivent être divisées de façon à ce que chaque sous- groupe travaille sur un ensemble de modules indépendants. Les représentants de ces groupes sont alors amenés à se réunir 30

31 ensemble de façon régulière afin d assurer la visibilité des sous- projets et garantir la communication entre les équipes qui y sont associées. Différents facteurs ont été identifiés comme autant d éléments facilitant la communication au sein d une équipe agile [40] : la proximité physique (les personnes travaillant ensemble dans un même endroit peuvent communiquer plus facilement), la proximité temporelle (les décalages horaires peuvent entraver la communication), le moral de l équipe (la communication et le partage d informations sont plus efficaces lorsque l ambiance de travail au sein de l équipe est de qualité). Le rattachement d acteurs à différents services fonctionnels peut rendre compliqué le suivi régulier des activités, d autant plus si le statut du chef de projet est dépourvu d influence forte. Dans une structure organisationnelle de ce type, il n est pas facile pour le chef de projet de réunir régulièrement son équipe et d exiger un retour fréquent sur les activités menées. Comme le notent [6], l intervention ponctuelle d acteurs affectés à plusieurs projets en parallèle, rend difficile l animation des réunions quotidiennes et engendre une perte d informations. Par ailleurs cette inefficacité opérationnelle affecte la capitalisation de connaissances sur les projets (d autant que celle- ci s opère souvent sur des connaissances tacites). De plus, le changement d acteurs au cours des projets requiert des efforts supplémentaires pour renforcer la cohésion de l équipe et la communication entre ses membres. La façon d appréhender les réunions quotidiennes (dans Scrum par exemple) peut être problématique. Sur certains projets, ces réunions peuvent prendre la forme de discussions houleuses voire de conflits plus ou moins durables entre membres de l équipe. Sur d autres, les réunions se passent de façon plus courtoise mais en forme de non dits avec le risque que les membres en difficulté ne cherchent plus le support de l équipe en cas de problème. Le client sur le site Un autre mode opératoire étudié dans plusieurs travaux de recherche sur les méthodes agiles est l implication du client sur le site. Selon plusieurs études de cas d entreprises ayant mis en œuvre ce mode opératoire, la participation du client au processus de développement favorise les retours d information continus [10], accroit la qualité du produit à travers la réduction du nombre de fonctionnalités inutiles et non acceptables [41, 42, 43] et améliore la satisfaction des clients quant au produit développé [44, 45]. Les retours d informations fréquents accélèrent par ailleurs l apprentissage organisationnel au sein des équipes de projet. Selon nombre de retours d expérience, les clients semblent apprécier leur participation aux projets. Ils sont informés des dernières évolutions du projet et leurs demandes évolutives sont souvent intégrées et prises en compte. Quant aux développeurs, ils perçoivent leur collaboration étroite avec le client comme utile [10, 18, 44, 46], la communication régulière avec ceux- ci permettant de réduire les conflits potentiels avec ceux- ci [17]. Toutefois, les développeurs estiment important d avoir au sein de l équipe projet une personne expérimentée, prête à accompagner les clients dans le processus agile de manière à faire monter ces derniers en compétences et à les aider dans la définition des demandes [44]. 31

32 Dans un environnement géodistribué, la proximité entre le client et l équipe de développement n est pas toujours envisageable. Certains praticiens ont développé une fonction de «client virtuel» : un individu (client réel ou faisant office de) qui accompagne l équipe de développement à travers des dispositifs numériques de communication [15, 26]. Mais il convient de ne pas idéaliser la figure du client. Des difficultés sont également rapportées relevant de l indisponibilité du client [14, 47], du stress auquel il est soumis [46, 48] et des compétences techniques que celui- ci doit posséder pour d une part, prendre les bonnes décisions dans le choix et la priorisation des fonctionnalités et d autre part, réaliser dans certains cas l écriture des tests fonctionnels [9]. Certains praticiens ont remis en cause la nécessité d une présence permanente du client sur le site de développement. Selon certaines études, seuls 21 % des efforts fournis par les clients apparaissent nécessaires pour assister l équipe de développement dans la production de la solution demandée [46]. Comme le notent Stephen & Rosenberg dans [46], un client peut, à lui seul, être difficilement le représentant des différents utilisateurs de l application développée. Les outils collaboratifs et de support au management Une attention particulière a été accordée aux outils visuels de communication capables d améliorer la transparence dans la gestion d un système de production, notamment celui de Toyota. Parmi les outils visuels utilisés dans l industrie automobile, on retrouve les étiquettes kanban. Appliqués au développement de logiciels, ces outils visuels sont matérialisés par les story- cards et les story- boards. Comme le soulignent [14, 12, 49, 50, 51], ces outils collaboratifs contribuent à la création d un environnement informatif en rendant visible et accessible, à tous les membres d une équipe, le flux du travail et l avancement du projet. Différentes informations sont habituellement renseignées correspondant aux étapes «à faire», «en cours», «à relire» et «terminées». A chaque étape sont affichés les story- cards sous forme de post- it. Ces outils permettent d avoir une vision partagée des demandes [48] et favorisent la communication et la coordination du travail des équipes [35, 48, 52]. D autres instruments de gestion ont été étudiés tels que les outils d identification et d analyse des causes racines des problèmes. Ces derniers semblent, à leur tour, réduire le travail de correction et améliorer la qualité des fonctionnalités produites [7]. Toutefois si l implémentation de ces outils visuels est facilement envisageable dans une organisation de type «plateau» où les acteurs peuvent facilement suivre au quotidien l évolution du projet et communiquer avec leurs pairs, il en est autrement dans des structures organisationnelles complexes, larges ou géodistribuées. Par conséquent, malgré les avantages intrinsèques que présente chacun des outils collaboratifs agiles, leur appropriation semble contingente au contexte dans lequel ils sont mis en œuvre. Plus une équipe s agrandit, plus il lui devient difficile de communiquer en direct, d avoir une collaboration étroite entre ses membres et de promouvoir le partage de connaissances tacites. L accroissement de la taille d une équipe est habituellement accompagné d une formalisation des procédures et d un système de gestion rigoureux s éloignant des caractéristiques organisationnelles agiles. 32

33 A première vue, le partage de ces outils paraît difficile dans le cas d équipes géodistribuées. Le remplacement d artefacts physiques par des artefacts électroniques nécessite des mises à jour régulières ainsi qu une infrastructure technologique de qualité favorisant les échanges à distance. Nous consacrons justement le prochain chapitre à des retours d expériences de praticiens s étant penchés sur la mise en œuvre de ces outils agiles dans un environnement géodistribué. 33

34 Chapitre V : Retours sur l adoption des modes opératoires agiles dans un environnement géodistribué A plusieurs reprises dans cet ouvrage, nous avons indiqué que l éclatement géographique des ressources à mobiliser dans le cadre d un même projet informatique pouvait être un obstacle à l appropriation des modes opératoires agiles. Pour autant, les contextes de géodistribution des ressources impliquées sur un même projet se multiplient, du fait de la tendance des sociétés informatiques à externaliser certaines activités de développement (en Chine, Inde, Brésil et pays de l est de l Europe). Les stratégies de globalisation présentant un grand nombre d avantages (réduction des coûts de main d œuvre, diversité des profils et des compétences des développeurs, optimisation du cycle de travail en travaillant sur différents fuseaux horaires, décomposition du travail en modules transversaux et indépendants), il convient de s interroger sur la manière dont les méthodes agiles peuvent se rendre accessibles à ce type d environnement. Bien que de nombreux experts en développement considèrent que les méthodes agiles correspondent davantage à des équipes de taille réduite et colocalisées [37, 41, 53], des recherches empiriques ont montré que ces méthodes, en particulier Scrum et Extreme Programming, peuvent être implémentées avec succès dans des équipes géodistribuées [16, 26, 36, 54, 55, 56]. Les défis Les défis majeurs soulevés par la géodistribution des ressources portent sur la nature des interactions entre acteurs du projet, l environnement technique, les différences culturelles, le rôle du client et les modalités du management de projet. Le manque d interactions a été reporté comme un obstacle majeur auquel sont confrontées les équipes agiles dispersées en plusieurs lieux géographiques. Outre la distance physique, divers facteurs contextuels semblent entraver la communication et les échanges entre les acteurs géodistribués : barrières de la langue, indisponibilité et asynchronisation des équipes, différents horaires de travail, etc. L infrastructure technologique de communication dont dispose une organisation constitue un élément essentiel pour permettre les interactions, notamment le partage virtuel de documents et d artefacts collaboratifs comme le product- backlog, le story- board, etc. Les différences culturelles entre équipes travaillant sur divers sites géographiques peuvent affecter la qualité des échanges. Elles peuvent entraîner des incompréhensions et des conflits entre les acteurs projets. Ces conflits peuvent naître de problèmes de compréhension (barrière de la langue), de différences dans les normes culturelles, des règles et des modes de fonctionnement des équipes [26, 39, 56, 57, 58, 59, 60]. L interdépendance des processus métiers peut conduire à des problèmes de synchronisation des activités menées en parallèle. De ce point de vue, le contrôle managérial des divers groupes devient une activité délicate à conduire [15, 26, 36, 56]. La volatilité des demandes, les changements au 34

35 niveau des spécifications et du design nécessitent des efforts supplémentaires de coordination. Des modes de management spécifique doivent dès lors être envisagés comme notamment la division du travail en modules indépendants. Ce type de stratégies peut toutefois engendrer des problèmes techniques quant à l intégration des codes [58, 61]. Il convient alors de mettre en place des règles de développement spécifiques et des outils technologiques performants permettant d assurer une cohérence entre les diverses sources de codes intégrés (outil partagé de dépôt de code, serveur partagé d intégration continue). Les recommandations des praticiens Face à ces défis, les recommandations de praticiens ont principalement trait aux modes de communication à mettre en place et aux modalités d organisation de l équipe projet. La communication directe et informelle occupe une place centrale au niveau des équipes de développement. Il est donc indispensable de disposer d une infrastructure technologique de qualité permettant les échanges virtuels. Diverses technologies d information et de communication sont mises en place pour faciliter la communication directe, le partage de documents et les échanges de connaissances tacites : vidéoconférences, whiteboard 14, Twikis 15, Instant Messenger 16, XPplanner 17, Jira 18, etc. Ces outils collaboratifs constituent un support indispensable à la conduite de réunion des équipes distribuées. Des visites régulières IRL 19 sont également nécessaires, surtout durant les phases critiques du projet, notamment les phases de planification et de tests. Les rencontres en présentiel permettent de renforcer la confiance et la collaboration entre les membres des équipes projets. Si les technologies d information et de communication permettent d améliorer la communication inter- équipes, elles ne se substituent pas parfaitement à la conversation en face à face (au rôle de la gestuelle, du regard, ). Selon certains praticiens, les méls, bien qu indispensables aux échanges, se heurtent à certaines difficultés. A titre d exemple, le temps de réponse aux méls peut être long en raison du décalage horaire et de l indisponibilité du destinataire. Il convient alors d ajuster les horaires de travail en réduisant au maximum le décalage surtout en phase critique du projet ou même, de recourir à certaines règles temps précis de réponse à un mail - qui permettent d éviter les retards. Les praticiens mettent l accent sur le besoin d avoir un client virtuel qui travaille et communique constamment avec l équipe de développement. De ce point de vue, il est préférable que le client soit représenté par une personne au contact facile et portant un grand intérêt au projet [15, 62]. Le client virtuel doit disposer de connaissances techniques lui permettant de communiquer avec l équipe de développement et de prendre les bonnes décisions en matière de fonctionnalités à prioriser et à 14 Logiciel permettant aux utilisateurs distribués de collaborer en temps réel et de partager leurs fichiers, graphes, etc. 15 Une plateforme de travail collaboratif permettant de stocker les informations sous forme de pages web et de pièces jointes. Localisé dans l intranet, cet outil est sécurisant et efficace pour communiquer les différents aspects du projet (use- cases, daily program status, burndown charts, etc.). 16 La messagerie instantanée ou le dialogue en ligne permet l échange instantané de messages textuels entre plusieurs ordinateurs connectés. 17 L XPplanner est un outil de planification et de traçabilité pour les équipes Extreme Programming. 18 Le Jira est un outil collaboratif permettant d assurer le suivi et la gestion du tableau des tâches, des bugs, des demandes d évolution, etc. Les demandes peuvent être affichées sous forme de cartes virtuelles. 19 In Real Life 35

36 implémenter. Si le client est indispensable au bon déroulement du projet, son rôle présente toutefois certaines limites : un client virtuel ne peut pas identifier les changements dans les demandes aussi rapidement qu un client présent physiquement avec son équipe. Il peut également constituer un coût supplémentaire inutile s il n a pas l implication ou les connaissances suffisantes pour prendre les bonnes décisions. Les différences culturelles entre les équipes globalement distribuées peuvent être réduites à travers des rencontres et des échanges fréquents. L échange culturel peut être favorisé par l organisation de voyages inter- sites et des échanges inter- équipes (permutation régulière des testeurs et des développeurs entre pays par exemple). Le rapprochement physique entre les acteurs projets permet de construire plus efficacement une compréhension commune du projet et des modes de travail respectifs. Enfin, des outils de support au management ont été proposés pour contrôler et suivre au quotidien l avancement des projets distribués : la décomposition du projet en équipes indépendantes [57] et la division des équipes en sous- équipes de taille réduite, plus faciles à animer [13, 26, 56, 62]. Certaines entreprises ont mis en pratique un principe de responsabilités de management uniques pour le projet mais donnant lieu à une rotation entre acteurs des différents pays impliqués dans le projet, chaque rôle étant assuré pour une durée limitée [55]. La mise en place de sous- équipes responsables, chacune, d un ensemble limité de fonctionnalités indépendantes semble faciliter les activités managériales. Dans cette optique, l organisation de mini- scrums à un niveau local et de scrum of scrums au niveau des représentants de chacun des sites permet de suivre de façon régulière l avancement du projet et de maintenir une cohésion entre les équipes [16, 23, 63]. Par ailleurs, il est important d avoir une équipe équilibrée en termes de taille, de compétences techniques et d autorité dans chacune des régions concernées par le projet [39]. Cela permet d accélérer les processus de prise de décisions et de résoudre rapidement les conflits émergents. 36

37 Chapitre VI : Retours sur la question d un choix de méthode ou d un degré d agilité Comme nous l avons précisé tout au long de cet ouvrage, les méthodes agiles ont toutes, par- delà leurs spécificités, trois exigences quant à leur modèle de cycle de vie du projet : une forte interaction entre développeurs et avec les utilisateurs (incarnés par la figure du client), des livraisons fréquentes du logiciel, la prise en compte des changements possibles des besoins utilisateurs au cours du projet. Ainsi, toutes renvoient à un modèle itératif et incrémental. La mise en œuvre d un tel modèle de développement se heurte à certaines réalités de structure d organisation que nous avons examinées dans les chapitres précédents (culture d entreprise, taille et localisation des équipes, compétences des acteurs projets informaticiens et client-, ). Nous avons rendu compte des aménagements, «petits arrangements» avec certaines propositions des méthodes agiles, mis en œuvre par les entreprises confrontées à ces contextes organisationnels peu favorables au déploiement de méthodes agiles. Nous avons ainsi évoqué l enjeu d analyser en amont les caractéristiques du projet et de son environnement pour guider le choix de la méthode de management à retenir. Envisager en amont les spécificités du projet informatique et les réalités du contexte organisationnel dans lequel il s inscrit est une posture qui a fait l objet de réflexions et travaux récents. Renvoyant à une analyse des risques du changement organisationnel associés à la mise en œuvre de méthodes agiles, ils évoquent une possible hybridation des méthodes [64] et l opportunité d introduire, via quelques chantiers de méthodes agiles sélectionnés dans le portefeuille de projets, un changement culturel au sein de l entreprise. Analyse des risques et choix d hybridation L évaluation des risques encourus par le choix de chacune des approches (structurée vs agile) permet de déterminer le mode de management adéquat au contexte donné et la manière dont les méthodes peuvent être combinées pour aboutir à de meilleurs résultats. Pour la gestion de grands systèmes aux objectifs de projet très incertains, au nombre de parties- prenantes élevé, portés par une forte culture de planification, la mise en œuvre d une méthode agile demande de faire l objet d une analyse de risque préalable tant ce type de configuration s éloigne du modèle organisationnel implicite des méthodes agiles. Le choix peut ainsi être fait d introduire une «dose» d agilité dans un mode de management de projet très structuré. Ainsi, des démarches d itérations accélérées et participatives peuvent être envisagées dès lors que l on dispose d une vision claire du futur système [64]. Une approche structurée permettant une définition claire des processus métiers concernés ainsi qu une représentation conceptuelle des informations sont des étapes amont qui sont alors essentielles. Certains éléments de la méthode XP peuvent participer à dégager des solutions de compromis en ce que, comme nous l avons déjà évoqué, les itérations de livraison correspondent à des jalons fixés ex- ante et respectés, alors que les itérations de développement peuvent fluctuer. Par ailleurs, comme nous l avons mentionné tout au long de cet ouvrage, la gestion de la qualité est une problématique au cœur des méthodes agile. Le contrôle qualité est très présent à travers les 37

38 validations du client à chaque itération de développement. Pour autant, la démarche qualité repose davantage sur les personnes que sur les procédures. Dans le cas de projets inscrits dans les démarches de qualification (ISO, CMM), la démarche de gestion de la qualité doit reposer sur des aménagements de processus spécifiques. Les méthodes agiles mettent toutes en retrait la place laissée à la documentation et interpellent sur la question de la pérennité de la connaissance du fonctionnement du logiciel. En fait, et à l instar de l Open Source, dans une approche agile la principale documentation est le code source. Or, la fréquence des livraisons tout au long d un projet garantit une parfaite maintenabilité. Les pratiques d ingénierie des méthodes agiles (pair programming, absence de code ownership, refactoring, ) garantissent un code source propre, lisible, bien conçu et documenté. Les règles strictes de codage et leur validation automatisée (tests unitaires, d intégration, fonctionnel, ) garantissent la qualité et tiennent lieu respectivement de conception détaillée et de spécification détaillée, exprimées en langage naturel dans les commentaires et en langage informatique. De fait, la «documentation» est toujours à jour par rapport au code ; l exécution quotidienne des tests et l intégration continue doivent permettre que le code reste toujours conforme aux spécifications. Dans une organisation agile dont les clients sont peu représentatifs et peu impliqués, il convient de réduire les risques encourus en encourageant des démarches de négociations des demandes entre les développeurs et les clients. Une documentation des livrables peut être utile pour réduire les risques d incompréhensions futures. Ou encore dans une organisation basée sur la planification mais dont les demandes sont volatiles, il convient d évaluer les demandes dont la non- spécification pose un risque élevé. Cela permet d éviter la documentation des demandes volatiles dont la spécification peut vite devenir obsolète. Un levier de changement culturel Les méthodes agiles redéfinissent l exercice d un leadership traditionnel basé sur le commandement et le contrôle. D une part, quelles que soient les méthodes, l équipe reçoit une délégation de responsabilité sur une partie du management de ses propres activités (estimation, planification, affectation des tâches, ). De plus, le collectif occupe une place essentielle et le management n est pas focalisé sur les individus isolément. Dans Scrum par exemple, le leadership est partagé entre le scrum master, le propriétaire du produit et l équipe. Toutefois l idée n est pas que toutes les décisions soient prises en commun mais que l équipe ait une visibilité sur la plupart des décisions, avec un équilibre entre décisions déléguées et décisions participatives. La part du changement culturel qui accompagne la mise en œuvre de méthodes agiles est réelle mais sa portée n est pas assurée. Les acteurs peuvent aspirer à être agiles mais ce n est qu après la réalisation du projet qu ils peuvent prétendre l être ou pas (Cockburn évoque le terme «vouloir être» agile). L agilité est avant tout un changement de priorité, un changement dans la nature même du projet, dont les objectifs ne sont plus le respect d un cahier des charges, de coûts et de délais. Comme analysé dans la partir I de cet ouvrage, le substrat théorique des méthodes agiles est limité et facilement maîtrisable. Mais, en pratique, les méthodes agiles imposent des exigences très fortes sur les individus et les organisations. Au niveau individuel, il y a des exigences fortes en matière de compétences techniques afin de produire un logiciel de qualité, évolutif et maintenable. Bien évidemment, là est l enjeu de 38

39 toutes les méthodes de management de projet informatique mais cela est une priorité avec l Agilité. Il y a par ailleurs à l échelle des individus une exigence de savoir- être et de discipline personnelle pour collaborer et communiquer : comme nous l avons mentionné, la mise en place du pair programming, les daily scrums sont, en soi, des chantiers de changement organisationnel. K. Schwaber, fondateur de la méthode scrum, souligne que la transparence portée par les pratiques de gestion agile, «explose l incompétence». Pour les directions d entreprise, les projets managés en «agile» posent un problème de manque de visibilité à moyen et long terme avec un impact sur la budgétisation des projets. La mise en place d une méthode agile est en soi un chantier de changement organisationnel qui peut s opérer dans le temps et faire l objet d un apprentissage de l organisation sur un ou plusieurs volets de la méthode retenue. Présentation d un cas de mise en œuvre d'une démarche «agile» La direction «Alpha» fait partie d un grand groupe français de télécommunication. Elle a pour mission de piloter le développement et la mise en œuvre des plateformes technologiques fournissant les offres de télévision numérique. Les projets pilotés par la direction «Alpha» impliquent des acteurs métiers transverses (architectes techniques, architectes fonctionnels, concepteurs, développeurs, etc.) distribués géographiquement et intervenant de façon ponctuelle au niveau des projets. Le chef de projet n a qu une responsabilité limitée. Son rôle est d assurer la coordination de différentes unités fonctionnelles impliquées dans le projet dont il a la charge et de veiller à la réalisation des objectifs dans les limites temporelles et budgétaires prédéfinies. Les acteurs qu il pilote sont rattachés à différents services fonctionnels ; ce mode d organisation correspond, selon la terminologie de Clark et Wheelwright [65] à une structure de type «lightweight». La direction «Alpha» œuvre dans un environnement technologique évolutif, soumis à une pression concurrentielle accrue, nécessitant une forte réactivité et adaptabilité des projets informatiques menés. Dans ce contexte mouvant, la direction générale décide de mettre en place une réflexion sur «la philosophie des méthodes agiles». Pour la direction générale, l enjeu majeur est de réduire les gaspillages induits au cours des projets en créant un contexte plus «agile», favorable à la communication et à l amélioration continue. Une équipe de cinq personnes, composée de trois managers de projets et de deux responsables qualité, a été désignée pour réfléchir à l implémentation d une approche «agile» dans le management des projets informatiques de l entreprise (nous la désignerons par «équipe agile»). Elle (l équipe agile) a sélectionné trois projets pilotes se trouvant à différents stades d avancement, comme terrain d étude des enjeux, possibilités et freins à la mise en œuvre de méthodes agile. Chaque projet pilote regroupe environ une trentaine de personnes (acteurs métiers rattachés à la direction «Alpha», acteurs métiers rattachés à d autres directions fonctionnelles avec lesquelles la direction «Alpha» collabore ainsi que des prestataires de services externes). Nous avons accompagné l équipe «agile» dans ses réflexions et décisions durant dix- sept mois (Aout Décembre 2010). La première étape de la démarche engagée par l équipe agile a consisté à 39

40 mettre en place des «ateliers de dysfonctionnement» auxquels ont participé des acteurs métiers (architectes techniques, architecte fonctionnels, chefs de projets, responsables maintenance, responsable qualification, etc.) concernés par l un des trois projets «pilotes» retenus. Les dysfonctionnements identifiés ont permis à l équipe agile de comprendre d une part, les causes des retards et des dépassements de budgets dans les projets et d autre part, de formuler des recommandations quant aux pratiques agiles à implémenter. Les membres de l équipe en charge du chantier «agile» ont été formés aux principes du lean management et des méthodes «agiles». De nombreux dysfonctionnements d ordre organisationnel et managérial sont «remontés». La production excessive constitue une première forme de gaspillage présente dans les projets menés au sein de la direction «Alpha». De nombreuses fonctionnalités et documentations sont développées alors qu elles se révèlent, par la suite, inutiles. La rareté des occasions de communication entre les acteurs métiers (réunions hebdomadaires organisées par le chef de projet avec seulement des «bouts» d équipes) et l absence d un environnement visuel (diffusion des informations par le biais des reporting formels, documentation exhaustive des différentes activités) rendent difficile la cohésion inter- équipes et la création de vision commune du projet. En outre, les acteurs métiers ont tendance à anticiper certaines activités et à prendre des initiatives sans pour autant les communiquer systématiquement à leurs pairs. «Le raté avec eux est par exemple qu'ils vont corriger plus que tu leur as demandé... ils ont tendance des fois à se substituer au client en voulant faire mieux et livrer plus que tu demandes» L attente renvoie à une deuxième forme de gaspillage remontée lors de ces ateliers. Elle se manifeste par des acteurs inoccupés, en situation d attente d informations précises, de décisions hiérarchiques, de validation de résultats ou de ressources momentanément indisponibles. Les acteurs peinent à identifier les interlocuteurs capables de les assister dans les problèmes rencontrés ou de les aider à répondre à leurs questionnements. Les délais d attente sur les phases des projets peuvent ainsi s expliquer par : la multiplicité des canaux de communication et de décideurs, la conduite simultanée de plusieurs projets et leur mobilisation de ressources communes qui deviennent dès lors des goulets d étranglement, la dépendance entre les phases d un projet, l indisponibilité des informations recherchées et/ou la faible fiabilité des données disponibles. «Les chefs de projet sont en attente de l aval du comité des services d achats pour les décisions budgétaires... donc là les développeurs rentrent dans les problèmes de rapports, de prises de décisions» Les dysfonctionnements identifiés justifiaient de repenser la structure de l organisation et le mode séquentiel de gestion de projets existant. Mais les membres de l équipe «agile» ont préféré s attarder sur les problèmes qui relèvent directement du manque de communication entre les acteurs projets et dont les solutions semblaient plus à portée (et moins lourdes à mettre en œuvre). De fait, ils se sont focalisés sur la mise en place d outils permettant d accroître les échanges entre les équipes : instauration de réunions quotidiennes, management visuel instrumenté par des tableaux 40

41 blancs, suivi et affichage d indicateurs de performance dont un format standard commun a été arrêté. L objectif étant d améliorer les échanges inter- équipes et d accroître la visibilité des projets. Les transports et manutentions inutiles constituent un troisième type de gaspillage en développement informatique. Les déplacements physiques des documents et les allers retours de mails peuvent ralentir le processus de traitement des demandes et par conséquent les activités des différents collaborateurs. Selon les personnes interviewées ou participant aux ateliers, les échanges inutiles d informations relèvent de la multiplicité des acteurs impliqués dans les projets et du manque de clarification des rôles à l intérieur de l organisation. «C est vrai que parfois les gens se demandent un peu par qui le projet est piloté...comme je te le disais, on a énormément de collaborateurs» ; «On a des difficultés à mettre des noms sur les personnes travaillant sur une activité ou un composant» Les activités redondantes ainsi que les arrêts et reprises d une même tâche ou activité sont également apparus comme des gaspillages fréquents dans les ateliers de remontées de dysfonctionnements des projets pilotes analysés. En effet, la reprise d une tâche suspendue engendre des pertes de temps considérables. Elle nécessite des efforts supplémentaires de la part de l acteur responsable dans la mesure où celui- ci est amené à se remettre dans les conditions préalables alors qu il s est déjà impliqué dans d autres tâches. «Il nous arrive souvent d arrêter un travail parce qu il est moins prioritaire et puis on essaye de le reprendre et donc de se remettre dans le contexte... On se trouve face à un travail à moitié fait et donc inutile» «Il y a des difficultés à avoir une vision globale. Il y a du travail refait dans le projet du fait de manque de vision globale de la proposition des solutions des architectes». Ces formes de gaspillage semblent être dues d une part, au manque de communication et de vision globale du projet et d autre part, à l absence de stratégies de priorisation des demandes. Ajoutons que les situations de «retravail» se sont révélées très fréquentes dans les projets de grande taille au sein desquels les équipes consacrent beaucoup de temps aux phases de planification et d études. Une autre forme de gaspillage apparue dans les projets retenus relève de «l inventaire». En industrie automobile, l inventaire renvoie aux stocks inutiles qui génèrent des gaspillages parce qu ils occupent un espace physique, nécessitent des déplacements et une maintenance. Dans le développement informatique, ce type de gaspillage concerne plutôt le travail partiellement effectué ainsi que la documentation et les fonctionnalités non nécessaires. Dans le cas étudié, le manque d échanges réguliers entre les acteurs, l absence de stratégies de priorisation et la mauvaise clarification des demandes sont autant d éléments évoqués comme des raisons qui se trouvent à l origine de ce type de gaspillage. 41

42 «Il y a des changements de priorité entre les différentes fonctionnalités et entre différents projets... on passe du temps à faire un truc et finalement on nous demande de laisser tomber et de commencer un nouveau truc...» ; «les clients changent souvent leurs demandes et nous demandent par conséquent de changer nos priorités, on modifie le périmètre d un projet déjà lancé pour intégrer une autre partie». Enfin une dernière forme de gaspillage remontée par les équipes concerne les défauts. Dans une industrie automobile, le repérage tardif des pièces défectueuses et des rebuts se trouvent à l origine de nombreux surcoûts. Dans le contexte étudié, les acteurs se plaignent d une part, de nombreux bugs qui apparaissent après le développement et d autre part, de la qualité des documents produits. Les systèmes en place d anticipation et de détection rapide des défauts s avèrent peu efficaces. «Il nous faut 12 mois pour sortir quelque chose... Et en plus quand on le sort, nos clients sont rarement satisfaits parce que ça ne correspond pas trop à ce qu ils attendaient...» «Il n y a pas de capitalisation des compétences lors de changement de prestation...» ; «Il y a une difficulté de capitaliser sur les compétences en cas de changement de prestataire» Afin de remédier à ce type de difficultés, l équipe «agile» a opté pour la mise en place de sessions «kaizen» et d outils d identification et de résolution de problèmes. L objectif étant de favoriser une démarche d identification rapide des problèmes et de résolution collective dès leur apparition. D un point de vue général, la rareté des échanges entre les parties prenantes semble affecter la coordination, le suivi et le contrôle des activités réalisées. Outre ce déficit de communication entre les acteurs projets, divers facteurs organisationnels et managériaux se trouvent à l origine des dysfonctionnements identifiés : le style de management «classique» valorisé par les chefs de projet, la structure organisationnelle pyramidale et le manque d autonomie des chefs de projets. Là encore, le traitement des problèmes relevant de la structure tèrs hiérarchique de l organisation a semblé hors de portée des membres de l équipe «agile». Ces derniers se sont vite rendus compte des limites de leur champ d action et ont, par conséquent, orienté leur démarche d amélioration en fonction. Les dysfonctionnements remontés lors des ateliers ont permis à l équipe «agile» de justifier, auprès du top management, de préconiser un mode de management plus «agile», toutefois sur un mode hybride, ménageant l organisation et culture en place dans l entreprise. Les chefs d équipes de taille réduite (les équipes de développement par exemple) ont facilement été convaincu de l enjeu de pratiques «agiles» telles que le développement itératif, les réunions quotidiennes, les échanges réguliers avec le client, etc. comme moyen permettant d améliorer la cohésion de celles- ci et la satisfaction des parties prenantes du projet. Les équipes de grande taille ont été plus sceptiques quant à l application de ces pratiques de collaboration. «Je suis positive par rapport à la démarche mais je pense qu elle est peut être non déclinable avec un volume d équipes aussi grand» (Chef de Projet P) ; «Je suis juste sceptique par rapport à la taille de l équipe» (Chef de projet P) ; «J aime bien que tout le monde ait une vision globale du projet mais ça va prendre beaucoup de temps en essayant de réunir toutes les personnes concernées» (Chef de Projet C). 42

43 «Il y a de nombreuses instances le long d un projet, la chaîne de décision est complexe...par exemple on a un grand nombre d interlocuteurs du côté du marketing... il est important d avoir un décideur» (Chef de Projet D). La géodistribution des équipes a constitué un autre facteur sur lequel les acteurs se sont attardés lors de la mise en place des outils «agiles». Face à des équipes de grande taille et géodistribuées (40 personnes en moyenne), les membres de l équipe «agile» ont longuement négocié les propositions à soumettre aux chefs de projets. L enjeu était d alléger la tâche des chefs de projet en leur mettant à disposition des outils préconstruits facilement adaptables et applicables à leurs contextes. Les réunions quotidiennes de quinze minutes, par exemple, ont semblé inappropriées pour des équipes de grande taille : des réunions à fréquences variables et limitant le nombre de participants ont été décidées. A ce titre, seuls les acteurs impliqués dans la phase dans laquelle se situe le projet seront conviés à ces réunions. Certes, cette solution permet au chef de projet de réunir les personnes concernées directement par une phase donnée d un projet, néanmoins elle ne répond pas à la visée essentielle des réunions de type «daily- scrum». La dispersion géographique a une incidence sur le plan organisationnel et technique : trouver un horaire convenable pour tous, s assurer que tout le monde est bien connecté, disposer de services de télécommunication qui permettent la transmission des images, des données et de la voix sur de longues distances. Le cas de cette entreprise est spécifique d une structure de type «lightweight» dans laquelle le statut du chef de projet est dépourvu d influence forte. Ce dernier collabore avec différents acteurs (acteurs projets, acteurs transverses provisoires, sous- traitants, etc.) et ne dispose pas d autorité hiérarchique sur les personnes qu il gère. «En tant que chef de projet, on n'a pas de gestion d'équipe. On gère notre équipe sur un projet mais il n y a personne qui nous est rattaché. Je n'évalue le travail de personne par exemple, je ne dis pas voilà, lui a fait un bon boulot ou pas, je ne fixe pas des objectifs... On pioche dans des pools de ressources gérées par d'autres chefs...c est compliqué car on va demander des tâches à des personnes dont on n est pas le chef» (Chef de Projet C). La capitalisation sur les connaissances et le suivi régulier des activités des équipes projets ne sont également pas garanties car d une part les équipes impliquées dans un projet sont instables et d une autre, chacune de ces équipes est rattachée à un responsable fonctionnel différent et bénéficie d un mode de fonctionnement qui lui est propre : tableau de bord avec indicateurs de performance différents, modes de communication et de collaboration intra- équipe, modes de planification, etc. «C est difficile de mettre en œuvre le partage de connaissance car chaque personne gère son propre planning. Le chef de projet est un chef d orchestre, il ne maîtrise pas les activités des acteurs métiers qui ont leurs contraintes et priorités» (TR, membre de l équipe «L») ; «Il y a un mouvement dans l équipe, les personnes concernées par le brief ne seraient pas les mêmes... les architectes ne sont pas les mêmes quand on est dans l étude ou dans la production... En plus il y a des gens qui arrivent en cours de route... je ne maîtrise pas les activités des contributeurs... il y a vraiment une perte d informations liée au départ des personnes au cours du projet» (Chef de Projet C). 43

44 Comment l ont fait remarqué les acteurs concernés, l instabilité des équipes et l autorité hiérarchique limitée du chef de projet compliquent la mise en mise en place des outils «agiles» proposés. Les changements d acteurs en cours de projets requièrent des efforts supplémentaires en termes de renforcement de la cohésion des équipes et de communication entre les membres de celles- ci. De plus, l intervention ponctuelle des acteurs engendre une perte d informations et de connaissances empêchant par conséquent la capitalisation sur les projets menés. Dans ce contexte il ne suffit pas au chef de projet d insister auprès des différents responsables métiers pour que leurs collaborateurs respectifs participent aux réunions quotidiennes qu il pilote. L animation de réunions quotidiennes avec l ensemble de l équipe est difficile à mettre en œuvre sauf incitations fortes (injonction) de la direction pour appuyer la démarche des chefs de projet ; des signaux forts ont été envoyés par la direction. Dans la direction «Alpha», les projets sont généralement menés selon un mode séquentiel s appuyant sur une séparation des expertises entre les différents métiers et valorisant la planification et la documentation exhaustives. Des réunions hebdomadaires de longue durée sont menées séparément et successivement avec chacune des entités impliquées dans la réalisation du projet. Suite à ces réunions, un ensemble de compte- rendu est élaboré et diffusé au sein de l organisation. L idée de mettre en place des réunions quotidiennes de courte durée a été mal accueillie. Ces réunions ont été perçues comme une charge supplémentaire à gérer, bien que leur objet diffère largement des réunions de revues hebdomadaires. La difficulté à motiver les acteurs projets à assister à des réunions supplémentaires et d intercaler celles- ci aux réunions déjà existantes ont été les principaux arguments avancés par les chefs de projet. «Aujourd hui on termine à 19 heures, il faut voir la réaction des gens pour rajouter encore une autre réunion...» (Chef de Projet E) ; «Si je vais encore faire ces daily briefs, je vais passer mon temps à faire des réunions... Les responsables transverses sont très sollicités et donc ils sont surchargés» (Chef de projet C) «On a un paquet de reporting à faire... J'ai un compte rendu global dans lequel je donne les liens vers tous les compte- rendus avec le client, les opérationnels, les architectes. Ils se trouvent sur Roll et sont envoyés par mail mais franchement ils ne s'en servent pas. Ils ne les lisent pas du tout. Il y a que moi qui m'en sert» (Chef de projet C). Du point de vue des partisans des méthodes «agiles», la documentation doit être réduite aux maximum et être remplacée par des livrables concrets matérialisant les différentes phases du projet : design, conception, développement, tests, etc. («working software over comprehensive documentation», Agile Manifesto). Dans le cas de l entité «Alpha», les acteurs projets ne sont pas prêts à abandonner ce type de pratiques. «Laurence (chef de projet) considère que tous les documents qu'elle a eu sont indispensables pour son projet» (JO membre de l équipe «L»). Cette attitude peut s expliquer par la culture organisationnelle de non prise de risque valorisant les processus et procédures très formels : les prises de décision nécessitant l accord de diverses 44

45 instances hiérarchiques, le besoin de traçabilité des actions entreprises conduisent à une documentation extensive «tout le monde prend trop de précaution ce qui rend toutes les actions très longue» (Chef de projet L). Mais là encore, les solutions envisageables ne semblant pas à portée de l équipe agile, il fut décidé de les reporter à plus tard et de compter sur les premiers chantiers de transformation organisationnelle pour amorcer un changement culturel. 45

46 Conclusion La première partie de cet ouvrage a été l occasion de présenter trois méthodes agiles en développement informatique : la méthode Scrum, la méthode Extreme Programming et la méthode de Développement Lean. Le principal intérêt de ces trois méthodes est de conférer à l organisation la capacité de reconfigurer rapidement son offre en réponse à l apparition d une nouvelle propriété de la demande client. Pour atteindre cet objectif, chacune promeut le respect de principes fondamentaux qui se déclinent dans les organisations en modes opératoires et en outils de gestion. Le tableau (3) propose un résumé des principes clefs, des modes opératoires et des outils défendus par chaque méthode. Tableau 3: Résumé concernant les méthodes Scrum, Extreme Programming et Lean Scrum [1] Extreme Programming [4] Lean [5] Principes Transparence Contrôle Adaptation Communication Retours d informations Simplicité des codes et du design Développement des compétences Réduction des gaspillages Réactivité face aux dysfonctionnements Développement des collaborateurs Réunion Pre- sprint Cycle de planification hebdomadaire Système pull, Modes opératoires Réunion Sprint Planning Réunions quotidiennes Réunion Post- sprint Réunion rétrospective Réunion hebdomadaire Réunion quotidienne Tests unitaires et fonctionnels Intégration continue Développement piloté par les tests, Développement itératif Chantiers d amélioration continue Client sur le site Outils de gestion Product- backlog Sprint- backlog Burndown charts Story- cards Story- board User- stories Tableaux de bord partagés Post- it Détrompeurs Framework for integrated tests 46

47 La deuxième partie de l ouvrage a été consacrée à une discussion sur la manière dont les organisations se saisissent des modes opératoires agiles. Il en ressort d un côté que la plupart des entreprises en mesurent les effets bénéfiques en termes de relation client, de communication interne, de visibilité et de contrôle sur l avancement du projet. D un autre côté, il apparait que les modes opératoires agiles sont exigeants et sans doute plus adaptés aux structures de taille réduite et colocalisées. Finalement, cet ouvrage nous permet de mettre en évidence et de conclure sur ce qui pourrait apparaitre, en première lecture, comme un paradoxe : les modes opératoires agiles sont indéniablement structurants. Ils contraignent l activité des équipes de développement et obligent tous les acteurs à suivre des procédures figées et exigeantes compte tenu du rythme soutenu des itérations, de la réactivité souhaitée face aux dysfonctionnements et de l intégration à échéance courte des modifications fréquentes de la demande client. Pourtant, l objectif recherché est bien celui de l agilité de l organisation et donc par extension, d une certaine forme de souplesse et de déséquilibre maîtrisé des processus de l entreprise. N existe- t- il donc pas une contradiction apparente entre les propriétés structurantes voire «rigidifiantes» des méthodes agiles et l objectif recherché d adaptation permanente de ses processus aux changements? L une des clefs de compréhension des méthodes agiles réside précisément dans la réponse négative qu il faut apporter à cette question. Les modes opératoires agiles sont effectivement structurants mais ils viennent structurer l apprentissage de chaque collaborateur et non les processus de développement informatique. Les méthodes agiles régissent la manière dont chaque collaborateur va apprendre. Le développement des compétences ne pouvant plus être pensé par anticipation en raison des changements imprévisibles de la demande et donc de l offre, les modalités de l apprentissage présentent de nouvelles caractéristiques. D abord, l acquisition de connaissances nouvelles se construit avec le client, virtuel ou intégré à l organisation. La place occupée par les itérations au sein des méthodes agiles témoigne de cette dimension collaborative dans l apprentissage. Ensuite, l apprentissage se fonde sur une nouvelle conception de la valeur créée par l organisation. Cette valeur est désormais définie du point de vue du client, ce qui permet à l entreprise de qualifier ses propres actions en «temps à valeur ajouté» ou en «gaspillages». Enfin, l apprentissage est le résultat d un partage subtil d informations formelles et informelles, dont certaines renvoient à une forme de savoir tacite, ce qui empêche de les digitaliser. Le management visuel par post- it, le pair programming, l ensemble des réunions en configuration plateau et la prudence des organisations agiles à l égard des outils informatiques censés faciliter le cadrage, le découpage et le suivi des projets participent de cette logique. Les difficultés à installer les méthodes agiles dans des organisations de grande taille et au sein d environnements où les collaborateurs sont dispersés géographiquement confirment notre hypothèse. L apprentissage est facilité par l existence de petites équipes. Il devient complexe à distance et ne peut pas être par nature sous- traité. 47

48 Le pari des méthodes agiles est ainsi de réussir à rendre l organisation flexible par le développement des compétences de ses collaborateurs. Elles ne rigidifient pas l organisation et ses processus de production mais figent les processus d apprentissage. Le pari est raisonnable. L organisation repose sur un ensemble d actifs (parc machines, expérience, brevets, capital humain ) dont les capacités de remise en cause sont plus en moindre grandes en fonction de leur nature. Parce qu elles présentent l avantage d être à la fois centrales pour l organisation, renouvelables avec l apparition d un nouveau challenge et cumulatives, les compétences des collaborateurs sont constitutives des méthodes agiles. L aptitude d une organisation à concevoir son agilité autour de méthodes d apprentissage structurantes est susceptible d expliquer son succès ou son échec. Si l entreprise s engage dans la voie de l agilité sans avoir stabilisé au préalable ses processus d apprentissage individuels et organisationnels, alors toute forme de changement (pour répondre aux nouvelles attentes du client) viendra déstabiliser sa production et dégradera la qualité du bien ou du service délivré. Les outils et les modes opératoires agiles seront ainsi envisagés par les collaborateurs comme participant d un management par la pression, les jalons étant raccourcis, les contrôles opérés par le client étant plus fréquents, et l environnement rendant les dysfonctionnements davantage visibles. Si l entreprise, au contraire, profite de l introduction des méthodes agiles pour les mettre au service de la formation et du développement des compétences de son personnel, alors le changement sera plus facilement opéré par les collaborateurs. En effet, les collaborateurs seront désormais capables de répondre aux nouveaux besoins du client par une maîtrise accrue de leur activité et donc par la faculté à savoir plus précisément comment faire progresser la production dans le sens des aspirations du client. L agilité nécessite ainsi une grande maîtrise de ses processus de production et d apprentissage. A ce titre, l agilité requiert de la stabilité. Il ne s agit pas ici d une simple recommandation contre- intuitive sur la manière de présenter les méthodes agiles dans l organisation. Le couple «agilité/stabilité» est en réalité un fondement des méthodes agiles et doit être envisagé comme constitutif de ces méthodes (Scrum, XP et Lean ). Par ailleurs, le parti- pris des méthodes agiles est que le développement des compétences des collaborateurs ne peut être envisagé de manière séparée de l action : c est en faisant que l on apprend. Et, c est de l interaction en situation réelle d action que naissent les connaissances collectives sur lesquelles repose la plupart des modes opératoires agiles. L action et les interactions sont donc les principales modalités pédagogiques de la dynamique d apprentissage sur laquelle se fondent les méthodes agiles. Pour cette raison, les méthodes agiles peuvent être associées à des méthodes de Knowledge Management (KM). Plus précisément, la littérature en gestion des connaissances évoque le terme de «Knowing» pour montrer que l acquisition d un savoir nouveau fait suite à la réalisation d opérations concrètes, en lien avec un problème réel et dont la solution est co- construite. Le savoir n émerge donc pas de l exploitation d un stock de savoir qu il suffirait de mettre à la disposition de ses collaborateurs. L apprentissage par l action et les interactions occupant une place centrale au sein des méthodes agiles, tant au niveau de l ingénierie des projets (cycles itératifs, pair programming, réunions quotidiennes) que des modes opératoires et des outils agiles (résolution de problèmes, tests unitaires, intégration continue ), elles peuvent parfaitement être appréhendées comme une dynamique d apprentissage de type «Knowing». 48

49 Cette vision des méthodes agiles comme pratique de Knowledge Management est confortée par la lecture des quatre valeurs introductives du document originel et resté le plus célèbre sur les méthodes agiles : le «Manifesto for Agile Software Development». Si les signataires de ce document résument les méthodes agiles par «la valorisation des individus, des interactions, de l application fonctionnelle, de la collaboration avec le client et de la réponse au changement plutôt que de considérer les processus, les outils, la documentation compréhensive, la négociation des contrats et les plans d actions», c est précisément parce que les premiers participent davantage d'une dynamique d apprentissage selon des modalités de Knowledge Management fondés sur la maitrise initiale de son activité (stabilité), l expérimentation en situation réelle (l action), la réactivité et la validation permanente des résultats (les interactions). 49

50 Bibliographie [1] Schwaber K. & Beedle M. (2002), Agile software development with scrum, Prentice Hall. [2] Takeuchi H. & Nonaka I. (1986), «The new product development game», Harvard Business Review, pp [3] Beck K. (1999), Extreme Programming Explained: Embrace Change, Addison- Wesley Professional. [4] Beck K. & Andres C. (2004), Extreme Programming Explained: Embrace Change, Addison- Wesley Professional, 2nd edition. [5] Poppendieck M. & T. (2006), Implementing lean software development : from concept to cash, Addison- Wesley. [6] Khalil C. (2011), «Les méthodes agiles de management de projets informatiques : une analyse par la pratique», thèse de Doctorat en Sciences de Gestion, département Sciences Économiques et Sociales, Télécom ParisTech. [7] Middleton P., Flaxel A. & Cookson A. (2005), «Lean software management case study: Timberline Inc.», Extreme Programming and Agile Processes in Software Engineering, Lecture notes in computer science, vol 3556, n , pp [8] Poppendieck M. & T. (2009), Leading lean software development : results are not the point, Addison- Wesley. [9] Tessem B. (2003), «Experiences in learning XP practices : a qualitative study», Proceedings 4th International conference on Extreme Programming and Agile Processes in Software Engineering, Italy, pp [10] Karlström D. & Runeson P. (2005), «Combining agile methods with stage- gate project management», IEEE Computer Society, vol 22, n 3, pp [11] LeJeune N.F. (2006), «Teaching software engineering practices with extreme programming», Journal of Computing Sciences in Colleges, vol 21, n 3, pp [12] Petersen K. & Wohlin C. (2009), «A comparison of issues and advantages in agile and incremental development between state of the art and an industrial case», Journal of systems and software, vol 82, n 9, pp [13] Beavers, Paul A. (2007), «Managing a large agile software engineering organization», Proceedings of the Agile Conference, IEEE Computer Society, pp [14] Middleton P. & Joyce D. (2010), «Lean software management: BBC worldwide case study», IEEE Transactions engineering management, pp [15] Simons M. (2002), «Internationally Agile», InformIT. [16] Berczuk S. (2007), «Back to basics : the role of agile principles in success with an distributed scrum team», Proceedings of Agile Conference, IEEE Computer Society, Washington, pp [17] Melnik G. & Maurer F. (2002), «Perceptions of agile practices : a student survey», Proceedings of the Second XP Universe and First Agile Universe Conference on Extreme Programming and Agile Methods, Lecture Notes in Computer Science, vol 2418, pp [18] Svensson H. & Host M. (2005), «Views from an organization on how agile development affects its collaboration with software development team», International conference on product focused software process improvement, Lecture Notes in Computer Science, vol 3547, Finland, pp [19] Paasivaara M. & Lassenius C. (2004), «Using Iterative and Incremental Processes in Global Software Development», Proceedings of the ICSE Workshop on Global Software Development, Edinburgh, Scotland, pp [20] Jokela T. & Abrahamsson P. (2004), «Usability assessment of an extreme programming project : close co- operation with the customer does not equal to good usability», Product Focused Software Process Improvement, Lecture Notes in Computer Science, vol. 3009, Berlin, pp

51 [21] Koch S. (2004), «Agile principles and open source software development : a theoretical and empirical discussion», Extreme Programming and Agile Processes in Software Engineering, Lecture Notes in Computer Science, vol 3092, Germany; pp [22] Bahli B. & Zeid E.S.A. (2005), «The role of knowledge creation in adopting extreme programming model: an empirical study», ITI 3rd International Conference on Information and Communications Technology: Enabling Technologies for the New Knowledge Society. [23] Sutherland J. (2001), «Agile can scale : inventing and reinventing scrum in five companies», Cutter IT Journal, vol 14, n 12, pp [24] Khalil C., Fernandez V. (2011), «Agile development teams in a plan- driven organization : interplay between agile and traditional software methodologies», International Symposium on information System and Software Engineering, Orlando, Floride. [25] Smits H. (2007), «Implementing scrum in a distributed software development organization», Proceedings of the conference on agile, pp [26] Sutherland J., Viktorov A., Blount J. & Puntikov N. (2007), «Distributed scrum : agile project management with outsourced development teams», 40th Annual Hawaii International Conference on System Sciences, Waikoloa, pp [27] Llieva S., Ivanov P. & Stefanova E. (2004), «Analyses of an agile methodology implementation», Proceedings of the 30th EUROMICRO Conference, IEEE Computer Society, pp [28] Williams L., Kessler R., Cunningham R.W. & Jeffries R. (2000), «Strengthening the Case for Pair Programming», IEEE Software, vol 17, n 4, pp [29] Cockburn A. & Williams L. (2003), «Agile software development : it's about Feedback and Change», Computer, vol 36, n 6, pp [30] Williams L. & Cockburn A. (2003), «Agile software development : it s about feedback and change», IEEE Computer Society, pp [31] Mannaro K., Melis M. & Marchesi M. (2004), «Empirical analysis on the satisfaction of IT employees comparing XP practices with other software development methodologies», Extreme Programming and Agile Processes in Software Engineering, Proceedings, Lecture Notes in Computer Science, vol. 3092, pp [32] Wellington C.A., Briggs T. & Girard C.D. (2005), «Comparison of student experiences with plan- driven and agile methodologies», Proceedings of the 35th Annual Conference, IEEE Frontiers in Education, pp. T3G- 18. [33] Chong J. (2005), «Social behaviors on XP and non XP : a comparative study», Proceedings of Agile Development Conference, Computer Society, pp [34] Robinson H. & Sharp H. (2004), «The characteristics of XP Teams», Extreme Programming and Agile Processes in Software Engineering, Lecture Notes in Computer Science, vol 3092, Berlin, pp [35] Robinson H., Segal J. & Sharp H. (2007), «Ethnographically- informed empirical studies of software practice», Information and Software Technology, vol 49, n 6, pp [36] Paasivaara M., Durasiewicz S. & Lassenius C. (2009), «Using scrum in distributed agile development : A multiple case study», 4th IEEE International Conference on Global Software Engineering, Limerick, Ireland, pp [37] Cockburn A. & Highsmith J. (2001), «Agile software development : The People Factor», Computer, pp [38] Kircher M., Jain P., Corsaro A. & Levine D. (2001), «Distributed extreme programming», Proceedings 2nd Conference on Extreme Programming and Flexible Processes in Software Engineering, Sardinia, Italy. [39] Yap M. (2005), «Follow the sun: distributed extreme Programming development», Proceedings of Agile Conference, Kirkland, pp

52 [40] Ambler S. (2002b), «Lessons in agility from internet- based development», IEEE Software, vol 19, n 2, pp [41] Rising L. & Janoff N. (2000), «The scrum software development process for small teams», IEEE Software, vol 17, n 4, pp [42] Hilkka M- R., Tuure T. & Matti R. (2005), «Is extreme programming just old wine in new bottle : a comparison of two cases», Journal of Database Management, vol 16, n 4, pp [43] Dyba T. (2000), «Improvisation in small software organizations», IEEE Software, vol 17, n 5, pp [44] Mann C. & Maurer F. (2005), «A case study on the impact of scrum on overtime and customer satisfaction», Proceedings of the Agile Development Conference, IEEE Computer Society, Washington, pp [45] Sillitti A., Ceschi M., Russo B. & Succi G. (2005), «Managing uncertainty in requirements : a survey documentation driven and agile companies», 11th IEEE International Software Metrics Symposium, Computer Society, pp [46] Koskela J. & Abrahamsson P. (2004), «on site customer in an XP project : empirical results from a case study», Software Process Improvement 11th European Conference, Lecture Notes in Computer Science, vol 3281, Berlin, pp [47] Layman L., Williams L., Damia D. & Bures H. (2006), «Essential communication practices for extreme programming in a global software development team», Information and Software Technology, vol 48, n 9, pp [48] Martin A., Biddle R. & Noble J. (2004), «The XP customer role in practice : three studies», Proceedings of the Agile Development Conference, Computer Society, Utah, pp [49] Cockburn A. (2002b), «Agile software development joins the would be crowd», Cutter IT Journal, vol 15, n 1, pp [50] Sharp H., Hall T., Baddoo N. & Beecham S. (2007), «Exploring motivational differences between software developers and project managers», ESEC/FSE. [51] Robinson H, Sharp H. (2005); «Organizational culture and XP : three case studies», Proceedings of the agile conference, Computer Society, pp [52] Sharp H., Robinson H. & Petre M. (2009), «The role of physical artifacts in agile software development : Two complementary perspectives», Interacting with Computers, vol 21, n 1-2, pp [53] Cohen D., Lindvall M. & Costa P. (2004), «An introduction to agile methods», Advances in computers, vol 62, pp [54] Kircher M., Jain P., Corsaro A. & Levine D. (2001), «Distributed extreme programming», Proceedings 2nd Conference on Extreme Programming and Flexible Processes in Software Engineering, Sardinia, Italy. [55] Danait A. (2005), «Agile offshore techniques - a case study», Proceedings of Agile Conference, IEEE Computer Society, Washington, DC, USA, pp [56] Paasivaara M., Durasiewicz S. & Lassenius C. (2008), «Distributed agile development : Using Scrum in a large project», IEEE International Conference on Global Software Engineering, Bangalore, pp [57] Herbsleb J.D. & Grinter R.E. (1999), «Splitting the organization and integrating the code : Conway s law revisited», Proceedings of the 21st International Conference on Software Engineering, CA, USA, pp [58] Herbsleb J.D. & Moitra D. (2001), «Global software development», IEEE Software, vol 18, n 2, pp [59] Poole C.J. (2004), «Distributed product development using extreme programming», Lecture Notes in Computer Science, vol 3092, pp

53 [60] Cristal M., Wildt D. & Prikladnicki R. (2008), «Usage of scrum Practices within a global company», Proceedings of ICGSE, pp [61] Mockus A. & Herbsleb J. (2001), «Challenges of global software development», Proceedings 7th International Software Metrics Symposium, London, pp [62] Layman L., Williams L. & Cunningham L. (2004), «Exploring extreme programming in context: an industrial case study», Proceeding of the Agile Development Conference, IEEE Computer Society, IEEE Computer Society Washington, DC, USA, pp [63] Summers M. (2008), «Insights into an agile adventure with offshore partners», Proceedings of the Conference on Agile, pp [64] Boehm B. & Turner R. (2005), «Management challenges to implementing agile processes in traditional development organizations», Software, IEEE, vol 22, n 5, pp [65] Midler C. (1993b), «Gestion de projet, l entreprise en question», in ECOSIP Pilotages de projet et entreprises : diversités et convergences, sous la direction de Midler C. & Giard V., Economica, pp