Methode Agile PDF

Rapport de stage
« Migration Agile du RIL »
Frédéric MONJO
Master I
Année 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
Remerciements
Avant toute chose, il est pour moi indispensable de remercier tous ceux qui m’
ont
accompagnés dans le déroulement de ce stage.
Je commencerais donc par Brice JONES, responsable de l’ équipe RIL, avec qui nous
avons réalisé un travail de fond sur l’
étude et l’
organisation des ressources matérielles et
humaines. Sa grande disponibilité d’écoute et son implication ont permis à ce stage de se
dérouler du mieux qu’il se peut.
L’ autre acteur principal de ce stage a été l’équipe « pilote » qui a mis en place et
expérimenté la nouvelle méthodologie proposée. Je leur dois beaucoup pour leur
investissement dans la mise en pratique de concepts qui sont parfois difficiles à intégrer. Un
merci spécial à Philippe MERIC qui m’a accueilli comme collègue et comme gendre.
Je remercie également toutes les autres personnes du RIL et du SESI, pour leur accueil
convivial, leur sympathie et leur bonne humeur.
Je remercie enfin les responsables de services qui m’

ont accueilli pour répondre à mes
interviews.
Table des matières
Introduction................................................................................................................................ 1
I - Contexte du stage ................................................................................................................ 2

1 - L’
organisme de Sécurité Sociale ..................................................................................................... 2
2 - La CPAM de Toulouse ....................................................................................................................... 3
3 - L’
Informatique Locale ....................................................................................................................... 4
4 - Le projet de refonte méthodologique............................................................................................ 4
II - Analyse de la situation ........................................................................................................ 5

1 - Méthodologie officielle ..................................................................................................................... 5
2 - Interviews............................................................................................................................................. 6
a - Développeurs ....................................................................................................................................................... 6
b - Direction ................................................................................................................................................................ 6
3 - Groupe de travail .............................................................................................................................. 6
4 - Bilan...................................................................................................................................................... 6
a - Attentes des développeurs ............................................................................................................................... 6
b - Attentes de la direction ..................................................................................................................................... 7
c - Risques identifiés .................................................................................................................................................. 8
5 - Présentation des méthodes Agiles ................................................................................................ 10
6 - Les réponses « Agiles » ..................................................................................................................... 10
a - Propositions d’
amélioration.............................................................................................................................10
b - Adéquation à l’ Agilité ......................................................................................................................................13
III - Mise en place du projet pilote ........................................................................................ 14

1 - La nécessité d’
un « pilote »............................................................................................................. 14
2 - Actions préparatoires ...................................................................................................................... 14
3 - Choix de la méthodologie ............................................................................................................. 15
a - Les alternatives principales..............................................................................................................................15
b - Le choix de la méthode « Scrum » .................................................................................................................15
4 - Choix du projet................................................................................................................................. 16
a - Alternatives .........................................................................................................................................................16
b - Difficultés .............................................................................................................................................................17
5 - Structuration de l’
équipe................................................................................................................ 17
6 - Planification de la migration .......................................................................................................... 17
a - Structure du projet.............................................................................................................................................17
b - Planning...............................................................................................................................................................18
7 - Positionnement personnel .............................................................................................................. 18
a - Analyse ................................................................................................................................................................18
b - Formation ............................................................................................................................................................18
c - Coaching ............................................................................................................................................................19
d - Aide à la formation ...........................................................................................................................................19
e - Outils de support................................................................................................................................................19
f - Assistance en ergonomie des applications...................................................................................................19
IV - Déroulement du projet pilote .......................................................................................... 21

1 - Backlog du produit .......................................................................................................................... 21
2 - Déroulement des sprints.................................................................................................................. 22
a - Sprint 1 .................................................................................................................................................................22
b - Sprint 2 .................................................................................................................................................................23
c - Sprint 3..................................................................................................................................................................23
d - Sprint 4 .................................................................................................................................................................24
3 - Vélocité moyenne de l’
équipe ..................................................................................................... 25
4 - Statistiques des releases .................................................................................................................. 25
a - Phase « technique » ..........................................................................................................................................25
b - Phase « logicielle ».............................................................................................................................................26
V - Bilan du stage .................................................................................................................... 27

1 - Bilan professionnel............................................................................................................................ 27
a - Préparation .........................................................................................................................................................27
b - Formation ............................................................................................................................................................27
c - Objectifs atteints et restants ............................................................................................................................27
d - Scénario envisagé.............................................................................................................................................29
e - Bénéfices.............................................................................................................................................................29
f - Difficultés ..............................................................................................................................................................30
2 - Bilan personnel ................................................................................................................................. 31
a - Intérêts du stage................................................................................................................................................31
b - Enseignements appliqués ................................................................................................................................31
c - Connaissances complémentaires..................................................................................................................31
d - De l’intérêt d’un « blog » ..................................................................................................................................31
e - Contributions au monde libre .........................................................................................................................32
f - Objectifs personnels ...........................................................................................................................................32
g - Projet professionnel ...........................................................................................................................................32
Conclusion ............................................................................................................................... 33
Glossaire et Acronymes.......................................................................................................... 34
Bibliographie ............................................................................................................................ 35
Rapport de stage 01/09/2006
Institut Universitaire Professionnalisé
Ingénierie des Systèmes Informatiques Page 1 sur 35
Université Paul Sabatier Toulouse III Frédéric Monjo
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.
I - Contexte du stage
1 - L’
organisme de Sécurité Sociale
Si la sécurité sociale telle qu’on la connaît aujourd’ hui a été créée en 1945, il n’
en
demeure pas moins que ses origines remontent à la Révolution de 1789. A cette époque les
solidarités se restreignaient au cadre familial ou professionnel (corporations).
Il faudra ainsi attendre la phase d'industrialisation du XIXème siècle pour voir se

développer, non sans débats et hésitations :
 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
