enregistrerEnregistrer Méthode Agile pour plus tard\nMigration Agile du RIL\nAnne universitaire 2005 / 2006 Stage du 3 avril 2006 au 1er septembre 2006 Caisse Primaire d Assurance Maladie de Toulouse Tuteur en entreprise : Sylvie COMBES Encadrant universitaire : Claude AUBRY\nAvant toute chose, il est pour moi indispensable de remercier tous ceux qui m ont accompagns dans le droulement de ce stage. Je commencerais donc par Brice JONES, responsable de l quipe RIL, avec qui nous avons ralis un travail de fond sur l tude et l organisation des ressources matrielles et humaines. Sa grande disponibilit d coute et son implication ont permis ce stage de se drouler du mieux qu il se peut. L autre acteur principal de ce stage a t l quipe pilote qui a mis en place et expriment la nouvelle mthodologie propose. Je leur dois beaucoup pour leur investissement dans la mise en pratique de concepts qui sont parfois difficiles intgrer. Un merci spcial Philippe MERIC qui m a accueilli comme collgue 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 rpondre mes interviews.\n1 - L organisme de Scurit Sociale ..................................................................................................... 2 2 - La CPAM de Toulouse ....................................................................................................................... 3 3 - L Informatique Locale ....................................................................................................................... 4 4 - Le projet de refonte mthodologique............................................................................................ 4\nII - Analyse de la situation ........................................................................................................ 5\n1 - Mthodologie officielle ..................................................................................................................... 5 2 - Interviews............................................................................................................................................. 6\na - Dveloppeurs ....................................................................................................................................................... 6 b - Direction ................................................................................................................................................................ 6\n3 - Groupe de travail .............................................................................................................................. 6 4 - Bilan...................................................................................................................................................... 6\na - Attentes des dveloppeurs ............................................................................................................................... 6 b - Attentes de la direction ..................................................................................................................................... 7 c - Risques identifis .................................................................................................................................................. 8\n5 - Prsentation des mthodes Agiles ................................................................................................ 10 6 - Les rponses Agiles ..................................................................................................................... 10\na - Propositions d amlioration.............................................................................................................................10 b - Adquation l Agilit ......................................................................................................................................13\nIII - Mise en place du projet pilote ........................................................................................ 14\n1 - La ncessit d un pilote ............................................................................................................. 14 2 - Actions prparatoires ...................................................................................................................... 14 3 - Choix de la mthodologie ............................................................................................................. 15\na - Les alternatives principales..............................................................................................................................15 b - Le choix de la mthode Scrum .................................................................................................................15\n4 - Choix du projet................................................................................................................................. 16\na - Alternatives .........................................................................................................................................................16 b - Difficults .............................................................................................................................................................17\n5 - Structuration de l quipe................................................................................................................ 17 6 - Planification de la migration .......................................................................................................... 17\na - Structure du projet.............................................................................................................................................17 b - Planning...............................................................................................................................................................18\n7 - Positionnement personnel .............................................................................................................. 18\na - Analyse ................................................................................................................................................................18 b - Formation ............................................................................................................................................................18 c - Coaching ............................................................................................................................................................19 d - Aide la formation ...........................................................................................................................................19 e - Outils de support................................................................................................................................................19\nf - Assistance en ergonomie des applications...................................................................................................19\nIV - Droulement du projet pilote .......................................................................................... 21\n1 - Backlog du produit .......................................................................................................................... 21 2 - Droulement des sprints.................................................................................................................. 22\na - Sprint 1 .................................................................................................................................................................22 b - Sprint 2 .................................................................................................................................................................23 c - Sprint 3..................................................................................................................................................................23 d - Sprint 4 .................................................................................................................................................................24\n3 - Vlocit moyenne de l quipe ..................................................................................................... 25 4 - Statistiques des releases .................................................................................................................. 25\na - Phase technique ..........................................................................................................................................25 b - Phase logicielle .............................................................................................................................................26\nV - Bilan du stage .................................................................................................................... 27\n1 - Bilan professionnel............................................................................................................................ 27\na - Prparation .........................................................................................................................................................27 b - Formation ............................................................................................................................................................27 c - Objectifs atteints et restants ............................................................................................................................27 d - Scnario envisag.............................................................................................................................................29 e - Bnfices.............................................................................................................................................................29 f - Difficults ..............................................................................................................................................................30\n2 - Bilan personnel ................................................................................................................................. 31\na - Intrts du stage................................................................................................................................................31 b - Enseignements appliqus ................................................................................................................................31 c - Connaissances complmentaires..................................................................................................................31 d - De l intrt d un blog ..................................................................................................................................31 e - Contributions au monde libre .........................................................................................................................32 f - Objectifs personnels ...........................................................................................................................................32 g - Projet professionnel ...........................................................................................................................................32\nConclusion ............................................................................................................................... 33 Glossaire et Acronymes.......................................................................................................... 34 Bibliographie ............................................................................................................................ 35\nInstitut Universitaire Professionnalis Ingnierie des Systmes Informatiques Universit Paul Sabatier Toulouse III\nMigration Agile du RIL Frdric Monjo\n01/09/2006 Page 1 sur 35\nL organisme de Scurit Sociale assure la couverture de la quasi-totalit de la population franaise. Cela reprsente des quantits de donnes gigantesques traiter et archiver. La Caisse Nationale d Assurance Maladie fdre toutes les caisses primaires et gre leur systme d information ainsi que les moyens d accs ces donnes. Nanmoins, chaque caisse a des besoins spcifiques en informatique, et certaines d entre elles disposent d un service ddi aux dveloppements internes ou la maintenance, dit service informatique locale . Le service informatique locale de Toulouse a utilis depuis longtemps la mthodologie de dveloppement officielle de la CNAM, trs dtaille et adapte de grands projets ; mais l chelle modre de la plupart des projets applicatifs locaux ne justifiait pas l utilisation d une mthode aussi formalise. Aussi il tait ncessaire pour les dveloppeurs d accder une mthode plus lgre, plus efficace, et qui assurerait un mme 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 mthode. Le but de ce rapport est de vous prsenter la dmarche suivie pour arriver la mise en place d une nouvelle mthode de dveloppement. Il est structur comme suit : La premire partie prsente succinctement le contexte du stage ; La deuxime partie dresse un bilan de l analyse de situation que j ai effectue au dbut de mon stage ; Puis la troisime partie expliquera comment la nouvelle mthodologie propose a t applique un projet pilote ; La quatrime partie restituera les principaux lments du droulement du projet pilote ; Et la cinquime partie dressera un bilan professionnel et personnel de tous les travaux effectus pendant ce stage.\n01/09/2006 Page 2 sur 35\nI - Contexte du stage\n1 - L organisme de Scurit Sociale\nSi la scurit sociale telle qu on la connat aujourd hui a t cre en 1945, il n en demeure pas moins que ses origines remontent la Rvolution de 1789. A cette poque les solidarits se restreignaient au cadre familial ou professionnel (corporations). Il faudra ainsi attendre la phase d'industrialisation du XIXme sicle pour voir se dvelopper, non sans dbats et hsitations : Les socits de secours mutuels, fondes sur la prvoyance collective volontaire et limites quelques activits ou quelques entreprises ; Un systme d'aide sociale intervenant pour faire face des besoins spcifiques, apprcis selon des critres subjectifs par une commission compose en partie d'lus locaux ; L'assistance mdicale gratuite (loi du 15 juillet 1893), le service dpartemental 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 apprciation subjective et spcialise, n'ont bnfici qu' une frange limite de la population. Aussi, ds le dbut du XXme sicle, 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 dcs (1928 et 1930) pour les salaris titulaires d'un contrat de travail, et un rgime spcial pour les agriculteurs (1928). La loi du 11 mars 1932 prvoit des allocations couvrant les charges familiales finances par des versements patronaux. A la veille de la deuxime guerre mondiale, la France dispose, dans les textes, d'un systme de protection complet mais fragile qui sera profondment renouvel aprs les hostilits. En 1945 les btisseurs du systme franais de scurit sociale poursuivent un triple objectif : unit de la scurit sociale, gnralisation 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 gnralisation de la scurit sociale l'ensemble de la population, mais les professions non salaries non agricoles s'y opposeront. Les principes de 1945 dont certains n'ont pu tre appliqus rapidement entrent progressivement dans les faits. L'unit administrative de la scurit sociale n'est toujours pas acheve mais plusieurs volutions contribuent la renforcer. Les diffrences de prestations et de cotisations entre les diffrents rgimes s'estompent rapidement. La gnralisation de la couverture toute la population a t poursuivie selon de nombreuses tapes de 1947 1999, date de cration de la Couverture Maladie Universelle. Le rgime gnral de scurit sociale a galement fait l'objet de plusieurs rorganisations : trois caisses nationales (CNAMTS pour l assurance maladie, CNAVTS pour l assurance\n01/09/2006 Page 3 sur 35\nvieillesse, CNAF pour les allocations familiales) plus ACOSS pour les finances, institution en 1996 des conseils de surveillance auprs des caisses nationales et des unions rgionales de caisses d'assurance maladie. Le financement de la scurit sociale s'est aussi modifi depuis 1945. Bien que les cotisations assises sur la masse salariale reprsentent encore la principale ressource des rgimes, la part des autres recettes (taxes fiscales, Contribution Sociale Gnralise, contribution sociale de solidarit la charge des entreprises, Contribution au Remboursement de la Dette Sociale) crot rapidement. Le systme franais de scurit sociale se caractrise donc aujourd'hui par une protection contre les risques sociaux gnralise l'ensemble de la population mais clate entre de nombreuses institutions faisant appel des sources diversifies de financement.\n2 - La CPAM de Toulouse\nLa Caisse Primaire d'Assurance Maladie de la Haute-Garonne est un organisme de droit priv qui gre une mission de service public. Elle assure plusieurs missions : Rembourser les prestations de l'Assurance Maladie au titre des risques maladie, maternit, dcs, invalidit et accident du travail - maladie professionnelle pour les bnficiaires du rgime gnral Participer la politique de matrise des dpenses de sant (campagnes d'information diriges vers nos diffrents publics, prvention des risques, contrle) Simplifier l'accs aux soins et acclrer 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 diffrents publics Quelques chiffres : 1 100 agents au service de plus d'1 million bnficiaires du rgime gnral, soit 89% de la population ; 12 agences et 6 permanences de proximit, soit 500 000 personnes reues chaque anne ; 1 plate-forme de service tlphonique qui traite dans l'anne plus de 600 000 appels ; 1 site Internet local d'informations et de service (230 000 connections par an) ; Plus de 23 millions d'oprations de paiement traites chaque anne, soit environ 90 000 oprations par jour ; 2,6 milliards d'euros de dpenses rembourses en 1 an, soit 2 100 euros par personne protge et par an ;\n01/09/2006 Page 4 sur 35\nCot de gestion infrieur 3% des dpenses.\n3 - L Informatique Locale\nPour grer les quipements matriels et logiciels des agents des caisses de la HauteGaronne, un service de gestion d informatique local a t mis en place : le SESI (Service d Etude et de Suivi Informatique). Ce service se dcompose comme suit :\nDGAI Marie-Pierre BARDIN\nDI Didier PELLUARD\nSESI Liliane LELIEVRE-ZAMORA\nMaintenance Dominique LETOUZEY\nRseau Infor. Locale Brice JONES\nAppli. Production Interne Evelyne MATHIEU\nLe RIL est constitu de deux quipes : une quipe en charge du rseau (matriel et administration des droits), et l autre en charge des dveloppements. C est avec cette dernire que nous avons entam un travail de refonte mthodologique.\n4 - Le projet de refonte mthodologique\nLa CNAM a publi une mthode de dveloppement interne officielle, de type cycle en V . Cette mthodologie ncessite la production de nombreux documents formels, et il s est avr qu elle n tait que partiellement applique aux diffrents projets, et de faon trs diffrente. Un groupe de travail a donc t mis en place pour repenser la mthodologie de dveloppement et l unifier pour tous les dveloppeurs. C est dans le cadre de ce groupe de travail que j ai effectu mon stage.\n01/09/2006 Page 5 sur 35\nLa premire phase de mon stage a t ddie l analyse de la situation actuelle, pour identifier les facteurs favorables et dfavorables aux diffrents types de mthodologies.\n1 - Mthodologie officielle\nLa mthodologie officielle a t produite par la CNAM (caisse nationale). Elle est drive d un cycle en V et intgre des spcificits propres l organisation des caisses d assurance maladie. Voici un schma reprsentant une vue macroscopique de la mthodologie :\nFormalisation du besoin Expression du besoin Evaluation du besoin Bilan d valuation PV Approbation du besoin Analyse Cahier des charges Rgles de conception de l IL PV Approbation Cahier des charges Ralisation Manuel d exploitation et d administration Oprations de maintenance pouvant entraner une reprise du processus Test PV de validation dfinitive Manuel utilisateur Gnralisation\nUne telle mthodologie est intressante 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 diffrents acteurs. Mais il n en demeure pas moins que le phnomne de l effet tunnel reste prsent : l application tant dveloppe d un seul coup, on ne peut apprcier 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 ambigut de l crit, d des cultures diffrentes entre le client et le fournisseur, provoque galement des incomprhensions. Les projets mens dans le RIL sont de petite envergure, et gnralement mens par un ou deux dveloppeurs. Ce type de mthodologie est par consquent peu adapt dans ce cas. Il est donc plus intressant de s orienter vers des mthodes de type Agile , trs bien adaptes des petites quipes. Mais avant d entreprendre la mise en uvre d une telle mthode, il est indispensable d valuer l adquation du contexte avec les concepts Agiles.\n01/09/2006 Page 6 sur 35\nL utilisation d interviews individuelles permet d obtenir diffrentes visions sur l approche mthodologique d un projet. Deux points de vue m ont sembls essentiels : celui des dveloppeurs sur le terrain, et celui de la direction plus macroscopique. a - Dveloppeurs Les interviews des dveloppeurs ont t ralises sur la base d un questionnaire simple : Quelle est votre dmarche personnelle pour raliser un projet (organisation, mthodologie, documentation, etc.) ? Quels sont les projets sur lesquels vous avez travaill ? Pour chacun, quelles sont les difficults rencontres ? Quelles sont vos remarques ? Une fois ces donnes collectes, j ai dress un bilan pour chaque dveloppeur, puis pour l ensemble des dveloppeurs. b - Direction Les interviews de la direction ont t ralises 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 mtriques que vous souhaiteriez possder sur le RIL ? Quels sont les artefacts que vous souhaiteriez possder venant du RIL ? De la mme manire, les donnes collectes ont t synthtises pour chaque personne interroge, puis de faon globale.\n3 - Groupe de travail\nA partir des problmes recenss dans les interviews, nous avons discut des solutions possibles pendant une sance organise en groupe de travail. Ce type de sance est inspir des concepts de management collaboratif : impliquer les intervenants en les faisant rflchir aux solutions, tout en fournissant des lments-cls sur la solution finale qui sera adopte. Ici, l ide tait d introduire des lments des mthodes Agiles comme rponse aux problmes identifis.\na - Attentes des dveloppeurs La synthse des interviews des dveloppeurs a mis en vidence les problmes classiques lis l utilisation d une mthodologie de type cascade . Voici les attentes exprimes :\n01/09/2006 Page 7 sur 35\nAmliorer la gestion des besoins : Dialoguer avec les bons interlocuteurs Mieux recenser et comprendre les besoins des demandeurs Montrer rgulirement des maquettes pour rvler les besoins cachs des demandeurs Faire tester plus efficacement aux utilisateurs\nAmliorer la gestion des projets : Canaliser les demandes de projet Travailler en quipes de taille suffisante pour viter les problmes de congs et partager les connaissances Produire de la documentation utile Canaliser et rduire les oprations de maintenance. Produire des FAQ types sur les problmes avec les applications.\nb - Attentes de la direction La synthse des interviews de direction a rvl ses principales attentes. Ces attentes correspondent aux critres traditionnels demands par les entits dirigeantes d une organisation : Disposer d un suivi d avancement : Visibilit sur chaque projet Gestion des priorits des projets Analyse de la pertinence des projets demands Artefacts de validation des tapes du projet\nAssurer la qualit du service Rapidit des dveloppements Systmes fiables et scuriss Indicateurs de performance\nDmarche de validation Respecter une dmarche de validation officielle\n01/09/2006 Page 8 sur 35\nc - Risques identifis L adoption d une mthodologie ne se limite pas seulement l application d un processus, elle ncessite aussi une organisation et un environnement adapts. Aussi, j ai class les problmes identifis et les risques qu ils comportent dans deux catgories : risques mthodologiques et risques organisationnels. Les tableaux ci-dessous dressent la liste des risques identifis pour chaque catgorie. Je n ai pas pondr ces risques car ils taient tous de la mme importance mon sens.\n01/09/2006 Page 9 sur 35\nFamille Problme Projets individuels ou par 2 maximum Risques - Connaissance du projet centralise sur une personne - Comptences acquises par une seule personne - Priorits des projets changeantes - Perte de temps due au changement de contexte frquent - Perte de productivit sur tous les projets - Redondance de bases de donnes - Redondance de fonctionnalits - Interruptions frquentes d'un projet pour un autre - Perte de temps due au changement de contexte frquent - Perte de qualit du travail - Dveloppeurs interrompus trop souvent - Perte de concentration - Perte de temps due au changement de contexte frquent - Perte importante de productivit - Diagnostic d'erreur faite par les dveloppeurs : perte de temps - Perte de temps due au changement de contexte frquent - Communication plus difficile dans l'quipe - Moins d'esprit d'quipe - Conditions de travail dsagrables - Perte de temps chercher des documents - Documents obsoltes\n4 5 projets simultans par personne Projets Pas de vrification de l'existant au lancement d'un projet Tous les projets sont urgents !\nAppels tlphoniques incessants, pour des raisons souvent futiles Hotline inefficace : transfre les problmes sans vrai diagnostic, alors qu'ils s'agit souvent de droits d'accs ou de configuration systme / rseau. Bureaux spars Bureaux mal rangs\n- Perte de temps due au changement de contexte Interruptions trs frquentes des projets frquent pour des oprations de maintenance - Perte de temps pour des corrections mineures qui urgentes peuvent tre reportes 90% des cas la fin du projet courant Maintenance Utilisateurs peu expriments en informatique, ne testent pas ou testent mal Administration des bases de donnes non attribue temps plein sur une personne - Nombreuses volutions demandes - Nombreux bugs dcouverts aprs la livraison - Modifications ouvertes tous - Aucun responsable en cas de problme - Aucune personne qui se rfrer en cas de problme\n01/09/2006 Page 10 sur 35\nFamille Problme Risques - Effet tunnel pour les utilisateurs - Planification mal value - Estimations mal values - Produit final non conforme aux vrais besoins des utilisateurs - Cahier des charges peu clair et interprt diffremment - Produit livr ne rpond pas aux attentes initiales des utilisateurs - Maintenance volutive importante aprs la livraison - Prise en compte trs tardive dans le projet - Maintenance volutive importante aprs la livraison - Besoins exprims en dsaccord avec les vrais besoins des utilisateurs - Nombreuses modifications demandes aprs la livraison - Produit livr ne rpond pas aux attentes initiales des utilisateurs - Maintenance volutive importante aprs la livraison - Dlais non respects - Gestion du projet chaotique - Difficult estimer - Pertinence des estimations - Dlais non respects - Gestion du projet chaotique\nMthode actuelle anarchique, souvent de type cascade\nBesoins mal exprims / mal compris\nBesoins changeants Besoins Utilisateurs finaux masqus par leur chef de service qui ne veut pas les librer Besoins recueillis auprs des mauvais utilisateurs Pas de planification efficace Estimations rarement faites, et si c'est le cas en jours-hommes Avancement du projet interrompu trs souvent par des oprations de maintenance\n5 - Prsentation des mthodes Agiles\nVous pourrez trouver une prsentation gnrale des principes et mthodes Agiles dans l annexe Support de formation : Processus et pratiques Agiles .\n6 - Les rponses Agiles\na - Propositions d amlioration L utilisation d une mthode Agile permet de pallier la plupart de ces risques de faon efficace. Voici les solutions proposes aux diffrents problmes, toujours classs par catgorie.\n01/09/2006 Page 11 sur 35\nFamille Problme Solution Agile Projets individuels ou par Travail en deux quipes de 4 2 maximum personnes 4 5 projets simultans par personne Pas de vrification de l'existant au lancement d'un projet Tous les projets sont urgents ! Appels tlphoniques incessants, pour des raisons souvent futiles Hotline inefficace : transfre les problmes sans vrai diagnostic. Bureaux spars Bnfices attendus - Connaissance commune du projet - Comptences acquises par toute l'quipe - Projets aboutis rapidement - Enchanement des projets rapide - Dveloppeurs au maximum de leur productivit - Plus de redondances inutiles Idem ci-dessus - Seuls les appels vraiment importants sont transmis - Meilleure concentration de l'quipe - Dveloppeurs au maximum de leur productivit Idem ci-dessus - Meilleure concentration - Meilleure communication - Esprit de groupe solidaire - Rsolution rapide des problmes - Bien-tre des dveloppeurs - Meilleure productivit - Meilleure ambiance - Documentation efficace\nUn seul projet la fois pour l'quipe Rfrencer tous les projets avec les fonctionnalits implmentes et les schmas de donnes On n'interrompt jamais un projet en cours Filtrer les appels vers l'quipe par un seul point d'entre : le ScrumMaster Isoler l'quipe des problmes de Hotline, ne lui transfrer que des appels justifis et diagnostiqus Tous les membres de l'quipe sont dans la mme pice, isole et calme\nBureaux mal rangs\nPice bien range, cadre agrable\nInterruptions trs frquentes des projets pour des oprations de maintenance urgentes Maintenance Utilisateurs peu expriments en informatique, ne testent pas ou testent mal\n- Interdire l'interruption d'un projet (recenser les oprations demandes et les raliser aprs la fin du projet en - Continuit du projet cours, avant d'entamer le projet - Meilleure productivit suivant) - Intervention seulement dans les - Evaluer finement l'urgence de la vrais cas d'urgence modification demande (trs souvent urgent sans l'tre vraiment) - Les tests peuvent tre guids dans - Les utilisateurs font partie de un premier temps par l'quipe l'quipe et testent souvent - Un utilisateur ne teste que les - Identification de rles utilisateurs fonctions qui le concernent, pas toute plutt que de personnes l'application (donc tests mieux cibls)\nFamille Problme Solution Agile Bnfices attendus\n01/09/2006 Page 12 sur 35\nPasser une mthode Agile (Scrum, XP)\nUtiliser des User Stories\nBesoins changeants Besoins Utilisateurs finaux masqus par leur chef de service qui ne veut pas les librer Besoins recueillis auprs des mauvais utilisateurs\nUtiliser des User Stories priorises Identifier des rles utilisateurs et un reprsentant de chaque rle Utiliser des rles utilisateurs Planification agile en deux tapes : - Sur une release (vlocit) - Sur chaque sprint (reste faire) - Estimations en points pour les fonctionnalits - Estimations en reste faire sur les tches dans un sprint\n- Dmarche itrative, pas d'effet tunnel - Planification intelligente - Estimations meilleures et qui s'amliorent - Produit final trs proche des besoins utilisateur - Qualit du produit amliore - Productivit trs augmente - Comprhension partielle dans un premier temps, puis explication orale au moment de l'implmentation, donc bien comprise - Fonctionnalits raffines, petites, simples comprendre et estimer - A chaque sprint, choix des US ralises - L'ordre et les US peuvent changer avant d'attaquer un nouveau sprint (sans impacter le sprint courant) - Plus grande pertinence des besoins car localiss des rles donc plus prcis - Les besoins sont exprims par rles donc mieux apprhends - 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'exprience rapide et fiable au niveau release - Avancement apparent sur chaque sprint (reste faire qui diminue, donne fiable) - Visibilit excellente sur le projet - Estimation relative sur les fonctionnalits : plus facile, plus fiable - Reste faire facile estimer et mettre jour - Retour d'exprience sur les estimations rapide et fiable - Raffinement des estimations rapide - Visibilit excellente sur le projet\nPas de planification efficace\nPlanification et Estimations rarement Estimation faites, et si c'est le cas en jours-hommes\nAvancement du projet interrompu trs souvent par des oprations de maintenance\nIsolement complet de - Continuit du projet l'quipe, interdiction - Oprations reportes en fin de projet et traites d'interrompre un sprint en efficacement cours ou un projet en - Meilleure productivit de l'quipe cours.\n01/09/2006 Page 13 sur 35\nb - Adquation l Agilit Aprs la rcupration de tous ces lments, j ai dress un bilan d adquation l Agilit sous forme de prsentation PowerPoint. Ce bilan prsentait plusieurs mtriques permettant d valuer le niveau d adquation du contexte du RIL avec les mthodes Agiles. Voici la liste des critres avec le niveau d adquation pour chacun : Evaluation organisationnelle Taille de l quipe\nUne quipe de petite taille est bien adapte\nCriticit des applications\nLes logiciels non critiques sont bien adapts\nCriticit de la maintenance\nLa maintenance non critique est bien adapte\nQualit de l environnement\nUn environnement calme et sain est favorable\nEvaluation mthodologique Dynamisme du contexte\nLes besoins peuvent changer souvent\nCulture des dveloppeurs\nSavoir-faires suffisants et diffusion\nBesoins bien compris / bien exprims\nPlanification efficace, estimations pertinentes\nVisibilit et gestion efficaces\nComme on peut le voir, le domaine organisationnel pose davantage de problmes que le domaine mthodologique, ce qui nous amens focaliser les premires actions sur ce domaine.\n01/09/2006 Page 14 sur 35\nIII - Mise en place du projet pilote\n1 - La ncessit d un pilote\nLa CNAM (Caisse Nationale d Assurance Maladie) a propos une mthodologie de type Cycle en V , qui se prte bien un contexte o les dmarches sont conues sur le schma Demande Analyse Production Validation . Le passage une mthode Agile implique un passage rapide la production, et un engagement empirique sur les besoins et les dlais. Cette conception implique beaucoup de changements dans la faon de grer les projets. Aussi pour obtenir l aval de la direction, il tait indispensable de mettre en place un projet pilote , dont les rsultats serviront prouver les bienfaits d une approche Agile.\n2 - Actions prparatoires\nDs le dbut du stage, et jusqu au lancement du projet pilote, j ai effectu un travail trs actif d autoformation sur les mthodes et techniques Agiles, afin de pouvoir rpondre au mieux aux problmes et questions qui me seraient exposs. J ai pour cela utilis de nombreuses sources sur Internet : sites spcialiss, 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 mtres cubes de vieille documentation et vieux livres ont t jets Mise en place d un nouveau processus de prise en compte des oprations de maintenance, incluant la mise en place du bugtracker Gemini :\n01/09/2006 Page 15 sur 35\nRorganisation des bureaux : pour amliorer la communication au sein d une quipe, il est prfrable qu elle se situe dans la mme pice. Un projet de ramnagement des bureaux a t lanc pour rassembler les deux quipes dans deux pices ddies. Chacune de ces pices sera galement quipe d un tableau blanc.\n3 - Choix de la mthodologie\na - Les alternatives principales Dans la famille Agile , deux mthodes sortent du lot pour leurs qualits : XP et Scrum. Ce sont la fois les plus souples et les plus efficaces, et sont trs prouves aujourd hui. Nous nous sommes donc pos la question du choix de la mthode. Scrum est plus oriente sur la gestion de projet, et fournit un ensemble de pratiques de base qui laissent volontairement le libre choix des techniques de dveloppement. XP possde peu prs la mme organisation de base que Scrum, mais propose des pratiques plus prcises : l utilisation des User Stories pour la gestion des besoins, et du dveloppement guid par les tests (TDD Test Driven Development) l intrieur de chaque itration. b - Le choix de la mthode Scrum La pratique du dveloppement guid par les tests tant relativement difficile mettre en uvre, nous avons choisi de commencer utiliser Scrum, en y intgrant quelques pratiques de XP (User Stories, Planning Poker). Une fois mis en place et stabilis, il sera\n01/09/2006 Page 16 sur 35\nintressant d intgrer les pratiques TDD comme facteur d amlioration de la qualit des logiciels produits. Scrum mentionne qu on n interrompt jamais l quipe pendant une itration. Pour pouvoir traiter quand mme les oprations de maintenance frquentes, nous avons amnag le processus en intercalant entre chaque itration une priode courte ddie la maintenance. Pour grer efficacement les demandes, nous avons galement dploy un bugtracker du nom de Gemini.\nPhases de maintenance trs courtes, pour traiter les urgences survenues pendant le sprint\n4 - Choix du projet\na - Alternatives La question du choix du projet pilote s est ensuite pose nous. Un nouveau projet devait justement dmarrer au moment du lancement du projet pilote. Son inconvnient tait simplement d tre relativement petit, et ralis par une seule personne en un mois environ. Mais en mme temps, une rorganisation des structures hirarchiques de la caisse a entran que la base de donnes centrale des agents de la caisse, partage entre toutes les applications, ne pouvait plus accueillir la nouvelle organisation. Il devenait donc urgent de reconstruire cette base de donnes et les applications qui en graient les donnes. Ce projet a donc t choisi comme projet pilote. C tait l occasion idale d apporter quelques amliorations l existant : Implmentation d une couche d objets mtier pour accder et manipuler les donnes, au lieu d'utiliser des requtes SQL. Unification de l interface d administration des donnes : remplacer les 3 applications indpendantes en une seule, dont l interface intgre une gestion des droits d accs pour filtrer les actions possibles. Amlioration de l ergonomie de l interface Il prsente les intrts suivants : Critique et urgent Utilisation de Scrum pour grer des dveloppements techniques Utilisation de Scrum pour grer des dveloppements logiciels\n01/09/2006 Page 17 sur 35\nLes trois applications seront rcrites successivement. Ainsi les deux dernires seront considres comme des volutions de la premire, comme des volutions des besoins. b - Difficults Nanmoins, ce projet prsente des difficults non ngligeables : La ralisation d une couche d objets mtier ne permet pas facilement l laboration d une liste de besoins dont la ralisation est mesurable. L interface d administration des donnes ne possde pas rellement d utilisateurs demandeurs. En effet, la gestion des donnes des agents a t confie certains agents pour permettre le bon fonctionnement des applications internes. Pour pallier au second problme, nous avons demand des responsables des Ressources Humaines de bien vouloir prendre part au projet pilote en tant que demandeurs.\n5 - Structuration de l quipe\nLe fonctionnement nominal du service permettait la ralisation simultane de nombreux projets. Il n tait donc pas possible de mobiliser l intgralit 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 dveloppeurs 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 rsultats. Une fois le projet pilote termin, cette quipe serait scinde en deux binmes, qui formeraient ensuite les deux quipes finales de 4.\n6 - Planification de la migration\na - Structure du projet De par la nature du projet pilote, nous avons identifi deux phases du projet, qui correspondent deux releases possibles : une premire phase dite technique dont le but est de construire la couche d objets mtier, et une deuxime dite logicielle dont le but est de construire les logiciels de gestion des donnes. La phase logicielle est structure comme suit : Une release qui regroupe le re-dveloppement et l unification de deux des logiciels (TABLE-IL et MAJANNU) sur la nouvelle couche objet Une release ddie au re-dveloppement du troisime logiciel (GEDAM). Cette dernire est conditionne par l arrive prochaine d une application nationale quivalente, mais peut-tre pas suffisante.\n01/09/2006 Page 18 sur 35\n( + Autoformation )\nGnralisation ? Maintenance\n( Sprint 2 )\nCe planning est lgrement diffrent ce qui tait prvu. En effet, la phase technique ne devait durer qu un seul sprint, mais des difficults caches ont oblig la prolonger d un sprint complmentaire.\n7 - Positionnement personnel\na - Analyse La premire mission qui m a t confie a en fait t celle d un consultant : il s agissait d identifier les points faibles dans l organisation et de proposer des amliorations. Bien que ne bnficiant que de peu d exprience professionnelle, la forte composante en gnie logiciel de la formation ISI m a permis de discerner rapidement les problmes classiques. L autoformation aux mthodes Agiles m a galement donn une vision nouvelle sur d autres problmes mthodologiques. b - Formation En force de proposition, j ai donc t charg d apporter mes connaissances en terme de mthodes Agiles. Ces connaissances ont t synthtises depuis de nombreux documents Internet, en y apportant mes propres points de vue. La formation que j ai dispense s est dcompose en 3 prsentations : Processus et Pratiques Agiles (1/2 journe) : Qu est-ce que Agile ? Les processus Agiles, Les pratiques Agiles. Scrum (1/2 journe) : Agilit, Concepts, De A Z, Jeu de rles\n01/09/2006 Page 19 sur 35\nGestion Agile des besoins (1/2 journe) : De l tude des besoins aux User Stories , Clients/Utilisateurs, Rcolter 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 prsent sur le terrain pour intervenir au bon moment et rappeler les concepts et les pratiques de la nouvelle mthodologie. J ai donc encadr au quotidien l quipe pilote dans cette optique. d - Aide la formation Les mthodes Agiles sont encore trs 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 hirarchie 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 prsent en amont de chaque projet. Il a pour but de leur faire comprendre les concepts des mthodes Agiles, de leur apprendre grer efficacement les utilisateurs, les besoins, le suivi de leur ralisation, et enfin de matriser leurs missions pour garantir le succs du projet. J avais planifi de raliser un support destin la hirarchie, s appuyant sur les rsultats du projet pilote pour leur prouver l efficacit d une mthode Agile, mais ce dernier ayant pris beaucoup trop de retard, je n ai donc pas ralis cette prsentation. e - Outils de support Une bonne mthode est moins apprciable si elle n est pas accompagne d un bon outil. Aussi j ai assur la mise en place d un outil de support la mthode Scrum : IceScrum. Je l ai configur, dploy, et j ai assur une formation son utilisation l quipe pilote. Cet outil libre et open source a t dvelopp lors du bureau d tudes de mon anne de Master I l IUP. Son dveloppement a t ensuite poursuivi par Cdric Laurens (tudiant de Licence III du BE), pendant son stage, simultanment au mien. Des versions successives ont donc t publies, et je me suis occup de les dployer sur les postes de l quipe. Il m a fallu galement assurer la migration des donnes d une version sur l autre. Nous avons galement souhait hberger ces donnes sur un serveur Microsoft SQL Server central, IceScrum tant normalement prvu pour fonctionner avec la plupart des SGBD courants. Malheureusement, il s est avr qu aucun pilote JDBC ne fonctionnait avec IceScrum pour SQL Server. Nous avons donc install une instance de MySQL sur un systme sauvegard. f - Assistance en ergonomie des applications Les dveloppeurs du RIL ont eux-mmes manifest leurs difficults avec l ergonomie des logiciels. Aussi il m a sembl pertinent de leur prsenter le SNI (Schma Navigationnel d Interface), qui permet de modliser l interface d une application du point de vue ergonomique.\n01/09/2006 Page 20 sur 35\nJ ai donc assur une formation rapide sur la modlisation l aide du SNI, montr les exemples de mes stages prcdents, et guid sa mise en pratique sur le projet pilote.\n01/09/2006 Page 21 sur 35\nIV - Droulement du projet pilote\nL utilisation d IceScrum a permis de conserver un historique de la ralisation du projet pilote.\n1 - Backlog du produit\nLe backlog du produit rfrence toutes les fonctionnalits que devra implmenter le logiciel. Il est prsent ici dans l ordre de priorits dfinies par le client, et avec les estimations de l quipe. Thme Couche mtier Couche mtier Couche mtier Couche mtier Couche mtier Couche mtier Couche mtier Couche mtier Un Agent arrive Un Agent arrive Un Agent arrive Gestion de la compatibilit ascendante Couche mtier Un Agent arrive Couche mtier Les Entits Organisationnelles Les Entits Organisationnelles Un Agent bouge Un Agent bouge Un Agent bouge Un Agent bouge Un Agent arrive Un Agent bouge Un Agent bouge Un Agent bouge Un Agent bouge Un Agent bouge Un Agent bouge Un Agent bouge Un Agent bouge Un Agent bouge Les Entits Organisationnelles Un Agent bouge Item Dfinir les rgles de gestion (mtier + droits d'accs des applis) pour la manipulation des objets Le dveloppeur veut accder des objets hirarchiques Dfinir une gestion des verrous Le dveloppeur veut accder des objets "simples" Le dveloppeur veut accder des objets par liste multicritres Implmenter la gestion des rles et droits d'accs Le Responsable peut dlguer ses droits ses subordonns Un Administrateur des dlgations peut changer les dlgations d'un cadre Le Gestionnaire Administrateur du Personnel cre l'agent Le Gestionnaire Administrateur du Personne Externe cre l'agent externe Informer automatiquement le responsable du service de l'agent cr Le dveloppeur veut garder une compatibilit avec l'ancienne base CPAM31 Implmenter un systme de trace des actions sur la BD Implmenter la rcupration automatique des complments d'infos sur l agent Implmenter une gestion d'erreurs base sur Gemini Le RH propose d'unifier la terminologie des entits organisationnelles (EO) Une EO st type (unit, secteur, service, ple, direction, dpartement) Un agent tout type de contrat peut revenir en CDD ou en CDI Un agent externe change de n GDP s'il rentre dans l'organisme Un gestionnaire ADP affecte un agent une EO Un gestionnaire ADP consulte l'historique agent Le responsable du service de l'agent cr complte ses informations Un gestionnaire ADP recherche un agent dans l'historique Informer automatiquement le responsable quand l'agent change EO Informer automatiquement le responsable quand l'agent change Nom Le responsable change l'affectation de son agent une EO Le responsable change l'affectation de son agent une EG Le responsable change l'affectation de son agent une donne complmentaire Un gestionnaire ADP positionne une date de dpart Le gestionnaire ADP gre le prt d'agent inter service Le gestionnaire ADP gre l'agent absent en longue dure Le responsable dispose d'une dlgation administrativement sur son EO Si le n GDP change, il faut conserver l'historique Points Estims 2 5 2 3 1 1 1 1 2 1 1 5 1 0 3 0 0 2 1 1 1 2 1 1 1 1 1 1 1 0 2 2 1\n01/09/2006 Page 22 sur 35\nLes Entits Gographiques Les Entits Organisationnelles Les Entits Organisationnelles Les Entits Organisationnelles Les Entits Organisationnelles Les Entits Organisationnelles Les Entits Gographiques Les Entits Gographiques Les Entits Gographiques Les Entits Gographiques Les Entits Gographiques Les Entits Organisationnelles\nUne salle (sans agent affect) peut avoir un n de tlphone Tout le monde affiche l'organigramme Le gestionnaire EO cre une EO Le gestionnaire EO dplace une EO Le gestionnaire EO met jour une EO Le gestionnaire EO supprime une EO Le gestionnaire Immobilier cre une EG Le gestionnaire Immobilier renomme une EG Le gestionnaire Immobilier supprime une EG Le responsable affecte un agent une EG Le gestionnaire Immobilier dplace une EG Le dveloppeur utilise un arbre hirarchique\n1 3 1 1 1 1 1 1 1 1 1 2\nCertains lments sont estims 0 points. Il s agit de contraintes non fonctionnelles, ou d lments dont l estimation dpend d un contexte technique non connu pour l instant.\n2 - Droulement des sprints\na - Sprint 1 Items du backlog raliss : Thme Couche mtier Item Le dveloppeur veut accder des objets hirarchiques Vlocit : 5 Burndown chart du sprint : Points Estims 5\n01/09/2006 Page 23 sur 35\nOn voit ici que les donns du sprint ont t saisies en milieu de sprint. Cela s explique par les difficults rencontres lors du dploiement de l outil IceScrum. Toutes les tches n ont pas pu tre ralises pendant ce sprint. b - Sprint 2 Items du backlog raliss : Thme Couche mtier Couche mtier Couche mtier Item Dfinir les rgles de gestion (mtier + droits d'accs des applis) pour la manipulation des objets Dfinir une gestion des verrous Le dveloppeur veut accder des objets "simples" Vlocit : 7 Burndown chart du sprint : Points Estims 2 2 3\nSur 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 vritables donnes ont t fournies en milieu de sprint. c - Sprint 3 Items du backlog raliss : Thme Couche mtier Couche mtier Item Le dveloppeur veut accder des objets par liste multicritres Implmenter la gestion des rles et droits d'accs Points Estims 1 1\n01/09/2006 Page 24 sur 35\nCouche mtier Couche mtier\nLe Responsable peut dlguer ses droits ses subordonns Un Administrateur des dlgations peut changer les dlgations d'un cadre Vlocit : 4 Burndown chart du sprint :\nCe graphique est intressant, puisqu il rvle plusieurs choses : la faible frquence 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 : Thme Les Entits Organisationnelles Les Entits Organisationnelles Les Entits Organisationnelles Les Entits Organisationnelles Les Entits Organisationnelles Item Le gestionnaire EO cre une EO Le gestionnaire EO dplace une EO Le gestionnaire EO met jour une EO Le gestionnaire EO supprime une EO Le dveloppeur utilise un arbre hirarchique Vlocit estime : 6 Points Estims 1 1 1 1 2\n01/09/2006 Page 25 sur 35\n3 - Vlocit moyenne de l quipe\nLa vlocit moyenne de l quipe est de 5,33 entre avril et aot. Cette vlocit est pondrer avec le fait que les congs 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 vlocit serait de 9.\n4 - Statistiques des releases\na - Phase technique\nBurndown Chart de la release "Phase logicielle"\n7 6 5 4 Points 3 2 1 0 1 Sprints 2 Vlocit Reste faire\n01/09/2006 Page 26 sur 35\nb - Phase logicielle\n50 45 40 35 30 Points 25 20 15 10 5 0 1 2 3 4 Sprints 5 6 7 Vlocit Reste faire\nSur ce graphique, les deux premiers sprints sont constats (vlocit de 5,33). Les suivants sont estims par rapport la nouvelle vlocit (9).\n01/09/2006 Page 27 sur 35\nV - Bilan du stage\nL objectif de ce chapitre est d tablir un bilan du projet du point de vue de l entreprise et du point de vue personnel.\na - Prparation Les actions de prparation du projet pilote ont t efficaces. En effet, les bureaux sont mieux rangs, crant ainsi une atmosphre plus agrable, et surtout facilitant l accs efficace aux documentations. La canalisation de la maintenance a permis de minimiser les irruptions dans la pice de l quipe de dveloppement, ainsi que les appels tlphoniques. C est aussi un contexte qui favorise un travail efficace dans de bonnes conditions. Le ramnagement des bureaux est toujours l tude. Il sera probablement ncessaire de faire dplacer des cloisons amovibles, et cela requiert l apprciation et l intervention des personnes qualifies dans ce domaine. b - Formation Le travail de prparation d une formation a t pour moi quelque chose de nouveau, et relativement difficile. Mme si je me suis beaucoup inspir de la documentation trouve sur Internet, j ai travaill attentivement le contenu et le plan pour tre sr qu ils soient pertinents. C est un travail fastidieux. c - Objectifs atteints et restants\nProjets individuels ou Travail en deux quipes par 2 maximum de 4 personnes 4 5 projets simultans par personne Pas de vrification de l'existant au lancement d'un projet Un seul projet la fois pour l'quipe\nBnfices attendus - Connaissance commune du projet - Comptences acquises par toute l'quipe - Projets aboutis rapidement - Enchanement des projets rapide - Dveloppeurs au maximum de leur productivit\nBnfices constats Oui Oui Non : Retard du projet pilote Non Non : Congs d t\nRfrencer tous les projets avec les ? Pas de mesure disponible fonctionnalits - Plus de redondances inutiles implmentes et les schmas de donnes Tous les projets sont On n'interrompt jamais un Idem ci-dessus Oui urgents ! projet en cours Appels - Seuls les appels vraiment tlphoniques Filtrer les appels vers importants sont transmis incessants, pour des l'quipe par un seul point - Meilleure concentration de l'quipe Non mis en application raisons souvent d'entre : le ScrumMaster - Dveloppeurs au maximum de leur futiles productivit\n01/09/2006 Page 28 sur 35\nHotline inefficace : transfre les problmes sans vrai diagnostic.\nIsoler l'quipe des problmes de Hotline, ne lui transfrer que des appels justifis et diagnostiqus Tous les membres de l'quipe sont dans la mme pice, isole et calme Pice bien range, cadre agrable - Interdire l'interruption d'un projet (recenser les oprations demandes et les raliser aprs la fin du projet en cours, avant d'entamer le projet suivant) - Evaluer finement l'urgence de la modification demande (trs souvent urgent sans l'tre vraiment) - Les utilisateurs font partie de l'quipe et testent souvent - Identification de rles utilisateurs plutt que de personnes\n- Seuls les appels vraiment importants sont transmis - Meilleure concentration de l'quipe - Dveloppeurs au maximum de leur productivit - Meilleure concentration - Meilleure communication - Esprit de groupe solidaire - Rsolution rapide des problmes - Bien-tre des dveloppeurs - Meilleure productivit - Meilleure ambiance - Documentation efficace\n? Pas encore mis en place Oui Oui Oui Oui\nInterruptions trs frquentes des projets pour des oprations de maintenance urgentes\n- Continuit du projet - Meilleure productivit - Intervention seulement dans les vrais cas d'urgence\nUtilisateurs peu expriments en informatique, ne testent pas ou testent mal\nUtiliser des User Stories priorises\n- Les tests peuvent tre guids dans un premier temps par l'quipe - Un utilisateur ne teste que les fonctions qui le concernent, pas toute l'application (donc tests mieux cibls) - Dmarche itrative, pas d'effet tunnel - Planification intelligente - Estimations meilleures et qui s'amliorent - Produit final trs proche des besoins utilisateur - Qualit du produit amliore - Productivit trs augmente - Comprhension partielle dans un premier temps, puis explication orale au moment de l'implmentation, donc bien comprise - Fonctionnalits raffines, petites, simples comprendre et estimer - A chaque sprint, choix des US ralises - L'ordre et les US peuvent changer avant d'attaquer un nouveau sprint (sans impacter le sprint courant) - Plus grande pertinence des besoins car localiss des rles donc plus prcis\n? Pas de mesure disponible\nOui Oui Oui Oui Oui Non : Temps d adaptation Oui\nUtilisateurs finaux masqus par leur chef de service qui ne veut pas les librer\nIdentifier des rles utilisateurs et un reprsentant de chaque rle\n01/09/2006 Page 29 sur 35\nBesoins recueillis auprs des mauvais utilisateurs\nUtiliser des rles utilisateurs\nPlanification agile en deux tapes : - Sur une release (vlocit) - Sur chaque sprint (reste faire)\n- Estimations en points Estimations rarement pour les fonctionnalits faites, et si c'est le - Estimations en reste cas en joursfaire sur les tches dans hommes un sprint\n- Les besoins sont exprims par rles donc mieux apprhends - 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'exprience rapide et fiable au niveau release - Avancement apparent sur chaque sprint (reste faire qui diminue, donne fiable) - Visibilit excellente sur le projet - Estimation relative sur les fonctionnalits : plus facile, plus fiable - Reste faire facile estimer et mettre jour - Retour d'exprience sur les estimations rapide et fiable - Raffinement des estimations rapide - Visibilit excellente sur le projet\nOui Oui ? Pas de mesure disponible Oui Non : Saisie non rgulire des donnes Oui Oui Oui Oui Oui Oui Oui Oui Oui\nIsolement complet de - Continuit du projet l'quipe, interdiction - Oprations reportes en fin de d'interrompre un sprint en projet et traites efficacement cours ou un projet en - Meilleure productivit de l'quipe cours.\nd - Scnario envisag La dure restante du projet pilote est estime 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 mthode Scrum. S il est montr qu elle a permis un rel gain de productivit et de qualit, elle sera probablement gnralise tous les dveloppeurs. Il est galement envisageable qu elle soit gnralise assez rapidement pour la tester en grandeur nature. e - Bnfices La mthode Scrum a prouv que ses principes fondamentaux apportent les avantages promis : Le dveloppement itratif permet de donner un rythme au projet, et de livrer un logiciel qui fonctionne intervalles rguliers. C est un atout tant pour le client, qui voit que le projet avance, que pour l quipe, qui voit qu elle avance de faon rgulire. La forte collaboration avec les clients a permis de bien comprendre et interprter les besoins, et galement de faire exprimer aux clients des rgles mtier parfois complexes, ou des besoins cachs qui sont apparus de proche en proche avec les autres besoins.\n01/09/2006 Page 30 sur 35\nL utilisation des User Stories a aussi t fructueuse en ce sens qu elles ont permis d exprimer les besoins de faon atomique, de les estimer plus facilement et de faon plus fiable. Les Scrums quotidiens permettent de faire le point et diffuser l avancement du travail, tout en identifiant les problmes pour qu ils soient traits au plus vite. Enfin, outre la mthode Scrum, l utilisation d un SNI pour modliser l interface de l application a t galement bnfique : Sa facilit de modlisation permet de concevoir une interface ergonomique rapidement, et engendre naturellement une bonne qualit de conception ; Une fois conu, le modle permet de produire l interface sans avoir rflchir son contenu, ce qui permet d tre plus efficace ; Enfin, sa lecture facile permet aux clients d avoir un aperu de l interface de leur application. f - Difficults Le projet pilote tant l pour tester la mthode Scrum, l quipe a normalement rencontr quelques difficults : Le changement d habitudes de travail : utiliser un outil de suivi de projet, Scrums quotidiens, et travail en quipe ; Le travail en quipe : aprs plusieurs annes passes travailler seul ou en binme, il faut rapprendre la rpartition 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 problmes d affinits ; Le respect du concept de timebox : le manque d habitude de l quipe et des clients entrane des runions 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 rgles mtier, etc.). Une des difficults potentielles identifies au lancement du projet, inhrentes ses spcificits, s est confirme dans la pratique : la difficult dans l expression des besoins par les clients de la partie logicielle. En effet, comme expliqu prcdemment, les clients n en sont pas vraiment, et nous leur avons demand de bien vouloir jouer ce rle. Un temps d adaptation a t ncessaire, mais aprs le premier sprint, ils se sont bien intgrs leur rle, et ont commenc identifier des besoins intressants. Tout cela a cot plus de temps que ce quoi on peut s attendre en temps normal.\n01/09/2006 Page 31 sur 35\na - Intrts du stage Ce stage a prsent des intrts certains. En effet, si mes prcdents 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 dcouvrir une autre approche du monde informatique, d acqurir quelques techniques rudimentaires, et de travailler mon regard critique sur les mthodes et les pratiques. La formation et l encadrement quotidien d une quipe de dveloppeurs expriments ont t un vritable dfi au niveau de la communication. Le fait d tre encore scolaris et en stage rend plus difficile l obtention de confiance et de crdibilit vis--vis de personnes d exprience. Dcouvrir les mthodes Agiles et les mettre en application en situation relle m a permis galement d apprendre plus leur sujet : les promesses faites, les promesses tenues, les difficults de mise en place, etc. b - Enseignements appliqus Bien que la dominante de ce stage soit les mthodes Agiles, on peut relier un certain nombre d enseignements dispenss pendant ma scolarit l IUP ISI : Gestion des risques : prvoir, anticiper et prvenir les risques lis aux choix du projet pilote ; Mthodologie : analyser les atouts et faiblesses des mthodologies connues, pour avoir un regard critique pertinent sur les mthodes Agiles ; Schma Navigationnel d Interface ; BE : premire exprience de Scrum, et outillage de la mthode avec IceScrum ; c - Connaissances complmentaires J ai eu besoin pour ce stage d acqurir de nouvelles connaissances : Mthodes Agiles : un gros travail d autoformation a t ncessaire l aide de documentation sur Internet fournie par des spcialistes 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 dispenss 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 intrt 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 mtier d actualit. Les mthodes Agiles prsentent donc un sujet de blog trs intressant.\n01/09/2006 Page 32 sur 35\nC est pourquoi j ai dcid rapidement d ouvrir mon propre blog, d une part pour raconter l exprience de mon stage vis--vis des mthodes Agiles, et d autre part pour dbattre de points de vue sur les diffrentes pratiques de ces mthodes. Les blogs, support de publication d articles, permettent aujourd hui d effectuer des trackbacks (ou rtroliens ), qui consistent publier un article sur son blog en rponse un article d un autre blog. Ce mcanisme permet ainsi de crer des liens entre blogs et d entrer en contact avec d autres personnes. C est de cette faon que j ai eu la chance d tre contact par OCTO Technology, socit de conseil en urbanisme et mthodologies Paris, qui m a suggr de dposer 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 dveloppement du logiciel IceScrum, dans une mesure rduite du fait de mon activit du stage. Suite la suggestion de Claude Aubry, j ai galement rcrit l article Scrum dans Wikipedia, l encyclopdie libre d Internet. L article existant tait plus ou moins la traduction d une publication ancienne des fondateurs de Scrum. Certains concepts exprims dans cette publication ont depuis volus, et il tait ncessaire de remettre plat l article et de le structurer comme un article encyclopdique. f - Objectifs personnels Au tout dbut du stage, je m tais donn comme objectif de russir faire migrer officiellement le service des dveloppements internes vers des mthodes Agiles. Ce dfi, trs ambitieux, je n ai pas russi le relever compltement. Nanmoins, le projet pilote est bien mis en place, et la mthode a au moins convaincu l quipe pilote. Les autres dveloppeurs n ayant pas pu encore l exprimenter, ils ne sont peut-tre pas autant favorables. Pour l instant le projet pilote n a pas fourni assez d lments pour prsenter la direction le projet de migration complte du service RIL. On peut esprer que d ici environ 4 mois, les lments de retour du projet pilote permettront de dterminer de faon fiable si la mthode Scrum est applicable et intressante pour le RIL. g - Projet professionnel Les stages successifs l IUP ISI m ont permis de dcouvrir plusieurs approches des mtiers de l informatique : le dveloppement, la prise en main MOE et MOA d un projet, et cette anne le conseil et la formation. Ma dernire anne touchera le domaine de l IHM, o je dcouvrirais probablement encore une autre facette de l informatique. Il est donc difficile pour moi aujourd hui de savoir avec prcision quel projet professionnel je peux envisager, mais j espre m tre assur de possder un champ de connaissances suffisamment vaste pour pouvoir rebondir sur les opportunits qui se prsenteront dans ma carrire.\n01/09/2006 Page 33 sur 35\nLes IUP ont fait le choix d intgrer dans leur cursus de nombreux stages en entreprise. Ce stage confirme une fois de plus la pertinence de ce choix de par ses qualits pdagogiques et professionnelles. Il a en effet t pour moi une exprience nouvelle, puisque j ai pu dcouvrir un nouveau contexte d entreprise. Il m a permis par ailleurs de consolider les connaissances thoriques et pratiques en matire de mthodologie, tout en tudiant des nouvelles alternatives aux mthodologies classiques . Une analyse du terrain nous a orients vers l utilisation d une mthode Agile : Scrum. Une telle mthode ncessite beaucoup de changements dans l organisation de l entreprise, et une nouvelle faon de voir un projet informatique. Tous ces lments sont des risques d chec potentiels, et il est indispensable de faire le ncessaire pour les viter ou les contrler le cas chant. Nous avons ainsi mis en place ensemble un projet pilote, dont l objectif tait de mettre l preuve la mthode 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 dj permis une premire valuation de la mthode, et bien que quelques difficults subsistent, il en ressort beaucoup de points positifs. Analyser une situation, discerner les problmes, trouver des solutions tout en valuant les risques lis aux changements requis, prparer et former, suivre, guider, sont autant de comptences ncessaires pour faire un travail efficace de conseil. J ai pu ainsi avoir un avant-got du mtier de consultant, me heurter aux difficults de communication, aux prjugs, aux caractres, aux passs de personnes exprimentes, et aux longues heures de prparation d une formation. Si je ne peux aujourd hui avoir la prtention de devenir rapidement consultant, j ai dcouvert une nouvelle orientation possible pour mon futur, et ajout une exprience riche mon champ de connaissances. J espre que tout le travail que nous avons effectu aboutira au succs de la mthode Scrum, sa gnralisation tous les dveloppeurs, et sa reconnaissance de la direction. Cela serait un pas supplmentaire dans la progression des mthodes 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.\n01/09/2006 Page 34 sur 35\nAgile Backlog de produit Backlog de sprint Base de donnes Bug BugTracker CNAM CPAM Ergonomie Nom d une famille de mthodes de dveloppement de logiciels qui possdent des caractristiques communes particulires Liste des fonctionnalits que devra raliser le logiciel une fois termin Liste des tches faire par l quipe l intrieur d un sprint Ensemble de fichiers permettant le stockage permanent de donnes, respectant un certain modle propre la nature de la base de donnes (relationnelle, objet, etc.). Faille du logiciel pouvant avoir de multiples raisons techniques. Outil permettant de recenser les bugs, les suivre et les affecter des dveloppeurs. Caisse Nationale d Assurance Maladie, qui rgit 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 interprtable. Dsigne l ensemble des interfaces (virtuelles ou relles) entre un utilisateur et une machine. Dans le cas d un logiciel, dsigne la fois les mthodes de saisie et la reprsentation visuelle l utilisateur. Un lment dans un backlog Priode de temps de quelques semaines au bout de laquelle est accomplie un ensemble d activits lies la mthode utilise Processus mis en uvre pour concevoir, raliser, et tester un logiciel. Priode de temps au bout de laquelle est publie une version de logiciel aboutie Rseau et Informatique Locale Mthode de dveloppement faisant partie de la famille des mthodes Agiles Modle permettant la modlisation 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. Itration l intrieur de la mthode Scrum, au terme de laquelle un logiciel partiel est prsent et doit fonctionner Mthode de dveloppement faisant partie de la famille des mthodes Agiles\nIHM (Interface Homme Machine) Item de backlog Itration Mthode / Processus Release RIL Scrum SNI (Schma Navigationnel d Interface) Sprint XP (eXtreme Programming)\n01/09/2006 Page 35 sur 35\nIUP ISI Master I. Ingnierie du logiciel , 2006. IUP ISI Master I. Ingnierie des systmes , 2006.\nMARTIN, 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 .\nSupport de formation : Processus et pratiques Agiles\nSupport de formation : Scrum\nSupport de formation : Gestion Agile des besoins\nPrsentation clients : Mener bien un projet Agile\nArticle Scrum dans Wikipedia\nExtraits de mon blog : Billets sur Scrum et mon stage\nDocuments similaires à Méthode Agile


Ne gérez que l'essentiel des fonctions d'entraîneur dans Football Manager 2019 Touch, l'alternative léchée et plus légère à la simulation de gestion de football favorite des joueurs.\nFootball Manager 2019 est VOTRE chance de prendre le contrôle du club que vous aimez pour le lancement de la nouvelle saison le 2 novembre. De nouvelles fonctionnalités et améliorations rendent votre simulation de gestion de football préférée plus réaliste que jamais.\nDans l'une des extensions les plus approfondies de l'histoire de Cities: Skylines, Industries approfondit grandement le fonctionnement de l'industrie dans le jeu. Cela permet aux joueurs de non seulement construire plusieurs dizaines voire centaines de nouveaux bâtiments industriels\nStratégie 17,99€ -10% 16,19€\nStratégie 89,99€ -10% 80,99€\nRPG (Jeu de Rôle) / Arcade & Indie 3,99€\nStratégie 25,00€ -10% 22,49€\nSimulation 11,99€ -17% 9,99€\nStratégie 9,99€ -15% 8,49€


Critiques Séries : Devious Maids. Saison 4. Episode 6. - Critiques séries et ciné, actu - Breaking News, ça déborde de potins\nDevious Maids // Saison 4. Episode 6. The Maid Who Knew Too Much.\nDevious Maids continue sur sa bonne lancée cette année avec de nouvelles histoires de secrets, de nouvelles morts et tout ce qu’il faut pour que nos bonnes préférées soient au top de leur forme. Rosie se plonge un peu plus dans le cercle, et va même se faire du mal en cours de route. Carmen tente de pousser sa carrière un pas en avant et elle n’a pas envie de penser qu’elle est vieille. Zoila veut que Frances sache que Kyle sortait avec elle mais elle n’a pas vraiment eu la réponse qu’elle attendait et le nouvel homme d’Evelyn était peut-être bien que l’on ne pouvait l’espérer. La grande partie de l’épisode était peut-être celle de la mort de Ben, mais chacun des personnages a eu quelque chose à dire d’intéressant. La mort de Ben permet encore une fois de faire avancer l’histoire et de nous dire qu’au fond Devious Maids n’est pas comme les autres. Accessoirement, Genevieve rejoint le culte et c’est quelque chose qui se passe bien au delà de mes attentes. Si quelqu’un devait infiltrer quelque chose c’est bien elle. Genevieve est amusante et en plus de ça, elle permet réellement de faire avancer l’histoire de la saison. En alliant l’utile à l’agréable, Devious Maids fait donc enfin de belles choses.\nDe plus, Genevieve qui aide Rosie était l’une des meilleures parties de l’épisode, mais plus l’on en sait de choses et moins Rosie semble saine et sauve. Ben a été tué et au fond il a eu tout ce qu’il méritait. Même Frances réalise que Ben a fait le mauvais choix même si elle était plus inquiété par Tucker. Sa mort n’était pas choquante mais je suis content de voir que la série ait décidé de liquider un personnage qui en avait sacrément besoin. Cela veut dire qu’au fond nous allons pouvoir voir la soeur de Peri débarquer, ce qui pourrait soit mettre encore plus en danger soit aider Rosie. Mais pour le moment, on ne peut qu’attendre le résultat. L’histoire de Marisol et de son film n’est pas ce que j’aime le plus dans Devious Maids. La série a beau faire des trucs sympathiques avec ses personnages, je ne suis pas le premier convaincu de l’histoire de Devious Maids ici. La direction que prend l’histoire de Marisol semble clairement l’éloigner de tout le monde alors qu’il aurait été intelligent de justement faire des choses légèrement différentes. Peut-être en allant un peu plus loin. Cela aurait été au moins logique. Finalement, le prochain épisode devrait répondre à pas mal de nos prières en espérant que les promesses soient tenues.\nNote : 7/10. En bref, dans une très solide saison pour Devious Maids, la série continue de surprendre.