Rapport de stage. «Migration Agile du RIL» Frédéric MONJO Master I

Transcription

1 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

2 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.

3 Table des matières Introduction... 1 I - Contexte du stage L organisme de Sécurité Sociale La CPAM de Toulouse L Informatique Locale Le projet de refonte méthodologique... 4 II - Analyse de la situation Méthodologie officielle Interviews... 6 a - Développeurs...6 b - Direction Groupe de travail Bilan... 6 a - Attentes des développeurs...6 b - Attentes de la direction...7 c - Risques identifiés Présentation des méthodes Agiles Les réponses «Agiles» a - Propositions d amélioration...10 b - Adéquation à l Agilité...13 III - Mise en place du projet pilote La nécessité d un «pilote» Actions préparatoires Choix de la méthodologie a - Les alternatives principales...15 b - Le choix de la méthode «Scrum» Choix du projet a - Alternatives...16 b - Difficultés Structuration de l équipe Planification de la migration a - Structure du projet...17 b - Planning Positionnement personnel a - Analyse...18 b - Formation...18 c - Coaching...19 d - Aide à la formation...19 e - Outils de support...19

4 f - Assistance en ergonomie des applications...19 IV - Déroulement du projet pilote Backlog du produit Déroulement des sprints a - Sprint b - Sprint c - Sprint d - Sprint Vélocité moyenne de l équipe Statistiques des releases a - Phase «technique»...25 b - Phase «logicielle»...26 V - Bilan du stage Bilan professionnel 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 Bilan personnel 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 Glossaire et Acronymes Bibliographie... 35

5 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.

6 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 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

7 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 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 : 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 personnes reçues chaque année ; 1 plate-forme de service téléphonique qui traite dans l'année plus de appels ; 1 site Internet local d'informations et de service ( connections par an) ; Plus de 23 millions d'opérations de paiement traitées chaque année, soit environ opérations par jour ; 2,6 milliards d'euros de dépenses remboursées en 1 an, soit euros par personne protégée et par an ;

8 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.

9 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.

10 Page 6 sur 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 :

11 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

12 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.

13 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

14 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.

15 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

16 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

17 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.

18 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» :

19 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

20 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»

21 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 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.

22 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

23 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.

24 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.

25 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

26 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

27 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

28 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