vieillesse, CNAF pour les allocations familiales) plus ACOSS pour les finances, institution en
1996 des conseils de surveillance auprès des caisses nationales et des unions régionales de
caisses d'assurance maladie.
Le financement de la sécurité sociale s'est aussi modifié depuis 1945. Bien que les
cotisations assises sur la masse salariale représentent encore la principale ressource des
régimes, la part des autres recettes (taxes fiscales, Contribution Sociale Généralisée,
contribution sociale de solidarité à la charge des entreprises, Contribution au
Remboursement de la Dette Sociale) croît rapidement.
Le système français de sécurité sociale se caractérise donc aujourd'hui par une

protection contre les risques sociaux généralisée à l'ensemble de la population mais éclatée
entre de nombreuses institutions faisant appel à des sources diversifiées de financement.
2 - La CPAM de Toulouse
La Caisse Primaire d'Assurance Maladie de la Haute-Garonne est un organisme de droit

privé qui gère une mission de service public. Elle assure plusieurs missions :
 Rembourser les prestations de l'Assurance Maladie au titre des risques maladie,

maternité, décès, invalidité et accident du travail - maladie professionnelle pour
les bénéficiaires du régime général
 Participer à la politique de maîtrise des dépenses de santé (campagnes

d'information dirigées vers nos différents publics, prévention des risques,
contrôle)
 Simplifier l'accès aux soins et accélérer les remboursements (faciliter l'utilisation

de la carte Vitale et accompagner l'informatisation des professionnels de santé)
 Lutter contre les exclusions et garantir les droits à la santé pour tous
 Offrir un service de proximité, adapté à nos différents publics
Quelques chiffres :
 1 100 agents au service de plus d'1 million bénéficiaires du régime général, soit
89% de la population ;
 12 agences et 6 permanences de proximité, soit 500 000 personnes reçues

chaque année ;
 1 plate-forme de service téléphonique qui traite dans l'année plus de 600 000
appels ;
 1 site Internet local d'informations et de service (230 000 connections par an) ;
 Plus de 23 millions d'opérations de paiement traitées chaque année, soit environ

90 000 opérations par jour ;
 2,6 milliards d'euros de dépenses remboursées en 1 an, soit 2 100 euros par
personne protégée et par an ;
 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 Réseau Infor. Locale Appli. Production Interne

Dominique LETOUZEY Brice JONES 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.
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
Cahier des charges
Règles de conception de l’
IL
PV Approbation Cahier des charges
Réalisation
Manuel d’
exploitation et d’
administration
Opérations de maintenance Test

pouvant entraîner une
reprise du processus PV de validation définitive
Manuel utilisateur
Généralisation
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.
2 - Interviews
L’
utilisation d’
interviews individuelles permet d’ obtenir différentes visions sur l’
approche
méthodologique d’ un projet. Deux points de vue m’ ont semblés essentiels : celui des
développeurs sur le terrain, et celui de la direction plus macroscopique.
a - Développeurs
Les interviews des développeurs ont été réalisées sur la base d’

un questionnaire simple :
 Quelle est votre démarche personnelle pour réaliser un projet (organisation,

méthodologie, documentation, etc.) ?
 Quels sont les projets sur lesquels vous avez travaillé ? Pour chacun, quelles sont
les difficultés rencontrées ?
 Quelles sont vos remarques ?
Une fois ces données collectées, j’

ai dressé un bilan pour chaque développeur, puis
pour l’
ensemble des développeurs.
b - Direction
Les interviews de la direction ont été réalisées à partir d’

un questionnaire plus élaboré :
 Quelles sont vos missions vis-à-vis de l’

informatique locale ?
 Quelles sont vos attentes envers le RIL ?
 Quelles sont les métriques que vous souhaiteriez posséder sur le RIL ?
 Quels sont les artefacts que vous souhaiteriez posséder venant du RIL ?
De la même manière, les données collectées ont été synthétisées pour chaque
personne interrogée, puis de façon globale.
3 - Groupe de travail
A partir des problèmes recensés dans les interviews, nous avons discuté des solutions
possibles pendant une séance organisée en groupe de travail. Ce type de séance est inspiré
des concepts de « management collaboratif » : impliquer les intervenants en les faisant
réfléchir aux solutions, tout en fournissant des éléments-clés sur la solution finale qui sera
adoptée. Ici, l’
idée était d’introduire des éléments des méthodes Agiles comme réponse aux
problèmes identifiés.
4 - Bilan
a - Attentes des développeurs
La synthèse des interviews des développeurs a mis en évidence les problèmes

classiques liés à l’
utilisation d’
une méthodologie de type « cascade ». Voici les attentes
exprimées :
 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
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.
Risques organisationnels
Famille Problème Risques
- Connaissance du projet centralisée sur une personne
Projets individuels ou par 2 maximum
- Compétences acquises par une seule personne
- Priorités des projets changeantes
- Perte de temps due au changement de contexte
4 à 5 projets simultanés par personne
fréquent
- Perte de productivité sur tous les projets
Projets
Pas de vérification de l'existant au - Redondance de bases de données
lancement d'un projet - Redondance de fonctionnalités
- Interruptions fréquentes d'un projet pour un autre
Tous les projets sont urgents !
fréquent
- Perte de qualité du travail
- Développeurs interrompus trop souvent
- Perte de concentration
Appels téléphoniques incessants, pour
des raisons souvent futiles
fréquent
- Perte importante de productivité
Hotline inefficace : transfère les - Diagnostic d'erreur faite par les développeurs : perte de
problèmes sans vrai diagnostic, alors temps
Environnement qu'ils s'agit souvent de droits d'accès - Perte de temps due au changement de contexte
ou de configuration système / réseau. fréquent
- Communication plus difficile dans l'équipe
Bureaux séparés
- Moins d'esprit d'équipe
- Conditions de travail désagréables
Bureaux mal rangés - Perte de temps à chercher des documents
- Documents obsolètes
Interruptions très fréquentes des projets fréquent
pour des opérations de maintenance - Perte de temps pour des corrections mineures qui
urgentes peuvent être reportées à 90% des cas à la fin du projet
courant
Maintenance Utilisateurs peu expérimentés en
- Nombreuses évolutions demandées
informatique, ne testent pas ou testent
- Nombreux bugs découverts après la livraison
mal
Administration des bases de données - Modifications ouvertes à tous
non attribuée à temps plein sur une - Aucun responsable en cas de problème
personne - Aucune personne à qui se référer en cas de problème
Risques méthodologiques
Famille Problème Risques
- Effet tunnel pour les utilisateurs
- Planification mal évaluée
Méthode actuelle anarchique, souvent
Méthode - Estimations mal évaluées
de type cascade
- Produit final non conforme aux vrais besoins des
utilisateurs
- Cahier des charges peu clair et interprété différemment

