Rapport de veille technologique

Transcription

1 Centres de compétences TIC Région wallonne, BE Rapport de veille Réalisé par Vivansa s.p.r.l. ( Simply because you need results.

2 [Page blanche pour impression recto-verso] Réalisé par : Vivansa ( 18-Jan-2010 Page : 2 of 89

3 IDENTIFICATION PROJET REFERENCE CONTRAT CSC-2009 CLIENT Centres de compétences TIC PROGRAMME Veille CONTRACTUEL Oui NOM, FONCTION DATE SIGNATURE Écrit par : Saïd Eloudrhiri, IT Consultant 13/01/10 Revu par : Pierre Halin, IT Consultant 16/01/10 Approuvé par : Vivien Monti, Manager 18/01/10 RESUME MOTS CLES : Le présent rapport se penche sur les méthodes agiles de gestion de projet et de développement logiciel. Le besoin en agilité conduit les entreprises à considérer les méthodes agiles comme le moyen de réduire le time-to-market et à obtenir des solutions métiers répondant aux attentes. Face aux valeurs et principes agiles, les entreprises ont le défi de revoir leur méthode de travail et leur système ancré dans le modèle hiérarchique. Des sacrifices que les entreprises seront contraintes de considérer au risque de les voir échouer dans la conquête de nouveaux marchés. Méthodes agiles, SCRUM, XP, agile CARACTERISTIQUE DU DOCUMENT NOMBRE DE PAGES NOMBRE DE FIGURES LANGUE DESTINATAIRE FR N/A Réalisé par : Vivansa ( 18-Jan-2010 Page : 3 of 89

4 Versions Ed. Rév. Date Description Action(*) Paragraphes /10/09 Préparation du document M Tous /10/09 Table des matières finalisée I Tous /01/10 Corps du document finalisé I/M Tous /01/10 Corrections mineures I/M Tous /01/10 Revue qualité Q Tous /01/10 Version finale pour livraison M Tous (*) Action : I = Insertion, R = Remplacement, M = Mise à jour, S = Suppression, Q = Revue Qualité Réalisé par : Vivansa ( 18-Jan-2010 Page : 4 of 89

5 Table des matières 1 GLOSSAIRE 10 2 INTRODUCTION 11 3 CONVENTIONS MESSAGES D'INFORMATION DÉFINITION SOURCES NOMS DE MARQUE 12 4 CONTEXTE PRÉAMBULE LES PROJETS IT DANS LE MONDE LES CAUSES POSSIBLES D'ÉCHECS LES MÉTHODES AGILES : LEVIER DU SUCCÈS? 15 5 APPROCHE TRADITIONNELLE PRÉAMBULE QUELQUES MÉTHODES MODÈLE EN CASCADE MODÈLE EN V ILLUSTRATION DES PRINCIPES CONTRACTUALISATION PLAN DE PROJET SPÉCIFICATIONS DES BESOINS DÉVELOPPEMENT ÉVOLUTION DES BESOINS TESTS LIVRAISON DE LA SOLUTION MÉTHODES TRADITIONNELLES ET ARCHITECTURE IT OBSERVATIONS 26 6 APPROCHE AGILE PRÉAMBULE COLLABORATION ITÉRATIF ET INCRÉMENTAL ADAPTATIF QUELQUES MÉTHODES SCRUM EXTREME PROGRAMMING (XP) AGILE VS TRADITIONNEL CONTRACTUALISATION 42 Réalisé par : Vivansa ( 18-Jan-2010 Page : 5 of 89

6 6.3.2 ACTEURS DU PROJET LA COLLABORATION Équipes locales Équipes distantes AMÉLIORATION CONTINUE LA TRANSPARENCE MÉTHODES AGILES ET ARCHITECTURE IT ARCHITECTURES ORIENTÉES SERVICES (SOA) CLOUD COMPUTING OBSERVATIONS 48 7 TENDANCES DU MARCHÉ ATTENTES DE L'AGILE LOCALISATION DES ÉQUIPES MÉFIANCE DE L'AGILE MÉTHODES AGILES ADOPTÉES RETOURS D'EXPÉRIENCE SUCCÈS DE MISE EN ŒUVRE RAISONS DES ÉCHECS MÉTIERS IMPACTÉS ET PROFIL SALARIAL TENDANCES EN BELGIQUE 62 8 MÉTHODES AGILES ET OUTILS OUTILS DE GESTION DE PROJET OUTILS DE RÉALISATION TECHNIQUE 64 9 LES DÉFIS ET LES OPPORTUNITÉS OPPORTUNITÉS DÉFIS FORMATIONS FORMATION DE BASE CONTEXTE EXEMPLE DE SUJETS FORMATION AVANCÉE : PILOTAGE DU PROJET CONTEXTE EXEMPLE DE SUJETS FORMATION AVANCÉE : RÉALISATION DU PROJET CONTEXTE EXEMPLE DE SUJETS CONCLUSION RÉFÉRENCES RAPPORTS DE VEILLE SITES GÉNÉRAUX 85 Réalisé par : Vivansa ( 18-Jan-2010 Page : 6 of 89

7 12.3 L'AGILE EN BELGIQUE OUVRAGES ARTICLES SONDAGES LIVRES BLANCS RETOUR D'EXPÉRIENCE OUTILS 89 Réalisé par : Vivansa ( 18-Jan-2010 Page : 7 of 89

8 Table de Figures Figure 4-1 : Project Resolution (source CHAOS Summary 2009 [REF33])...14 Figure 5-1 : Modèle en cascade...17 Figure 5-2 : Modèle en V...18 Figure 5-3 : Établissement du contrat...19 Figure 5-4 : Plan de projet...20 Figure 5-5 : Production des spécifications...20 Figure 5-6 : Équipe de développement...21 Figure 5-7 : Besoin de changements fonctionnels...23 Figure 5-8 : Impact des changements...24 Figure 5-9 : Livraison de la solution...25 Figure 5-10 : Évolution des besoins...25 Figure 6-1 : Relation entre le client et le fournisseur...28 Figure 6-2 : Métaphore de la poule et du cochon (source [REF20])...28 Figure 6-3 : Itératif et incrémental...30 Figure 6-4 : Zoom d'une itération...31 Figure 6-5 : Adaptabilité...34 Figure 6-6 : Scrum Artefacts...37 Figure 6-7 : Les pratiques d'xp (source xprogramming.com)...39 Figure 6-8 : Cycle de l'extrême Programming (source extremeprogramming.org)...41 Figure 6-9 : Intégration continue (source Octo Technology [REF43])...41 Figure 6-10 : Établissement du contrat agile...42 Figure 6-11 : Identifier les acteurs...43 Figure 6-12 : Acteurs du projet agile...43 Figure 6-13 : Équipes distantes...46 Figure 7-1 : Motivations d'adoption de l'agile (source [REF34])...51 Figure 7-2 : Motivations d'adoption de l'agile par le Scrum User Group France (source [REF37])...51 Figure 7-3 : Distribution des membres de l'équipe IT (source [REF36])...52 Figure 7-4 : Projets externalisés...52 Figure 7-5 : Préoccupations organisationnelles (source [REF34])...53 Figure 7-6 : Obstacles d'adoption (source [REF34])...54 Figure 7-7 : Scrum User Group France (source [REF37])...55 Figure 7-8 : VersionOne (source [REF34])...55 Figure 7-9 : Succès des projets agiles (source [REF34])...57 Figure 7-10 : Échecs d'implémentation (source [REF34])...57 Réalisé par : Vivansa ( 18-Jan-2010 Page : 8 of 89

9 Figure 7-11 : Ventilation des réponses (source [REF38])...58 Figure 7-12 : Nombre d'années d'expérience IT (source [REF38])...59 Figure 7-13 : Age des répondants (source [REF38])...59 Figure 7-14 : Profil des répondants (source [REF38])...60 Figure 7-15 : Certifications (source [REF38])...61 Figure 7-16 : Taille des entreprises (source [REF38])...61 Figure 7-17 : Profil des entreprises en Europe (source [REF38])...62 Réalisé par : Vivansa ( 18-Jan-2010 Page : 9 of 89

10 1 Glossaire DoD... DSDM... FDD... IT... Java EE... KISS... MOA... MOE... PME... QA... RAD... ROI... SOA... TDD... XP... Definition of Done Dynamic Systems Development Method Feature Driven Development Information Technology (technologie de l'information) Java Enterprise Edition Keep IT Stupid Simple Maîtrise d'ouvrage Maîtrise d'œuvre Petites et Moyennes Entreprises Quality Assurance Rapid Application Development Return On Investment Service Oriented Architecture Test Driven Development extreme Programming Réalisé par : Vivansa ( 18-Jan-2010 Page : 10 of 89

11 2 Introduction Membres du réseau des Centres de Compétences de la Région wallonne, les centres Technifutur (Liège - http :// TechnofuturTIC (Charleroi - http :// Technocité (Mons - http :// et Techno.bel (Ciney - http :// sont chargés de la mise en œuvre d un projet de sensibilisation, d information et de formation de haut niveau dans le domaine des Technologies de l Information et des Télécommunications (TIC). Dans ce cadre, ils conduisent une activité de veille ciblée sur l évolution des métiers et des qualifications dans ce secteur. Ces centres fédèrent leurs moyens afin de mener cette démarche de veille de façon commune et en réseau. La société Vivansa (http :// par l intermédiaire de son unité Recherche & Développement, a été sollicitée pour participer à l animation continue de cette veille et à la rédaction d un rapport bisannuel. Afin d utiliser les ressources disponibles de façon optimale, cette veille se concentre sur un thème choisi conjointement. L'agilité est un thème récurrent dans les rapports de veille (voir [REF1] et [REF2]). Ce rapport s'intéresse aux pratiques agiles qui permettent d'élaborer des solutions IT en visant le succès du projet. Car c'est bien de succès ou d'échecs dont il s'agit. Les projets IT ressemblent de plus en plus à des travaux pharaoniques qui engloutissent du temps et de l'argent. Sans oublier que le stress agit négativement sur la motivation des personnes et donc la qualité du projet. Les entreprises IT peinent à reconsidérer l'usage des méthodes de développement dites traditionnelles tant les principes fondateurs sont profondément ancrés dans la culture de l'entreprise. L'agressivité du marché globalisé, les nouveautés s, les mutations du métier et les besoins très précis des utilisateurs conduisent à rendre particulièrement inefficaces les méthodes traditionnelles considérées comme trop rigides. Les méthodes agiles semblent être la solution pour modifier les pratiques de travail en se fondant sur des valeurs plus humanistes et des principes qui répondent aux besoins de qualité et d'agilité qu'impose le marché. Le rapport est subdivisé comme suit : Section 3...Convention Section 4...Contexte Section 5...Approche traditionnelle Section 6...Approche agile Section 7...Tendances du marché Section 8...Méthodes agiles et outils Section 9...Les défis et les opportunités Section 10...Formations Section 11...Conclusion Section 12...Références Réalisé par : Vivansa ( 18-Jan-2010 Page : 11 of 89

12 3 Conventions 3.1 Messages d'information Lorsque nous souhaitons attirer le lecteur sur un sujet précis, nous utiliserons les mises en évidence suivante : Ceci est une information jugée intéressante. Ceci est une information utile pour l'organisation de formations. 3.2 Définition Fournisseur IT Client Solution Produit Projet Agiliste Le Fournisseur IT représente l'équipe informatique en charge de développer la Solution (Maîtrise d'oeuvre ou MOE). Cette équipe peut-être issue d'un prestataire externe ou du département informatique interne à l'entreprise du Client. Le Client représente l'acteur qui sollicite la Solution informatique (Maîtrise d'ouvrage ou MOA). Nous utiliserons indépendamment les termes Solution, Produit ou Projet pour définir le besoin métier à développer par le Fournisseur IT pour le Client. La personne qui pratique une démarche agile. 3.3 Sources Certains liens mènent à des sources d'information rédigées en anglais. Le lecteur qui souhaite traduire ces informations pourra utiliser le service de traduction en ligne Google Translate 1 disponible gratuitement sur Internet. 3.4 Noms de marque L'ensemble des marques et logo mentionné dans ce document reste la propriété de leurs ayants droit. 1 Google Translate : http ://translate.google.com Réalisé par : Vivansa ( 18-Jan-2010 Page : 12 of 89

13 4 Contexte 4.1 Préambule La crise financière d'octobre 2008 s'est largement étendue à l'économie réelle en n'épargnant aucun pays. Il faudra attendre encore de nombreuses années avant de voir les effets de la crise s'estomper. En espérant qu'un nouvel évènement ne vienne encore secouer l'économie toujours très fragile. En Belgique, et plus particulièrement en Région wallonne, le tissu économique est essentiellement composé de PME. Celles-ci ont subi de lourdes pertes et on ne compte plus les faillites et restructurations entraînant de nombreuses pertes d'emploi. Cette morosité économique incite les sociétés à revoir leur stratégie pour ajouter plus d'agilité dans leur mode de fonctionnement et leur prise de décision. En effet, les entreprises trop rigides ont du mal à réagir efficacement face à des évènements imprévisibles de grande ampleur. Dans ce contexte, les entreprises qui souhaitent ne pas disparaître doivent fidéliser leurs clients tout en se distinguant de la concurrence. D'après une étude menée en Belgique par le fournisseur d informations Kluwer et la société de consultance Möbius (voir [REF32]), il ressort que les cadres supérieurs estiment que l'agilité de leur entreprise leur permettra de sortir renforcés de la crise actuelle. L'agilité au sein de l'entreprise agit comme un effet de levier pour : réagir promptement aux changements ; établir et maintenir une relation solide avec ses clients ; constituer une solide culture d'entreprise ; promouvoir l'innovation en bénéficiant de l'usage des nouvelles technologies ; obtenir une grande flexibilité de ses collaborateurs tout en maintenant leur motivation. Pour cela les entreprises ont besoin de solutions informatiques qui soutiennent leur métier en dynamisant leur stratégie et en s'adaptant souplement aux défis internes ou externes. 4.2 Les projets IT dans le monde Le constat des cabinets-conseils montre la difficulté croissante des entreprises à obtenir une solution informatique qui respecte le budget initial, le planning des livraisons et surtout les besoins fonctionnels du client. Depuis la moitié des années 1990, le groupe américain Standish élabore un rapport qui met en lumière le taux de succès et d'échecs des projets informatiques dans le monde. Réalisé par : Vivansa ( 18-Jan-2010 Page : 13 of 89

14 Dans la figure suivante (Figure 4-1), on remarque que l'année 2008 a vu une croissance des projets IT en échecs : 32 % des projets ont été un succès (Succeded) : livré à temps, dans le budget imparti et avec les fonctionnalités attendues. 24 % ont échoué (Failed) : projet annulé ou jamais utilisé. 44 % ont été renégociés (Challenged) : livré en retard, dépassant le budget initial et/ou avec moins de fonctionnalités promises. Figure 4-1 : Project Resolution (source CHAOS Summary 2009 [REF33]) Le constat que l'on peut en tirer est que le ROI (retour sur investissement) est loin d'être garanti pour les clients. Et même s'il faut tempérer ces chiffres, il nous faut admettre que ceux-ci sont loin d'être irréalistes. La presse et les nombreux retours d'expérience sont là pour confirmer cette tendance. En Belgique, on se souvient de l'échec retentissant du projet Phénix dont l'objectif était d'informatiser le département de la Justice. Les retards et le manque de qualité ont été les griefs du gouvernement à l'encontre du fournisseur IT. Au final, une rupture de contrat et quelque 28 millions d'euros (voir [REF28]) dépensés sans que les utilisateurs disposent d'une solution qui réponde à leurs attentes. 4.3 Les causes possibles d'échecs Parmi les nombreuses causes qui entraînent les projets IT vers l'échec, on peut citer les suivantes : une mauvaise définition des besoins ; des problèmes de priorisation des tâches ; Réalisé par : Vivansa ( 18-Jan-2010 Page : 14 of 89

15 de mauvaises estimations de charge ; des cycles de développement trop long ; des équipes sous pression qui entraînent du stress et de la démotivation ; un manque de transparence pour le client ; une incapacité d'intégrer des changements fonctionnels en cours de projet. Ces causes sont en grande partie imputables aux méthodes de développement traditionnelles jugées trop rigides et qui peinent à s'adapter aux défis économiques qui requièrent de la part des entreprises plus d'agilité. 4.4 Les méthodes agiles : levier du succès? Les méthodes agiles ont élaboré des pratiques de gestion de projet et d'ingénierie logicielle en les expérimentant sur le terrain. Ces pratiques révolutionnent le développement de projets IT en apportant des valeurs et des principes qui encouragent l'intelligence collective, la recherche de la qualité, la collaboration, la communication, la transparence et l'intégration du client comme partenaire à part entière de l'élaboration de la solution. Nous allons montrer comment et pourquoi les méthodes agiles provoquent cet engouement croissant et les valeurs ajoutées qu'elles peuvent apporter au fonctionnement des entreprises et des individus. Mais avant cela, rappelons les principes qui caractérisent les méthodes traditionnelles et les limites de cette approche face aux attentes du marché. Réalisé par : Vivansa ( 18-Jan-2010 Page : 15 of 89

16 5 Approche traditionnelle 5.1 Préambule Depuis plus de trente ans, les méthodes traditionnelles de développement font le quotidien de la majorité des projets informatiques. Ces méthodes ont peu évolué et le fossé se creuse chaque jour entre la rigidité des pratiques de développement traditionnelles et les attentes du marché (réactivité, agilité). Dans une majorité de cas, les projets informatiques ne répondent plus aux besoins des utilisateurs ou sont purement abandonnés. En quelques mots, une approche traditionnelle tend à cadrer et spécifier en amont tous les aspects de la solution avant d'aborder le cycle de développement, des tests et de livraison. Autant dire que la route qui mène à un résultat visible et palpable pour le client est très longue. Et comme les tests sont en bout de route, le projet a de grandes chances de buter sur des problèmes de qualité technique ou fonctionnelle. Nous allons rappeler ce qui caractérise les approches (ou méthodes) traditionnelles pour mieux comprendre les contraintes qu'elles imposent. 5.2 Quelques méthodes Sans chercher à être exhaustifs, nous allons brièvement présenter les principales méthodes de développement traditionnelles. Le lecteur, soucieux d'approfondir l'une ou l'autre méthode de travail, trouvera dans ce document une liste d'ouvrage et de sites de référence (voir 12). Les formations devront rappeler les grands principes des méthodes traditionnelles afin de souligner les contraintes et mieux amener la discussion vers les méthodes agiles Modèle en cascade Le modèle de développement en cascade est la méthode classique la plus utilisée depuis plus de 30 ans. Réalisé par : Vivansa ( 18-Jan-2010 Page : 16 of 89

17 Figure 5-1 : Modèle en cascade Le modèle en cascade est également connu sous le nom de "plan-driven development" (ou développement piloté par le plan). Le plan est au coeur de cette méthode qui, dès le démarrage du projet, ne souhaite rien laisser au hasard. D'où l'appellation de méthode "prédictive". L'approche est séquentielle et chaque discipline (capture des besoins, spécifications, etc.) est exécutée et documentée dans le détail avant de passer le relais à la discipline suivante. Cette notion de détail explique la profusion de documentation qui caractérise ce modèle de développement. Les changements fonctionnels en cours de projet sont assez mal accueillis, car ils risquent de fortement perturber le plan initial ou remettre en cause les cahiers de spécifications (fonctionnelles et techniques) qui ont été élaborés. D'autre part, les tests qui arrivent assez tard dans le processus peuvent révéler des incohérences tant fonctionnelles que techniques. Du côté de la conception de la solution, l'ingénierie des équipes de développement est peu mise à contribution. Les développeurs sont souvent relégués à la codification de ce qui a déjà été largement spécifié. Ce mode de travail a tendance à engendrer une certaine frustration de la part du développeur qui s'isole dans son travail et n'a pas l'impression de participer activement à la réalisation du projet. Réalisé par : Vivansa ( 18-Jan-2010 Page : 17 of 89

18 Le client doit prendre son mal en patience avant de voir les premiers éléments tangibles de la solution. Le risque est donc grand que la solution livrée soit mal accueillie par le client qui ne retrouve pas la qualité attendue ou les besoins initiaux qui ont été exprimés. On attribue la paternité de l'approche en cascade au Docteur Winston W. Royce qui le premier décrivit en 1970 le principe de fonctionnement (voir [REF13]). Mais au lieu de promouvoir cette approche, le Dr Royce en montrait les limites et les risques. Malgré tout, durant plus de trente ans, les méthodes en cascade ont été appliquées dans de larges projets informatiques confirmant trop souvent l'analyse du Dr Royce Modèle en V Le modèle en V est une évolution du modèle en cascade dans lequel chaque discipline, bénéfice d'un alter ego en charge de tester sa cohérence. L'objectif étant de relever assez tôt les incohérences dans les phases d'analyse pour livrer une solution la plus proche possible des besoins exprimés. Figure 5-2 : Modèle en V Malgré tout, ce modèle reste encore assez lourd à mettre en oeuvre, les documents produits sont encore très nombreux et l'application ne reste visible qu'assez tard dans le processus de développement. 5.3 Illustration des principes Nous allons illustrer quelques principes en suivant les principales étapes d'un projet informatique. Réalisé par : Vivansa ( 18-Jan-2010 Page : 18 of 89

19 Pour pointer les limites des méthodes traditionnelles, nous allons volontairement illustrer une situation avec des sources de problèmes Contractualisation Entre le client et le fournisseur informatique, un contrat est établi pour définir : le périmètre de la solution et les livrables (en anglais «deliverables») ; l'enveloppe financière ; la date et les modalités de la livraison finale ; les pénalités de retard. Figure 5-3 : Établissement du contrat En règle général, ces contrats sont très contraignant et ne procurent que peu ou pas de souplesse pour adapter l'une ou l'autre clause Plan de projet Il est déjà temps de produire le plan de projet qui va détailler chaque activité en y posant les principaux jalons (en anglais «milestones»). Par ce plan de projet, le fournisseur s'engage sur les activités à réaliser. Il est courant de voir les charges des activités estimées par des personnes autres que celles qui seront impliquées dans leur réalisation. Ceci peut amener bien des surprises au moment où l'activité devra être concrètement réalisée. Le stress des personnes impliquées et les retards de délais seront inévitablement au rendez-vous. Dès que le plan est accepté, celui-ci sert de feuille de route pour la réalisation du projet. Ce caractère «immuable» du plan de projet sera la source de bien des soucis pour le chef de projet et les collaborateurs pour tenir leur engagement vis-à-vis du client. Réalisé par : Vivansa ( 18-Jan-2010 Page : 19 of 89

20 Figure 5-4 : Plan de projet En effet, chaque aménagement du plan de projet devra être motivé et âprement négocié avec le client. À ce stade, on perçoit déjà que le projet ne démarre pas sous les meilleurs auspices Spécifications des besoins Après la récolte des besoins métier, le fournisseur documente de manière très détaillée les spécifications fonctionnelles et techniques. Ces documents seront validés par le client, mais qui pourra éprouver des difficultés à visualiser les principes. La validation sera souvent longue et incomplète. Figure 5-5 : Production des spécifications Le contrat et le plan projet viennent cadrer l'ensemble des livrables à produire. Cela amène à des situations où des documents sont tout de même écrits même si leur pertinence n'est plus aussi grande. Ces situations entraînent une perte de temps et donc d'argent pour le client. Réalisé par : Vivansa ( 18-Jan-2010 Page : 20 of 89

21 5.3.4 Développement Place maintenant au développement proprement dit. Dans la plupart des cas, les développeurs découvrent le projet et doivent assimiler un ensemble de spécifications auxquelles ils n'ont pas participé. Comme le plan projet est déjà bien avancé, le mot d'ordre donné aux développeurs est de suivre scrupuleusement ce qui est spécifié pour éviter toute dérive du planning. Ce qui ferme toute porte à l'émergence de nouvelles idées ou à la détection de problèmes potentiels. Le développeur est enfermé dans les tâches qu'il doit réaliser conformément au plan et dans un délai imposé. Cette situation provoque des frustrations et une démotivation croissante qui auront pour effet d'impacter la qualité du projet et les délais de livraison. Stress au travail Selon une étude de Test-Achats (voir [REF39]), le stress au travail occasionne annuellement plus de 9 millions de jours d'absentéisme en Belgique. Des facteurs tels que les cadences de travail effrénées, un manque de collaboration et de communication ou un manque de reconnaissance sont des sources de stress. Ces absences coûtent cher aux entreprises et, dans le cas qui nous occupe, impacte négativement la dynamique du projet informatique. Il est donc dans l'intérêt des entreprises de prendre ce problème très au sérieux et de chercher à y remédier. La collaboration entre les individus est également perfectible, chaque individu travaillant sur son îlot. Figure 5-6 : Équipe de développement Réalisé par : Vivansa ( 18-Jan-2010 Page : 21 of 89

22 Pour le client, le cycle de développement est très frustrant. Un effet «tunnel» s'installe et le client perd le contact avec le projet par manque de visibilité. Le mécontentement et la méfiance du client grandissent à mesure que l'effet tunnel perdure. Effet Tunnel L'effet tunnel (voir [REF31]) en informatique n'est pas à confondre avec le même terme employé en physique quantique. En informatique, l'effet tunnel traduit le laps de temps durant lequel le client perd le contact avec le fournisseur qui est occupé à développer la solution Évolution des besoins Pendant que le fournisseur développe la solution, les besoins du client ne se figent pas pour autant. Le client sera sollicité par des évènements qu'il ne devra pas ignorer, par exemple : des pressions économiques imposant une réactivité plus grande face à la concurrence en réduisant le time-to-market (le temps nécessaire à la mise sur le marché d'un produit) ; une nouvelle directive imposant d'adapter les processus métiers ; de nouveaux besoins exprimés par les utilisateurs ; des évolutions s que l'on souhaite intégrer pour se différencier de la concurrence. Réalisé par : Vivansa ( 18-Jan-2010 Page : 22 of 89

23 Figure 5-7 : Besoin de changements fonctionnels Tout naturellement, le client va souhaiter étudier avec le fournisseur IT l'opportunité d'intégrer ces changements dans la solution en cours d'élaboration, et si possible sans impacter le budget initial et le délai de livraison. Mais cela n'est pas si simple! Pour le fournisseur, ces changements ont un sérieux impact sur les développements en cours ainsi que sur les spécifications fonctionnelles et techniques. Le fournisseur n'est pas très enthousiaste pour revoir ce qui a été si durement produit. D'autant qu'on lui demande de respecter autant que possible le budget et le délai de livraison. Le réflexe habituel est de voir le fournisseur refuser poliment les nouvelles demandes en se basant sur le contrat et le plan de projet. Réalisé par : Vivansa ( 18-Jan-2010 Page : 23 of 89

24 Figure 5-8 : Impact des changements Cette situation va indéniablement entraîner une frustration du côté du client qui pointe un manque de flexibilité (autrement dit «d'agilité») de son fournisseur Tests La fin des développements annonce la phase des tests techniques et fonctionnels. Comme cette phase arrive assez tard dans le cycle du projet, le volume d'erreurs détecté accroît le risque de délai dans le planning. Le risque de glissement est plus grand si les erreurs sont de type fonctionnel et compromettent les fondements des spécifications. Dans ce cas de figure, il sera très difficile de déterminer qui du client ou du fournisseur IT est dans son bon droit. Le fournisseur IT reprochera au client de mal avoir exposé les besoins et le client reprochera au fournisseur IT qu'il était de sa responsabilité de valider l'ensemble des problèmes potentiels et de lever les alarmes suffisamment tôt. D'autant que le client n'a pas été en mesure de tester les versions intermédiaires de la solution (effet tunnel). Des tests tardifs et un manque de feed-back des utilisateurs du client peuvent être très dommageables dans la réussite du projet. Réalisé par : Vivansa ( 18-Jan-2010 Page : 24 of 89

25 5.3.7 Livraison de la solution Le fournisseur IT a remplit ses engagements et livre la solution à son client dans les délais fixés. Comme le projet a manqué de transparence, le client a des appréhensions quant au produit livré : la qualité est-elle au rendez-vous? les besoins métiers ont-ils été compris et intégrés? sera t'il possible d'installer et d intégrer le produit sans encombre? On peut dire que dans bien des cas, le client reçoit un "chat dans un sac"! Figure 5-9 : Livraison de la solution D'autant que la solution, même si elle a été développée conformément aux besoins initiaux, risque de ne plus répondre aux attentes du client qui entre-temps ont évolué. Le produit a peut-être été livré à temps, mais il n'est plus en adéquation avec les besoins du métier qui ont pourtant été exprimés en cours de projets et refusés par manque d'agilité dans la méthode de travail. Figure 5-10 : Évolution des besoins Les utilisateurs sont frustrés de ne pas bénéficier d'une solution répondant aux besoins du moment et menacent de ne pas l'adopter. Ils estiment, à juste titre, n'avoir pas été suffisamment impliqués dans l'élaboration et la validation de la solution. Réalisé par : Vivansa ( 18-Jan-2010 Page : 25 of 89

26 Le fournisseur IT estime pour sa part avoir respecté les termes du contrat, mais le client lui reproche son manque d'agilité. Les ajouts fonctionnels devront faire l'objet d'un nouveau contrat, mais le client réfléchit à la pertinence du renouvellement de sa confiance au fournisseur IT. 5.4 Méthodes traditionnelles et architecture IT Les méthodes traditionnelles n'encouragent pas la mise en oeuvre d'une architecture informatique qui soit plus souple et plus agile aux changements. Par exemple, les méthodes actuelles ne répondent pas aux attentes d'une démarche d'architecture orientée services ou SOA (voir section dans [REF1]). Ainsi, le développement traditionnel va perpétuer le syndrome des silos applicatifs. 5.5 Observations La méthode traditionnelle offre certes l'avantage de cerner dans ses moindres détails les besoins fonctionnels, mais son manque de souplesse restreint les possibilités d'intégrer des changements en cours de projet. Pourtant l'expérience des récents évènements économiques, nous montre qu'il est plus habile d'être agile face au changement que d avoir la prétention de prévoir des situations qui sont souvent hors de notre contrôle. En résumé, qui doit-on blâmer? Le client, d'avoir changé en cours de route les besoins fonctionnels? En partie non, car il est de son plein droit de disposer d'une solution qui répondra amplement à ses besoins et aux défis qui l'attendent. Mais le contrat imposé au fournisseur laissait peu de place à une certaine forme d'agilité. Le fournisseur IT d'avoir livré une solution qui n'est plus en phase avec les nouveaux besoins? En partie non, car le logiciel a été livré dans les temps en respectant les clauses contractuelles. Mais la méthode choisie n'a pas permis d'intégrer souplement les nouveaux changements fonctionnels et d offrir la transparence nécessaire vis-à-vis du client. Nous allons voir que les méthodes agiles apportent des éléments de réponse pour pallier aux problèmes que nous avons illustrés. Réalisé par : Vivansa ( 18-Jan-2010 Page : 26 of 89

27 6 Approche agile 6.1 Préambule L'émergence des méthodes agiles ne date pas d'hier. Elles sont apparues au milieu des années 1990 en réponse à la rigidité des méthodes traditionnelles de développement informatique. Elles trouvent leur inspiration dans de nouvelles pratiques d'industrialisation parues dans les années 70 et 80 et appliquées avec succès par le secteur automobile japonais (voir [REF16] et [REF17]). Aujourd'hui, les méthodes agiles bénéficient de nombreux retours d'expérience mesurables (voir 7) et sont pratiquées aussi bien dans les PME que dans des entreprises telles que IBM, Microsoft, Yahoo ou Google. De nombreuses méthodes agiles ont ainsi émergé s'adressant tant à la gestion de projet qu'aux pratiques logicielles. Pour créer une synergie entre ces différentes méthodes, dix-sept sommités du développement logiciel agile on écrit en 2001 un manifeste agile (voir [REF3]). Les méthodes agiles se différencient des méthodes traditionnelles par la mise en oeuvre d'un ensemble de douze principes et de quatre valeurs décrits dans le manifeste agile. La vocation de ce manifeste est de promouvoir les mêmes fondements quelle que soit la méthode agile utilisée. Les quatre valeurs du manifeste agile prônent : les individus et les interactions plutôt qu'un usage exclusif de processus et d'outils ; la livraison d'un logiciel pleinement fonctionnel plutôt qu'une documentation exagérément abondante ; une collaboration avec le client plutôt que la stricte application des clauses contractuelles ; l'agilité et la flexibilité dans l'accueil des changements métier plutôt qu'un suivi aveugle d'un plan strict et rigide. Sans chercher à être exhaustifs, nous allons illustrer quelques principes agiles qui résument assez bien les valeurs du manifeste agile : la collaboration ; le développement itératif et incrémental ; l'adaptabilité Collaboration La figure suivante (Figure 6-1) symbolise la collaboration permanente qui anime les échanges entre le client et le fournisseur tout au long de l'élaboration de la solution. Réalisé par : Vivansa ( 18-Jan-2010 Page : 27 of 89

28 Figure 6-1 : Relation entre le client et le fournisseur Cette relation ne sera efficace qu'à condition que chaque acteur collabore pleinement au projet. Les méthodes de développement traditionnelles reposent sur une culture très hiérarchisée qui rend parfois difficiles la communication et la collaboration entre les personnes. Dans les méthodes agiles, une distinction claire est établie entre "Personnes concernées" et les "Personnes impliquées" telles qu'illustrées ci-dessous : Figure 6-2 : Métaphore de la poule et du cochon (source [REF20]) En d'autres termes, les méthodes agiles encouragent chaque personne à jouer pleinement son rôle. On évite ainsi des situations où des personnes concernées (le client, le chef de projet) estiment la durée d'un développement en lieu et place du développeur (personne impliquée par le développement). Ce principe permet d'améliorer la collaboration entre les individus, chacun se sentant plus «acteur» que «spectateur» du projet. En d'autres termes, les méthodes agiles prônent l établissement d une démocratie au sein du projet. Une révolution en soi! Itératif et incrémental Le développement itératif et incrémental permet de découper la solution à réaliser en un ensemble de fonctionnalités qui seront développées itération par itération. L'objectif étant de livrer au client un système utilisable au terme de chaque itération. Réalisé par : Vivansa ( 18-Jan-2010 Page : 28 of 89

29 Ce principe se distingue des méthodes traditionnelles où le client ne découvre la solution qu'au terme du long processus de développement. Pour bien comprendre la notion d'itération, nous allons utiliser une métaphore dans laquelle le projet à réaliser est apparenté à un éléphant que l'on souhaite manger. Dans une approche traditionnelle, l'idée serait de tenter d'engloutir l'éléphant. On comprend aisément que cela risque de s'avérer long, fastidieux, voire impossible. Dans une approche agile, la réponse découle du bon sens et consiste à manger l'éléphant morceau par morceau. La figure suivante (Figure 6-3) illustre les différentes étapes qui peuvent survenir dans un développement itératif et incrémental : Réalisé par : Vivansa ( 18-Jan-2010 Page : 29 of 89

30 Rapport de veille Figure 6-3 : Itératif et incrémental Le point de départ est amorcé par la demande du client qui exprime son besoin (étape 1). Les fonctionnalités sont identifiées et priorisées (étape 2). L'équipe informatique va évaluer la charge de travail. En fonction de la charge de travail soutenable par l'équipe de développement, un nombre d'itérations est défini pour aboutir au résultat attendu par le client (étape 3). À chaque itération, des fonctionnalités sont choisies sur base de leur niveau de priorité et du temps nécessaire pour les développer. À l'issue de chaque itération, un produit utilisable et démontrable est préparé (étape 4). Chaque livraison est préalablement démontrée au client (étape 5). La livraison est évaluée par les utilisateurs du client qui transmettent leurs commentaires (notion de feed-back). Le client a la liberté de poursuivre (Go) ou stopper (No Go) le développement (étape 6). La réalisation du projet est transparente pour le client qui peut réorienter le processus de développement d'une nouvelle itération en fonction de nouvelles priorités. Réalisé par : Vivansa ( 18-Jan-2010 Page : 30 of 89

31 Si on y regarde de plus près, une itération se compose généralement d'un ensemble d'activités tel qu'illustré ci-dessous : On y retrouve les activités suivantes : Figure 6-4 : Zoom d'une itération Réunions (Meeting) : Chaque itération débute par une réunion avec le client pour déterminer ce qui sera réalisé. Une réunion (au minimum hebdomadaire) est organisée pour le suivi de l'activité. Et en fin d'itération, une réunion sert à démontrer au client la solution développée et discuter des améliorations à apporter pour la suite du projet. Planification (Planning) : en début d'itération, l'équipe estime l'effort nécessaire pour développer les fonctionnalités qui seront intégrées dans l'itération. Ce sont donc les personnes impliquées (les développeurs) qui estiment la durée des tâches. Analyse (Analysis) : l'analyse est enrichie au cours de chaque itération. Au lieu d'écrire des analyses gargantuesques comme dans les méthodes traditionnelles, les méthodes agiles prônent le principe KISS (Keep IT Stupid Simple). En d'autres termes, il faut commencer "simplement" et enrichir le système au fur et à mesure des itérations. Développement (Test / Build / Re-factor) : les méthodes agiles telles que l'extreme Programming (voir 6.2.2) encouragent le développement piloté par les tests (TDD - Test Driven Development) ainsi que le refactoring qui consiste à améliorer constamment la qualité ce qui a été réalisé. La mise en place d'une plateforme d'intégration continue est également nécessaire pour automatiser les tests de la solution. Correction des erreurs (Bug Fixing) : les erreurs rencontrées lors des itérations précédentes sont corrigées en fonction de leur niveau de priorité. Réalisé par : Vivansa ( 18-Jan-2010 Page : 31 of 89

32 Documentation (Documentation) : une idée préconçue au sujet des méthodes agiles est de croire que la documentation est inexistante. La documentation s'écrit et s'enrichit itération par itération. L'objectif n'étant pas d'écrire un volume impressionnant de documents, mais d'élaborer une documentation concise et pleinement exploitable. Assurance Qualité (QA) : la qualité est un paramètre important des méthodes agiles pour garantir un haut niveau de confiance entre le client et le fournisseur. L'ensemble des livrables (l'application, la documentation, le kit d'installation, etc.) est contrôlé conformément aux attentes. Kit installable (Package) : à la fin de l'itération, une solution installable, utilisable et démontrable est prête à l'emploi. Si le client décide de stopper le projet, il a la garantie de bénéficier d'une application utilisable (même si celle-ci ne couvre que partiellement les besoins). Démonstration (Demo) : la solution est présentée au client et à l'ensemble de l'équipe. D'autres acteurs, tels que les utilisateurs finaux (en anglais, «end users»), peuvent assister à ces démonstrations. Les démonstrations s'inscrivent dans le processus de feed-back qui sert à récolter les commentaires des utilisateurs. Livraison (Delivery) : le client reçoit la solution installable qu'il pourra déployer sur ses systèmes afin d'être testé par les utilisateurs et par la suite déployer en production si le niveau de qualité est atteint. Vélocité (Velocity) : la vélocité est une donnée cruciale qui définit la capacité de l'équipe à réaliser un ensemble de tâches. Cette mesure empirique est affinée à chaque itération. La vélocité permet de produire un planning réaliste et d'amener un rythme de travail soutenable par l'équipe de développement. Les méthodes traditionnelles se caractérisent souvent par l'usage d'un rythme de travail effréné induit par un plan de projet serré et des retards à compenser. Cela conduit à des situations de stress chez les collaborateurs et un effet domino sur la dynamique du projet. Par exemple, il est illusoire de penser qu'un développeur est concentré chaque jour à 100%. Des évènements viendront immanquablement interrompre sa concentration : répondre aux s, répondre aux questions des collègues, suivre des formations, etc. Les méthodes agiles sont plus cohérentes, car elles donnent des pratiques pour mesurer la capacité d'une équipe à absorber du travail (vélocité) en fonction des disponibilités de chacun et d'un paramètre jugeant le niveau de concentration (focus factor). Cela conduit à mettre en place un planning d'activité réaliste en accord avec un rythme de travail soutenable Adaptatif La particularité des méthodes agiles est d'embrasser les changements métier du client au lieu de les rejeter comme c'est souvent le cas dans les méthodes traditionnelles. Pour le client, son métier évolue en permanence et il se doit de réagir efficacement pour ne pas risquer d'être distancé par la concurrence. Il est dès lors tout à fait normal que le client sollicite le fournisseur informatique pour étudier la possibilité d'adapter la solution en cours de développement pour qu'elle intègre les nouveaux besoins fonctionnels. Réalisé par : Vivansa ( 18-Jan-2010 Page : 32 of 89

33 Ce processus est à ce point normal dans l'approche agile que les livraisons fréquentes au client stimulent de nouvelles idées ou l'alerte sur des incohérences fonctionnelles propre à son métier. La bonne nouvelle pour le client est que ces changements pourront probablement se réaliser sans impact financier si le nombre d'itérations et la charge de travail ne changent pas. Le client n'a ainsi plus l'impression d'être une "vache à lait". La figure suivante (Figure 6-5) illustre comment un changement fonctionnel peut survenir dans un processus de développement agile : Réalisé par : Vivansa ( 18-Jan-2010 Page : 33 of 89

34 Rapport de veille Figure 6-5 : Adaptabilité Le point de départ est amorcé par la demande du client qui exprime son besoin (étape 1). Les fonctionnalités sont identifiées et priorisées (étape 2). Réalisé par : Vivansa ( 18-Jan-2010 Page : 34 of 89

35 L'équipe informatique va évaluer la charge de travail. En fonction de la charge de travail soutenable par l'équipe de développement, un nombre d'itérations est défini pour aboutir au résultat attendu par le client (étape 3). À chaque itération, des fonctionnalités sont choisies sur base de leur niveau de priorité et du temps nécessaire pour les développer. À l'issue de chaque itération, un produit utilisable et démontrable est préparé (étape 4). L'évaluation des versions intermédiaires par les utilisateurs a permis de relever des améliorations fonctionnelles (étape 5). Il en découle une nouvelle vision de la solution à développer (étape 6). Cette vision est présentée par le client aux membres de l'équipe qui va en mesurer l'impact. Il est décidé que cette nouvelle vision est compatible avec la solution actuelle dans le budget fixé et les itérations restantes (étape 7) seront réaménagées en vue d'aboutir au résultat attendu. Il est évident que cette illustration est idyllique. Dans la réalité, il se peut que des sacrifices fonctionnels soient décidés avec le client ou que de nouvelles itérations soient ajoutées au projet. 6.2 Quelques méthodes Parmi les méthodes agiles les plus connues, nous pouvons citer les suivantes : Scrum ; extreme Programming ; Crystal ; Lean Software Development ; DSDM ; FDD ; RAD ; Agile UP. Pour la majorité d'entre elles, ces méthodes partagent les mêmes valeurs et principes énoncés dans le manifeste agile. On trouvera des méthodes plus orientées «gestion de projet» et d'autres faisant la part belle aux pratiques d'ingénierie logicielles. Nous avons pris le parti de nous pencher sur deux méthodes très utilisées : Scrum et extreme Programming (XP). Réalisé par : Vivansa ( 18-Jan-2010 Page : 35 of 89

36 Comme nous le verrons par la suite, ces deux méthodes (signataires du manifeste agile) sont tout à fait complémentaires. L'une étant orientée organisation et gestion de projet (Scrum) alors que la seconde s'impliquant davantage sur les pratiques techniques (XP). Par ailleurs, les méthodes Scrum et XP sont à ce jour les plus largement utilisés tels que le démontrent les différents chiffres (voir 7.4). Le lecteur, soucieux d'approfondir l'une ou l'autre méthode agile, trouvera dans ce document une liste d'ouvrages et des sites de référence (voir 12) faisant la part belle tant à l'historique qu'aux principaux principes animant ces méthodes agiles. Au fil des années, Scrum a gagné ses lettres de noblesse et une forte visibilité. Google a adopté Scrum pour développer son application AdWords. AdWords est l'une des applications informatiques qui génèrent le plus grand revenu (66 % du chiffre d'affaires de Google au second trimestre voir [REF21]). Voir pour cela le retour d'expérience de Scrum chez Google présenté par Jeff Sutherland, l'un des cofondateurs de la méthode Scrum (voir [REF42]) Scrum C'est 1995 que Jeff Sutherland et Ken Schwaber ont officiellement présenté leur méthode baptisée Scrum, concrétisant des années d'expérience en matière de gestion de projet agile (voir [REF26]). Scrum est une méthode agile de pilotage du projet sortant des tranchées et qui a donc été élaborée et expérimentée sur le terrain. Une méthode dont les pratiques ont été inspirées de nouvelles pratiques de développement notamment industriel (voir [REF17]). Scrum définit un ensemble de bonnes pratiques pour la gestion et l'organisation d'un projet qu'il soit ou non informatique. Scrum ne se limite pas aux projets informatiques et peut très bien s'appliquer à d'autres domaines d'activité. Ce document ne traitera que l'application des méthodes agiles dans le contexte informatique. Parmi les pratiques décrites dans Scrum, nous pouvons citer les suivantes : une implication plus grande du client dans l'élaboration et le suivi du projet ; remettre les collaborateurs au centre du processus de développement ; une plus grande collaboration entre les acteurs du projet ; une revisite permanente du plan de projet et des priorités ; la mise en place de petites équipe de développement tout en brisant les silos d'activité ; le développement de la solution réalisée de manière itérative et incrémentale ; Réalisé par : Vivansa ( 18-Jan-2010 Page : 36 of 89

37 l'acceptation des changements fonctionnels en cours de développement ; la démontrabilité de la solution à chaque fin d'itération ; des livraisons fréquentes et le retour des utilisateurs (feed-back) ; la rétrospective en fin d'itération en vue d'améliorer la qualité de l'ensemble. La figure suivante (Figure 6-6) schématise quelques-uns des artefacts définis dans Scrum : Figure 6-6 : Scrum Artefacts Passons d'abord en revue les différents acteurs et leur rôle au sein du projet : Les Stakeholders regroupent les acteurs de la maîtrise d'ouvrage (le client) : utilisateurs, managers, responsable qualité, responsable marketing, etc. Le Product Owner est le représentant de la maîtrise d'ouvrage dans le projet. Sa responsabilité est fonctionnelle et il a pour mission de définir et prioriser les fonctionnalités de l'application, de donner les directives métiers, de valider les livrables, de communiquer avec les stakeholders. Le Scrum Master n'a pas de rôle directif, mais intervient au même titre qu'un coach qui anime l'activité et facilite le processus Scrum. Il veille à résoudre les obstacles qui peuvent venir perturber le fonctionnement de l'équipe (Team) ou du Product Owner. Le Scrum Master est Réalisé par : Vivansa ( 18-Jan-2010 Page : 37 of 89

38 également le garant des pratiques agiles. Il aura la charge de relever les mesures de performances du projet et de lever les alertes lorsque cela est nécessaire. Le Team est l'équipe en charge de réaliser le produit. L'esprit est démocratique avec des équipes qui doivent contenir des collaborateurs expérimentés. L'équipe autopilote la qualité et la performance du projet. Si l'on se reporte à la figure précédente (Figure 6-6), nous pouvons résumer quelques-uns des artefacts utilisés dans Scrum : 1. Le client définit l'ensemble de fonctionnalités à développer. Chaque fonctionnalité est brièvement décrite (User Stories). La liste de fonctionnalités constitue le Product Backlog qui est alimenté par la maîtrise d'ouvrage (Stakeholders) au travers de son représentant (Product Owner). 2. La réunion de "Sprint Planning Meeting" permet de passer de clarifier l'ensemble des fonctionnalités. C'est l'équipe (Team) qui pratique les estimations. 3. Le volume des fonctionnalités, le budget et le calendrier permettront de définir le nombre d'itérations requises pour aboutir au résultat final. Le Sprint Backlog contient la liste des tâches à développer pour l'itération courante en accord avec le Product Owner. Le nombre de tâches est défini en fonction de la capacité de l'équipe d'absorber le travail demandé (vélocité). 4. Chaque itération (Sprint) prend en moyenne 2 à 4 semaines et couvre les activités de développement, de tests, de documentation, etc. 5. De courtes réunions quotidiennes (Daily Scrum ou Standup Meeting) permettent au Scrum Master et à tous les membres de l'équipe d'avoir un statut de l'activité et des points de blocage éventuels. Le graphique de progression de l'activité (Burndown Chart) est mis à jour pour évaluer le progrès. 6. À la fin de l'itération, un produit est prêt à être démontré et livré au client. 7. La démonstration du produit est réalisée lors du Sprint Review Meeting auquel participe toute personne intéressée par le projet. 8. L'équipe et le Scrum Master procèdent à une rétrospective de l'itération pour identifier les points d'amélioration (Sprint Retrospective Meeting). 9. L'équipe est prête à poursuivre l'effort en entamant un nouveau cycle de développement qui repart du Product Backlog. Les fonctionnalités sont réévaluées et accueillent de nouvelles demandes du client ou des changements de priorité. Nous n'avons là qu'effleuré les principes de Scrum. Des livres entiers sont consacrés à cette méthode (voir 12) extreme Programming (XP) C'est en 1996 que Kent Beck et Ron Jeffries ont collaboré pour mettre au point une méthode agile destinée à décrire les bonnes pratiques de développement logiciel. Tout comme Scrum, l'extreme Programming (ou XP) est sorti des tranchées suite à une mise en pratique de principes expérimentés Réalisé par : Vivansa ( 18-Jan-2010 Page : 38 of 89

39 sur des projets IT de la société Chrysler 1. En 1999, la méthode XP a été présentée au public au travers d'un livre (voir [REF12]). Contrairement à Scrum, XP se focalise sur les pratiques de réalisation applicables quelle que soit la technologie employée (Java, Java EE,.Net, PHP, Ruby, Flex, etc.). L'eXtreme Programming fournit un ensemble de pratiques de développement informatiques. Figure 6-7 : Les pratiques d'xp (source xprogramming.com) Parmi les nombreuses pratiques, nous allons en retenir quelques-unes qui se démarquent fortement des méthodes traditionnelles. Test Driven Development (TDD) Pair Programming Le TDD, ou développement piloté par les tests, est une pratique qui impose au développeur de développer les tests en même temps que le code. Cette pratique permet d'automatiser les tests unitaires ainsi que de mettre très tôt la qualité au centre des développements. La programmation en binôme permet aux membres de l'équipe de développement d'être plus efficaces dans la recherche d'un problème ou le développement d'une nouvelle fonctionnalité. Le binôme est également utilisé comme pratique de coaching d'un collaborateur moins expérimenté ou pour assurer la diffusion de la connaissance au sein de l'équipe. Coding Standards L'adoption de standards de développement facilite la compréhension du code par tout un chacun. 1 Le lecteur aura relevé que le processus d'industrialisation automobile a fortement inspiré les créateurs de méthodes agiles. Réalisé par : Vivansa ( 18-Jan-2010 Page : 39 of 89

40 Continuous Integration Collective Ownership L'intégration continue est un pré-requis pour garantir la qualité des développements et détecter assez tôt les erreurs. Cette pratique nécessite la mise en place d'outils adéquats et la pratique de tests automatisables. Le risque majeur dans une équipe de développement est de voir des collaborateurs s'approprier la connaissance de pans entiers de la solution. Un mauvais partage des connaissances peut entraîner l'arrêt du développement si les personnes concernées sont indisponibles (maladie, vacances, départ). Cette pratique de propriété collective impose que la connaissance de la solution soit correctement diluée au sein de tous les membres de l'équipe : sources partagées, documentation mise à jour, séances de pair programming, etc. Simple Design XP prône de commencer à analyser et développer le projet en adoptant une démarche simple (et non simpliste). La complexité ira grandissante en phase avec le déroulement des itérations. Cette pratique installe la courbe d'apprentissage et permet dès le début d'aller à l'essentiel. Cela évite le syndrome des méthodes traditionnelles qui passent plus de temps à théoriser la solution au travers de volumineuse documentation et de constater que la pratique démontre des incohérences. Refactoring Le refactoring consiste à améliorer la qualité du code en partant du principe que le code écrit est de toute manière perfectible et qu'il est inutile de passer trop de temps à peindre une "Mona Lisa" du premier coup. Le refactoring sera d'autant plus efficace que le principe de "Collaborative Ownership" conduira un autre collaborateur à revoir le code écrit par d'autres. Planning Game Sustainable Pace Small Releases Le planning est défini par les personnes concernées, à savoir l'équipe de développement. Différentes techniques existent pour permettre aux collaborateurs d'estimer au mieux la charge de travail. On citera par exemple le Planning Poker décrit dans l'ouvrage de Henrik Kniberg (voir [REF8]). Un rythme soutenable pour l'équipe est le meilleur garant pour maintenir des collaborateurs motivés et dégagés de tout stress. Livrer souvent au client permet d'obtenir le feed-back des utilisateurs nécessaires pour évaluer si les objectifs ont été atteints en termes de fonctionnalités et de qualité. La figure suivante (Figure 6-8) illustre le cycle de développement tel que décrit par XP. On notera des similitudes avec Scrum : Réalisé par : Vivansa ( 18-Jan-2010 Page : 40 of 89

41 Figure 6-8 : Cycle de l'extrême Programming (source extremeprogramming.org) Enfin, ci-après est donné un exemple de plateforme d'intégration continue qu'il est nécessaire de mettre en place pour assurer l'industrialisation des développements, des tests et des livraisons : 6.3 Agile vs Traditionnel Figure 6-9 : Intégration continue (source Octo Technology [REF43]) Sans chercher à être exhaustif, nous allons illustrer quelques principes pour lesquels l'approche agile sera mise en comparaison avec l'approche traditionnelle. Les méthodes agiles Scrum et XP serviront de base à nos propos. Réalisé par : Vivansa ( 18-Jan-2010 Page : 41 of 89

42 6.3.1 Contractualisation Entre le client et le fournisseur informatique, un contrat "agile" établit notamment: les modalités de fonctionnement et de collaboration ; la transparence de l'activité ; la date de livraison finale ; le principe d'itération ; le type de livrable à fournir à chaque itération ; l'adaptabilité de la solution ; les pénalités de retard. Figure 6-10 : Établissement du contrat agile Agile vs Traditionnel La différence par rapport aux méthodes traditionnelles est de préciser que les fonctionnalités peuvent changer durant l'élaboration de la solution. Le contrat stipule également que la solution sera développée de manière itérative et incrémentale. Des étapes de livraison seront planifiées. À chaque fin d'étape, le client évaluera le travail réalisé et un système déployable et utilisable lui sera livré. La notion de contractualisation agile pour des contrats au forfait est un vaste débat et demande tant de la part du client que du fournisseur IT, un changement de mentalité pour rompre avec les approches traditionnelles. Nous recommandons au lecteur intéressé par ce sujet de consulter l'article de Nathalie Lopez-Saussier (voir [REF18]) ainsi que celui de Claude Aubry (voir [REF19]). Les formations doivent montrer les bénéfices d'un contrat agile par rapport à un contrat traditionnel. La présentation d'un contrat agile type aidera les participants à mieux visualiser la portée d un tel contrat. Réalisé par : Vivansa ( 18-Jan-2010 Page : 42 of 89

43 6.3.2 Acteurs du projet Comme tout projet informatique, il est crucial d'identifier les acteurs qui interviendront dans le projet. Les méthodes agiles n'échappent bien entendu pas à cette règle même si elles tentent de réduire le nombre d'interlocuteurs. Figure 6-11 : Identifier les acteurs Du côté du client, un acteur (logique ou physique) sera perçu comme le propriétaire de la solution (Product Owner). Il sera le Directeur Métier apte à guider l'équipe informatique dans le développement de la solution. Le Product Owner sera l'interface entre le fournisseur IT et les futurs utilisateurs du système. Du côté du fournisseur IT, le Scrum Master aura la mission de servir d'interface entre le client et l'équipe et de veiller aux bonnes applications des pratiques agiles. Chaque équipe de développement (Team) sera de taille gérable. La règle empirique dit que plus le nombre de collaborateurs est élevé, plus les défis de gestion sont grands. "Diviser pour mieux régner" est la règle qui prévaut dans ce contexte. La figure suivante (Figure 6-2) schématise les acteurs rassemblés autour d'un projet agile tel qu on le retrouve dans Scrum : Figure 6-12 : Acteurs du projet agile Réalisé par : Vivansa ( 18-Jan-2010 Page : 43 of 89

44 Agile vs Traditionnel Dans une méthode traditionnelle, on se perd souvent à identifier les points de contact du projet tant chez le client que chez le fournisseur. Du côté du fournisseur IT, l'approche traditionnelle met en place une organisation très hiérarchisée conduisant à des situations où dans l'équipe il y a "trop de chefs et pas assez d'indiens" La collaboration Équipes locales Les individus sont la valeur ajoutée du projet. De la bonne collaboration entre les personnes dépendra le succès du projet. Les méthodes agiles ont compris ce principe et l'appliquent en cherchant à faire tomber les barrières entre les individus (notamment hiérarchiques) pour offrir un espace de dialogue propice à l'émergence des idées et à la résolution de problèmes. Les réunions quotidiennes (Daily Scrum) en sont un exemple. De plus, un collaborateur efficace est une personne qui allie tant les compétences techniques ("hard skills") requises par son métier que des valeurs humaines ("soft skills") lui permettant de s'intégrer de manière harmonieuse au sein d'une équipe. Comme chaque membre de l'équipe est acteur du projet, le désir de succès n'en sera que plus grand et chacun pourra en partager le mérite. Une équipe collaborative, dégagée de tout stress et dont on reconnaît les mérites sera une équipe gagnante. Dans le contexte qui nous occupe, les "hard skills" regroupent l'ensemble des aptitudes d'une personne pour réaliser son travail : analyser, tester, documenter, développer, etc. Par contre, les "soft skills" concernent les aptitudes requises pour établir des relations avec d'autres personnes : parler, écouter, partager, négocier, coacher, motiver, résoudre des conflits, etc. Agile vs Traditionnel Dans la plupart des situations, les méthodes traditionnelles sont peu efficaces en matière de communication entre les personnes. Avec le client, la communication est cadrée par le contrat. En interne, les membres de l'équipe sont souvent anonymes. On ne pense pas en termes de «personnes» mais de «ressources» pour coder, tester et livrer. Seuls quelques "gourous" sont visibles au regard du client et récoltent les mérites du succès qui est pourtant collectif. Réalisé par : Vivansa ( 18-Jan-2010 Page : 44 of 89

45 Cette situation favorise le stress au travail et conduit à la démotivation des collaborateurs. Les outils informatiques, tels que le Wiki, les blogs ou les plateformes collaboratives, soutiennent la communication entre l'ensemble des collaborateurs. Le Cloud regorge d'outils permettant de favoriser la collaboration entre les acteurs du projet (voir [REF2]) Équipes distantes Ignorer aujourd'hui l'externalisation de services au travers de structures nearshore, offshore ou même via le crowdsourcing (voir [REF2]), consiste à pratiquer une politique de l'autruche. Les enveloppes financières des offres de marché incitent les fournisseurs IT à appliquer des prix de plus en plus agressifs. L'usage de structure externe venant de pays plus attractifs sur le plan du coût du travail, offre l'avantage de réduire le coût tout en bénéficiant de compétences supplémentaires venant renforcer les équipes locales. Mais, il est important de correctement intégrer les équipes externes au sein du processus de développement agile. Et de s'assurer que les équipes externes adhèrent aux valeurs et principes agiles et qu'ils les pratiquent au quotidien. Les méthodes telles que Scrum ou XP permettent ce type de collaboration distante. Correctement gérées, les équipes locales et distantes devraient fonctionner sans problèmes. Les outils (WiKi, vidéoconférence, plateforme collaborative, gestion de contrôle des sources, , etc.) permettront eux aussi d'intégrer les membres externes dans le projet de développement agile. Le développement itératif va permettre de mesurer la performance et la qualité des équipes externes et réagir très tôt si un problème apparaît : qualité discutable, vélocité très faible, manque de communication, manque de transparence. Bien évidemment, il sera recommandé de maintenir une équipe locale située dans le même pays que le client afin de maintenir la transparence du projet. Réalisé par : Vivansa ( 18-Jan-2010 Page : 45 of 89

46 Figure 6-13 : Équipes distantes Agile vs Traditionnel Les méthodes traditionnelles utilisent bien évidemment des équipes distantes. L'avantage des méthodes agiles permet d'uniformiser la méthode de travail au sein des équipes locales et distantes. On évite ainsi des philosophies de travail très différentes qui parasitent la communication entre les équipes. Le bureau de conseil Gartner s'est prêté au jeu des prévisions et estime que "D'ici 2012, les entreprises de services IT en Inde et aux environs représenteront 20% de l'offre de services dans le Cloud" (voir [REF29]) Amélioration continue L'amélioration continue est une des clés du succès des méthodes agiles favorisée par des pratiques telles que le développement piloté par les tests, le refactoring, le pair programming, l'intégration continue, les rétrospectives et les livraisons fréquentes. Réalisé par : Vivansa ( 18-Jan-2010 Page : 46 of 89

47 À chaque itération, la qualité du produit s'améliore grâce notamment au feed-back des utilisateurs et à l'enrichissement des tests techniques et fonctionnels. Agile vs Traditionnel Dans le cycle des méthodes traditionnelles, les tests unitaires et d'intégration arrivent assez tard dans le processus de développement. Ce qui met à mal la qualité du produit et impacte le budget et les délais de livraison. Si la couverture des tests n'est pas complète, la stabilité de l'application sera impactée et l'équipe se retrouvera à jouer les pompiers pyromanes La transparence La transparence permet d'offrir à tous les acteurs du projet une totale visibilité sur l'évolution du projet. On évite notamment d'avoir des équipes qui n'ont pas une vision précise du projet. Les méthodes agiles ont compris que la transparence améliore la communication entre les personnes et installe un climat de confiance avec le client. La mise à disposition des métriques et des statistiques permet à tous de quantifier le progrès du développement projet. Agile vs Traditionnel La transparence n'est pas vraiment au cœur des préoccupations des méthodes traditionnelles. Et si elle est présente, elle sera sûrement conditionnée par les clauses contractuelles. Les audits servent aussi d'excuse au client pour savoir comment se passe le projet et si tout se réalise conformément à ce qui a été négocié. Lorsque le projet entre dans un effet tunnel, la méfiance du client grandit, car il devient difficile de déterminer si tout est sous contrôle. 6.4 Méthodes agiles et architecture IT Architectures Orientées Services (SOA) Les architectures orientées services (SOA) sont sans contexte celles qui apportent plus d'agilité au système d'information. Encore faut-il que le SOA soit correctement mis en œuvre. Les entreprises ont souvent été frileuses à adopter une démarche SOA par manque d'une méthode apte à mesurer rapidement les progrès réalisés. Les méthodes agiles sont taillées sur mesure pour concrétiser une démarche SOA (voir la section dans [REF1]). Réalisé par : Vivansa ( 18-Jan-2010 Page : 47 of 89

48 La démarche SOA couplée aux méthodes agiles est la voie royale pour développer souplement des solutions métiers qui pourront s'intégrer à l'environnement existant tout en permettant une réaction rapide face aux changements. Comme le SOA a été largement décrit dans un précédent rapport, nous n'allons pas nous étendre plus longtemps sur ce sujet et invitons le lecteur à se référer au document correspondant (voir [REF1]) Cloud Computing Tout comme le SOA, la convergence entre méthodes agiles et Coud Computing est évidente (voir la section dans [REF2]). Les méthodes agiles seront tout indiquées pour développer des services métier à déployer dans le nuage. Le Cloud Computing a déjà fait l'objet d'une étude dans un précédent rapport (voir [REF2]). 6.5 Observations Les méthodes agiles bouleversent les fondements du développement traditionnel. Les pratiques agiles ont pour mission d'apporter plus d'agilité dans le système d'information en prônant des valeurs humanistes et une plus grande implication du client dans la réalisation de son projet. On perçoit l'émergence de nouveaux profils métier tels que le coach agile ou le développeur agile. Mais si les entreprises ne sont pas prêtes à envisager un changement de culture, il sera difficile pour elles de s'inscrire dans une démarche agile. La manière la plus pragmatique pour évaluer une démarche agile est de l'appliquer dans le cadre d'un projet pilote. Une estimation de ce projet sera réalisée comme s'il devait être développé en utilisant une approche traditionnelle. Ensuite, le projet pilote est développé en appliquant des pratiques agiles. La direction doit jouer le jeu et laisser le processus agile opéré en donnant carte blanche à l'équipe. Le projet pilote intégrera des changements d'orientation métier pour évaluer l'agilité de l'approche. En fin de projet, des évaluations seront réalisées sur différents paramètres tels que : respect des délais ; stabilité de la solution ; cohérence de la documentation ; état d'esprit de l'équipe ; feed-back des utilisateurs ; coût du projet. Un point doit également être mentionné : ne pas céder au dogmatisme. Une méthode agile promeut des pratiques, mais il vous appartient de les adapter à votre convenance. Réalisé par : Vivansa ( 18-Jan-2010 Page : 48 of 89

49 Vous devez expérimenter les méthodes agiles et les utiliser de la manière la plus optimale possible. N'oubliez pas que chaque projet sera différent, comme chaque client l'est tout autant. Ne jetez pas non plus le bébé avec l'eau du bain. Si votre entreprise possède des pratiques qui fonctionnent et qui ont été longuement éprouvées sur le terrain, n'hésitez pas à les utiliser en combinaison avec les méthodes agiles. Réalisé par : Vivansa ( 18-Jan-2010 Page : 49 of 89

50 7 Tendances du marché À ce jour, les études de marché fournissent des données montrant les tendances du marché face à l'adoption croissante des méthodes agiles. Malheureusement, ce type d'étude n'a pas encore été spécifiquement réalisé pour le marché belge. Nous devrons donc nous contenter de statistiques internationales ou réalisées pour le marché français. Notre objectif n'est pas de reproduire le contenu des études qui ont servi de référence (voir 12.6), mais de nous concentrer sur quelques chiffres pour tenter de discerner les tendances du marché. Les études qui ont servi de base à cette réflexion sont les suivantes : VersionOne : sondage réalisé durant l'été 2008 qui a permis de collecter plus de 2300 réponses de 3061 répondants répartis sur 80 pays (voir [REF34]). Ce sondage a pour objectif de servir de baromètre pour évaluer la perception des organisations face à leur pratique des méthodes agiles. Scott W. Ambler : sondage réalisé en juillet 2009 sur un panel de 123 participants (voir [REF35] et [REF36]). L'objectif du sondage étant de déterminer les pratiques des développeurs agiles. ASPE & VersionOne : sondage réalisé entre les mois de mars et juin 2009 qui a récolté 2786 réponses sur près de 89 pays (voir [REF38]). L'objectif du sondage étant orienté sur le profil salarial des répondants. Scrum User Group France : sondage publié en juin 2009 qui a récolté 230 réponses provenant de plus de 150 entreprises (voir [REF37]). Le sondage a permis de récolter des tendances sur l'adoption des méthodes agiles sur l'ensemble du territoire français. 7.1 Attentes de l'agile La figure suivante (Figure 7-1) montre les motivations qui ont conduit à adopter une méthode agile. Réalisé par : Vivansa ( 18-Jan-2010 Page : 50 of 89

51 Figure 7-1 : Motivations d'adoption de l'agile (source [REF34]) Les chiffres montrent que le besoin d'être plus réactif par rapport aux besoins du marché (Time-to- Market) et d'accroître sa flexibilité par rapport aux changements du métier (Changing priorities) compte parmi les attentes les plus grandes. On note par ailleurs que le moral de l'équipe (Improved Team Morale) se situe en fin de tableau. Pourtant, nous verrons que les méthodes agiles influencent fortement ce paramètre. Il est également intéressant de voir les motivations exprimées dans le sondage de Scrum User Group France (Figure 7-2). Les données sont très différentes de celles récoltées par VersionOne. Figure 7-2 : Motivations d'adoption de l'agile par le Scrum User Group France (source [REF37]) Une des raisons qui pourraient expliquer cet écart est peut-être induite par les paramètres suivants : Réalisé par : Vivansa ( 18-Jan-2010 Page : 51 of 89

52 un panel de participants moins nombreux et pas du tout internationalisé comme dans l'étude de VersionOne ; les répondants ont probablement un profil plus technique que métier. 7.2 Localisation des équipes On lira souvent que les méthodes agiles préconisent une colocation des équipes agiles et de leurs membres. La réalité est tout autre car la mondialisation a amené les entreprises à trouver des moyens pour maximiser les profits en recherchant les formules les plus adéquates : départements localisés dans des pays moins taxés ; partenariat avec des sociétés tierces ; usage de main-d œuvre externalisée (nearshoring, offshoring, crowdsourcing). La figure suivante (Figure 7-3) montre bien qu'une grande partie des équipes est distante. Figure 7-3 : Distribution des membres de l'équipe IT (source [REF36]) L'étude de VersionOne confirme la tendance de l'usage de l externalisation (en anglais «outsourcing»). Figure 7-4 : Projets externalisés Réalisé par : Vivansa ( 18-Jan-2010 Page : 52 of 89

53 7.3 Méfiance de l'agile La figure suivante (Figure 7-5) montre que les critiques à l'encontre des méthodes agiles sont principalement dues à des problèmes de conduite du changement. Figure 7-5 : Préoccupations organisationnelles (source [REF34]) Par exemple, ne pas avoir de planning très détaillé en amont du projet ou le sentiment de la perte de contrôle de la gestion de projet, montre que les habitudes des managers sont toujours très ancrées dans une approche traditionnelle. Le manque de documentation est une critique récurrente à l'encontre des méthodes agiles. Il est vrai que comparé aux méthodes traditionnelles, le volume de documentation est faible. Mais les pratiques agiles prônent pour des documents pragmatiques allant à l'essentiel. La figure suivante (Figure 7-6) permet de mieux cerner les doutes envers les méthodes agiles principalement liées à la crainte du management de ne pouvoir changer sa culture d'entreprise. Ces craintes s'expliquent par le manque d'expérience aux méthodes agiles. Réalisé par : Vivansa ( 18-Jan-2010 Page : 53 of 89

54 Figure 7-6 : Obstacles d'adoption (source [REF34]) Les managers ne doivent pas être les grands oubliés des formations aux méthodes agiles. Il est important que le management soit convaincu de l'efficacité de la démarche agile sans quoi une telle adoption sera vouée à l'échec. Les managers seront notamment sensibilisés sur la conduite du changement à mettre en œuvre pour opérer une mutation en douceur de la culture d'entreprise. 7.4 Méthodes agiles adoptées Parmi les nombreuses méthodes agiles, il est indéniable que la complémentarité de Scrum et XP en font les méthodes de prédilection pour la majorité des personnes sondées, que ce soit en France ou plus globalement dans le monde : Réalisé par : Vivansa ( 18-Jan-2010 Page : 54 of 89

55 Figure 7-7 : Scrum User Group France (source [REF37]) 3 Figure 7-8 : VersionOne (source [REF34]) Les formations devront avant tout se concentrer sur les méthodes agiles Scrum et XP (extreme Programming), car leur complémentarité couvre aussi bien la gestion de projet (Scrum) que les pratiques liées à l'ingénierie logicielle (extreme Programming). 7.5 Retours d'expérience Parmi les retours d'expérience relevée dans le sondage de VersionOne (voir [REF34]), nous avons retenu quelques-uns d'entre eux mis en regard des attentes exprimées dans la même étude (voir 7.1). Attentes Retour sur expérience 3 Il faut toutefois tempérer l'étude réalisée par le Scrum User Group France car l'objectif de ce groupe est justement de promouvoir l'usage de Scrum. On peut donc penser que les répondants étaient déjà acquis à la cause Scrum. Malgré tout, la tendance majoritaire de Scrum et XP rejoint l'étude de VersionOne. Réalisé par : Vivansa ( 18-Jan-2010 Page : 55 of 89

56 Table 1 : Attentes vs. Retours d'expérience (source [REF34]). Les chiffrent confirment que la pratique des méthodes agiles permet de répondre à la plupart des attentes telles que : la réactivité par rapport aux attentes du marché ; la flexibilité liée aux changements du métier ; l'alignement de l'it par rapport aux préoccupations métier ; l'amélioration de la qualité. Mais nous avons également voulu montrer qu au-delà des préoccupations économiques, les méthodes de travail repensées par les méthodes agiles améliorent considérablement le moral des équipes (Improved Team Morale). Un paramètre qui influe positivement sur la dynamique des projets de l'entreprise. Réalisé par : Vivansa ( 18-Jan-2010 Page : 56 of 89

57 Attentes Retour sur expérience Table 2 : Amélioration du moral des équipes (source [REF34]) Succès de mise en œuvre Un peu plus de la moitié des projets ont abouti, ce qui marque une progression significative par rapport à l'étude du Standish Group (32 % en voir 4.2). Figure 7-9 : Succès des projets agiles (source [REF34]) Raisons des échecs En cas d'échecs, les raisons invoquées sont en grande partie à imputer à la difficulté de transformer la culture d'entreprise ainsi qu'à un manque flagrant d'expérience. Figure 7-10 : Échecs d'implémentation (source [REF34]) Réalisé par : Vivansa ( 18-Jan-2010 Page : 57 of 89

58 Il faut toutefois relever que même si la perception du manque de formation ne paraît pas être la cause principale d'échecs, nous pouvons affirmer qu'une formation et un coaching adéquat destiné aussi bien aux managers qu'aux équipes IT permettraient de réduire les situations d'échec. Cela confirme que l'accompagnement au changement est l'une des clés nécessaires pour opérer les mutations vers une démarche agile. 7.6 Métiers impactés et profil salarial Le sondage international réalisé par ASPE & VersionOne (voir [REF38]) est très intéressant, car il permet de se faire une idée sur les profils impliqués par les méthodes agiles en vue de cibler la bonne population et leur offrir les formations adéquates. La ventilation des réponses montre que près d'un tiers des répondants provient d'europe. Figure 7-11 : Ventilation des réponses (source [REF38]) Une donnée essentielle est de relever le nombre d'années d'expérience des répondants qui dépasse 5 ans pour plus de 70 % d'entre eux. Autrement dit, les acteurs agiles dans les entreprises sont des personnes généralement expérimentées. Réalisé par : Vivansa ( 18-Jan-2010 Page : 58 of 89

59 Figure 7-12 : Nombre d'années d'expérience IT (source [REF38]) La distribution de l'âge des répondants montre une nouvelle fois que nous sommes face à des personnes assez expérimentées. Figure 7-13 : Age des répondants (source [REF38]) Les formations peuvent contribuer à remettre sur le marché du travail des profils expérimentés en informatique et qui se reconvertiraient dans les méthodes agiles. Le rôle de coach agile cadre très bien avec des personnes ayant une longue expérience des pratiques informatiques et qui ont largement expérimenté les méthodes traditionnelles et en connaissent les limites. La figure suivante (Figure 7-14) montre que les répondants se situent généralement au milieu de l'échelle de l'organisation de l'entreprise avec en majorité des développeurs confirmés et des chefs de projet. Réalisé par : Vivansa ( 18-Jan-2010 Page : 59 of 89

60 Figure 7-14 : Profil des répondants (source [REF38]) Pour ce qui est des certifications (Figure 7-15), on constate que la majorité des répondants ne possède par de certification liée aux méthodes agiles ou à la gestion de projet. Cela ne veut pas dire que les certifications ne sont pas nécessaires, mais qu'elles seront essentiellement prisées par des personnes qui piloteront les projets. Les développeurs agiles se contentent de pratiquer des méthodes qu'ils expérimentent quotidiennement sur le terrain. Il faut avouer qu'à choisir, un client aura tendance à retenir un coach agile certifié qui aura pu éprouver ses connaissances de la méthode. Ce sera d'autant vrai si le client éprouve quelques réserves par rapport à la démarche agile mais qu'il est disposé à l'expérimenter. Réalisé par : Vivansa ( 18-Jan-2010 Page : 60 of 89

61 Figure 7-15 : Certifications (source [REF38]) La taille des entreprises des répondants confirme qu'en Europe on trouve une majorité de PME. C'est donc vers ces sociétés que les formations seront ciblées. Figure 7-16 : Taille des entreprises (source [REF38]) En Europe toujours, les métiers des entreprises sondées sont majoritairement des sociétés de services informatiques : Réalisé par : Vivansa ( 18-Jan-2010 Page : 61 of 89

62 Figure 7-17 : Profil des entreprises en Europe (source [REF38]) 7.7 Tendances en Belgique Il est très difficile d'évaluer le taux de pénétration des méthodes agiles en Belgique, car nous manquons de sondages centrés sur le pays. Mais les recherches montrent que le mouvement est en marche même s il gagnerait à être plus visible. En plus de conférences sur les pratiques agiles, la Belgique fait partie de groupes œuvrant pour encourager les méthodes agiles (voir 12.3). Toutefois, on constate que les initiatives sont plus visibles dans le nord du pays. Les méthodes agiles en Belgique Il serait intéressant d'organiser en Belgique et plus spécifiquement en Région wallonne, un sondage pour déterminer le taux de pénétration des méthodes agiles au sein des entreprises et les arguments qui éventuellement freinent leur adoption. Ce sondage devra être le plus neutre possible pour obtenir des résultats tangibles. Réalisé par : Vivansa ( 18-Jan-2010 Page : 62 of 89

63 8 Méthodes agiles et outils À quoi devrait ressembler la boîte à outils de l'agiliste? La réponse la plus simple est que cela dépend d'un ensemble de facteurs et de l'usage : pilotage de projet ou développement techniques. Un point important à considérer est celui d'utiliser des outils qui amélioreront la dynamique et la qualité du projet et qui seront adoptés par tous. Si vous tentez d'imposer un outil à une équipe qui ne l'adopte pas, vous pouvez être sûr que la dynamique de votre projet en pâtira. Les outils sont nécessaires pour réaliser ses tâches au quotidien, mais chaque projet aura des spécificités qui nécessiteront d'autres outils. Dans ce qui suit, nous n'allons pas chercher à donner des noms de produits. Ceci étant, nous donnons en référence des ouvrages (voir 12.4) et sites qui proposent des outils agiles (voir 12.9). Il faut savoir que des outils agiles de type Web 2.0 ou issus du Cloud Computing existent. 8.1 Outils de gestion de projet Le coach agile utilise une batterie d'outils pour pouvoir suivre et mesurer les progrès de l'activité tout en communiquant efficacement avec tous les acteurs du projet. En règle générale, on retrouvera des outils pour gérer les tâches suivantes : Liste et suivi des tâches ; Production des métriques ; Suivi des requêtes et incidents ; Outil collaboratif avec calendrier partagé ; ; Messagerie instantanée ; Application de vidéoconférence ; WiKi. Il faut savoir que le client devrait avoir un accès à certains outils de gestion de projet pour lui permettre de suivre l'activité et déposer les commentaires ou le descriptif des erreurs rencontrées. Les outils du coach prendront la forme d'applications informatiques, mais pas toujours : Tableau blanc ; Post-it ; Marqueurs ; Jeu de cartes (pour planifier les estimations via la méthode du Poker Planning). Réalisé par : Vivansa ( 18-Jan-2010 Page : 63 of 89

64 8.2 Outils de réalisation technique Les développeurs agiles utiliseront une batterie d'outils pour documenter, développer, tester et livrer le produit. Ces outils pourront dépendre de l'environnement de développement (Java EE,.NET, PHP, Python, Ruby, etc.). En règle générale, on retrouvera des outils pour gérer les tâches suivantes : Environnement de développement ; Plateforme de contrôle et partage des codes sources ; Plateforme d'intégration continue ; Outils de mesure de performance ; Suivi des requêtes et incidents ; Liste et suivi des tâches ; Messagerie instantanée ; Application de vidéoconférence ; WiKi ; Outil collaboratif avec calendrier partagé. Le Cloud Computing pourra être envisagé afin de disposer par exemple d'un ensemble de serveurs de tests élastiques pour tester le produit à livrer au client dans un environnement pratiquement similaire au sien. Réalisé par : Vivansa ( 18-Jan-2010 Page : 64 of 89

65 9 Les défis et les opportunités L'adoption des méthodes agiles implique que tous les acteurs, tant côté client que fournisseur IT, s'investissent totalement dans la démarche agile pour assurer le succès du projet. Les principes agiles créent un terreau idéal qui verra fleurir des idées nouvelles issues de l'intelligence collective du groupe. Les changements métier qui s'inviteront indéniablement en cours de projet, ne seront pas systématiquement rejetés, mais intégrés au fil de l'eau. Cette dynamique est créée par une nouvelle façon de travailler et de communiquer, mais en contrepartie exige une mutation des mentalités. Un cap qui reste parfois difficile à passer pour certaines entreprises ou individus trop ancrés dans leurs habitudes «métier» et peu enclin aux changements. Commençons par passer en revue quelques opportunités concrètes qui seront suivies par les défis qui viendront freiner l'adoption d'une démarche agile. 9.1 Opportunités Réduire le "time to market" Le grand défi des entreprises est de réduire le temps nécessaire à mettre leur produit sur le marché. Avec les méthodes traditionnelles, le "time to market" est très long et peut empêcher les entreprises de conquérir des parts de marché. La réponse des méthodes agiles face à cet enjeu est de livrer très tôt et souvent des versions utilisables de la solution qui s'enrichira, itération par itération, de nouvelles fonctionnalités. Le client peut ainsi envisager d'adopter une stratégie commerciale plus agressive pour assurer sa présence sur le marché. Meilleur contrôle de l'enveloppe financière Le développement itératif permet de mieux planifier l'usage des ressources en fonction des priorités exprimées par le client. À chaque itération, le client a une meilleure visibilité de l'enveloppe financière et peut soit recadrer ses priorités soit décider d'arrêter le projet. Comme chaque itération se termine avec un produit livrable, le client a la certitude de payer pour une solution qu'il pourra exploiter. Dans une démarche traditionnelle qui avorte, le client risque de payer pour recevoir de nombreux documents, mais une solution très peu exploitable. Amélioration de la communication avec le client Dans tout projet informatique, un problème récurrent est le manque ou la perte de communication avec le client. Les effets tunnel typiques des méthodes traditionnelles encouragent ce type de problèmes. Réalisé par : Vivansa ( 18-Jan-2010 Page : 65 of 89

66 Les méthodes agiles recommandent de maintenir régulièrement le contact avec le client et de mettre en place une démarche de "feed-back" dans laquelle le client voit, teste et commente les livraisons successives de la solution à chaque fin d'itération. De plus, le client a son représentant qui va vivre le projet au même titre que l'équipe agile. Amélioration de la visibilité À la fin de chaque itération, l'équipe IT présente et livre au client la solution et tous ses livrables : code source, code binaire, jeux de tests, programme d'installation, scripts d'administration, documentation, résultats des tests (unitaires, fonctionnels, intégration), etc. Le client peut ensuite valider l'ensemble des livrables et indiquer les points d'amélioration, les informations manquantes, les erreurs. Durant chaque itération, le représentant du client a une visibilité totale du projet et peut mesurer l'efficacité des équipes de développement et transmettre ses remarques et recommandations au coach agile du projet. Lors de la livraison finale, le client n'a plus la fâcheuse impression "d'acheter un chat dans un sac". L'intelligence collective est mise à contribution Dans une approche traditionnelle, les membres des équipes informatiques se plaignent de ne pas être suffisamment écoutés. Ces personnes sont souvent sous-exploitées et reléguées à des fonctions de "machines à coder, tester ou documenter". En cause, un plan de projet contraignant instauré en début de projet et qui ferme la porte à toute remise en question. Ensuite, un système hiérarchique qui installe les penseurs, les décideurs, et les exécutants. Cela paraît caricatural, mais malheureusement assez proche de la réalité. Dans une approche agile, les rôles sont moins cloisonnés et chaque personne est invitée à s'exprimer et à proposer des idées en vue d'améliorer la qualité globale de la solution. L'équipe IT est autogérée ce qui a pour objectif de ne pas étouffer les collaborateurs par un management directif. Les personnes collaborent entre eux sans esprit hiérarchique ou élitiste. Les différentes réunions permettent de juger la pertinence des suggestions en vue de planifier les actions pour les plus pertinentes d'entres-elles. Le principe KISS (Keep IT Stupid Simple) et le développement itératif favorisent la mise en contribution de chacun, car la solution est analysée et développée étape par étape ce qui autorise et encourage le groupe à proposer de nouvelles idées en même temps qu'il acquiert plus de maîtrise sur les objectifs métiers qui peuvent être parfois très compliqués. Les collaborateurs jouent ainsi un rôle plus actif et voient leur travail valorisé. Ce sentiment crée une meilleure dynamique pour le plus grand bénéfice du projet. Processus d'amélioration continue À la fin de chaque itération, le retour des utilisateurs (feed-back) et les séances de rétrospectives, permettent de ternir compte des observations en vue d'améliorer la qualité du projet. Réalisé par : Vivansa ( 18-Jan-2010 Page : 66 of 89

67 Non seulement ce processus est tout bénéfice pour le client qui voit sa solution se stabiliser d'itération en itération, mais l'entreprise IT enrichit sa base de connaissance qui viendra éclairer les autres projets en cours ou à venir. Identification précoce des risques La démarche itérative et le feed-back du client permettent d'identifier assez tôt les risques tant techniques et fonctionnels que financiers. Les acteurs du projet sont ainsi en mesure d'analyser les risques et d'appliquer les corrections adéquates. Réduction du stress de l'équipe IT De nos jours, le stress semble être un paramètre normal lié à la pression économique du marché globalisé. Certains parlent même de stress positif et de stress négatif! Il ne faut pas confondre le stress positif avec l'ardeur que certains ont en travaillant. Dans les méthodes de développement traditionnel, le stress est presque omniprésent, car l'expérience montre que les collaborateurs sont enfermés dans un environnement dont ils ne se sentent pas acteurs, et contraint à des estimations qu'ils n'ont pas eux-mêmes évalué. Le rythme de travail est tel que les heures supplémentaires sont récurrentes. Inutile de dire qu'un tel rythme ne peut pas être soutenu trop longtemps. Quelle est la réponse apportée par les méthodes agiles? Une collaboration étroite entre les personnes et l'autogestion de l'équipe sont des pratiques qui conduisent les collaborateurs à réduire les facteurs de stress. Le coach doit également veiller à protéger l'équipe de problèmes qui ne sont non directement liés à l'activité de développement et à identifier les obstacles qui freinent le projet et l'évolution des personnes. La prise de confiance des collaborateurs augmente La démarche itérative permet aux collaborateurs de gravir la courbe d'apprentissage en affinant leur connaissance métier du client. Les méthodes agiles reconnaissent le droit à l'erreur, mais au lieu de blâmer l'équipe, il est plutôt recommandé d'identifier l'erreur et d'en tirer les leçons pour améliorer la qualité de la solution lors des itérations suivantes. "On apprend de ses erreurs" est une citation qui trouve tout son sens dans les méthodes agiles. Les méthodes agiles comme moteur d'innovation De grandes sociétés comme Google encouragent leurs collaborateurs à consacrer 10 à 20 % de leur temps à se lancer dans des projets personnels pour stimuler l'esprit d'innovation. Les idées intéressantes pourront faire l'objet de projets plus ambitieux. Les méthodes agiles sont très souvent utilisées dans le cadre de ces démarches. Quelques PME pratiquent également ces méthodes (voir [REF41]). Réalisé par : Vivansa ( 18-Jan-2010 Page : 67 of 89

68 Ce type de pratique est à recommander aux entreprises de toute taille. C'est souvent par des axes de recherches inattendues que naissent les «success stories». Mise en pratique rapide L'usage des méthodes agiles telles que Scrum ou XP peuvent s'appliquer assez rapidement au sein d'une équipe IT. Les principes sont très pragmatiques et ne nécessitent pas une formation longue et laborieuse pour amorcer le mouvement. Réalisé par : Vivansa ( 18-Jan-2010 Page : 68 of 89

69 9.2 Défis Freins au changement de la Direction Les méthodes agiles impliquent un changement des mentalités sur la manière de travailler et de collaborer. Bien que les méthodes agiles soient loin d'être de nouveaux concepts, certaines entreprises sont peu disposées à franchir le pas et préfèrent se cantonner aux méthodes traditionnelles de travail qu'elles maîtrisent. Ce problème est essentiellement lié à un manque de connaissance qui peut être facilement comblé en suivant des programmes de formation et de coaching agile adéquats. Freins au changement des collaborateurs Certains collaborateurs sont peu enthousiastes à l'idée de changer de méthode de travail et s'interrogent sur leur capacité à travailler différemment. Le développement des "soft skills", ou la capacité de mieux travailler en équipe, n'est pas une démarche évidente pour certaines personnes. Les formations et le coaching agile permettront d'accompagner les collaborateurs à amorcer le changement. Malgré tout, l'entreprise devra faire face à des collaborateurs plus réfractaires qui verront aux principes agiles un danger pour leur fonction. Chaque entreprise comporte des collaborateurs possédant LA connaissance des solutions métiers. Ces collaborateurs estiment avoir du pouvoir qui leur garantit une pérennité dans l'entreprise. Se séparer d'eux mettrait à mal certaines solutions métier. Il faudra donc manœuvrer avec psychologie pour amener ces "réfractaires" à adopter les principes agiles. Éliminer les contre-productions Le coach veillera à mettre en place un environnement technique adéquat pour permettre aux acteurs du projet de travailler le plus efficacement possible : plateforme d'intégration continue, système de traçabilité des erreurs, plateforme collaborative, WiKi, tableaux blancs, outils de tests, etc. Dans le même esprit, le coach agile veillera à ôter les obstacles ralentissant le projet. Une agilité de façade Adopter les méthodes agiles doit être un engagement clair de direction qui doit encourager la démarche et s'y investir en conséquence (formation, coaching, outils, etc.). Sans cela, l'entreprise IT adoptera une agilité de façade avec le risque de devoir honorer un contrat agile tout en usant de pratiques traditionnelles. Ce n'est pas le développement itératif qui fait l'agilité, c'est un ensemble de pratiques qu'il faut appliquer. Réalisé par : Vivansa ( 18-Jan-2010 Page : 69 of 89

70 Éviter le dogmatisme Les méthodes agiles telles que Scrum ou XP ne doivent pas être appliquées à la lettre comme s il s'agissait de livres saints. Les méthodes agiles sont avant tout des cadres métiers (framework) qui seront appliqués et adaptés en fonction du besoin. Ces méthodes pourront être combinées lorsque la complémentarité est évidente : Scrum + XP, Scrum + KanBan, etc. Pour éviter ce problème, l'entreprise doit se doter d'un coach agile qui aidera à la mise en pratique de la démarche. L'agile à tout prix Ce point rejoint le point précédent sur le dogmatisme. Il n'est pas toujours évident de vouloir pratiquer certaines pratiques agiles à une solution métier existante. Par exemple, il peut s'avérer très difficile d'utiliser le principe du TDD (développement piloté par les tests) dans une application existante dont l'architecture actuelle technique ne se prête guère à ce genre de pratiques. S'acharner à appliquer des principes agiles dans un environnement inadéquat peut fortement impacter la vélocité des itérations. Difficulté de localiser le Product Owner Le succès du projet passera inévitablement par une bonne direction métier insufflée par le représentant du client (Product Owner). La connaissance métier du Product Owner sera capitale pour définir et prioriser les fonctionnalités à développer. Si des doutes persistent, le coach devra alerter le client pour signaler le problème et les risques encourus. Le client ne joue pas le jeu Le manque de feed-back des utilisateurs ou le manque d'implication du client peuvent sérieusement impacter la dynamique du projet. Les termes du contrat agiles devront mentionner ce risque potentiel et imposer au client qu'il joue pleinement son rôle. Difficulté d'homogénéiser les équipes distantes Lorsque les équipes sont distantes (par exemple dans le cas de l'offshoring), il est impératif que les principes agiles soient appliqués par tous. L'équipe distante doit se doter d'un coach agile qui se synchronisera avec le coach local. Le coach distant s'assurera que les pratiques agiles soient compatibles avec celles employées localement. Réalisé par : Vivansa ( 18-Jan-2010 Page : 70 of 89

71 La mise en place de moyens de communication efficaces (vidéoconférence, source partagée, WiKi, etc.) est nécessaire pour réduire les contraintes de distances géographiques. Un contrat agile sera également passé entre le fournisseur IT et son partenaire distant. Des clauses de sortie de contrat seront clairement décrites si la société distante ne peut garantir le niveau de qualité et de planning attendu le client. Outils inadéquats ou inexistants L'usage d'outils inadéquats ou inexistants impacte la productivité de l'équipe et perturbe la communication entre les acteurs du projet. Le coach veillera à sensibiliser la Direction pour qu'elle mettre à disposition les outils nécessaires pour la production du projet (gestions de source centralisée, tests automatisés, plateforme collaborative, système de bug tracking, etc.) et la communication (WiKi, vidéoconférence, messagerie instantanée, etc.). Il faudra surtout s'assurer de ne pas imposer des outils mal perçus par l'équipe et jugés contreproductifs. Des formations ou des séances de coaching seront également à prévoir pour s'assurer que les outils mis en place sont correctement maîtrisés par tous. Le plus important sera de convaincre la Direction de dégager les moyens pour s'équiper efficacement. Sans cela, l'agilité du projet en souffrira. Le coach agile n'est pas pleinement disponible Le coach a pour vocation d'être le garant des principes agiles. Il doit donc se rendre disponible auprès de l'ensemble des acteurs (le client, l'équipe IT, les directeurs, le chef de projet, etc.) pour animer l'activité, expliquer les principes agiles et suivre au jour le jour les avancements du projet. La peur de la transparence Les principes agiles recommandent une transparence du projet vis-à-vis du client. En réalité, les entreprises IT sont peu préparées à jouer carte blanche et cherche à occulter certains aspects du projet : les outils de tests ou de collaboration ne sont pas conformes aux attentes ; les collaborateurs sont affectés sur d'autres projets. Sous-estimer les problèmes de rapport humain Le succès du projet reposera sur les qualités humaines des personnes formant l'équipe de travail. "Mettre des individus ensemble, cela ne fait pas forcément une équipe" ([REF30]). Ce serait une erreur de croire qu'un coach agile sera en mesure de calmer toutes les formes de conflit entre les personnes. Les méthodes agiles ne fournissent pas forcément toutes les clés pour accompagner les membres de l'équipe vers ce changement de mentalité. Réalisé par : Vivansa ( 18-Jan-2010 Page : 71 of 89

72 Chaque individu est unique et possède sa propre sensibilité. Il sera donc nécessaire de sortir du cadre strictement IT pour développer les capacités personnelles. Des techniques existent telles que l'ennéagrame (voir [REF22]) qui soutient le développement personnel et collectif des équipes. Des techniques de team building peuvent être recommandées pour créer un esprit de cohésion entre les membres d'une équipe. Au final, chacun y trouvera son compte : le collaborateur se comprendra mieux et aura une meilleure perception de ses collègues ; le coach agile saura comment tirer le meilleur de chacun ; l'entreprise se dote d'une équipe efficace. Évaluer la fin d'une tâche Un problème récurrent en informatique, et qui n'échappe pas aux méthodes agiles est de définir correctement les conditions qui déterminent qu'une tâche est terminée. En agile, ce principe est connu sous l'acronyme DoD (Definition of Done) autrement dit de donner la signification de "terminé". Il faudra donc s'accorder à l'avance sur les conditions requises pour estimer qu'une tâche est terminée, par exemple : le code source est sauvegardé sur le système de contrôle de version ; les tests ne produisent pas d'erreur ; la documentation est rédigée. Réalisé par : Vivansa ( 18-Jan-2010 Page : 72 of 89

73 10 Formations Au-delà de la simple pratique des méthodes agiles, il faut que l'équipe managériale de l'entreprise adhère à une telle démarche. Nous avons vu que sans le soutien de la direction, une approche agile n'a que peu de chance d'être pleinement mise en œuvre. Les managers ne seront donc pas oubliés des formations d'autant qu'il faudra les sensibiliser aux limites atteintes par les approches traditionnelles. Il leur sera présenté les opportunités qu'offrent les méthodes agiles tant pour répondre aux demandes des clients que pour optimiser le fonctionnement interne de l'entreprise. Mais le changement de culture a un coût et sans conduite du changement, peu de managers se lanceront dans une démarche agile. Les formations doivent donc éclairer les managers sur la meilleure manière d'envisager la mutation de leurs entreprises vers une démarche agile. Des formations plus avancées seront à prévoir afin de former les collaborateurs qui pratiqueront au quotidien ces méthodes. En termes de métier, les profils qui se dégagent sont le coach agile et le développeur agile. Des formations annexes, qui ne seront pas illustrées ci-après, devraient être envisagées pour aider les participants ou les équipes de projet à développer leur capacité à communiquer et travailler ensemble (soft-skills). Réalisé par : Vivansa ( 18-Jan-2010 Page : 73 of 89

74 10.1 Formation de base Contexte La formation de base d'une journée au moins s'adresse à tout public désireux d obtenir une introduction aux principes des méthodes agiles tel que : Directeur de société ; Directeur IT ; Directeur financier ; Chefs de projets ; Développeurs. Les participants doivent être sensibilisés sur les risques encourus à ignorer les méthodes agiles comme : de ne pouvoir réagir souplement face aux défis ; de ne pas profiter des évolutions s ; d'engendrer du stress au travail, cause principale d'absentéisme. La formation doit montrer les avantages dont bénéficiera le client tels qu'une meilleure visibilité du projet et de pouvoir jouer un rôle actif dans l'élaboration de la solution. Les managers doivent trouver des motivations à envisager une démarche agile en les sensibilisant tant sur les facteurs de succès que sur les valeurs humanistes. Les chefs de projets verront tout l'intérêt de s'adosser à un coach agile pour assurer le suivi de l'activité et maintenir le moral des équipes et la confiance du client. Les développeurs y trouveront les éléments de base pour mieux comprendre les enjeux avant d'aborder une formation avancée. Réalisé par : Vivansa ( 18-Jan-2010 Page : 74 of 89

75 Exemple de sujets Le tableau ci-dessous présente des exemples de sujets qui pourront alimenter le catalogue de formation de base : Contexte L'économie de marché a besoin d'entreprises agiles et flexibles face aux défis de la mondialisation. Montrer que de nombreuses études pointent que les projets en échec sont plus importants que ceux connaissant le succès. Les méthodes traditionnelles Par une illustration, montrer en quoi les méthodes traditionnelles échouent en termes d'agilité et de flexibilité. Les méthodes agiles : Pourquoi? La démarche agile Les acteurs de l'agile Présenter l'histoire des méthodes agiles pour sensibiliser les participants qu'il ne s'agit en rien du buzz du moment. Insister sur l'approche empirique de ces méthodes bâties sur les retours d'expérience. Montrer pourquoi les méthodes agiles mettent l'accent sur les valeurs humaines. Citer de grands projets agiles tels que ceux réalisés chez Microsoft, Yahoo et Google. Sur base du manifeste agile, présenter les quatre valeurs et les douze principes de l'agile. Expliquer le rôle des acteurs intervenant dans un projet agile. La méthode Scrum pourra être utilisée pour définir les rôles suivants : Product Owner ; Scrum Master (coach agile du projet) ; Équipe. Montrer également comment le chef de projet va pouvoir collaborer avec ces acteurs. Les valeurs humaines : entre "hard skills" et "soft skills" Illustration des principes agiles Pour maintenir le degré de motivation d'une équipe au maximum, il faut que les collaborateurs développent tant leur "hard skills" (compétences techniques) que "soft skills" (valeurs humaines). Expliquer la différence entre "être impliqué" et "être concerné". Sur base d'une illustration, montrer comment un projet IT peut être instancié dans une démarche agile : contrat agile ; identifier les acteurs ; récolte et priorisation des besoins ; réunion du suivi ; planning et estimation de charge ; Réalisé par : Vivansa ( 18-Jan-2010 Page : 75 of 89

76 développement piloté par les tests ; itération ; intégration continue ; livraisons et feed-back des utilisateurs. Panorama des méthodes agiles Opportunités et défis Projet pilote Méthodes agile, SOA et Cloud Computing Agilité et qualité Agilité et Outsourcing Le coaching agile Références Présenter les principales méthodes agiles et décrire leur domaine d'application, leur force et faiblesse : Scrum ; extreme Programming (XP) ; Crystal ; Lean Software Development ; OpenUP. En plus des opportunités évidentes, les défis à relever sont bien présents et les ignorer serait une erreur stratégique. Quelle conduite du changement faut-il suivre pour opérer en douceur un changement de culture de l'entreprise? Quelles sont les réticences que l'on pourra observer dans les entreprises : la peur de la perte d'une certaine forme de pouvoir ; offrir au client la transparence du projet ; laisser une plus grande autonomie aux équipes de développement. Entamer un projet pilote est sûrement la voie à suivre pour évaluer la pratique des méthodes agiles. Montrer que les méthodes agiles sont tout à fait indiquées pour concrétiser une démarche SOA et aborder le Cloud Computing. Démontrer qu'au travers des pratiques agiles, l'amélioration continue est un principe clé qui aidera l'entreprise et ses équipes à se hisser vers le haut. Montrer comment composer des équipes agiles distantes en bénéficiant de ressources issues du nearshoring, offshoring ou crowdsourcing. S'inscrire dans une démarche agile pourra requérir l'assistance d'un coach agile qui accompagnera l'entreprise vers le changement. La formation donnera des clés pour faire le bon choix de coach telles que les certifications obtenues et les moyens de les vérifier. Donner aux participants toute information lui permettant d'approfondir le sujet : articles, blogs, ouvrages, conférences. Réalisé par : Vivansa ( 18-Jan-2010 Page : 76 of 89

77 10.2 Formation avancée : pilotage du projet Contexte La formation avancée de pilotage de projet a pour objectif d'illustrer au travers d'exemples pratiques comment piloter un projet à l'aide de méthodes agiles. D'une durée de deux journées minimum, le public visé par cette formation sera orienté sur les acteurs qui ont actuellement la charge de suivre et piloter des projets informatiques : Managers ; Chefs d'équipe ; Chefs de projet. Pour illustrer les principes agiles appliqués au pilotage d'un projet, une étude de cas sera utilisée et chaque participant invité à collaborer dans des exercices pratiques. La formation pourra être orientée vers une méthode agile bien précise. Cette formation sera l'occasion pour les entreprises d'envisager un nouveau type de profil, le coach agile. Réalisé par : Vivansa ( 18-Jan-2010 Page : 77 of 89

78 Exemple de sujets En complément des sujets développés dans le cadre de la formation de base (voir ), le tableau ci-dessous présente des exemples de sujets appliqués à la méthode Scrum et qui pourront alimenter le catalogue de formation : Présentation de l étude de cas L'agilité : Pourquoi? Présentation de Scrum L'étude de cas et les objectifs seront présentés aux participants. Les limites des méthodes traditionnelles. Présentation du manifeste agile, ses valeurs et ses principes. Historique de la méthode. Ces grands fondements et sa démarche empirique. Les grands projets réalisés avec Scrum tel que AdWords de Google. Présenter la Scrum Alliance. Les acteurs vus par Scrum Quels sont les acteurs du projet Scrum : Product Owner ; Scrum Master ; Team. Comment les identifier et quel est leur périmètre d'action. Étapes de Scrum Présenter et illustrer les différentes étapes de Scrum : Les outils essentiels Définition du Product Backlog ; Le Sprint Planning Meeting et l'estimation des charges ; La gestion de l'itération ou Sprint ; Les réunions quotidiennes ou Daily Scrum ; Les règles de développement agile ; La préparation des démonstrations et le Sprint Review Meeting ; La rétrospective de l'itération par le Sprint Retrospective ; La livraison ; La redéfinition des besoins et des priorités. Quels sont les outils essentiels pour piloter un projet de développement agile : planification des activités ; suivi des tâches au quotidien ; Mesure de performance ; Plateformes collaboratives ; WiKi ; Plateforme de suivi des requêtes et incidents ; Réalisé par : Vivansa ( 18-Jan-2010 Page : 78 of 89

79 Outils disponibles sur le Cloud. Relation avec le client Comment établir et maintenir la relation avec le client? Relation avec l'équipe Comment animer l'équipe? Comment négocier les changements fonctionnels et techniques? Comment détecter et résoudre les conflits? Relation avec le management Comment communiquer et maintenir la confiance du management de l'entreprise? Mesure de la qualité et des performances Présentation de l'extreme Programming (XP) Certifications Références Quelles sont les mesures et les statistiques à obtenir pour évaluer la performance du projet? Présenter les principes généraux de la méthode XP qui se complémente parfaitement à Scrum en tant que méthode agile d'ingénierie logicielle. Les différents types de certifications Scrum, comment s'y préparer et quelle est leur valeur ajoutée en terme de visibilité. Donner aux participants une liste de références vers des articles, des blogs, des ouvrages, des tutoriaux, etc. Réalisé par : Vivansa ( 18-Jan-2010 Page : 79 of 89

80 10.3 Formation avancée : réalisation du projet Contexte La formation avancée pour la réalisation de projet a pour objectif d'illustrer au travers d'exemples pratiques comment réaliser un projet à l'aide de méthodes agiles. D'une durée de deux journées minimum, le public visé par cette formation sera orienté sur les acteurs qui ont actuellement la charge de suivre, piloter et réaliser des projets informatiques : Managers ; Chefs d'équipe ; Chefs de projet ; Développeurs. Pour illustrer les principes agiles appliqués au pilotage d'un projet, une étude de cas sera utilisée et chaque participant invité à collaborer dans des exercices pratiques. La formation dépendra de la méthode agile utilisée ainsi que de l'environnement technique cible (Java,.Net, PHP, etc.). Cette formation sera l'occasion pour les entreprises d'envisager un nouveau type de profil, le développeur agile. Réalisé par : Vivansa ( 18-Jan-2010 Page : 80 of 89

81 Exemple de sujets En complément des sujets développés dans le cadre de la formation de base (voir ), le tableau ci-dessous présente des exemples de sujets appliqués à la méthode extreme Programming et qui pourront alimenter le catalogue de formation : Présentation de l étude de cas L'agilité : Pourquoi? L'étude de cas et les objectifs seront présentés aux participants. Les limites des méthodes traditionnelles. Présentation du manifeste agile, ses valeurs et ses principes. Collaboration Comment collaborer efficacement avec : Présentation de XP le client le chef de projet le coach agile les collaborateurs Historique de la méthode. Ces grands fondements et sa démarche empirique. Pratiques de XP Présenter et illustrer les différentes pratiques d'xp tel que : Cycle de développement Les outils essentiels Pair Programming ; Intégration continue ; Développement piloté par les tests ; Planning Game ; Pratiques de programmation ; Approche collaborative. Présenter et illustrer les différentes étapes du cycle de développement d'xp : Pratique des User Stories ; Les itérations ; La définition des plannings ; Les tests ; Les outils utilisés. Quels sont les outils essentiels pour le développement selon les principes agiles : Développement piloté par les tests ; Intégration continue ; Partage des codes sources ; Mesure de performance ; Plateformes collaboratives ; WiKi ; Réalisé par : Vivansa ( 18-Jan-2010 Page : 81 of 89

82 Plateforme de suivi des requêtes et incidents. Présentation de Scrum Références Présenter les principes généraux de la méthode Scrum qui se complémente parfaitement à XP en tant que méthode agile de pilotage projet. Donner aux participants une liste de références vers des articles, des blogs, des ouvrages, des tutoriaux, etc. Réalisé par : Vivansa ( 18-Jan-2010 Page : 82 of 89

83 11 Conclusion Qui aujourd'hui peut prétendre que la vision métier cristallisée dans le plan projet et détaillée dans la montagne de documents de spécifications sera toujours la même dans les mois ou les années qui seront nécessaires pour développer et livrer l'application tant attendue par le client? Les chiffres sont là pour le démontrer. Peu de grands projets IT réussissent sans mal. De nos jours, il est primordial pour les entreprises de suivre l'évolution du marché qui demande de plus en plus d'agilité et de flexibilité. Il est donc nécessaire que chaque projet informatique embrasse le changement. Si le marché impose un changement, le time-to-market doit être très court, car ni le marché, ni vos concurrents ne vous attendront! Dans ce contexte, les méthodes de développement traditionnelles sont-elles encore bonnes pour le service? Ce document a montré qu'appliquées telles quelles, les méthodes traditionnelles (en cascade ou en "cycle en V") ne sont plus correctement armées pour faire face aux défis économiques actuels et à l'appétit de nouvelles technologies des utilisateurs. Les chiffres le démontrent et les analystes insistent sur l'inaptitude des méthodes traditionnelles à être suffisamment réactives face aux évolutions métiers. et de gestion de projet semblent donc être prêtes à reprendre le relais. Depuis le milieu des années 1990, les méthodes agiles sorties des tranchées ont appliqué à l'informatique les nouveaux principes d'industrialisation en vogue dans la construction automobile qui ont fait le succès de l'industrie japonaise. Depuis lors, l'adhésion aux méthodes agiles est sans cesse grandissante tant par les PME que par les grandes sociétés telles Microsoft, Yahoo ou encore Google. Leur efficacité n'est plus à prouver et leur souplesse d'utilisation ainsi faite que les nombreux retours d'expérience enrichissent les pratiques. Le manifeste agile n'est pas étranger à l'engouement qui fédère de plus en plus d'adeptes. Des valeurs et des principes simples, mais pas simplistes, qui en plus de prôner des valeurs humanistes ajoutent des valeurs de qualité, de communication et de collaboration. Là où les méthodes traditionnelles parlent prédiction et hiérarchie, les méthodes agiles répondent par l agilité, l adaptabilité et l'intelligence collective. Ainsi les valeurs humanistes des méthodes agiles révolutionnent les projets informatiques pour établir une nouvelle démocratie du travail. L'efficacité du projet implique que le rythme de travail des collaborateurs soit soutenable tout en se dégageant des facteurs de stress qui coûtent tant aux entreprises. Les méthodes traditionnelles de développement peinent encore à sortir des développements d'applications en silo. Réalisé par : Vivansa ( 18-Jan-2010 Page : 83 of 89

84 Les méthodes agiles peuvent de leur côté concrétiser une démarche SOA ou Cloud Computing. Et le client dans tout ça? Le client, même s'il est roi, reste le grand oublié des méthodes traditionnelles. Lorsque tout va bien, le client est choyé. Par contre, lorsque les relations se grippent, le client devient un adversaire qu'il faut combattre à coup de lecture "notariale" des clauses du contrat et du plan de projet. Les méthodes agiles considèrent le client comme un acteur à part entière qui devra s'impliquer pour la réussite du projet. Le client sera présent tout au long de la réalisation du projet pour donner sa vision métier, prioriser les besoins, négocier les changements fonctionnels et évaluer les fréquentes livraisons. Mais pourquoi les méthodes traditionnelles perdurent-elles? La raison majeure est la peur des entreprises face au changement et surtout ceux qui affectent la culture d'entreprise et son modèle hiérarchique. Un sentiment de perte de contrôle des managers face à une équipe agile autogéré n'est pas non plus très bien perçu. Les vieux principes ont la vie dure! La transparence vis-à-vis du client est également une concession que la direction de l'entreprise a du mal à concéder. Pour vivre heureux, vivons cachés. Tant que les équipes managériales ne s'engageront pas dans une démarche agile, les chances de succès d'adopter les méthodes agiles ont peu de chance de réussir. Et pourtant, les entreprises et leurs collaborateurs ont tout à y gagner. Une entreprise est valorisée par les solutions qu'elle produit et sa réactivité face aux changements. Sans l'engagement et l'écoute de TOUS les collaborateurs, les idées auront bien du mal à germer. Pour l'heure, il est difficile d'estimer le taux de pénétration des méthodes agiles au sein des entreprises wallonnes. Par contre, le nord du pays affiche beaucoup plus cette tendance. On voit donc tout l'intérêt qu'ont les Centres de Compétence à canaliser les formations pour une approche qui va à coup sûr se généraliser dans les années à venir. Réalisé par : Vivansa ( 18-Jan-2010 Page : 84 of 89

85 12 Références 12.1 Rapports de veille [REF1] Said Eloudrhiri - Pierre Halin, Urbanisation et SOA. Vers une entreprise agile, Vivansa, septembre 2008 http :// [REF2] Said Eloudrhiri, Cloud Computing. Enjeux, Perspectives et Impacts métiers, Vivansa, septembre 2009 http :// Sites généraux [REF3] Agile Manifesto. http ://agilemanifesto.org/ Pour une traduction française du manifeste agile : http ://fr.wikipedia.org/wiki/manifeste_agile [REF4] Les méthodes agiles, Wikipedia http ://fr.wikipedia.org/wiki/méthode_agile http ://en.wikipedia.org/wiki/agile_software_development [REF5] ScrumAlliance http :// L'agile en Belgique [REF6] Agile Consortium http :// [REF7] XP.BE - Belgian XP/Agile User Group http :// Réalisé par : Vivansa ( 18-Jan-2010 Page : 85 of 89

86 12.4 Ouvrages [REF8] Henrik Kniberg, Scrum and XP from the Trenches, InfoQ, 2007 http :// Une version française est disponible sur le site d'infoq. [REF9] Henrik Kniberg and Mattias Skarin, Kanban and Scrum. Making the both of them, InfoQ, 2009 http :// [REF10] [REF11] [REF12] Jean-Pierre Vickoff, Méthode Agile. Les meilleures pratiques Compréhension et mise en oeuvre, Editions QI, 2009 Véronique Messager Rota, Gestion de projet. Vers les méthodes agiles, 2ème édition, Eyrolles, 2009 Kent Beck, Extreme Programming Explained : Embrace Change, second edition, Addison- Wesley Educational Publishers Inc, Articles [REF13] Royce, Winston, "Managing the Development of Large Software Systems", Proceedings of IEEE WESCON, 1970 http :// [REF14] Worldwide cost of IT failure : $6.2 trillion http ://blogs.zdnet.com/projectfailures/?p=7627&tag=nl.e539 [REF15] Standish Group, The CHAOS Report 2009 on IT Project Failure, Standish Group, 2009 http :// [REF16] A process for the development of software for non-technical users as an adaptive system, E. A. Edmonds, General Systems, XIX : , 1974 [REF17] The New New Product Development Game, Hirotaka Takeuchi and Ikujiro Nonaka, Harvard Business Review, January 1986 http ://hbr.org/product/new-new-product-development-game/an/86116-pdf-eng http ://apln-richmond.pbworks.com/f/new+new+prod+devel+game.pdf [REF18] La contractualisation agile, une affaire de bon sens, Nathalie Lopez-Saussier (Valtech Technology), Le Journal du Net, Février 2009 http :// Réalisé par : Vivansa ( 18-Jan-2010 Page : 86 of 89

87 lopez-saussier-valtech-technology-la-contractualisation-agile-une-affaire-de-bon [REF19] Contrat au forfait et démarche agile, Claude Aubry, Avril 2008 http :// [REF20] Métaphore de la poule et du cochon, Clark and Vizdos, 2006 http :// [REF21] Google : des bénéfices en hausse de 19% au second trimestre http :// [REF22] L'ennéagramme - un coup de neuf http :// Soir - References - Semaine pdf L'HPEI met la pression sur le MBTI http :// Tribune Juin 2009.pdf L alliance entre coaching et Ennéagramme : synergie ou antinomie? Sibylle Heunert Doulfakar et Marie-Claude Cialente, Centre de Compétences PROFIL hp, Suisseseptembrere 2006 http :// [REF23] Le coût du stress au travail : 1,9 à 3 mds d'euros en France en 2007, AFP, janvier 2010 http :// tude [REF24] Le stress au travail coûte 3 à 5 % du PIB, lemonde.fr, juin 2009 http :// [REF25] La loi de Pareto http ://fr.wikipedia.org/wiki/loi_de_pareto [REF26] Agile Development : Lessons learned from the first Scrum http ://jeffsutherland.com/scrum/firstscrum2004.pdf [REF27] The Rules of Extreme Programming http :// [REF28] Phenix, un gaspillage de 28 millions d'euros, DataNews, janvier 2009 http ://datanews.rnews.be/fr/news/ /phenix--un-gaspillage-de-28-millions-d- Réalisé par : Vivansa ( 18-Jan-2010 Page : 87 of 89

88 euros.html [REF29] 9 prévisions sur l'avenir de l'ict, Data News, janvier 2010 http ://datanews.rnews.be/fr/news/ /9-previsions-sur-l-avenir-de-l-ict.html [REF30] La psychologie, secret de la réussite des méthodes agiles http :// [REF31] Définition de l'effet tunnel en informatique Sondages [REF32] Les entreprises agiles, mieux armées contre la crise http :// OBE_FR.pdf [REF33] Chaos Summary Report 2009, Standish Group http :// pdf Le rapport complet n'étant pas gratuit, un aperçu est donné sur le site suivant : http :// [REF34] VersionOne : 3rd Annual "State of Agile Development" Survey (August 2008) http :// Pour la version PDF : http :// [REF35] Agile Practices Survey Results : July 2009, Scott W. Ambler http :// [REF36] Results from Scott Ambler and Michael Vizdos s July 2009 Agile Practices Survey http :// [REF37] Enquête Nationale Méthodes Agiles juinin French Scrum User Group http :// Réalisé par : Vivansa ( 18-Jan-2010 Page : 88 of 89

89 [REF38] The 2009 Agile Practitioner Salary Survey, ASPE and VersionOne http :// [REF39] Le Belge stresse au travail, mars 2009, rtbf.be http :// Livres blancs [REF40] The IT Complexity Crisis : Danger and Opportunity http :// Retour d'expérience [REF41] Softkinetic : Nous nous sommes inspirés du modèle Google" (CreaWal 2009) http :// http :// [REF42] Agile Project Management : Lessons Learned at Google, Jeff Sutherland, July 2008 http :// [REF43] Octo Technology, Java Productivity Primer http :// Outils [REF44] Icescrum http :// [REF45] Agile Tools. Open source and free agile tools. http :// Réalisé par : Vivansa ( 18-Jan-2010 Page : 89 of 89