Frédéric MONJO Master I Année universitaire 2005 / 2006 Stage du 3 avril 2006 au 1 er septembre 2006 Caisse Primaire d Assurance Maladie de Toulouse Tuteur en entreprise : Sylvie COMBES Encadrant universitaire : Claude AUBRY
Remerciements Avant toute chose, il est pour moi indispensable de remercier tous ceux qui m ont accompagnés dans le déroulement de ce stage. Je commencerais donc par Brice JONES, responsable de l équipe RIL, avec qui nous avons réalisé un travail de fond sur l étude et l organisation des ressources matérielles et humaines. Sa grande disponibilité d écoute et son implication ont permis à ce stage de se dérouler du mieux qu il se peut. L autre acteur principal de ce stage a été l équipe «pilote» qui a mis en place et expérimenté la nouvelle méthodologie proposée. Je leur dois beaucoup pour leur investissement dans la mise en pratique de concepts qui sont parfois difficiles à intégrer. Un merci spécial à Philippe MERIC qui m a accueilli comme collègue et comme gendre. Je remercie également toutes les autres personnes du RIL et du SESI, pour leur accueil convivial, leur sympathie et leur bonne humeur. Je remercie enfin les responsables de services qui m ont accueilli pour répondre à mes interviews.
Table des matières Introduction... 1 I - Contexte du stage... 2 1 - L organisme de Sécurité Sociale... 2 2 - La CPAM de Toulouse... 3 3 - L Informatique Locale... 4 4 - Le projet de refonte méthodologique... 4 II - Analyse de la situation... 5 1 - Méthodologie officielle... 5 2 - Interviews... 6 a - Développeurs...6 b - Direction...6 3 - Groupe de travail... 6 4 - Bilan... 6 a - Attentes des développeurs...6 b - Attentes de la direction...7 c - Risques identifiés...8 5 - Présentation des méthodes Agiles... 10 6 - Les réponses «Agiles»... 10 a - Propositions d amélioration...10 b - Adéquation à l Agilité...13 III - Mise en place du projet pilote... 14 1 - La nécessité d un «pilote»... 14 2 - Actions préparatoires... 14 3 - Choix de la méthodologie... 15 a - Les alternatives principales...15 b - Le choix de la méthode «Scrum»...15 4 - Choix du projet... 16 a - Alternatives...16 b - Difficultés...17 5 - Structuration de l équipe... 17 6 - Planification de la migration... 17 a - Structure du projet...17 b - Planning...18 7 - Positionnement personnel... 18 a - Analyse...18 b - Formation...18 c - Coaching...19 d - Aide à la formation...19 e - Outils de support...19
f - Assistance en ergonomie des applications...19 IV - Déroulement du projet pilote... 21 1 - Backlog du produit... 21 2 - Déroulement des sprints... 22 a - Sprint 1...22 b - Sprint 2...23 c - Sprint 3...23 d - Sprint 4...24 3 - Vélocité moyenne de l équipe... 25 4 - Statistiques des releases... 25 a - Phase «technique»...25 b - Phase «logicielle»...26 V - Bilan du stage... 27 1 - Bilan professionnel... 27 a - Préparation...27 b - Formation...27 c - Objectifs atteints et restants...27 d - Scénario envisagé...29 e - Bénéfices...29 f - Difficultés...30 2 - Bilan personnel... 31 a - Intérêts du stage...31 b - Enseignements appliqués...31 c - Connaissances complémentaires...31 d - De l intérêt d un «blog»...31 e - Contributions au monde libre...32 f - Objectifs personnels...32 g - Projet professionnel...32 Conclusion... 33 Glossaire et Acronymes... 34 Bibliographie... 35
Page 1 sur 35 Introduction L organisme de Sécurité Sociale assure la couverture de la quasi-totalité de la population française. Cela représente des quantités de données gigantesques à traiter et archiver. La Caisse Nationale d Assurance Maladie fédère toutes les caisses primaires et gère leur système d information ainsi que les moyens d accès à ces données. Néanmoins, chaque caisse a des besoins spécifiques en informatique, et certaines d entre elles disposent d un service dédié aux développements internes ou à la maintenance, dit «service informatique locale». Le service «informatique locale» de Toulouse a utilisé depuis longtemps la méthodologie de développement officielle de la CNAM, très détaillée et adaptée à de grands projets ; mais l échelle modérée de la plupart des projets applicatifs locaux ne justifiait pas l utilisation d une méthode aussi formalisée. Aussi il était nécessaire pour les développeurs d accéder à une méthode plus légère, plus efficace, et qui assurerait un même niveau de qualité des produits. C est dans ce contexte que mon stage a eu pour objectif de participer à la mise en place d une nouvelle méthode. Le but de ce rapport est de vous présenter la démarche suivie pour arriver à la mise en place d une nouvelle méthode de développement. Il est structuré comme suit : La première partie présente succinctement le contexte du stage ; La deuxième partie dresse un bilan de l analyse de situation que j ai effectuée au début de mon stage ; Puis la troisième partie expliquera comment la nouvelle méthodologie proposée a été appliquée à un projet pilote ; La quatrième partie restituera les principaux éléments du déroulement du projet pilote ; Et la cinquième partie dressera un bilan professionnel et personnel de tous les travaux effectués pendant ce stage.
Page 2 sur 35 I - Contexte du stage 1 - L organisme de Sécurité Sociale Si la sécurité sociale telle qu on la connaît aujourd hui a été créée en 1945, il n en demeure pas moins que ses origines remontent à la Révolution de 1789. A cette époque les solidarités se restreignaient au cadre familial ou professionnel (corporations). Il faudra ainsi attendre la phase d'industrialisation du XIX ème développer, non sans débats et hésitations : siècle pour voir se Les sociétés de secours mutuels, fondées sur la prévoyance collective volontaire et limitées à quelques activités ou quelques entreprises ; Un système d'aide sociale intervenant pour faire face à des besoins spécifiques, appréciés selon des critères subjectifs par une commission composée en partie d'élus locaux ; L'assistance médicale gratuite (loi du 15 juillet 1893), le service départemental d'aide sociale à l'enfance (loi du 27 juin 1904), et l'assistance aux vieillards infirmes et incurables (loi du 14 juillet 1905). En respectant leurs principes fondateurs, les mutuelles et l'aide sociale constituent aujourd'hui des composantes de la protection sociale. Les mutuelles et l'aide sociale, fonctionnant alors sous appréciation subjective et spécialisée, n'ont bénéficié qu'à une frange limitée de la population. Aussi, dès le début du XX ème siècle, apparaissent des tentatives en faveur de l'assurance obligatoire de certains risques sociaux : accidents du travail (1898), assurance vieillesse (1910), assurance maladie, maternité, invalidité, vieillesse et décès (1928 et 1930) pour les salariés titulaires d'un contrat de travail, et un régime spécial pour les agriculteurs (1928). La loi du 11 mars 1932 prévoit des allocations couvrant les charges familiales financées par des versements patronaux. A la veille de la deuxième guerre mondiale, la France dispose, dans les textes, d'un système de protection complet mais fragile qui sera profondément renouvelé après les hostilités. En 1945 les bâtisseurs du système français de sécurité sociale poursuivent un triple objectif : unité de la sécurité sociale, généralisation quant aux personnes, extension des risques couverts. En 1946, les allocations familiales sont étendues à pratiquement toute la population. La loi du 22 mai 1946 pose le principe de la généralisation de la sécurité sociale à l'ensemble de la population, mais les professions non salariées non agricoles s'y opposeront. Les principes de 1945 dont certains n'ont pu être appliqués rapidement entrent progressivement dans les faits. L'unité administrative de la sécurité sociale n'est toujours pas achevée mais plusieurs évolutions contribuent à la renforcer. Les différences de prestations et de cotisations entre les différents régimes s'estompent rapidement. La généralisation de la couverture à toute la population a été poursuivie selon de nombreuses étapes de 1947 à 1999, date de création de la Couverture Maladie Universelle. Le régime général de sécurité sociale a également fait l'objet de plusieurs réorganisations : trois caisses nationales (CNAMTS pour l assurance maladie, CNAVTS pour l assurance
Page 3 sur 35 vieillesse, CNAF pour les allocations familiales) plus ACOSS pour les finances, institution en 1996 des conseils de surveillance auprès des caisses nationales et des unions régionales de caisses d'assurance maladie. Le financement de la sécurité sociale s'est aussi modifié depuis 1945. Bien que les cotisations assises sur la masse salariale représentent encore la principale ressource des régimes, la part des autres recettes (taxes fiscales, Contribution Sociale Généralisée, contribution sociale de solidarité à la charge des entreprises, Contribution au Remboursement de la Dette Sociale) croît rapidement. Le système français de sécurité sociale se caractérise donc aujourd'hui par une protection contre les risques sociaux généralisée à l'ensemble de la population mais éclatée entre de nombreuses institutions faisant appel à des sources diversifiées de financement. 2 - La CPAM de Toulouse La Caisse Primaire d'assurance Maladie de la Haute-Garonne est un organisme de droit privé qui gère une mission de service public. Elle assure plusieurs missions : Rembourser les prestations de l'assurance Maladie au titre des risques maladie, maternité, décès, invalidité et accident du travail - maladie professionnelle pour les bénéficiaires du régime général Participer à la politique de maîtrise des dépenses de santé (campagnes d'information dirigées vers nos différents publics, prévention des risques, contrôle) Simplifier l'accès aux soins et accélérer les remboursements (faciliter l'utilisation de la carte Vitale et accompagner l'informatisation des professionnels de santé) Lutter contre les exclusions et garantir les droits à la santé pour tous Offrir un service de proximité, adapté à nos différents publics Quelques chiffres : 1 100 agents au service de plus d'1 million bénéficiaires du régime général, soit 89% de la population ; 12 agences et 6 permanences de proximité, soit 500 000 personnes reçues chaque année ; 1 plate-forme de service téléphonique qui traite dans l'année plus de 600 000 appels ; 1 site Internet local d'informations et de service (230 000 connections par an) ; Plus de 23 millions d'opérations de paiement traitées chaque année, soit environ 90 000 opérations par jour ; 2,6 milliards d'euros de dépenses remboursées en 1 an, soit 2 100 euros par personne protégée et par an ;
Page 4 sur 35 Coût de gestion inférieur à 3% des dépenses. 3 - L Informatique Locale Pour gérer les équipements matériels et logiciels des agents des caisses de la Haute- Garonne, un service de gestion d informatique local a été mis en place : le SESI (Service d Etude et de Suivi Informatique). Ce service se décompose comme suit : DGAI Marie-Pierre BARDIN DI Didier PELLUARD SESI Liliane LELIEVRE-ZAMORA Maintenance Dominique LETOUZEY Réseau Infor. Locale Brice JONES Appli. Production Interne Evelyne MATHIEU Réseau Développement Le RIL est constitué de deux équipes : une équipe en charge du réseau (matériel et administration des droits), et l autre en charge des développements. C est avec cette dernière que nous avons entamé un travail de refonte méthodologique. 4 - Le projet de refonte méthodologique La CNAM a publié une méthode de développement interne officielle, de type «cycle en V». Cette méthodologie nécessite la production de nombreux documents formels, et il s est avéré qu elle n était que partiellement appliquée aux différents projets, et de façon très différente. Un groupe de travail a donc été mis en place pour repenser la méthodologie de développement et l unifier pour tous les développeurs. C est dans le cadre de ce groupe de travail que j ai effectué mon stage.
Page 5 sur 35 II - Analyse de la situation La première phase de mon stage a été dédiée à l analyse de la situation actuelle, pour identifier les facteurs favorables et défavorables aux différents types de méthodologies. 1 - Méthodologie officielle La méthodologie officielle a été produite par la CNAM (caisse nationale). Elle est dérivée d un «cycle en V» et intègre des spécificités propres à l organisation des caisses d assurance maladie. Voici un schéma représentant une vue macroscopique de la méthodologie : Formalisation du besoin Expression du besoin Evaluation du besoin Bilan d évaluation PV Approbation du besoin Analyse Réalisation Cahier des charges Règles de conception de l IL PV Approbation Cahier des charges Opérations de maintenance pouvant entraîner une reprise du processus Test Généralisation Manuel d exploitation et d administration PV de validation définitive Manuel utilisateur Support Une telle méthodologie est intéressante dans le cadre de projets de grande envergure, impliquant plusieurs dizaines de personnes. Le formalisme poussé permet ainsi d assurer une bonne communication entre les différents acteurs. Mais il n en demeure pas moins que le phénomène de l «effet tunnel» reste présent : l application étant développée d un seul coup, on ne peut apprécier le logiciel qu en fin de processus. On sait bien aujourd hui que des changements parfois importants surviennent dans l expression des besoins une fois que le client peut tester le logiciel produit. L ambiguïté de l écrit, dû à des cultures différentes entre le client et le fournisseur, provoque également des incompréhensions. Les projets menés dans le RIL sont de petite envergure, et généralement menés par un ou deux développeurs. Ce type de méthodologie est par conséquent peu adapté dans ce cas. Il est donc plus intéressant de s orienter vers des méthodes de type «Agile», très bien adaptées à des petites équipes. Mais avant d entreprendre la mise en œ uvre d une telle méthode, il est indispensable d évaluer l adéquation du contexte avec les concepts Agiles.
Page 6 sur 35 2 - Interviews L utilisation d interviews individuelles permet d obtenir différentes visions sur l approche méthodologique d un projet. Deux points de vue m ont semblés essentiels : celui des développeurs sur le terrain, et celui de la direction plus macroscopique. a - Développeurs Les interviews des développeurs ont été réalisées sur la base d un questionnaire simple : Quelle est votre démarche personnelle pour réaliser un projet (organisation, méthodologie, documentation, etc.)? Quels sont les projets sur lesquels vous avez travaillé? Pour chacun, quelles sont les difficultés rencontrées? Quelles sont vos remarques? Une fois ces données collectées, j ai dressé un bilan pour chaque développeur, puis pour l ensemble des développeurs. b - Direction Les interviews de la direction ont été réalisées à partir d un questionnaire plus élaboré : Quelles sont vos missions vis-à-vis de l informatique locale? Quelles sont vos attentes envers le RIL? Quelles sont les métriques que vous souhaiteriez posséder sur le RIL? Quels sont les artefacts que vous souhaiteriez posséder venant du RIL? De la même manière, les données collectées ont été synthétisées pour chaque personne interrogée, puis de façon globale. 3 - Groupe de travail A partir des problèmes recensés dans les interviews, nous avons discuté des solutions possibles pendant une séance organisée en groupe de travail. Ce type de séance est inspiré des concepts de «management collaboratif» : impliquer les intervenants en les faisant réfléchir aux solutions, tout en fournissant des éléments-clés sur la solution finale qui sera adoptée. Ici, l idée était d introduire des éléments des méthodes Agiles comme réponse aux problèmes identifiés. 4 - Bilan a - Attentes des développeurs La synthèse des interviews des développeurs a mis en évidence les problèmes classiques liés à l utilisation d une méthodologie de type «cascade». Voici les attentes exprimées :
Page 7 sur 35 Améliorer la gestion des besoins : - Dialoguer avec les bons interlocuteurs - Mieux recenser et comprendre les besoins des demandeurs - Montrer régulièrement des maquettes pour révéler les besoins cachés des demandeurs - Faire tester plus efficacement aux utilisateurs Améliorer la gestion des projets : - Canaliser les demandes de projet - Travailler en équipes de taille suffisante pour éviter les problèmes de congés et partager les connaissances - Produire de la documentation utile - Canaliser et réduire les opérations de maintenance. Produire des FAQ types sur les problèmes avec les applications. b - Attentes de la direction La synthèse des interviews de direction a révélé ses principales attentes. Ces attentes correspondent aux critères traditionnels demandés par les entités dirigeantes d une organisation : Disposer d un suivi d avancement : - Visibilité sur chaque projet - Gestion des priorités des projets - Analyse de la pertinence des projets demandés - Artefacts de validation des étapes du projet Assurer la qualité du service - Rapidité des développements - Systèmes fiables et sécurisés - Indicateurs de performance Démarche de validation - Respecter une démarche de validation officielle
Page 8 sur 35 c - Risques identifiés L adoption d une méthodologie ne se limite pas seulement à l application d un processus, elle nécessite aussi une organisation et un environnement adaptés. Aussi, j ai classé les problèmes identifiés et les risques qu ils comportent dans deux catégories : risques méthodologiques et risques organisationnels. Les tableaux ci-dessous dressent la liste des risques identifiés pour chaque catégorie. Je n ai pas pondéré ces risques car ils étaient tous de la même importance à mon sens.
Page 9 sur 35 Risques organisationnels Famille Problème Risques Projets individuels ou par 2 maximum - Connaissance du projet centralisée sur une personne - Compétences acquises par une seule personne Projets Environnement Maintenance 4 à 5 projets simultanés par personne Pas de vérification de l'existant au lancement d'un projet Tous les projets sont urgents! Appels téléphoniques incessants, pour des raisons souvent futiles Hotline inefficace : transfère les problèmes sans vrai diagnostic, alors qu'ils s'agit souvent de droits d'accès ou de configuration système / réseau. Bureaux séparés Bureaux mal rangés Interruptions très fréquentes des projets pour des opérations de maintenance urgentes Utilisateurs peu expérimentés en informatique, ne testent pas ou testent mal Administration des bases de données non attribuée à temps plein sur une personne - Priorités des projets changeantes - Perte de temps due au changement de contexte fréquent - Perte de productivité sur tous les projets - Redondance de bases de données - Redondance de fonctionnalités - Interruptions fréquentes d'un projet pour un autre - Perte de temps due au changement de contexte fréquent - Perte de qualité du travail - Développeurs interrompus trop souvent - Perte de concentration - Perte de temps due au changement de contexte fréquent - Perte importante de productivité - Diagnostic d'erreur faite par les développeurs : perte de temps - Perte de temps due au changement de contexte fréquent - Communication plus difficile dans l'équipe - Moins d'esprit d'équipe - Conditions de travail désagréables - Perte de temps à chercher des documents - Documents obsolètes - Perte de temps due au changement de contexte fréquent - Perte de temps pour des corrections mineures qui peuvent être reportées à 90% des cas à la fin du projet courant - Nombreuses évolutions demandées - Nombreux bugs découverts après la livraison - Modifications ouvertes à tous - Aucun responsable en cas de problème - Aucune personne à qui se référer en cas de problème
Page 10 sur 35 Risques méthodologiques Famille Problème Risques Méthode Méthode actuelle anarchique, souvent de type cascade - Effet tunnel pour les utilisateurs - Planification mal évaluée - Estimations mal évaluées - Produit final non conforme aux vrais besoins des utilisateurs Besoins Planification et Estimation Besoins mal exprimés / mal compris Besoins changeants Utilisateurs finaux masqués par leur chef de service qui ne veut pas les libérer Besoins recueillis auprès des mauvais utilisateurs Pas de planification efficace Estimations rarement faites, et si c'est le cas en jours-hommes Avancement du projet interrompu très souvent par des opérations de maintenance - Cahier des charges peu clair et interprété différemment - Produit livré ne répond pas aux attentes initiales des utilisateurs - Maintenance évolutive importante après la livraison - Prise en compte très tardive dans le projet - Maintenance évolutive importante après la livraison - Besoins exprimés en désaccord avec les vrais besoins des utilisateurs - Nombreuses modifications demandées après la livraison - Produit livré ne répond pas aux attentes initiales des utilisateurs - Maintenance évolutive importante après la livraison - Délais non respectés - Gestion du projet chaotique - Difficulté à estimer - Pertinence des estimations - Délais non respectés - Gestion du projet chaotique 5 - Présentation des méthodes Agiles Vous pourrez trouver une présentation générale des principes et méthodes Agiles dans l annexe «Support de formation : Processus et pratiques Agiles». 6 - Les réponses «Agiles» a - Propositions d amélioration L utilisation d une méthode «Agile» permet de pallier à la plupart de ces risques de façon efficace. Voici les solutions proposées aux différents problèmes, toujours classés par catégorie.
Page 11 sur 35 Risques organisationnels Famille Problème Solution Agile Bénéfices attendus Projets Environnement Maintenance Projets individuels ou par 2 maximum 4 à 5 projets simultanés par personne Pas de vérification de l'existant au lancement d'un projet Tous les projets sont urgents! Appels téléphoniques incessants, pour des raisons souvent futiles Hotline inefficace : transfère les problèmes sans vrai diagnostic. Bureaux séparés Bureaux mal rangés Interruptions très fréquentes des projets pour des opérations de maintenance urgentes Utilisateurs peu expérimentés en informatique, ne testent pas ou testent mal Travail en deux équipes de 4 personnes Un seul projet à la fois pour l'équipe Référencer tous les projets avec les fonctionnalités implémentées et les schémas de données On n'interrompt jamais un projet en cours Filtrer les appels vers l'équipe par un seul point d'entrée : le ScrumMaster Isoler l'équipe des problèmes de Hotline, ne lui transférer que des appels justifiés et diagnostiqués Tous les membres de l'équipe sont dans la même pièce, isolée et calme Pièce bien rangée, cadre agréable - Interdire l'interruption d'un projet (recenser les opérations demandées et les réaliser après la fin du projet en cours, avant d'entamer le projet suivant) - Evaluer finement l'urgence de la modification demandée (très souvent urgent sans l'être vraiment) - Les utilisateurs font partie de l'équipe et testent souvent - Identification de rôles utilisateurs plutôt que de personnes - Connaissance commune du projet - Compétences acquises par toute l'équipe - Projets aboutis rapidement - Enchaînement des projets rapide - Développeurs au maximum de leur productivité - Plus de redondances inutiles Idem ci-dessus - Seuls les appels vraiment importants sont transmis - Meilleure concentration de l'équipe - Développeurs au maximum de leur productivité Idem ci-dessus - Meilleure concentration - Meilleure communication - Esprit de groupe solidaire - Résolution rapide des problèmes - Bien-être des développeurs - Meilleure productivité - Meilleure ambiance - Documentation efficace - Continuité du projet - Meilleure productivité - Intervention seulement dans les vrais cas d'urgence - Les tests peuvent être guidés dans un premier temps par l'équipe - Un utilisateur ne teste que les fonctions qui le concernent, pas toute l'application (donc tests mieux ciblés) Risques méthodologiques Famille Problème Solution Agile Bénéfices attendus
Page 12 sur 35 Méthode Besoins Planification et Estimation Méthode actuelle anarchique, souvent de type cascade Besoins mal exprimés / mal compris Besoins changeants Utilisateurs finaux masqués par leur chef de service qui ne veut pas les libérer Besoins recueillis auprès des mauvais utilisateurs Pas de planification efficace Estimations rarement faites, et si c'est le cas en jours-hommes Avancement du projet interrompu très souvent par des opérations de maintenance Passer à une méthode Agile (Scrum, XP) Utiliser des User Stories Utiliser des User Stories priorisées Identifier des rôles utilisateurs et un représentant de chaque rôle Utiliser des rôles utilisateurs Planification agile en deux étapes : - Sur une release (vélocité) - Sur chaque sprint (reste à faire) - Estimations en points pour les fonctionnalités - Estimations en reste à faire sur les tâches dans un sprint Isolement complet de l'équipe, interdiction d'interrompre un sprint en cours ou un projet en cours. - Démarche itérative, pas d'effet tunnel - Planification intelligente - Estimations meilleures et qui s'améliorent - Produit final très proche des besoins utilisateur - Qualité du produit améliorée - Productivité très augmentée - Compréhension partielle dans un premier temps, puis explication orale au moment de l'implémentation, donc bien comprise - Fonctionnalités raffinées, petites, simples à comprendre et estimer - A chaque sprint, choix des US réalisées - L'ordre et les US peuvent changer avant d'attaquer un nouveau sprint (sans impacter le sprint courant) - Plus grande pertinence des besoins car localisés à des rôles donc plus précis - Les besoins sont exprimés par rôles donc mieux appréhendés - Plusieurs points de vue sur l'application - Logiciel fourni en accord avec les vrais besoins de tous les utilisateurs - Pertinence de la planification par retour d'expérience rapide et fiable au niveau release - Avancement apparent sur chaque sprint (reste à faire qui diminue, donnée fiable) - Visibilité excellente sur le projet - Estimation relative sur les fonctionnalités : plus facile, plus fiable - Reste à faire facile à estimer et à mettre à jour - Retour d'expérience sur les estimations rapide et fiable - Raffinement des estimations rapide - Visibilité excellente sur le projet - Continuité du projet - Opérations reportées en fin de projet et traitées efficacement - Meilleure productivité de l'équipe
Page 13 sur 35 b - Adéquation à l Agilité Après la récupération de tous ces éléments, j ai dressé un bilan d adéquation à l Agilité sous forme de présentation PowerPoint. Ce bilan présentait plusieurs métriques permettant d évaluer le niveau d adéquation du contexte du RIL avec les méthodes Agiles. Voici la liste des critères avec le niveau d adéquation pour chacun : Evaluation organisationnelle - Taille de l équipe Une équipe de petite taille est bien adaptée - Criticité des applications Les logiciels non critiques sont bien adaptés - Criticité de la maintenance La maintenance non critique est bien adaptée - Qualité de l environnement Un environnement calme et sain est favorable Evaluation méthodologique - Dynamisme du contexte Les besoins peuvent changer souvent - Culture des développeurs Savoir-faires suffisants et diffusion - Analyse des besoins Besoins bien compris / bien exprimés - Planification et Estimation Planification efficace, estimations pertinentes - Gestion de projet Visibilité et gestion efficaces Comme on peut le voir, le domaine organisationnel pose davantage de problèmes que le domaine méthodologique, ce qui nous amenés à focaliser les premières actions sur ce domaine.
Page 14 sur 35 III - Mise en place du projet pilote 1 - La nécessité d un «pilote» La CNAM (Caisse Nationale d Assurance Maladie) a proposé une méthodologie de type «Cycle en V», qui se prête bien à un contexte où les démarches sont conçues sur le schéma «Demande Analyse Production Validation». Le passage à une méthode Agile implique un passage rapide à la production, et un engagement empirique sur les besoins et les délais. Cette conception implique beaucoup de changements dans la façon de gérer les projets. Aussi pour obtenir l aval de la direction, il était indispensable de mettre en place un projet «pilote», dont les résultats serviront à prouver les bienfaits d une approche Agile. 2 - Actions préparatoires Dès le début du stage, et jusqu au lancement du projet pilote, j ai effectué un travail très actif d autoformation sur les méthodes et techniques Agiles, afin de pouvoir répondre au mieux aux problèmes et questions qui me seraient exposés. J ai pour cela utilisé de nombreuses sources sur Internet : sites spécialisés, listes de mailing, etc. Avant de lancer le projet pilote, il était indispensable de faire en sorte que l environnement organisationnel soit favorable. Nous avons donc mené des actions sur ce domaine en priorité : Rangement et nettoyage des bureaux : cela n avait pas été fait depuis 20 ans Environ 2 mètres cubes de vieille documentation et vieux livres ont été jetés Mise en place d un nouveau processus de prise en compte des opérations de maintenance, incluant la mise en place du bugtracker «Gemini» :
Page 15 sur 35 Réorganisation des bureaux : pour améliorer la communication au sein d une équipe, il est préférable qu elle se situe dans la même pièce. Un projet de réaménagement des bureaux a été lancé pour rassembler les deux équipes dans deux pièces dédiées. Chacune de ces pièces sera également équipée d un tableau blanc. 3 - Choix de la méthodologie a - Les alternatives principales Dans la famille «Agile», deux méthodes sortent du lot pour leurs qualités : XP et Scrum. Ce sont à la fois les plus souples et les plus efficaces, et sont très éprouvées aujourd hui. Nous nous sommes donc posé la question du choix de la méthode. Scrum est plus orientée sur la gestion de projet, et fournit un ensemble de pratiques de base qui laissent volontairement le libre choix des techniques de développement. XP possède à peu près la même organisation de base que Scrum, mais propose des pratiques plus précises : l utilisation des «User Stories» pour la gestion des besoins, et du développement guidé par les tests (TDD Test Driven Development) à l intérieur de chaque itération. b - Le choix de la méthode «Scrum» La pratique du développement guidé par les tests étant relativement difficile à mettre en œ uvre, nous avons choisi de commencer à utiliser Scrum, en y intégrant quelques pratiques de XP (User Stories, Planning Poker). Une fois mis en place et stabilisé, il sera
Page 16 sur 35 intéressant d intégrer les pratiques TDD comme facteur d amélioration de la qualité des logiciels produits. Scrum mentionne qu on n interrompt jamais l équipe pendant une itération. Pour pouvoir traiter quand même les opérations de maintenance fréquentes, nous avons aménagé le processus en intercalant entre chaque itération une période courte dédiée à la maintenance. Pour gérer efficacement les demandes, nous avons également déployé un bugtracker du nom de Gemini. Release Phases de maintenance très courtes, pour traiter les urgences survenues pendant le sprint Sprint Sprint Sprint Sprint 4 - Choix du projet a - Alternatives La question du choix du projet pilote s est ensuite posée à nous. Un nouveau projet devait justement démarrer au moment du lancement du projet pilote. Son inconvénient était simplement d être relativement petit, et réalisé par une seule personne en un mois environ. Mais en même temps, une réorganisation des structures hiérarchiques de la caisse a entraîné que la base de données centrale des agents de la caisse, partagée entre toutes les applications, ne pouvait plus accueillir la nouvelle organisation. Il devenait donc urgent de reconstruire cette base de données et les applications qui en géraient les données. Ce projet a donc été choisi comme projet pilote. C était l occasion idéale d apporter quelques améliorations à l existant : Implémentation d une couche d objets métier pour accéder et manipuler les données, au lieu d'utiliser des requêtes SQL. Unification de l interface d administration des données : remplacer les 3 applications indépendantes en une seule, dont l interface intègre une gestion des droits d accès pour filtrer les actions possibles. Amélioration de l ergonomie de l interface Il présente les intérêts suivants : Critique et urgent Utilisation de Scrum pour gérer des développements «techniques» Utilisation de Scrum pour gérer des développements «logiciels»
Page 17 sur 35 Les trois applications seront réécrites successivement. Ainsi les deux dernières seront considérées comme des évolutions de la première, comme des évolutions des besoins. b - Difficultés Néanmoins, ce projet présente des difficultés non négligeables : La réalisation d une couche d objets métier ne permet pas facilement l élaboration d une liste de besoins dont la réalisation est mesurable. L interface d administration des données ne possède pas réellement d utilisateurs demandeurs. En effet, la gestion des données des agents a été confiée à certains agents pour permettre le bon fonctionnement des applications internes. Pour pallier au second problème, nous avons demandé à des responsables des Ressources Humaines de bien vouloir prendre part au projet pilote en tant que demandeurs. 5 - Structuration de l équipe Le fonctionnement nominal du service permettait la réalisation simultanée de nombreux projets. Il n était donc pas possible de mobiliser l intégralité du service sur deux projets seulement. Nous avons donc fait le choix de constituer une équipe pilote, à temps plein sur un unique projet, alors que le reste des développeurs poursuivait un fonctionnement habituel. Pour constituer l équipe pilote, nous avons retenu les 4 personnes qui avaient le plus travaillé ensemble par le passé, et qui avaient obtenu de bons résultats. Une fois le projet pilote terminé, cette équipe serait scindée en deux binômes, qui formeraient ensuite les deux équipes finales de 4. 6 - Planification de la migration a - Structure du projet De par la nature du projet pilote, nous avons identifié deux phases du projet, qui correspondent à deux releases possibles : une première phase dite «technique» dont le but est de construire la couche d objets métier, et une deuxième dite «logicielle» dont le but est de construire les logiciels de gestion des données. La phase logicielle est structurée comme suit : Une release qui regroupe le re-développement et l unification de deux des logiciels (TABLE-IL et MAJANNU) sur la nouvelle couche objet Une release dédiée au re-développement du troisième logiciel (GEDAM). Cette dernière est conditionnée par l arrivée prochaine d une application nationale équivalente, mais peut-être pas suffisante.
Page 18 sur 35 b - Planning Avril Mai Juin Analyse de la situation ( + Autoformation ) Formation Lancement Phase technique Sprint 1 Phase technique Sprint 2 Juillet Août Septembre+ ( Sprint 2 ) Maintenance Phase logicielle Sprint 1 Phase logicielle Sprint 2 Maintenance Phase logicielle Sprint 3 Généralisation? Ce planning est légèrement différent ce qui était prévu. En effet, la phase technique ne devait durer qu un seul sprint, mais des difficultés cachées ont obligé à la prolonger d un sprint complémentaire. 7 - Positionnement personnel a - Analyse La première mission qui m a été confiée a en fait été celle d un «consultant» : il s agissait d identifier les points faibles dans l organisation et de proposer des améliorations. Bien que ne bénéficiant que de peu d expérience professionnelle, la forte composante en génie logiciel de la formation ISI m a permis de discerner rapidement les problèmes classiques. L autoformation aux méthodes Agiles m a également donné une vision nouvelle sur d autres problèmes méthodologiques. b - Formation En force de proposition, j ai donc été chargé d apporter mes connaissances en terme de méthodes Agiles. Ces connaissances ont été synthétisées depuis de nombreux documents Internet, en y apportant mes propres points de vue. La formation que j ai dispensée s est décomposée en 3 présentations : Processus et Pratiques Agiles (1/2 journée) : Qu est-ce que «Agile»? Les processus Agiles, Les pratiques Agiles. Scrum (1/2 journée) : Agilité, Concepts, De A à Z, Jeu de rôles
Page 19 sur 35 Gestion Agile des besoins (1/2 journée) : De l étude des besoins aux «User Stories», Clients/Utilisateurs, Récolter les besoins, Estimer les User Stories, Prioriser les User Stories. c - Coaching Comme une formation ponctuelle ne permet de retenir que l essentiel, il était important d être présent «sur le terrain» pour intervenir au bon moment et rappeler les concepts et les pratiques de la nouvelle méthodologie. J ai donc encadré au quotidien l équipe pilote dans cette optique. d - Aide à la formation Les méthodes Agiles sont encore très peu connues en France, et les pratiques qu elles proposent sortent du cadre des projets traditionnels. Il est donc indispensable pour une équipe Agile d expliquer aux demandeurs et à sa hiérarchie quelles sont ses pratiques, pourquoi elle les adopte, et comment ils vont travailler ensemble. J ai donc produit un premier support destiné aux services demandeurs, qui devrait être présenté en amont de chaque projet. Il a pour but de leur faire comprendre les concepts des méthodes Agiles, de leur apprendre à gérer efficacement les utilisateurs, les besoins, le suivi de leur réalisation, et enfin de maîtriser leurs missions pour garantir le succès du projet. J avais planifié de réaliser un support destiné à la hiérarchie, s appuyant sur les résultats du projet pilote pour leur prouver l efficacité d une méthode Agile, mais ce dernier ayant pris beaucoup trop de retard, je n ai donc pas réalisé cette présentation. e - Outils de support Une bonne méthode est moins appréciable si elle n est pas accompagnée d un bon outil. Aussi j ai assuré la mise en place d un outil de support à la méthode Scrum : IceScrum. Je l ai configuré, déployé, et j ai assuré une formation à son utilisation à l équipe pilote. Cet outil libre et open source a été développé lors du bureau d études de mon année de Master I à l IUP. Son développement a été ensuite poursuivi par Cédric Laurens (étudiant de Licence III du BE), pendant son stage, simultanément au mien. Des versions successives ont donc été publiées, et je me suis occupé de les déployer sur les postes de l équipe. Il m a fallu également assurer la migration des données d une version sur l autre. Nous avons également souhaité héberger ces données sur un serveur Microsoft SQL Server central, IceScrum étant normalement prévu pour fonctionner avec la plupart des SGBD courants. Malheureusement, il s est avéré qu aucun pilote JDBC ne fonctionnait avec IceScrum pour SQL Server. Nous avons donc installé une instance de MySQL sur un système sauvegardé. f - Assistance en ergonomie des applications Les développeurs du RIL ont eux-mêmes manifesté leurs difficultés avec l ergonomie des logiciels. Aussi il m a semblé pertinent de leur présenter le SNI (Schéma Navigationnel d Interface), qui permet de modéliser l interface d une application du point de vue ergonomique.
Page 20 sur 35 J ai donc assuré une formation rapide sur la modélisation à l aide du SNI, montré les exemples de mes stages précédents, et guidé sa mise en pratique sur le projet pilote.
Page 21 sur 35 IV - Déroulement du projet pilote Thème L utilisation d IceScrum a permis de conserver un historique de la réalisation du projet pilote. 1 - Backlog du produit Le backlog du produit référence toutes les fonctionnalités que devra implémenter le logiciel. Il est présenté ici dans l ordre de priorités définies par le client, et avec les estimations de l équipe. Item Points Estimés Couche métier Définir les règles de gestion (métier + droits d'accès des applis) pour la manipulation des objets 2 Couche métier Le développeur veut accéder à des objets hiérarchiques 5 Couche métier Définir une gestion des verrous 2 Couche métier Le développeur veut accéder à des objets "simples" 3 Couche métier Le développeur veut accéder à des objets par liste multicritères 1 Couche métier Implémenter la gestion des rôles et droits d'accès 1 Couche métier Le Responsable peut déléguer ses droits à ses subordonnés 1 Couche métier Un Administrateur des délégations peut changer les délégations d'un cadre 1 Un Agent arrive Le Gestionnaire Administrateur du Personnel crée l'agent 2 Un Agent arrive Le Gestionnaire Administrateur du Personne Externe crée l'agent externe 1 Un Agent arrive Informer automatiquement le responsable du service de l'agent créé 1 Gestion de la compatibilité Le développeur veut garder une compatibilité avec l'ancienne base ascendante CPAM31 5 Couche métier Implémenter un système de trace des actions sur la BD 1 Un Agent arrive Implémenter la récupération automatique des compléments d'infos sur l agent 0 Couche métier Implémenter une gestion d'erreurs basée sur Gemini 3 Les Entités Organisationnelles Le RH propose d'unifier la terminologie des entités organisationnelles (EO) 0 Les Entités Organisationnelles Une EO st typée (unité, secteur, service, pôle, direction, département) 0 Un Agent bouge Un agent tout type de contrat peut revenir en CDD ou en CDI 2 Un Agent bouge Un agent externe change de n GDP s'il rentre dans l'organisme 1 Un Agent bouge Un gestionnaire ADP affecte un agent à une EO 1 Un Agent bouge Un gestionnaire ADP consulte l'historique agent 1 Un Agent arrive Le responsable du service de l'agent créé complète ses informations 2 Un Agent bouge Un gestionnaire ADP recherche un agent dans l'historique 1 Un Agent bouge Informer automatiquement le responsable quand l'agent change EO 1 Un Agent bouge Informer automatiquement le responsable quand l'agent change Nom 1 Un Agent bouge Le responsable change l'affectation de son agent à une EO 1 Un Agent bouge Le responsable change l'affectation de son agent à une EG 1 Un Agent bouge Le responsable change l'affectation de son agent à une donnée complémentaire 1 Un Agent bouge Un gestionnaire ADP positionne une date de départ 1 Un Agent bouge Le gestionnaire ADP gère le prêt d'agent inter service 0 Un Agent bouge Le gestionnaire ADP gère l'agent absent en longue durée 2 Les Entités Organisationnelles Le responsable dispose d'une délégation administrativement sur son EO 2 Un Agent bouge Si le n GDP change, il faut conserver l'historique 1
Page 22 sur 35 Les Entités Géographiques Une salle (sans agent affecté) peut avoir un n de téléphone 1 Les Entités Organisationnelles Tout le monde affiche l'organigramme 3 Les Entités Organisationnelles Le gestionnaire EO crée une EO 1 Les Entités Organisationnelles Le gestionnaire EO déplace une EO 1 Les Entités Organisationnelles Le gestionnaire EO met à jour une EO 1 Les Entités Organisationnelles Le gestionnaire EO supprime une EO 1 Les Entités Géographiques Le gestionnaire Immobilier crée une EG 1 Les Entités Géographiques Le gestionnaire Immobilier renomme une EG 1 Les Entités Géographiques Le gestionnaire Immobilier supprime une EG 1 Les Entités Géographiques Le responsable affecte un agent à une EG 1 Les Entités Géographiques Le gestionnaire Immobilier déplace une EG 1 Les Entités Organisationnelles Le développeur utilise un arbre hiérarchique 2 Thème Certains éléments sont estimés à 0 points. Il s agit de contraintes non fonctionnelles, ou d éléments dont l estimation dépend d un contexte technique non connu pour l instant. 2 - Déroulement des sprints a - Sprint 1 Items du backlog réalisés : Item Couche métier Le développeur veut accéder à des objets hiérarchiques 5 Burndown chart du sprint : Vélocité : 5 Points Estimés
Page 23 sur 35 Thème On voit ici que les donnés du sprint ont été saisies en milieu de sprint. Cela s explique par les difficultés rencontrées lors du déploiement de l outil IceScrum. Toutes les tâches n ont pas pu être réalisées pendant ce sprint. b - Sprint 2 Items du backlog réalisés : Item Points Estimés Couche métier Définir les règles de gestion (métier + droits d'accès des applis) pour la manipulation des objets 2 Couche métier Définir une gestion des verrous 2 Couche métier Le développeur veut accéder à des objets "simples" 3 Burndown chart du sprint : Vélocité : 7 Thème Sur ce graphique, on peut voir d abord un plateau, puis un pic. Il s agit tout simplement de la saisie des informations qui n a pas été faite correctement. Les véritables données ont été fournies en milieu de sprint. c - Sprint 3 Items du backlog réalisés : Item Couche métier Le développeur veut accéder à des objets par liste multicritères 1 Couche métier Implémenter la gestion des rôles et droits d'accès 1 Points Estimés
Page 24 sur 35 Couche métier Le Responsable peut déléguer ses droits à ses subordonnés 1 Couche métier Un Administrateur des délégations peut changer les délégations d'un cadre 1 Burndown chart du sprint : Vélocité : 4 Thème Ce graphique est intéressant, puisqu il révèle plusieurs choses : la faible fréquence des mises à jour dans l outil d une part, et une sous-estimation initiale du reste à faire d autre part, puisqu il augmente brutalement en fin de sprint (cela ne correspond pas à l ajout d une User Story dans les objectifs du sprint). d - Sprint 4 Items du backlog de produit : Item Les Entités Organisationnelles Le gestionnaire EO crée une EO 1 Les Entités Organisationnelles Le gestionnaire EO déplace une EO 1 Les Entités Organisationnelles Le gestionnaire EO met à jour une EO 1 Les Entités Organisationnelles Le gestionnaire EO supprime une EO 1 Les Entités Organisationnelles Le développeur utilise un arbre hiérarchique 2 Vélocité estimée : 6 Points Estimés
Page 25 sur 35 3 - Vélocité moyenne de l équipe La vélocité moyenne de l équipe est de 5,33 entre avril et août. Cette vélocité est à pondérer avec le fait que les congés ont diminué l effectif de l équipe de moitié en moyenne. Pour estimer la planification du projet à partir de septembre (effectifs complets), nous avons donc estimé que la vélocité serait de 9. 4 - Statistiques des releases a - Phase «technique» Burndown Chart de la release "Phase logicielle" 7 6 5 4 Points 3 Vélocité Reste à faire 2 1 0 1 2 Sprints
Page 26 sur 35 b - Phase «logicielle» Burndown Chart de la release "Phase logicielle" 50 45 40 35 30 Points 25 20 15 Vélocité Reste à faire 10 5 0 1 2 3 4 5 6 7 Sprints Sur ce graphique, les deux premiers sprints sont constatés (vélocité de 5,33). Les suivants sont estimés par rapport à la nouvelle vélocité (9).
Page 27 sur 35 V - Bilan du stage L objectif de ce chapitre est d établir un bilan du projet du point de vue de l entreprise et du point de vue personnel. 1 - Bilan professionnel a - Préparation Les actions de préparation du projet pilote ont été efficaces. En effet, les bureaux sont mieux rangés, créant ainsi une atmosphère plus agréable, et surtout facilitant l accès efficace aux documentations. La canalisation de la maintenance a permis de minimiser les irruptions dans la pièce de l équipe de développement, ainsi que les appels téléphoniques. C est aussi un contexte qui favorise un travail efficace dans de bonnes conditions. Le réaménagement des bureaux est toujours à l étude. Il sera probablement nécessaire de faire déplacer des cloisons amovibles, et cela requiert l appréciation et l intervention des personnes qualifiées dans ce domaine. b - Formation Le travail de préparation d une formation a été pour moi quelque chose de nouveau, et relativement difficile. Même si je me suis beaucoup inspiré de la documentation trouvée sur Internet, j ai travaillé attentivement le contenu et le plan pour être sûr qu ils soient pertinents. C est un travail fastidieux. c - Objectifs atteints et restants Problème Solution Agile Bénéfices attendus Bénéfices constatés Projets individuels ou par 2 maximum 4 à 5 projets simultanés par personne Pas de vérification de l'existant au lancement d'un projet Tous les projets sont urgents! Appels téléphoniques incessants, pour des raisons souvent futiles Travail en deux équipes de 4 personnes Un seul projet à la fois pour l'équipe Référencer tous les projets avec les fonctionnalités implémentées et les schémas de données On n'interrompt jamais un projet en cours Filtrer les appels vers l'équipe par un seul point d'entrée : le ScrumMaster - Connaissance commune du projet - Compétences acquises par toute l'équipe - Projets aboutis rapidement - Enchaînement des projets rapide - Développeurs au maximum de leur productivité Oui Oui Non : Retard du projet pilote Non Non : Congés d été - Plus de redondances inutiles? Pas de mesure disponible Idem ci-dessus - Seuls les appels vraiment importants sont transmis - Meilleure concentration de l'équipe - Développeurs au maximum de leur productivité Oui Non mis en application
Page 28 sur 35 Hotline inefficace : transfère les problèmes sans vrai diagnostic. Bureaux séparés Bureaux mal rangés Interruptions très fréquentes des projets pour des opérations de maintenance urgentes Utilisateurs peu expérimentés en informatique, ne testent pas ou testent mal Méthode actuelle anarchique, souvent de type cascade Besoins mal exprimés / mal compris Besoins changeants Utilisateurs finaux masqués par leur chef de service qui ne veut pas les libérer Isoler l'équipe des problèmes de Hotline, ne lui transférer que des appels justifiés et diagnostiqués Tous les membres de l'équipe sont dans la même pièce, isolée et calme Pièce bien rangée, cadre agréable - Interdire l'interruption d'un projet (recenser les opérations demandées et les réaliser après la fin du projet en cours, avant d'entamer le projet suivant) - Evaluer finement l'urgence de la modification demandée (très souvent urgent sans l'être vraiment) - Les utilisateurs font partie de l'équipe et testent souvent - Identification de rôles utilisateurs plutôt que de personnes Passer à une méthode Agile (Scrum, XP) Utiliser des User Stories Utiliser des User Stories priorisées Identifier des rôles utilisateurs et un représentant de chaque rôle - Seuls les appels vraiment importants sont transmis - Meilleure concentration de l'équipe - Développeurs au maximum de leur productivité - Meilleure concentration - Meilleure communication - Esprit de groupe solidaire - Résolution rapide des problèmes - Bien-être des développeurs - Meilleure productivité - Meilleure ambiance - Documentation efficace - Continuité du projet - Meilleure productivité - Intervention seulement dans les vrais cas d'urgence - Les tests peuvent être guidés dans un premier temps par l'équipe - Un utilisateur ne teste que les fonctions qui le concernent, pas toute l'application (donc tests mieux ciblés) - Démarche itérative, pas d'effet tunnel - Planification intelligente - Estimations meilleures et qui s'améliorent - Produit final très proche des besoins utilisateur - Qualité du produit améliorée - Productivité très augmentée - Compréhension partielle dans un premier temps, puis explication orale au moment de l'implémentation, donc bien comprise - Fonctionnalités raffinées, petites, simples à comprendre et estimer - A chaque sprint, choix des US réalisées - L'ordre et les US peuvent changer avant d'attaquer un nouveau sprint (sans impacter le sprint courant) - Plus grande pertinence des besoins car localisés à des rôles donc plus précis Oui Oui Oui? Pas encore mis en place Oui Oui Oui Oui Oui Oui Oui? Pas de mesure disponible Oui Oui Oui Oui Oui Non : Temps d adaptation Oui Oui Oui Oui Oui
Page 29 sur 35 Besoins recueillis auprès des mauvais utilisateurs Pas de planification efficace Estimations rarement faites, et si c'est le cas en jourshommes Avancement du projet interrompu très souvent par des opérations de maintenance Utiliser des rôles utilisateurs Planification agile en deux étapes : - Sur une release (vélocité) - Sur chaque sprint (reste à faire) - Estimations en points pour les fonctionnalités - Estimations en reste à faire sur les tâches dans un sprint Isolement complet de l'équipe, interdiction d'interrompre un sprint en cours ou un projet en cours. - Les besoins sont exprimés par rôles donc mieux appréhendés - Plusieurs points de vue sur l'application - Logiciel fourni en accord avec les vrais besoins de tous les utilisateurs - Pertinence de la planification par retour d'expérience rapide et fiable au niveau release - Avancement apparent sur chaque sprint (reste à faire qui diminue, donnée fiable) - Visibilité excellente sur le projet - Estimation relative sur les fonctionnalités : plus facile, plus fiable - Reste à faire facile à estimer et à mettre à jour - Retour d'expérience sur les estimations rapide et fiable - Raffinement des estimations rapide - Visibilité excellente sur le projet - Continuité du projet - Opérations reportées en fin de projet et traitées efficacement - Meilleure productivité de l'équipe Oui Oui? Pas de mesure disponible Oui Non : Saisie non régulière des données Oui Oui Oui Oui Oui Oui Oui Oui Oui d - Scénario envisagé La durée restante du projet pilote est estimée à 5 sprints de 3 semaines. Au terme de ce projet, indispensable pour le bon fonctionnement de la caisse, un bilan sera établi sur les apports de la méthode Scrum. S il est montré qu elle a permis un réel gain de productivité et de qualité, elle sera probablement généralisée à tous les développeurs. Il est également envisageable qu elle soit généralisée assez rapidement pour la tester en grandeur nature. e - Bénéfices La méthode Scrum a prouvé que ses principes fondamentaux apportent les avantages promis : Le développement itératif permet de donner un rythme au projet, et de livrer un logiciel qui fonctionne à intervalles réguliers. C est un atout tant pour le client, qui voit que le projet avance, que pour l équipe, qui voit qu elle avance de façon régulière. La forte collaboration avec les clients a permis de bien comprendre et interpréter les besoins, et également de faire exprimer aux clients des règles métier parfois complexes, ou des besoins cachés qui sont apparus de proche en proche avec les autres besoins.
Page 30 sur 35 L utilisation des User Stories a aussi été fructueuse en ce sens qu elles ont permis d exprimer les besoins de façon atomique, de les estimer plus facilement et de façon plus fiable. Les Scrums quotidiens permettent de faire le point et diffuser l avancement du travail, tout en identifiant les problèmes pour qu ils soient traités au plus vite. Enfin, outre la méthode Scrum, l utilisation d un SNI pour modéliser l interface de l application a été également bénéfique : Sa facilité de modélisation permet de concevoir une interface ergonomique rapidement, et engendre naturellement une bonne qualité de conception ; Une fois conçu, le modèle permet de produire l interface sans avoir à réfléchir à son contenu, ce qui permet d être plus efficace ; Enfin, sa lecture facile permet aux clients d avoir un aperçu de l interface de leur application. f - Difficultés Le projet pilote étant là pour tester la méthode Scrum, l équipe a normalement rencontré quelques difficultés : Le changement d habitudes de travail : utiliser un outil de suivi de projet, Scrums quotidiens, et travail en équipe ; Le travail en équipe : après plusieurs années passées à travailler seul ou en binôme, il faut réapprendre la répartition du travail et le respect de ce sur quoi on s engage vis-à-vis de l équipe ; Communication d équipe : la confrontation de points de vue à 4 est difficile, notamment avec les problèmes d affinités ; Le respect du concept de «timebox» : le manque d habitude de l équipe et des clients entraîne des réunions qui peuvent s étaler en longueur. Il a été difficile de les interrompre ou les raccourcir, car les propos des discussions étaient fondamentaux (identification de User Stories, explication des règles métier, etc.). Une des difficultés potentielles identifiées au lancement du projet, inhérentes à ses spécificités, s est confirmée dans la pratique : la difficulté dans l expression des besoins par les clients de la partie logicielle. En effet, comme expliqué précédemment, les clients n en sont pas vraiment, et nous leur avons demandé de bien vouloir jouer ce rôle. Un temps d adaptation a été nécessaire, mais après le premier sprint, ils se sont bien intégrés à leur rôle, et ont commencé à identifier des besoins intéressants. Tout cela a coûté plus de temps que ce à quoi on peut s attendre en temps normal.
Page 31 sur 35 2 - Bilan personnel a - Intérêts du stage Ce stage a présenté des intérêts certains. En effet, si mes précédents stages se situaient dans le domaine de la production de logiciel, celui-ci se situait dans le domaine du conseil. Cela a été pour moi l occasion de découvrir une autre approche du monde informatique, d acquérir quelques techniques rudimentaires, et de travailler mon regard critique sur les méthodes et les pratiques. La formation et l encadrement quotidien d une équipe de développeurs expérimentés ont été un véritable défi au niveau de la communication. Le fait d être encore scolarisé et en stage rend plus difficile l obtention de confiance et de crédibilité vis-à-vis de personnes d expérience. Découvrir les méthodes Agiles et les mettre en application en situation réelle m a permis également d apprendre plus à leur sujet : les promesses faites, les promesses tenues, les difficultés de mise en place, etc. b - Enseignements appliqués Bien que la dominante de ce stage soit les méthodes Agiles, on peut relier un certain nombre d enseignements dispensés pendant ma scolarité à l IUP ISI : Gestion des risques : prévoir, anticiper et prévenir les risques liés aux choix du projet pilote ; Méthodologie : analyser les atouts et faiblesses des méthodologies connues, pour avoir un regard critique pertinent sur les méthodes Agiles ; Schéma Navigationnel d Interface ; BE : première expérience de Scrum, et outillage de la méthode avec IceScrum ; c - Connaissances complémentaires J ai eu besoin pour ce stage d acquérir de nouvelles connaissances : Méthodes Agiles : un gros travail d autoformation a été nécessaire à l aide de documentation sur Internet fournie par des spécialistes du domaine ; Formation : produire un support de formation est quelque chose de difficile, et il m a fallu beaucoup de temps pour mettre au point ces supports, en m inspirant des enseignements dispensés à l IUP ; Enfin, accompagner une équipe au quotidien n est pas non plus quelque chose de simple. J ai pu apprendre beaucoup sur ce sujet. d - De l intérêt d un «blog» Si le blog s est popularisé pour servir de journal intime public, c est un outil professionnel puissant. En effet, il permet de dialoguer avec d autres professionnels sur des sujets métier d actualité. Les méthodes Agiles présentent donc un sujet de blog très intéressant.
Page 32 sur 35 C est pourquoi j ai décidé rapidement d ouvrir mon propre blog, d une part pour raconter l expérience de mon stage vis-à-vis des méthodes Agiles, et d autre part pour débattre de points de vue sur les différentes pratiques de ces méthodes. Les blogs, support de publication d articles, permettent aujourd hui d effectuer des «trackbacks» (ou «rétroliens»), qui consistent à publier un article sur son blog en réponse à un article d un autre blog. Ce mécanisme permet ainsi de créer des liens entre blogs et d entrer en contact avec d autres personnes. C est de cette façon que j ai eu la chance d être contacté par OCTO Technology, société de conseil en urbanisme et méthodologies à Paris, qui m a suggéré de déposer ma candidature chez eux. Je n ai malheureusement pas pu postuler du fait que je n avais pas terminé ma scolarité. e - Contributions au monde libre Ce stage a été aussi pour moi l occasion de contribuer au monde libre. J ai ainsi poursuivi ma contribution au développement du logiciel IceScrum, dans une mesure réduite du fait de mon activité du stage. Suite à la suggestion de Claude Aubry, j ai également réécrit l article Scrum dans Wikipedia, l encyclopédie libre d Internet. L article existant était plus ou moins la traduction d une publication ancienne des fondateurs de Scrum. Certains concepts exprimés dans cette publication ont depuis évolués, et il était nécessaire de remettre à plat l article et de le structurer comme un article encyclopédique. f - Objectifs personnels Au tout début du stage, je m étais donné comme objectif de réussir à faire migrer officiellement le service des développements internes vers des méthodes Agiles. Ce défi, très ambitieux, je n ai pas réussi à le relever complètement. Néanmoins, le projet pilote est bien mis en place, et la méthode a au moins convaincu l équipe pilote. Les autres développeurs n ayant pas pu encore l expérimenter, ils ne sont peut-être pas autant favorables. Pour l instant le projet pilote n a pas fourni assez d éléments pour présenter à la direction le projet de migration complète du service RIL. On peut espérer que d ici environ 4 mois, les éléments de retour du projet pilote permettront de déterminer de façon fiable si la méthode Scrum est applicable et intéressante pour le RIL. g - Projet professionnel Les stages successifs à l IUP ISI m ont permis de découvrir plusieurs approches des métiers de l informatique : le développement, la prise en main MOE et MOA d un projet, et cette année le conseil et la formation. Ma dernière année touchera le domaine de l IHM, où je découvrirais probablement encore une autre facette de l informatique. Il est donc difficile pour moi aujourd hui de savoir avec précision quel projet professionnel je peux envisager, mais j espère m être assuré de posséder un champ de connaissances suffisamment vaste pour pouvoir rebondir sur les opportunités qui se présenteront dans ma carrière.
Page 33 sur 35 Conclusion Les IUP ont fait le choix d intégrer dans leur cursus de nombreux stages en entreprise. Ce stage confirme une fois de plus la pertinence de ce choix de par ses qualités pédagogiques et professionnelles. Il a en effet été pour moi une expérience nouvelle, puisque j ai pu découvrir un nouveau contexte d entreprise. Il m a permis par ailleurs de consolider les connaissances théoriques et pratiques en matière de méthodologie, tout en étudiant des nouvelles alternatives aux méthodologies «classiques». Une analyse du terrain nous a orientés vers l utilisation d une méthode Agile : Scrum. Une telle méthode nécessite beaucoup de changements dans l organisation de l entreprise, et une nouvelle façon de voir un projet informatique. Tous ces éléments sont des risques d échec potentiels, et il est indispensable de faire le nécessaire pour les éviter ou les contrôler le cas échéant. Nous avons ainsi mis en place ensemble un projet pilote, dont l objectif était de mettre à l épreuve la méthode Scrum dans le contexte de l informatique locale. Ce projet n est pas encore terminé à l heure de la fin de mon stage, mais il a déjà permis une première évaluation de la méthode, et bien que quelques difficultés subsistent, il en ressort beaucoup de points positifs. Analyser une situation, discerner les problèmes, trouver des solutions tout en évaluant les risques liés aux changements requis, préparer et former, suivre, guider, sont autant de compétences nécessaires pour faire un travail efficace de conseil. J ai pu ainsi avoir un avant-goût du métier de consultant, me heurter aux difficultés de communication, aux préjugés, aux caractères, aux passés de personnes expérimentées, et aux longues heures de préparation d une formation. Si je ne peux aujourd hui avoir la prétention de devenir rapidement consultant, j ai découvert une nouvelle orientation possible pour mon futur, et ajouté une expérience riche à mon champ de connaissances. J espère que tout le travail que nous avons effectué aboutira au succès de la méthode Scrum, à sa généralisation à tous les développeurs, et à sa reconnaissance de la direction. Cela serait un pas supplémentaire dans la progression des méthodes Agiles en France, et placerait l informatique locale de la caisse de Toulouse comme un exemple d adaptation et d évolution, et comme un pionnier vis-à-vis des autres caisses d assurance maladie.
Page 34 sur 35 Glossaire et Acronymes Agile Backlog de produit Backlog de sprint Base de données Bug BugTracker CNAM CPAM Ergonomie IHM (Interface Homme Machine) Item de backlog Itération Méthode / Processus Release RIL Scrum SNI (Schéma Navigationnel d Interface) Sprint XP (extreme Programming) Nom d une famille de méthodes de développement de logiciels qui possèdent des caractéristiques communes particulières Liste des fonctionnalités que devra réaliser le logiciel une fois terminé Liste des tâches à faire par l équipe à l intérieur d un sprint Ensemble de fichiers permettant le stockage permanent de données, respectant un certain modèle propre à la nature de la base de données (relationnelle, objet, etc.). Faille du logiciel pouvant avoir de multiples raisons techniques. Outil permettant de recenser les bugs, les suivre et les affecter à des développeurs. Caisse Nationale d Assurance Maladie, qui régit toutes les caisses primaires Caisse Primaire d Assurance Maladie (ici, celle de Toulouse) Capacité d une interface entre un outil et un utilisateur à être facilement utilisable et interprétable. Désigne l ensemble des interfaces (virtuelles ou réelles) entre un utilisateur et une machine. Dans le cas d un logiciel, désigne à la fois les méthodes de saisie et la représentation visuelle à l utilisateur. Un élément dans un backlog Période de temps de quelques semaines au bout de laquelle est accomplie un ensemble d activités liées à la méthode utilisée Processus mis en œuvre pour concevoir, réaliser, et tester un logiciel. Période de temps au bout de laquelle est publiée une version de logiciel aboutie Réseau et Informatique Locale Méthode de développement faisant partie de la famille des méthodes Agiles Modèle permettant la modélisation de l interface utilisateur d un logiciel. Il a été mis au point par M. JB. Crampes, enseignant chercheur de l Université Paul Sabatier à Toulouse. Itération à l intérieur de la méthode Scrum, au terme de laquelle un logiciel partiel est présenté et doit fonctionner Méthode de développement faisant partie de la famille des méthodes Agiles
Page 35 sur 35 Bibliographie IUP ISI Master I. «Ingénierie du logiciel», 2006. IUP ISI Master I. «Ingénierie des systèmes», 2006. MARTIN, Robert C. Agile methods: The bottom line. COHN, Mike. Project Economics: Selecting and prioritizing high-value projects. COHN, Mike. What s holding you back? Object Mentor. The Primavera success story. COHN, Mike. User Stories Applied. COHN, Mike. Becoming an effective Scrum Product Owner. COHN, Mike. What project customers can do to turn a good product into a great one. MARTIN, Robert C. On analysis. MARTIN, Robert C. Continuous care vs. Initial design. MARTIN, Robert C. PERT, CPM, and Agile Project Management. COHN, Mike. Agile Estimating and Planning. MARTIN, Robert C. Agile Processes. COHN, Mike and FORD, Doris. Introducing an Agile process to an organization. COHN, Mike and SCHWABER, Ken. The need for Agile project management. COHN, Mike. The upside of downsizing. COHN, Mike. Toward a catalogue of Scrum smells.
Annexe I Support de formation : «Processus et pratiques Agiles»
Annexe II Support de formation : «Scrum»
Annexe III Support de formation : «Gestion Agile des besoins»
Annexe IV Présentation clients : «Mener à bien un projet Agile»
Annexe V Article «Scrum» dans Wikipedia
Annexe VI Extraits de mon blog : Billets sur Scrum et mon stage