- Produit livré ne répond pas aux attentes initiales des
Besoins mal exprimés / mal compris
utilisateurs
- Maintenance évolutive importante après la livraison
- Prise en compte très tardive dans le projet

Besoins changeants
Besoins
Utilisateurs finaux masqués par leur - Besoins exprimés en désaccord avec les vrais besoins
chef de service qui ne veut pas les des utilisateurs
libérer - Nombreuses modifications demandées après la livraison
- Produit livré ne répond pas aux attentes initiales des

Besoins recueillis auprès des mauvais
utilisateurs
utilisateurs
- Délais non respectés
Pas de planification efficace
- Gestion du projet chaotique
Estimations rarement faites, et si c'est - Difficulté à estimer

Planification et le cas en jours-hommes - Pertinence des estimations
Estimation
Avancement du projet interrompu très
- Délais non respectés
souvent par des opérations de
- Gestion du projet chaotique
maintenance
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.
Risques organisationnels
Famille Problème Solution Agile Bénéfices attendus
- Connaissance commune du projet
Projets individuels ou par Travail en deux équipes de 4
- Compétences acquises par toute
2 maximum personnes
l'équipe
- Projets aboutis rapidement
4 à 5 projets simultanés - Enchaînement des projets rapide
Un seul projet à la fois pour l'équipe
par personne - Développeurs au maximum de leur
Projets
productivité
Pas de vérification de Référencer tous les projets avec les
l'existant au lancement fonctionnalités implémentées et les - Plus de redondances inutiles
d'un projet schémas de données
Tous les projets sont On n'interrompt jamais un projet en
Idem ci-dessus
urgents ! cours
- Seuls les appels vraiment
Appels téléphoniques importants sont transmis
Filtrer les appels vers l'équipe par un
incessants, pour des - Meilleure concentration de l'équipe
seul point d'entrée : le ScrumMaster
raisons souvent futiles - Développeurs au maximum de leur
productivité
Hotline inefficace : Isoler l'équipe des problèmes de
transfère les problèmes Hotline, ne lui transférer que des Idem ci-dessus
sans vrai diagnostic. appels justifiés et diagnostiqués
Environnement
- Meilleure concentration
Tous les membres de l'équipe sont - Meilleure communication
Bureaux séparés
dans la même pièce, isolée et calme - Esprit de groupe solidaire
- Résolution rapide des problèmes
- Bien-être des développeurs
- Meilleure productivité
Bureaux mal rangés Pièce bien rangée, cadre agréable
- Meilleure ambiance
- Documentation efficace
- Interdire l'interruption d'un projet
(recenser les opérations demandées
Interruptions très et les réaliser après la fin du projet en - Continuité du projet
fréquentes des projets cours, avant d'entamer le projet - Meilleure productivité
pour des opérations de suivant) - Intervention seulement dans les
maintenance urgentes - Evaluer finement l'urgence de la vrais cas d'urgence
Maintenance modification demandée (très souvent
urgent sans l'être vraiment)
- Les tests peuvent être guidés dans
Utilisateurs peu - Les utilisateurs font partie de
un premier temps par l'équipe
expérimentés en l'équipe et testent souvent
- Un utilisateur ne teste que les
informatique, ne testent - Identification de rôles utilisateurs
fonctions qui le concernent, pas toute
pas ou testent mal plutôt que de personnes
l'application (donc tests mieux ciblés)
Risques méthodologiques
Famille Problème Solution Agile Bénéfices attendus
- Démarche itérative, pas d'effet tunnel

- Planification intelligente
Méthode actuelle
Passer à une méthode - Estimations meilleures et qui s'améliorent
Méthode anarchique, souvent de
Agile (Scrum, XP) - Produit final très proche des besoins utilisateur
type cascade
- Qualité du produit améliorée
- Productivité très augmentée
- Compréhension partielle dans un premier
temps, puis explication orale au moment de
Besoins mal exprimés /
Utiliser des User Stories l'implémentation, donc bien comprise
mal compris
- Fonctionnalités raffinées, petites, simples à
comprendre et estimer
- A chaque sprint, choix des US réalisées
Utiliser des User Stories - L'ordre et les US peuvent changer avant
Besoins changeants
priorisées d'attaquer un nouveau sprint (sans impacter le
sprint courant)
Besoins
Utilisateurs finaux Identifier des rôles
masqués par leur chef utilisateurs et un - Plus grande pertinence des besoins car
de service qui ne veut représentant de chaque localisés à des rôles donc plus précis
pas les libérer rôle
- Les besoins sont exprimés par rôles donc mieux
Besoins recueillis appréhendés
Utiliser des rôles
auprès des mauvais - Plusieurs points de vue sur l'application
utilisateurs
utilisateurs - Logiciel fourni en accord avec les vrais besoins
de tous les utilisateurs
Planification agile en
- Pertinence de la planification par retour
deux étapes :
d'expérience rapide et fiable au niveau release
Pas de planification - Sur une release
- Avancement apparent sur chaque sprint (reste à
efficace (vélocité)
faire qui diminue, donnée fiable)
- Sur chaque sprint
- Visibilité excellente sur le projet
(reste à faire)
- Estimation relative sur les fonctionnalités : plus
- Estimations en points facile, plus fiable
Planification et Estimations rarement pour les fonctionnalités - Reste à faire facile à estimer et à mettre à jour
Estimation faites, et si c'est le cas - Estimations en reste à - Retour d'expérience sur les estimations rapide
en jours-hommes faire sur les tâches dans et fiable
un sprint - Raffinement des estimations rapide
- Visibilité excellente sur le projet
Isolement complet de
Avancement du projet - Continuité du projet
l'équipe, interdiction
interrompu très souvent - Opérations reportées en fin de projet et traitées
d'interrompre un sprint en
par des opérations de efficacement
cours ou un projet en
maintenance - Meilleure productivité de l'équipe
cours.
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.
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 » :
 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
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.
Phases de maintenance très

courtes, pour traiter les
urgences survenues pendant
le sprint
Release
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 »

 Les trois applications seront réécrites successivement. Ainsi les deux dernières
seront considérées comme des évolutions de la première, comme des
évolutions des besoins.
b - Difficultés
Néanmoins, ce projet présente des difficultés non négligeables :
 La réalisation d’une couche d’ objets métier ne permet pas facilement

l’
élaboration d’une liste de besoins dont la réalisation est mesurable.
 L’
interface d’ administration des données ne possède pas réellement
d’utilisateurs demandeurs. En effet, la gestion des données des agents a été
confiée à certains agents pour permettre le bon fonctionnement des
applications internes.
Pour pallier au second problème, nous avons demandé à des responsables des
Ressources Humaines de bien vouloir prendre part au projet pilote en tant que demandeurs.
5 - Structuration de l’
équipe
Le fonctionnement nominal du service permettait la réalisation simultanée de

nombreux projets. Il n’était donc pas possible de mobiliser l’ intégralité du service sur deux
projets seulement. Nous avons donc fait le choix de constituer une équipe pilote, à temps
plein sur un unique projet, alors que le reste des développeurs poursuivait un fonctionnement
habituel.
Pour constituer l’
équipe pilote, nous avons retenu les 4 personnes qui avaient le plus
travaillé ensemble par le passé, et qui avaient obtenu de bons résultats. Une fois le projet
pilote terminé, cette équipe serait scindée en deux binômes, qui formeraient ensuite les deux
équipes finales de 4.
6 - Planification de la migration
a - Structure du projet
De par la nature du projet pilote, nous avons identifié deux phases du projet, qui
correspondent à deux releases possibles : une première phase dite « technique » dont le but
est de construire la couche d’ objets métier, et une deuxième dite « logicielle » dont le but est
de construire les logiciels de gestion des données.
La phase logicielle est structurée comme suit :
 Une release qui regroupe le re-développement et l’ unification de deux des

logiciels (TABLE-IL et MAJANNU) sur la nouvelle couche objet
 Une release dédiée au re-développement du troisième logiciel (GEDAM). Cette

dernière est conditionnée par l’arrivée prochaine d’
une application nationale
équivalente, mais peut-être pas suffisante.
b - Planning
Avril Mai Juin

Phase technique
Analyse de la Phase technique
Formation
Lancement
situation
Sprint 1 Sprint 2
( + Autoformation )
Juillet Août Septembre+

Phase logicielle Phase logicielle Phase
Généralisation ?
Maintenance
Maintenance
logicielle
( Sprint 2 )
Sprint 1 Sprint 2 …
Sprint 3
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

 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.
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.
IV - Déroulement du projet pilote

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.
Points
Thème Item
Estimés
Définir les règles de gestion (métier + droits d'accès des applis) pour la
Couche métier 2
manipulation des objets
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
5
ascendante CPAM31
Couche métier Implémenter un système de trace des actions sur la BD 1
Implémenter la récupération automatique des compléments d'infos sur
Un Agent arrive 0
l’
agent
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
Le responsable change l'affectation de son agent à une donnée
Un Agent bouge 1
complémentaire
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
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
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 :
Points
Thème Item
Estimés
Couche métier Le développeur veut accéder à des objets hiérarchiques 5
Vélocité : 5
Burndown chart du sprint :

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
Points
Thème Item
Estimés
Définir les règles de gestion (métier + droits d'accès des applis) pour la
Couche métier 2
manipulation des objets
Couche métier Définir une gestion des verrous 2
Couche métier Le développeur veut accéder à des objets "simples" 3
Vélocité : 7
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
Points
Thème Item
Estimés
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
Vélocité : 4
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 :
Points
Thème Item
Estimés
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
3 - Vélocité moyenne de l’
équipe
La vélocité moyenne de l’équipe est de 5,33 entre avril et août. Cette vélocité est à
pondérer avec le fait que les congés ont diminué l’ effectif de l’équipe de moitié en
moyenne.
Pour estimer la planification du projet à partir de septembre (effectifs complets), nous

avons donc estimé que la vélocité serait de 9.
4 - Statistiques des releases
a - Phase « technique »
Burndown Chart de la release "Phase logicielle"
4
Points Vélocité
3 Reste à faire
0
1 2
Sprints
b - Phase « logicielle »
Burndown Chart de la release "Phase logicielle"
50
45
40
35
30
Points 25
Vélocité
20 Reste à faire
15
10
0
1 2 3 4 5 6 7
Sprints
Sur ce graphique, les deux premiers sprints sont constatés (vélocité de 5,33). Les suivants
sont estimés par rapport à la nouvelle vélocité (9).
V - Bilan du stage
L’
objectif de ce chapitre est d’
établir un bilan du projet du point de vue de l’
entreprise
et du point de vue personnel.
1 - Bilan professionnel
a - Préparation
Les actions de préparation du projet pilote ont été efficaces. En effet, les bureaux sont
mieux rangés, créant ainsi une atmosphère plus agréable, et surtout facilitant l’ accès
efficace aux documentations.
La canalisation de la maintenance a permis de minimiser les irruptions dans la pièce de

l’
équipe de développement, ainsi que les appels téléphoniques. C’ est aussi un contexte qui
favorise un travail efficace dans de bonnes conditions.
Le réaménagement des bureaux est toujours à l’ étude. Il sera probablement

nécessaire de faire déplacer des cloisons amovibles, et cela requiert l’
appréciation et
l’
intervention des personnes qualifiées dans ce domaine.
b - Formation
Le travail de préparation d’ une formation a été pour moi quelque chose de nouveau,
et relativement difficile. Même si je me suis beaucoup inspiré de la documentation trouvée
sur Internet, j’
ai travaillé attentivement le contenu et le plan pour être sûr qu’ ils soient
pertinents. C’est un travail fastidieux.
c - Objectifs atteints et restants
Problème Solution Agile Bénéfices attendus Bénéfices constatés

- Connaissance commune du projet Oui
Projets individuels ou Travail en deux équipes
- Compétences acquises par toute Oui
par 2 maximum de 4 personnes
l'équipe
- Projets aboutis rapidement Non : Retard du projet pilote
4 à 5 projets
Un seul projet à la fois - Enchaînement des projets rapide Non
simultanés par
pour l'équipe - Développeurs au maximum de leur Non : Congés d’été
personne
productivité
Référencer tous les
Pas de vérification
projets avec les
de l'existant au
fonctionnalités - Plus de redondances inutiles ? Pas de mesure disponible
lancement d'un
implémentées et les
projet
schémas de données
Tous les projets sont On n'interrompt jamais un
Idem ci-dessus Oui
urgents ! projet en cours
Appels - Seuls les appels vraiment
téléphoniques 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'entrée : le ScrumMaster - Développeurs au maximum de leur
futiles productivité
Isoler l'équipe des - Seuls les appels vraiment Oui

Hotline inefficace :
problèmes de Hotline, ne importants sont transmis
transfère les
lui transférer que des - Meilleure concentration de l'équipe Oui
problèmes sans vrai
appels justifiés et - Développeurs au maximum de leur Oui
diagnostic.
diagnostiqués productivité
Tous les membres de - Meilleure concentration
l'équipe sont dans la - Meilleure communication
Bureaux séparés ? Pas encore mis en place
même pièce, isolée et - Esprit de groupe solidaire
calme - Résolution rapide des problèmes
- Bien-être des développeurs Oui
Pièce bien rangée, cadre - Meilleure productivité Oui
Bureaux mal rangés
agréable - Meilleure ambiance Oui
- Documentation efficace Oui
- Interdire l'interruption
d'un projet (recenser les
opérations demandées et
Interruptions très les réaliser après la fin du
fréquentes des projet en cours, avant - Continuité du projet Oui
projets pour des d'entamer le projet - Meilleure productivité Oui
opérations de suivant) - Intervention seulement dans les Oui
maintenance - Evaluer finement vrais cas d'urgence
urgentes l'urgence de la
modification demandée
(très souvent urgent sans
l'être vraiment)
- Les utilisateurs font - Les tests peuvent être guidés dans
Utilisateurs peu
partie de l'équipe et un premier temps par l'équipe
expérimentés en
testent souvent - Un utilisateur ne teste que les
informatique, ne ? Pas de mesure disponible
- Identification de rôles fonctions qui le concernent, pas
testent pas ou
utilisateurs plutôt que de toute l'application (donc tests mieux
testent mal
personnes ciblés)
- Démarche itérative, pas d'effet Oui
tunnel
- Planification intelligente Oui
Méthode actuelle - Estimations meilleures et qui Oui
Passer à une méthode
anarchique, souvent s'améliorent
Agile (Scrum, XP)
de type cascade - Produit final très proche des Oui
besoins utilisateur
- Qualité du produit améliorée Oui
- Productivité très augmentée Non : Temps d’
adaptation
- Compréhension partielle dans un Oui
premier temps, puis explication orale
Besoins mal
au moment de l'implémentation,
exprimés / mal Utiliser des User Stories
donc bien comprise
compris
- Fonctionnalités raffinées, petites, Oui
simples à comprendre et estimer
- A chaque sprint, choix des US
réalisées Oui
Utiliser des User Stories
Besoins changeants - L'ordre et les US peuvent changer
priorisées
avant d'attaquer un nouveau sprint Oui
(sans impacter le sprint courant)
Utilisateurs finaux
Identifier des rôles
masqués par leur - Plus grande pertinence des
utilisateurs et un
chef de service qui besoins car localisés à des rôles Oui
représentant de chaque
ne veut pas les donc plus précis
rôle
libérer
- Les besoins sont exprimés par Oui

rôles donc mieux appréhendés
Besoins recueillis
Utiliser des rôles - Plusieurs points de vue sur Oui
auprès des mauvais
utilisateurs l'application
utilisateurs
- Logiciel fourni en accord avec les ? Pas de mesure disponible
vrais besoins de tous les utilisateurs
- Pertinence de la planification par Oui
Planification agile en
retour d'expérience rapide et fiable
deux étapes :
au niveau release
Pas de planification - Sur une release
- Avancement apparent sur chaque Non : Saisie non régulière des
efficace (vélocité)
sprint (reste à faire qui diminue, données
- Sur chaque sprint
donnée fiable)
(reste à faire)
- Visibilité excellente sur le projet Oui
- Estimation relative sur les Oui
fonctionnalités : plus facile, plus
fiable
- Estimations en points
Estimations rarement - Reste à faire facile à estimer et à Oui
pour les fonctionnalités
faites, et si c'est le mettre à jour
- Estimations en reste à
cas en jours- - Retour d'expérience sur les Oui
faire sur les tâches dans
hommes estimations rapide et fiable
un sprint
- Raffinement des estimations Oui
rapide
- Visibilité excellente sur le projet Oui
Avancement du Isolement complet de
- Continuité du projet Oui
projet interrompu l'équipe, interdiction
- Opérations reportées en fin de Oui
très souvent par des d'interrompre un sprint en
projet et traitées efficacement
opérations de cours ou un projet en
- Meilleure productivité de l'équipe Oui
maintenance cours.
d - Scénario envisagé
La durée restante du projet pilote est estimée à 5 sprints de 3 semaines. Au terme de ce

projet, indispensable pour le bon fonctionnement de la caisse, un bilan sera établi sur les
apports de la méthode Scrum. S’ il est montré qu’
elle a permis un réel gain de productivité et
de qualité, elle sera probablement généralisée à tous les développeurs. Il est également
envisageable qu’ elle soit généralisée assez rapidement pour la tester en grandeur nature.
e - Bénéfices
La méthode Scrum a prouvé que ses principes fondamentaux apportent les avantages
promis :
 Le développement itératif permet de donner un rythme au projet, et de livrer un

logiciel qui fonctionne à intervalles réguliers. C’
est un atout tant pour le client,
qui voit que le projet avance, que pour l’ équipe, qui voit qu’elle avance de
façon régulière.
 La forte collaboration avec les clients a permis de bien comprendre et

interpréter les besoins, et également de faire exprimer aux clients des règles
métier parfois complexes, ou des besoins cachés qui sont apparus de proche
en proche avec les autres besoins.
 L’utilisation des User Stories a aussi été fructueuse en ce sens qu’

elles ont permis
d’exprimer les besoins de façon atomique, de les estimer plus facilement et de
façon plus fiable.
 Les Scrums quotidiens permettent de faire le point et diffuser l’ avancement du

travail, tout en identifiant les problèmes pour qu’
ils soient traités au plus vite.
Enfin, outre la méthode Scrum, l’ utilisation d’

un SNI pour modéliser l’
interface de
l’
application a été également bénéfique :
 Sa facilité de modélisation permet de concevoir une interface ergonomique

rapidement, et engendre naturellement une bonne qualité de conception ;
 Une fois conçu, le modèle permet de produire l’interface sans avoir à réfléchir à
son contenu, ce qui permet d’être plus efficace ;
 Enfin, sa lecture facile permet aux clients d’

avoir un aperçu de l’
interface de
leur application.
f - Difficultés
Le projet pilote étant là pour tester la méthode Scrum, l’

équipe a normalement
rencontré quelques difficultés :
 Le changement d’ habitudes de travail : utiliser un outil de suivi de projet, Scrums

quotidiens, et travail en équipe ;
 Le travail en équipe : après plusieurs années passées à travailler seul ou en

binôme, il faut réapprendre la répartition du travail et le respect de ce sur quoi
on s’engage vis-à-vis de l’
équipe ;
 Communication d’équipe : la confrontation de points de vue à 4 est difficile,

notamment avec les problèmes d’affinités ;
 Le respect du concept de « timebox » : le manque d’ habitude de l’

équipe et
des clients entraîne des réunions qui peuvent s’ étaler en longueur. Il a été
difficile de les interrompre ou les raccourcir, car les propos des discussions
étaient fondamentaux (identification de User Stories, explication des règles
métier, etc.).
Une des difficultés potentielles identifiées au lancement du projet, inhérentes à ses

spécificités, s’
est confirmée dans la pratique : la difficulté dans l’
expression des besoins par
les clients de la partie logicielle. En effet, comme expliqué précédemment, les clients n’ en
sont pas vraiment, et nous leur avons demandé de bien vouloir jouer ce rôle. Un temps
d’adaptation a été nécessaire, mais après le premier sprint, ils se sont bien intégrés à leur
rôle, et ont commencé à identifier des besoins intéressants. Tout cela a coûté plus de temps
que ce à quoi on peut s’ attendre en temps normal.
2 - Bilan personnel
a - Intérêts du stage
Ce stage a présenté des intérêts certains. En effet, si mes précédents stages se situaient
dans le domaine de la production de logiciel, celui-ci se situait dans le domaine du conseil.
Cela a été pour moi l’ occasion de découvrir une autre approche du monde informatique,
d’acquérir quelques techniques rudimentaires, et de travailler mon regard critique sur les
méthodes et les pratiques.
La formation et l’encadrement quotidien d’ une équipe de développeurs expérimentés

ont été un véritable défi au niveau de la communication. Le fait d’
être encore scolarisé et en
stage rend plus difficile l’obtention de confiance et de crédibilité vis-à-vis de personnes
d’expérience.
Découvrir les méthodes Agiles et les mettre en application en situation réelle m’ a

permis également d’ apprendre plus à leur sujet : les promesses faites, les promesses tenues,
les difficultés de mise en place, etc.
b - Enseignements appliqués
Bien que la dominante de ce stage soit les méthodes Agiles, on peut relier un certain
nombre d’enseignements dispensés pendant ma scolarité à l’
IUP ISI :
 Gestion des risques : prévoir, anticiper et prévenir les risques liés aux choix du
projet pilote ;
 Méthodologie : analyser les atouts et faiblesses des méthodologies connues,

pour avoir un regard critique pertinent sur les méthodes Agiles ;
 Schéma Navigationnel d’
Interface ;
 BE : première expérience de Scrum, et outillage de la méthode avec IceScrum ;
c - Connaissances complémentaires
J’
ai eu besoin pour ce stage d’
acquérir de nouvelles connaissances :
 Méthodes Agiles : un gros travail d’

autoformation a été nécessaire à l’
aide de
documentation sur Internet fournie par des spécialistes du domaine ;
 Formation : produire un support de formation est quelque chose de difficile, et il

m’ a fallu beaucoup de temps pour mettre au point ces supports, en m’ inspirant
des enseignements dispensés à l’ IUP ;
 Enfin, accompagner une équipe au quotidien n’est pas non plus quelque chose
de simple. J’
ai pu apprendre beaucoup sur ce sujet.
d - De l’
intérêt d’
un « blog »
Si le blog s’
est popularisé pour servir de journal intime public, c’
est un outil professionnel
puissant. En effet, il permet de dialoguer avec d’ autres professionnels sur des sujets métier
d’actualité. Les méthodes Agiles présentent donc un sujet de blog très intéressant.
C’est pourquoi j’ ai décidé rapidement d’ ouvrir mon propre blog, d’une part pour
raconter l’
expérience de mon stage vis-à-vis des méthodes Agiles, et d’ autre part pour
débattre de points de vue sur les différentes pratiques de ces méthodes.
Les blogs, support de publication d’ articles, permettent aujourd’ hui d’effectuer des
« trackbacks » (ou « rétroliens »), qui consistent à publier un article sur son blog en réponse à
un article d’ un autre blog. Ce mécanisme permet ainsi de créer des liens entre blogs et
d’ entrer en contact avec d’ autres personnes.
C’est de cette façon que j’ai eu la chance d’être contacté par OCTO Technology,
société de conseil en urbanisme et méthodologies à Paris, qui m’
a suggéré de déposer ma
candidature chez eux. Je n’ ai malheureusement pas pu postuler du fait que je n’
avais pas
terminé ma scolarité.
e - Contributions au monde libre
Ce stage a été aussi pour moi l’occasion de contribuer au monde libre. J’ ai ainsi
poursuivi ma contribution au développement du logiciel IceScrum, dans une mesure réduite
du fait de mon activité du stage.
Suite à la suggestion de Claude Aubry, j’ ai également réécrit l’ article Scrum dans

Wikipedia, l’encyclopédie libre d’Internet. L’ article existant était plus ou moins la traduction
d’ une publication ancienne des fondateurs de Scrum. Certains concepts exprimés dans
cette publication ont depuis évolués, et il était nécessaire de remettre à plat l’ article et de le
structurer comme un article encyclopédique.
f - Objectifs personnels
Au tout début du stage, je m’ étais donné comme objectif de réussir à faire migrer
officiellement le service des développements internes vers des méthodes Agiles. Ce défi, très
ambitieux, je n’ ai pas réussi à le relever complètement.
Néanmoins, le projet pilote est bien mis en place, et la méthode a au moins convaincu
l’
équipe pilote. Les autres développeurs n’ ayant pas pu encore l’ expérimenter, ils ne sont
peut-être pas autant favorables.
Pour l’instant le projet pilote n’

a pas fourni assez d’ éléments pour présenter à la
direction le projet de migration complète du service RIL. On peut espérer que d’
ici environ 4
mois, les éléments de retour du projet pilote permettront de déterminer de façon fiable si la
méthode Scrum est applicable et intéressante pour le RIL.
g - Projet professionnel
Les stages successifs à l’ IUP ISI m’

ont permis de découvrir plusieurs approches des
métiers de l’informatique : le développement, la prise en main MOE et MOA d’ un projet, et
cette année le conseil et la formation. Ma dernière année touchera le domaine de l’
IHM, où
je découvrirais probablement encore une autre facette de l’ informatique.
Il est donc difficile pour moi aujourd’hui de savoir avec précision quel projet
professionnel je peux envisager, mais j’
espère m’ être assuré de posséder un champ de
connaissances suffisamment vaste pour pouvoir rebondir sur les opportunités qui se
présenteront dans ma carrière.
Conclusion
Les IUP ont fait le choix d’
intégrer dans leur cursus de nombreux stages en entreprise.
Ce stage confirme une fois de plus la pertinence de ce choix de par ses qualités
pédagogiques et professionnelles.
Il a en effet été pour moi une expérience nouvelle, puisque j’ ai pu découvrir un

nouveau contexte d’ entreprise. Il m’
a permis par ailleurs de consolider les connaissances
théoriques et pratiques en matière de méthodologie, tout en étudiant des nouvelles
alternatives aux méthodologies « classiques ».
Une analyse du terrain nous a orientés vers l’ utilisation d’

une méthode Agile : Scrum.
Une telle méthode nécessite beaucoup de changements dans l’ organisation de l’entreprise,
et une nouvelle façon de voir un projet informatique. Tous ces éléments sont des risques
d’ échec potentiels, et il est indispensable de faire le nécessaire pour les éviter ou les contrôler
le cas échéant.
Nous avons ainsi mis en place ensemble un projet pilote, dont l’objectif était de mettre
à l’
épreuve la méthode Scrum dans le contexte de l’ informatique locale. Ce projet n’ est pas
encore terminé à l’ heure de la fin de mon stage, mais il a déjà permis une première
évaluation de la méthode, et bien que quelques difficultés subsistent, il en ressort beaucoup
de points positifs.
Analyser une situation, discerner les problèmes, trouver des solutions tout en évaluant
les risques liés aux changements requis, préparer et former, suivre, guider, sont autant de
compétences nécessaires pour faire un travail efficace de conseil. J’ ai pu ainsi avoir un
avant-goût du métier de consultant, me heurter aux difficultés de communication, aux
préjugés, aux caractères, aux passés de personnes expérimentées, et aux longues heures de
préparation d’ une formation. Si je ne peux aujourd’ hui avoir la prétention de devenir
rapidement consultant, j’ ai découvert une nouvelle orientation possible pour mon futur, et
ajouté une expérience riche à mon champ de connaissances.
J’espère que tout le travail que nous avons effectué aboutira au succès de la méthode
Scrum, à sa généralisation à tous les développeurs, et à sa reconnaissance de la direction.
Cela serait un pas supplémentaire dans la progression des méthodes Agiles en France, et
placerait l’
informatique locale de la caisse de Toulouse comme un exemple d’ adaptation et
d’évolution, et comme un pionnier vis-à-vis des autres caisses d’
assurance maladie.
Glossaire et Acronymes
Nom d’
une famille de méthodes de développement de logiciels qui possèdent des caractéristiques
Agile
communes particulières
Backlog de produit Liste des fonctionnalités que devra réaliser le logiciel une fois terminé
Backlog de sprint Liste des tâches à faire par l’

équipe à l’
intérieur d’
un sprint
Ensemble de fichiers permettant le stockage permanent de données, respectant un certain

Base de données
modèle propre à la nature de la base de données (relationnelle, objet, etc.).
Bug Faille du logiciel pouvant avoir de multiples raisons techniques.
BugTracker Outil permettant de recenser les bugs, les suivre et les affecter à des développeurs.
CNAM Caisse Nationale d’

Assurance Maladie, qui régit toutes les caisses primaires
CPAM Caisse Primaire d’

Assurance Maladie (ici, celle de Toulouse)
Capacité d’une interface entre un outil et un utilisateur à être facilement utilisable et

Ergonomie
interprétable.
Désigne l’ ensemble des interfaces (virtuelles ou réelles) entre un utilisateur et une machine. Dans
IHM (Interface Homme Machine) le cas d’ un logiciel, désigne à la fois les méthodes de saisie et la représentation visuelle à
l’
utilisateur.
Item de backlog Un élément dans un backlog
Période de temps de quelques semaines au bout de laquelle est accomplie un ensemble

Itération
d’
activités liées à la méthode utilisée
Méthode / Processus Processus mis en œuvre pour concevoir, réaliser, et tester un logiciel.
Release Période de temps au bout de laquelle est publiée une version de logiciel aboutie
RIL Réseau et Informatique Locale
Scrum Méthode de développement faisant partie de la famille des méthodes Agiles
SNI (Schéma Navigationnel Modèle permettant la modélisation de l’

interface utilisateur d’
un logiciel. Il a été mis au point par
d’
Interface) M. JB. Crampes, enseignant chercheur de l’Université Paul Sabatier à Toulouse.
Itération à l’
intérieur de la méthode Scrum, au terme de laquelle un logiciel partiel est présenté
Sprint
et doit fonctionner
XP (eXtreme Programming) Méthode de développement faisant partie de la famille des méthodes Agiles
Bibliographie
IUP ISI Master I. « Ingénierie du logiciel », 2006.
IUP ISI Master I. « Ingénierie des systèmes », 2006.
MARTIN, Robert C. “Agile methods: The bottom line”

.
COHN, Mike. “Project Economics: Selecting and prioritizing high-value projects”

.
COHN, Mike. “What’

s holding you back?”
Object Mentor. “The Primavera success story”

.
COHN, Mike. “User Stories Applied”

.
COHN, Mike. “Becoming an effective Scrum Product Owner”

.
COHN, Mike. “What project customers can do to turn a good product into a great one”
.
MARTIN, Robert C. “On analysis”

.
MARTIN, Robert C. “Continuous care vs. Initial design”

.
MARTIN, Robert C. “PERT, CPM, and Agile Project Management”

.
COHN, Mike. “Agile Estimating and Planning”

.
MARTIN, Robert C. “Agile Processes”

.
COHN, Mike and FORD, Doris. “Introducing an Agile process to an organization”

.
COHN, Mike and SCHWABER, Ken. “The need for Agile project management”
.
COHN, Mike. “The upside of downsizing”

.
COHN, Mike. “Toward a catalogue of Scrum smells”

.
Annexe I
Support de formation :
« Processus et pratiques Agiles »
Annexe II
« Scrum »
Annexe III
« Gestion Agile des besoins »
Annexe IV
Présentation clients :
« Mener à bien un projet Agile »
Annexe V
Article « Scrum » dans Wikipedia
Annexe VI
Extraits de mon blog :
Billets sur Scrum et mon stage

Methode Agile PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Methode Agile PDF

Transféré par

Droits d'auteur :

Formats disponibles

Rapport de stage

« Migration Agile du RIL »

Année universitaire 2005 / 2006

Tuteur en entreprise : Sylvie COMBES

Je remercie enfin les responsables de services qui m’

I - Contexte du stage ................................................................................................................ 2

II - Analyse de la situation ........................................................................................................ 5

III - Mise en place du projet pilote ........................................................................................ 14

IV - Déroulement du projet pilote .......................................................................................... 21

V - Bilan du stage .................................................................................................................... 27

Le service « informatique locale » de Toulouse a utilisé depuis longtemps la

Aussi il était nécessaire pour les développeurs d’

 La première partie présente succinctement le contexte du stage ;

 La deuxième partie dresse un bilan de l’

 Puis la troisième partie expliquera comment la nouvelle méthodologie proposée

 La quatrième partie restituera les principaux éléments du déroulement du projet

 Et la cinquième partie dressera un bilan professionnel et personnel de tous les

Il faudra ainsi attendre la phase d'industrialisation du XIXème siècle pour voir se

 Les sociétés de secours mutuels, fondées sur la prévoyance collective volontaire

 L'assistance médicale gratuite (loi du 15 juillet 1893), le service départemental

En respectant leurs principes fondateurs, les mutuelles et l'aide sociale constituent

Les mutuelles et l'aide sociale, fonctionnant alors sous appréciation subjective et

En 1945 les bâtisseurs du système français de sécurité sociale poursuivent un triple

La généralisation de la couverture à toute la population a été poursuivie selon de

Le système français de sécurité sociale se caractérise donc aujourd'hui par une

La Caisse Primaire d'Assurance Maladie de la Haute-Garonne est un organisme de droit

 Rembourser les prestations de l'Assurance Maladie au titre des risques maladie,

 Participer à la politique de maîtrise des dépenses de santé (campagnes

 Simplifier l'accès aux soins et accélérer les remboursements (faciliter l'utilisation

 Offrir un service de proximité, adapté à nos différents publics

 12 agences et 6 permanences de proximité, soit 500 000 personnes reçues

 Plus de 23 millions d'opérations de paiement traitées chaque année, soit environ

 Coût de gestion inférieur à 3% des dépenses.

Maintenance Réseau Infor. Locale Appli. Production Interne

4 - Le projet de refonte méthodologique

La CNAM a publié une méthode de développement interne officielle, de type « cycle

Un groupe de travail a donc été mis en place pour repenser la méthodologie de

Opérations de maintenance Test

Les interviews des développeurs ont été réalisées sur la base d’

 Quelle est votre démarche personnelle pour réaliser un projet (organisation,

 Quelles sont vos remarques ?

Une fois ces données collectées, j’

Les interviews de la direction ont été réalisées à partir d’

 Quelles sont vos missions vis-à-vis de l’

 Quelles sont vos attentes envers le RIL ?

a - Attentes des développeurs

La synthèse des interviews des développeurs a mis en évidence les problèmes

 Améliorer la gestion des besoins :

- Dialoguer avec les bons interlocuteurs

- Mieux recenser et comprendre les besoins 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

- Produire de la documentation utile

- Canaliser et réduire les opérations de maintenance. Produire des FAQ types

- 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

- Systèmes fiables et sécurisés

L’adoption d’ une méthodologie ne se limite pas seulement à l’ application d’ un