Rapport de Stage PDF

Rapport de stage
Migration Agile du RIL

Frdric MONJO
Master I
Anne universitaire 2005 / 2006
Stage du 3 avril 2006 au 1
er
septembre 2006
Caisse Primaire dAssurance 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 mont
accompagns dans le droulement de ce stage.
Je commencerais donc par Brice JONES, responsable de lquipe RIL, avec qui nous
avons ralis un travail de fond sur ltude et lorganisation des ressources matrielles et
humaines. Sa grande disponibilit dcoute et son implication ont permis ce stage de se
drouler du mieux quil se peut.
Lautre acteur principal de ce stage a t lquipe 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 ma 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 mont accueilli pour rpondre mes
interviews.
Table des matires
Introduction................................................................................................................................ 1
I - Contexte du stage................................................................................................................ 2
1 - Lorganisme de Scurit Sociale..................................................................................................... 2
2 - La CPAM de Toulouse ....................................................................................................................... 3
3 - LInformatique Locale....................................................................................................................... 4
4 - Le projet de refonte mthodologique............................................................................................ 4
II - Analyse de la situation........................................................................................................ 5
1 - Mthodologie officielle..................................................................................................................... 5
2 - Interviews............................................................................................................................................. 6
a - Dveloppeurs....................................................................................................................................................... 6
b - Direction................................................................................................................................................................ 6
3 - Groupe de travail .............................................................................................................................. 6
4 - Bilan...................................................................................................................................................... 6
a - Attentes des dveloppeurs ............................................................................................................................... 6
b - Attentes de la direction ..................................................................................................................................... 7
c - Risques identifis .................................................................................................................................................. 8
5 - Prsentation des mthodes Agiles ................................................................................................ 10
6 - Les rponses Agiles ..................................................................................................................... 10
a - Propositions damlioration............................................................................................................................. 10
b - Adquation lAgilit...................................................................................................................................... 13
III - Mise en place du projet pilote ........................................................................................ 14
1 - La ncessit dun pilote ............................................................................................................. 14
2 - Actions prparatoires ...................................................................................................................... 14
3 - Choix de la mthodologie ............................................................................................................. 15
a - Les alternatives principales.............................................................................................................................. 15
b - Le choix de la mthode Scrum ................................................................................................................. 15
4 - Choix du projet................................................................................................................................. 16
a - Alternatives ......................................................................................................................................................... 16
b - Difficults ............................................................................................................................................................. 17
5 - Structuration de lquipe................................................................................................................ 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 - Droulement du projet pilote.......................................................................................... 21
1 - Backlog du produit .......................................................................................................................... 21
2 - Droulement des sprints.................................................................................................................. 22
a - Sprint 1 ................................................................................................................................................................. 22
b - Sprint 2 ................................................................................................................................................................. 23
c - Sprint 3.................................................................................................................................................................. 23
d - Sprint 4 ................................................................................................................................................................. 24
3 - Vlocit moyenne de lquipe ..................................................................................................... 25
4 - Statistiques des releases.................................................................................................................. 25
a - Phase technique .......................................................................................................................................... 25
b - Phase logicielle ............................................................................................................................................. 26
V - Bilan du stage .................................................................................................................... 27
1 - Bilan professionnel............................................................................................................................ 27
a - Prparation......................................................................................................................................................... 27
b - Formation............................................................................................................................................................ 27
c - Objectifs atteints et restants ............................................................................................................................ 27
d - Scnario envisag............................................................................................................................................. 29
e - Bnfices............................................................................................................................................................. 29
f - Difficults .............................................................................................................................................................. 30
2 - Bilan personnel ................................................................................................................................. 31
a - Intrts du stage................................................................................................................................................ 31
b - Enseignements appliqus ................................................................................................................................ 31
c - Connaissances complmentaires.................................................................................................................. 31
d - De lintrt dun blog .................................................................................................................................. 31
e - Contributions au monde libre......................................................................................................................... 32
f - Objectifs personnels ........................................................................................................................................... 32
g - Projet professionnel ........................................................................................................................................... 32
Conclusion ............................................................................................................................... 33
Glossaire et Acronymes.......................................................................................................... 34
Bibliographie............................................................................................................................ 35
Institut Universitaire Professionnalis
Ingnierie des Systmes Informatiques
Universit Paul Sabatier Toulouse III
Rapport de stage
Frdric Monjo
01/09/2006
Page 1 sur 35
Introduction
Lorganisme 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 dAssurance Maladie fdre toutes les caisses primaires et gre
leur systme dinformation ainsi que les moyens daccs ces donnes. Nanmoins, chaque
caisse a des besoins spcifiques en informatique, et certaines dentre elles disposent dun
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 lchelle modre de la plupart des projets applicatifs locaux ne justifiait
pas lutilisation dune mthode aussi formalise.
Aussi il tait ncessaire pour les dveloppeurs daccder une mthode plus lgre,
plus efficace, et qui assurerait un mme niveau de qualit des produits. Cest dans ce
contexte que mon stage a eu pour objectif de participer la mise en place dune nouvelle
mthode.
Le but de ce rapport est de vous prsenter la dmarche suivie pour arriver la mise en
place dune 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 lanalyse de situation que jai 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.
Rapport de stage
Frdric Monjo
01/09/2006
Page 2 sur 35
I - Contexte du stage
1 - Lorganisme de Scurit Sociale
Si la scurit sociale telle quon la connat aujourdhui a t cre en 1945, il nen
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 XIX
me
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
XX
me
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 lassurance maladie, CNAVTS pour lassurance
Rapport de stage
Frdric Monjo
01/09/2006
Page 3 sur 35
vieillesse, 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.
2 - La CPAM de Toulouse
La 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 ;
Rapport de stage
Frdric Monjo
01/09/2006
Page 4 sur 35
Cot de gestion infrieur 3% des dpenses.
3 - LInformatique Locale
Pour grer les quipements matriels et logiciels des agents des caisses de la Haute-
Garonne, un service de gestion dinformatique local a t mis en place : le SESI
(Service dEtude et de Suivi Informatique). Ce service se dcompose comme suit :
Le RIL est constitu de deux quipes : une quipe en charge du rseau (matriel et
administration des droits), et lautre en charge des dveloppements. Cest avec cette
dernire que nous avons entam un travail de refonte mthodologique.
4 - Le projet de refonte mthodologique
La 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
sest avr quelle ntait 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 lunifier pour tous les dveloppeurs. Cest dans le cadre de ce groupe de
travail que jai effectu mon stage.
SESI
Liliane LELIEVRE-ZAMORA
Maintenance
Dominique LETOUZEY
Rseau Infor. Locale
Brice JONES
Appli. Production Interne
Evelyne MATHIEU
Rseau Dveloppement
DI
Didier PELLUARD
DGAI
Marie-Pierre BARDIN
Rapport de stage
Frdric Monjo
01/09/2006
Page 5 sur 35
II - Analyse de la situation
La premire phase de mon stage a t ddie lanalyse de la situation actuelle,
pour identifier les facteurs favorables et dfavorables aux diffrents types de mthodologies.
1 - Mthodologie officielle
La mthodologie officielle a t produite par la CNAM (caisse nationale). Elle est
drive dun cycle en V et intgre des spcificits propres lorganisation des caisses
dassurance maladie. Voici un schma reprsentant une vue macroscopique de la
mthodologie :
Une telle mthodologie est intressante dans le cadre de projets de grande envergure,
impliquant plusieurs dizaines de personnes. Le formalisme pouss permet ainsi dassurer une
bonne communication entre les diffrents acteurs.
Mais il nen demeure pas moins que le phnomne de l effet tunnel reste prsent :
lapplication tant dveloppe dun seul coup, on ne peut apprcier le logiciel quen fin de
processus. On sait bien aujourdhui que des changements parfois importants surviennent
dans lexpression des besoins une fois que le client peut tester le logiciel produit. Lambigut
de lcrit, 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 sorienter vers des mthodes de type Agile , trs bien
adaptes des petites quipes. Mais avant dentreprendre la mise en uvre dune telle
mthode, il est indispensable dvaluer ladquation du contexte avec les concepts Agiles.
Formalisation du besoin
Evaluation du besoin
Analyse
Ralisation
Expression du besoin
Bilan dvaluation
PV Approbation du besoin
Cahier des charges
Rgles de conception de lIL
PV Approbation Cahier des charges
Test
Manuel dexploitation et dadministration
Gnralisation
Support
PV de validation dfinitive
Manuel utilisateur
Oprations de maintenance
pouvant entraner une
reprise du processus
Rapport de stage
Frdric Monjo
01/09/2006
Page 6 sur 35
2 - Interviews
Lutilisation dinterviews individuelles permet dobtenir diffrentes visions sur lapproche
mthodologique dun projet. Deux points de vue mont 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 dun 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, jai dress un bilan pour chaque dveloppeur, puis
pour lensemble des dveloppeurs.
b - Direction
Les interviews de la direction ont t ralises partir dun questionnaire plus labor :
Quelles sont vos missions vis--vis de linformatique 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.
3 - Groupe de travail
A 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, lide tait dintroduire des lments des mthodes Agiles comme rponse aux
problmes identifis.
4 - Bilan
a - Attentes des dveloppeurs
La synthse des interviews des dveloppeurs a mis en vidence les problmes
classiques lis lutilisation dune mthodologie de type cascade . Voici les attentes
exprimes :
Rapport de stage
Frdric Monjo
01/09/2006
Page 7 sur 35
Amliorer 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
Amliorer 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.
b - 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 dune
organisation :
Disposer dun suivi davancement :
- Visibilit sur chaque projet
- Gestion des priorits des projets
- Analyse de la pertinence des projets demands
- Artefacts de validation des tapes du projet
Assurer la qualit du service
- Rapidit des dveloppements
- Systmes fiables et scuriss
- Indicateurs de performance
Dmarche de validation
- Respecter une dmarche de validation officielle
Rapport de stage
Frdric Monjo
01/09/2006
Page 8 sur 35
c - Risques identifis
Ladoption dune mthodologie ne se limite pas seulement lapplication dun
processus, elle ncessite aussi une organisation et un environnement adapts. Aussi, jai
class les problmes identifis et les risques quils comportent dans deux catgories : risques
mthodologiques et risques organisationnels. Les tableaux ci-dessous dressent la liste des
risques identifis pour chaque catgorie. Je nai pas pondr ces risques car ils taient tous
de la mme importance mon sens.
Rapport de stage
Frdric Monjo
01/09/2006
Page 9 sur 35
Risques organisationnels
Famille Problme Risques
Projets
Projets individuels ou par 2 maximum
- Connaissance du projet centralise sur une personne
- Comptences acquises par une seule personne
4 5 projets simultans par personne
- Priorits des projets changeantes
- Perte de temps due au changement de contexte
frquent
- Perte de productivit sur tous les projets
Pas de vrification de l'existant au
lancement d'un projet
- Redondance de bases de donnes
- Redondance de fonctionnalits
Tous les projets sont urgents !
- Interruptions frquentes d'un projet pour un autre
frquent
- Perte de qualit du travail
Environnement
Appels tlphoniques incessants, pour
des raisons souvent futiles
- Dveloppeurs interrompus trop souvent
- Perte de concentration
frquent
- Perte importante de productivit
Hotline inefficace : transfre les
problmes sans vrai diagnostic, alors
qu'ils s'agit souvent de droits d'accs
ou de configuration systme / rseau.
- Diagnostic d'erreur faite par les dveloppeurs : perte de
temps
frquent
Bureaux spars
- Communication plus difficile dans l'quipe
- Moins d'esprit d'quipe
Bureaux mal rangs
- Conditions de travail dsagrables
- Perte de temps chercher des documents
- Documents obsoltes
Maintenance
Interruptions trs frquentes des projets
pour des oprations de maintenance
urgentes
frquent
- Perte de temps pour des corrections mineures qui
peuvent tre reportes 90% des cas la fin du projet
courant
Utilisateurs peu expriments en
informatique, ne testent pas ou testent
mal
- Nombreuses volutions demandes
- Nombreux bugs dcouverts aprs la livraison
Administration des bases de donnes
non attribue temps plein sur une
personne
- Modifications ouvertes tous
- Aucun responsable en cas de problme
- Aucune personne qui se rfrer en cas de problme
Rapport de stage
Frdric Monjo
01/09/2006
Page 10 sur 35
Risques mthodologiques
Famille Problme Risques
Mthode
Mthode actuelle anarchique, souvent
de type cascade
- Effet tunnel pour les utilisateurs
- Planification mal value
- Estimations mal values
- Produit final non conforme aux vrais besoins des
utilisateurs
Besoins
Besoins mal exprims / mal compris
- Cahier des charges peu clair et interprt diffremment
- Produit livr ne rpond pas aux attentes initiales des
utilisateurs
- Maintenance volutive importante aprs la livraison
Besoins changeants
- Prise en compte trs tardive dans le projet
Utilisateurs finaux masqus par leur
chef de service qui ne veut pas les
librer
- Besoins exprims en dsaccord avec les vrais besoins
des utilisateurs
- Nombreuses modifications demandes aprs la livraison
Besoins recueillis auprs des mauvais
utilisateurs
- Produit livr ne rpond pas aux attentes initiales des
utilisateurs
Planification et
Estimation
Pas de planification efficace
- Dlais non respects
- Gestion du projet chaotique
Estimations rarement faites, et si c'est
le cas en jours-hommes
- Difficult estimer
- Pertinence des estimations
Avancement du projet interrompu trs
souvent par des oprations de
maintenance
- Dlais non respects
- Gestion du projet chaotique
5 - Prsentation des mthodes Agiles
Vous pourrez trouver une prsentation gnrale des principes et mthodes Agiles dans
lannexe Support de formation : Processus et pratiques Agiles .
6 - Les rponses Agiles
a - Propositions damlioration
Lutilisation dune mthode Agile permet de pallier la plupart de ces risques de
faon efficace. Voici les solutions proposes aux diffrents problmes, toujours classs par
catgorie.
Rapport de stage
Frdric Monjo
01/09/2006
Page 11 sur 35
Risques organisationnels
Famille Problme Solution Agile Bnfices attendus
Projets
Projets individuels ou par
2 maximum
Travail en deux quipes de 4
personnes
- Connaissance commune du projet
- Comptences acquises par toute
l'quipe
4 5 projets simultans
par personne
Un seul projet la fois pour l'quipe
- Projets aboutis rapidement
- Enchanement des projets rapide
- Dveloppeurs au maximum de leur
productivit
Pas de vrification de
l'existant au lancement
d'un projet
Rfrencer tous les projets avec les
fonctionnalits implmentes et les
schmas de donnes
- Plus de redondances inutiles
Tous les projets sont
urgents !
On n'interrompt jamais un projet en
cours
Idem ci-dessus
Environnement
Appels tlphoniques
incessants, pour des
raisons souvent futiles
Filtrer les appels vers l'quipe par un
seul point d'entre : le ScrumMaster
- Seuls les appels vraiment
importants sont transmis
- Meilleure concentration de l'quipe
productivit
Hotline inefficace :
transfre les problmes
sans vrai diagnostic.
Isoler l'quipe des problmes de
Hotline, ne lui transfrer que des
appels justifis et diagnostiqus
Idem ci-dessus
Bureaux spars
Tous les membres de l'quipe sont
dans la mme pice, isole et calme
- Meilleure concentration
- Meilleure communication
- Esprit de groupe solidaire
- Rsolution rapide des problmes
Bureaux mal rangs Pice bien range, cadre agrable
- Bien-tre des dveloppeurs
- Meilleure productivit
- Meilleure ambiance
- Documentation efficace
Maintenance
Interruptions trs
frquentes des projets
pour des oprations de
maintenance urgentes
- 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)
- Continuit du projet
- Intervention seulement dans les
vrais cas d'urgence
Utilisateurs peu
expriments en
informatique, ne testent
pas ou testent mal
- Les utilisateurs font partie de
l'quipe et testent souvent
- Identification de rles utilisateurs
plutt que de personnes
- 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)
Risques mthodologiques
Famille Problme Solution Agile Bnfices attendus
Rapport de stage
Frdric Monjo
01/09/2006
Page 12 sur 35
Mthode
Mthode actuelle
anarchique, souvent de
type cascade
Passer une mthode
Agile (Scrum, XP)
- 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
Besoins
Besoins mal exprims /
mal compris
Utiliser des User Stories
- Comprhension partielle dans un premier
temps, puis explication orale au moment de
l'implmentation, donc bien comprise
- Fonctionnalits raffines, petites, simples
comprendre et estimer
Besoins changeants
priorises
- 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)
Utilisateurs finaux
masqus par leur chef
de service qui ne veut
pas les librer
Identifier des rles
utilisateurs et un
reprsentant de chaque
rle
- Plus grande pertinence des besoins car
localiss des rles donc plus prcis
Besoins recueillis
auprs des mauvais
utilisateurs
Utiliser des rles
utilisateurs
- 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
Planification et
Estimation
Pas de planification
efficace
Planification agile en
deux tapes :
- Sur une release
(vlocit)
- Sur chaque sprint
(reste faire)
- 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
Estimations rarement
faites, et si c'est le cas
en jours-hommes
- Estimations en points
pour les fonctionnalits
- Estimations en reste
faire sur les tches dans
un sprint
- 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
Avancement du projet
interrompu trs souvent
par des oprations de
maintenance
Isolement complet de
l'quipe, interdiction
d'interrompre un sprint en
cours ou un projet en
cours.
- Oprations reportes en fin de projet et traites
efficacement
- Meilleure productivit de l'quipe
Rapport de stage
Frdric Monjo
01/09/2006
Page 13 sur 35
b - Adquation lAgilit
Aprs la rcupration de tous ces lments, jai dress un bilan dadquation lAgilit
sous forme de prsentation PowerPoint. Ce bilan prsentait plusieurs mtriques permettant
dvaluer le niveau dadquation du contexte du RIL avec les mthodes Agiles.
Voici la liste des critres avec le niveau dadquation pour chacun :
Evaluation organisationnelle
- Taille de lquipe
Une quipe de petite taille est bien adapte
- Criticit des applications
Les logiciels non critiques sont bien adapts
- Criticit de la maintenance
La maintenance non critique est bien adapte
- Qualit de lenvironnement
Un environnement calme et sain est favorable
Evaluation mthodologique
- Dynamisme du contexte
Les besoins peuvent changer souvent
- Culture des dveloppeurs
Savoir-faires suffisants et diffusion
- Analyse des besoins
Besoins bien compris / bien exprims
- 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 problmes
que le domaine mthodologique, ce qui nous amens focaliser les premires actions sur
ce domaine.
Rapport de stage
Frdric Monjo
01/09/2006
Page 14 sur 35
III - Mise en place du projet pilote
1 - La ncessit dun pilote
La CNAM (Caisse Nationale dAssurance 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 laval de la direction, il tait indispensable de mettre en place un
projet pilote , dont les rsultats serviront prouver les bienfaits dune approche Agile.
2 - Actions prparatoires
Ds le dbut du stage, et jusquau lancement du projet pilote, jai effectu un travail
trs actif dautoformation sur les mthodes et techniques Agiles, afin de pouvoir rpondre au
mieux aux problmes et questions qui me seraient exposs. Jai 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
lenvironnement organisationnel soit favorable. Nous avons donc men des actions sur ce
domaine en priorit :
Rangement et nettoyage des bureaux : cela navait pas t fait depuis 20
ans Environ 2 mtres cubes de vieille documentation et vieux livres ont t
jets
Mise en place dun nouveau processus de prise en compte des oprations de
maintenance, incluant la mise en place du bugtracker Gemini :
Rapport de stage
Frdric Monjo
01/09/2006
Page 15 sur 35
Rorganisation des bureaux : pour amliorer la communication au sein dune
quipe, il est prfrable quelle 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
dun tableau blanc.
3 - Choix de la mthodologie
a - 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 aujourdhui. 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 : lutilisation des User Stories pour la gestion des besoins, et du
dveloppement guid par les tests (TDD Test Driven Development) lintrieur 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
Rapport de stage
Frdric Monjo
01/09/2006
Page 16 sur 35
intressant dintgrer les pratiques TDD comme facteur damlioration de la qualit des
logiciels produits.
Scrum mentionne quon ninterrompt jamais lquipe 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.
Release
Sprint Sprint Sprint Sprint
Release
Sprint Sprint Sprint Sprint
Phases de maintenance trs
courtes, pour traiter les
urgences survenues pendant
le sprint
Phases de maintenance trs
courtes, pour traiter les
urgences survenues pendant
le sprint
4 - Choix du projet
a - Alternatives
La question du choix du projet pilote sest ensuite pose nous. Un nouveau projet
devait justement dmarrer au moment du lancement du projet pilote. Son inconvnient tait
simplement dtre 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. Ctait loccasion idale dapporter
quelques amliorations lexistant :
Implmentation dune couche dobjets mtier pour accder et manipuler les
donnes, au lieu d'utiliser des requtes SQL.
Unification de linterface dadministration des donnes : remplacer les 3
applications indpendantes en une seule, dont linterface intgre une gestion
des droits daccs pour filtrer les actions possibles.
Amlioration de lergonomie de linterface
Il prsente les intrts suivants :
Critique et urgent
Utilisation de Scrum pour grer des dveloppements techniques
Utilisation de Scrum pour grer des dveloppements logiciels
Rapport de stage
Frdric Monjo
01/09/2006
Page 17 sur 35
Les 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 dune couche dobjets mtier ne permet pas facilement
llaboration dune liste de besoins dont la ralisation est mesurable.
Linterface dadministration des donnes ne possde pas rellement
dutilisateurs 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.
5 - Structuration de lquipe
Le fonctionnement nominal du service permettait la ralisation simultane de
nombreux projets. Il ntait donc pas possible de mobiliser lintgralit 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 lquipe 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.
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 premire phase dite technique dont le but
est de construire la couche dobjets 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 lunification 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 larrive prochaine dune application nationale
quivalente, mais peut-tre pas suffisante.
Rapport de stage
Frdric Monjo
01/09/2006
Page 18 sur 35
b - Planning
Ce planning est lgrement diffrent ce qui tait prvu. En effet, la phase technique
ne devait durer quun seul sprint, mais des difficults caches ont oblig la prolonger dun
sprint complmentaire.
7 - Positionnement personnel
a - Analyse
La premire mission qui ma t confie a en fait t celle dun consultant : il
sagissait didentifier les points faibles dans lorganisation et de proposer des amliorations.
Bien que ne bnficiant que de peu dexprience professionnelle, la forte composante en
gnie logiciel de la formation ISI ma permis de discerner rapidement les problmes
classiques. Lautoformation aux mthodes Agiles ma galement donn une vision nouvelle
sur dautres problmes mthodologiques.
b - Formation
En force de proposition, jai donc t charg dapporter 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 jai dispense sest dcompose en 3 prsentations :
Processus et Pratiques Agiles (1/2 journe) : Quest-ce que Agile ? Les
processus Agiles, Les pratiques Agiles.
Scrum (1/2 journe) : Agilit, Concepts, De A Z, Jeu de rles
Septembre+
Avril Mai Juin
Juillet Aot
Analyse de la
situation
( + Autoformation )
F
o
r
m
a
t
i
o
n
L
a
n
c
e
m
e
n
tPhase technique
Sprint 1
Phase logicielle
Sprint 2
M
a
i
n
t
e
n
a
n
c
e
M
a
i
n
t
e
n
a
n
c
e
Phase technique
Sprint 2
(
S
p
r
i
n
t
2
)
Phase
logicielle
Sprint 3
G
r
a
l
i
s
a
t
i
o
n
?

Phase logicielle
Sprint 1
Rapport de stage
Frdric Monjo
01/09/2006
Page 19 sur 35
Gestion Agile des besoins (1/2 journe) : De ltude 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 lessentiel, il tait
important dtre prsent sur le terrain pour intervenir au bon moment et rappeler les
concepts et les pratiques de la nouvelle mthodologie. Jai donc encadr au quotidien
lquipe pilote dans cette optique.
d - Aide la formation
Les mthodes Agiles sont encore trs peu connues en France, et les pratiques quelles
proposent sortent du cadre des projets traditionnels. Il est donc indispensable pour une
quipe Agile dexpliquer aux demandeurs et sa hirarchie quelles sont ses pratiques,
pourquoi elle les adopte, et comment ils vont travailler ensemble.
Jai 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.
Javais planifi de raliser un support destin la hirarchie, sappuyant sur les rsultats
du projet pilote pour leur prouver lefficacit dune mthode Agile, mais ce dernier ayant pris
beaucoup trop de retard, je nai donc pas ralis cette prsentation.
e - Outils de support
Une bonne mthode est moins apprciable si elle nest pas accompagne dun bon
outil. Aussi jai assur la mise en place dun outil de support la mthode Scrum : IceScrum.
Je lai configur, dploy, et jai assur une formation son utilisation lquipe pilote.
Cet outil libre et open source a t dvelopp lors du bureau dtudes de mon anne
de Master I lIUP. 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 lquipe. Il ma
fallu galement assurer la migration des donnes dune version sur lautre.
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 sest avr quaucun 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 lergonomie
des logiciels. Aussi il ma sembl pertinent de leur prsenter le SNI (Schma Navigationnel
dInterface), qui permet de modliser linterface dune application du point de vue
ergonomique.
Rapport de stage
Frdric Monjo
01/09/2006
Page 20 sur 35
Jai donc assur une formation rapide sur la modlisation laide du SNI, montr les
exemples de mes stages prcdents, et guid sa mise en pratique sur le projet pilote.
Rapport de stage
Frdric Monjo
01/09/2006
Page 21 sur 35
IV - Droulement du projet pilote
Lutilisation dIceScrum a permis de conserver un historique de la ralisation du projet
pilote.
1 - Backlog du produit
Le backlog du produit rfrence toutes les fonctionnalits que devra implmenter le
logiciel. Il est prsent ici dans lordre de priorits dfinies par le client, et avec les estimations
de lquipe.
Thme Item
Points
Estims
Couche mtier
Dfinir les rgles de gestion (mtier + droits d'accs des applis) pour la
manipulation des objets
2
Couche mtier Le dveloppeur veut accder des objets hirarchiques 5
Couche mtier Dfinir une gestion des verrous 2
Couche mtier Le dveloppeur veut accder des objets "simples" 3
Couche mtier Le dveloppeur veut accder des objets par liste multicritres 1
Couche mtier Implmenter la gestion des rles et droits d'accs 1
Couche mtier Le Responsable peut dlguer ses droits ses subordonns 1
Couche mtier Un Administrateur des dlgations peut changer les dlgations d'un cadre 1
Un Agent arrive Le Gestionnaire Administrateur du Personnel cre l'agent 2
Un Agent arrive Le Gestionnaire Administrateur du Personne Externe cre l'agent externe 1
Un Agent arrive Informer automatiquement le responsable du service de l'agent cr 1
Gestion de la compatibilit
ascendante
Le dveloppeur veut garder une compatibilit avec l'ancienne base
CPAM31
5
Couche mtier Implmenter un systme de trace des actions sur la BD 1
Un Agent arrive
Implmenter la rcupration automatique des complments d'infos sur
lagent
0
Couche mtier Implmenter une gestion d'erreurs base sur Gemini 3
Les Entits Organisationnelles Le RH propose d'unifier la terminologie des entits organisationnelles (EO) 0
Les Entits Organisationnelles Une EO st type (unit, secteur, service, ple, direction, dpartement) 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 complte ses informations 2
Un Agent bouge Un gestionnaire ADP recherche un agent dans l'historique 1
Un Agent bouge Informer automatiquement le responsable quand l'agent change EO 1
Un Agent bouge Informer automatiquement le responsable quand l'agent change Nom 1
Un Agent bouge Le responsable change l'affectation de son agent une EO 1
Un Agent bouge Le responsable change l'affectation de son agent une EG 1
Un Agent bouge
Le responsable change l'affectation de son agent une donne
complmentaire
1
Un Agent bouge Un gestionnaire ADP positionne une date de dpart 1
Un Agent bouge Le gestionnaire ADP gre le prt d'agent inter service 0
Un Agent bouge Le gestionnaire ADP gre l'agent absent en longue dure 2
Les Entits Organisationnelles Le responsable dispose d'une dlgation administrativement sur son EO 2
Un Agent bouge Si le n GDP change, il faut conserver l'historique 1
Rapport de stage
Frdric Monjo
01/09/2006
Page 22 sur 35
Les Entits Gographiques Une salle (sans agent affect) peut avoir un n de tlphone 1
Les Entits Organisationnelles Tout le monde affiche l'organigramme 3
Les Entits Organisationnelles Le gestionnaire EO cre une EO 1
Les Entits Organisationnelles Le gestionnaire EO dplace une EO 1
Les Entits Organisationnelles Le gestionnaire EO met jour une EO 1
Les Entits Organisationnelles Le gestionnaire EO supprime une EO 1
Les Entits Gographiques Le gestionnaire Immobilier cre une EG 1
Les Entits Gographiques Le gestionnaire Immobilier renomme une EG 1
Les Entits Gographiques Le gestionnaire Immobilier supprime une EG 1
Les Entits Gographiques Le responsable affecte un agent une EG 1
Les Entits Gographiques Le gestionnaire Immobilier dplace une EG 1
Les Entits Organisationnelles Le dveloppeur utilise un arbre hirarchique 2
Certains lments sont estims 0 points. Il sagit de contraintes non fonctionnelles, ou
dlments dont lestimation dpend dun contexte technique non connu pour linstant.
2 - Droulement des sprints
a - Sprint 1
Items du backlog raliss :
Thme Item
Points
Estims
Couche mtier Le dveloppeur veut accder des objets hirarchiques 5
Vlocit : 5
Burndown chart du sprint :
Rapport de stage
Frdric Monjo
01/09/2006
Page 23 sur 35
On voit ici que les donns du sprint ont t saisies en milieu de sprint. Cela sexplique
par les difficults rencontres lors du dploiement de loutil IceScrum. Toutes les tches nont
pas pu tre ralises pendant ce sprint.
b - Sprint 2
Thme Item
Points
Estims
Couche mtier
Dfinir les rgles de gestion (mtier + droits d'accs des applis) pour la
manipulation des objets
2
Couche mtier Dfinir une gestion des verrous 2
Couche mtier Le dveloppeur veut accder des objets "simples" 3
Vlocit : 7
Sur ce graphique, on peut voir dabord un plateau, puis un pic. Il sagit tout simplement
de la saisie des informations qui na pas t faite correctement. Les vritables donnes ont
t fournies en milieu de sprint.
c - Sprint 3
Thme Item
Points
Estims
Couche mtier Le dveloppeur veut accder des objets par liste multicritres 1
Couche mtier Implmenter la gestion des rles et droits d'accs 1
Rapport de stage
Frdric Monjo
01/09/2006
Page 24 sur 35
Couche mtier Le Responsable peut dlguer ses droits ses subordonns 1
Couche mtier Un Administrateur des dlgations peut changer les dlgations d'un cadre 1
Vlocit : 4
Ce graphique est intressant, puisquil rvle plusieurs choses : la faible frquence des
mises jour dans loutil dune part, et une sous-estimation initiale du reste faire dautre part,
puisquil augmente brutalement en fin de sprint (cela ne correspond pas lajout dune User
Story dans les objectifs du sprint).
d - Sprint 4
Items du backlog de produit :
Thme Item
Points
Estims
Les Entits Organisationnelles Le gestionnaire EO cre une EO 1
Les Entits Organisationnelles Le gestionnaire EO dplace une EO 1
Les Entits Organisationnelles Le gestionnaire EO met jour une EO 1
Les Entits Organisationnelles Le gestionnaire EO supprime une EO 1
Les Entits Organisationnelles Le dveloppeur utilise un arbre hirarchique 2
Vlocit estime : 6
Rapport de stage
Frdric Monjo
01/09/2006
Page 25 sur 35
3 - Vlocit moyenne de lquipe
La vlocit moyenne de lquipe est de 5,33 entre avril et aot. Cette vlocit est
pondrer avec le fait que les congs ont diminu leffectif de lquipe 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.
4 - Statistiques des releases
a - Phase technique
0
1
2
3
4
5
6
7
Points
1 2
Sprints
Burndown Chart de la release "Phase logicielle"
Vlocit
Reste faire
Rapport de stage
Frdric Monjo
01/09/2006
Page 26 sur 35
b - Phase logicielle
0
5
10
15
20
25
30
35
40
45
50
Points
1 2 3 4 5 6 7
Sprints
Burndown Chart de la release "Phase logicielle"
Vlocit
Reste faire
Sur ce graphique, les deux premiers sprints sont constats (vlocit de 5,33). Les suivants
sont estims par rapport la nouvelle vlocit (9).
Rapport de stage
Frdric Monjo
01/09/2006
Page 27 sur 35
V - Bilan du stage
Lobjectif de ce chapitre est dtablir un bilan du projet du point de vue de lentreprise
et du point de vue personnel.
1 - Bilan professionnel
a - 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 laccs
efficace aux documentations.
La canalisation de la maintenance a permis de minimiser les irruptions dans la pice de
lquipe de dveloppement, ainsi que les appels tlphoniques. Cest aussi un contexte qui
favorise un travail efficace dans de bonnes conditions.
Le ramnagement des bureaux est toujours ltude. Il sera probablement
ncessaire de faire dplacer des cloisons amovibles, et cela requiert lapprciation et
lintervention des personnes qualifies dans ce domaine.
b - Formation
Le travail de prparation dune 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, jai travaill attentivement le contenu et le plan pour tre sr quils soient
pertinents. Cest un travail fastidieux.
c - Objectifs atteints et restants
Problme Solution Agile Bnfices attendus Bnfices constats
Projets individuels ou
par 2 maximum
Travail en deux quipes
de 4 personnes
- Connaissance commune du projet
- Comptences acquises par toute
l'quipe
Oui
Oui
4 5 projets
simultans par
personne
Un seul projet la fois
pour l'quipe
- Projets aboutis rapidement
- Enchanement des projets rapide
productivit
Non : Retard du projet pilote
Non
Non : Congs dt
Pas de vrification
de l'existant au
lancement d'un
projet
Rfrencer tous les
projets avec les
fonctionnalits
implmentes et les
schmas de donnes
- Plus de redondances inutiles ? Pas de mesure disponible
Tous les projets sont
urgents !
On n'interrompt jamais un
projet en cours
Idem ci-dessus Oui
Appels
tlphoniques
incessants, pour des
raisons souvent
futiles
Filtrer les appels vers
l'quipe par un seul point
d'entre : le ScrumMaster
productivit
Non mis en application
Rapport de stage
Frdric Monjo
01/09/2006
Page 28 sur 35
Hotline inefficace :
transfre les
problmes sans vrai
diagnostic.
Isoler l'quipe des
problmes de Hotline, ne
lui transfrer que des
appels justifis et
diagnostiqus
productivit
Oui
Oui
Oui
Bureaux spars
Tous les membres de
l'quipe sont dans la
mme pice, isole et
calme
- Meilleure concentration
- Meilleure communication
- Esprit de groupe solidaire
- Rsolution rapide des problmes
? Pas encore mis en place
Bureaux mal rangs
Pice bien range, cadre
agrable
- Bien-tre des dveloppeurs
- Meilleure ambiance
- Documentation efficace
Oui
Oui
Oui
Oui
Interruptions trs
frquentes des
projets pour des
oprations de
maintenance
urgentes
- 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)
- Intervention seulement dans les
vrais cas d'urgence
Oui
Oui
Oui
Utilisateurs peu
expriments en
informatique, ne
testent pas ou
testent mal
- Les utilisateurs font
partie de l'quipe et
testent souvent
- Identification de rles
utilisateurs plutt que de
personnes
- 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)
? Pas de mesure disponible
Mthode actuelle
anarchique, souvent
de type cascade
Passer une mthode
Agile (Scrum, XP)
- 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
Oui
Oui
Oui
Oui
Oui
Non : Temps dadaptation
Besoins mal
exprims / mal
compris
- Comprhension partielle dans un
premier temps, puis explication orale
au moment de l'implmentation,
donc bien comprise
- Fonctionnalits raffines, petites,
simples comprendre et estimer
Oui
Oui
Besoins changeants
priorises
- 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)
Oui
Oui
Utilisateurs finaux
masqus par leur
chef de service qui
ne veut pas les
librer
Identifier des rles
utilisateurs et un
reprsentant de chaque
rle
- Plus grande pertinence des
besoins car localiss des rles
donc plus prcis
Oui
Rapport de stage
Frdric Monjo
01/09/2006
Page 29 sur 35
Besoins recueillis
auprs des mauvais
utilisateurs
Utiliser des rles
utilisateurs
- 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
Oui
Oui
? Pas de mesure disponible
Pas de planification
efficace
Planification agile en
deux tapes :
- Sur une release
(vlocit)
- Sur chaque sprint
(reste faire)
- 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)
Oui
Non : Saisie non rgulire des
donnes
Oui
Estimations rarement
faites, et si c'est le
cas en jours-
hommes
- Estimations en points
pour les fonctionnalits
- Estimations en reste
faire sur les tches dans
un sprint
- 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
Oui
Oui
Oui
Oui
Oui
Avancement du
projet interrompu
trs souvent par des
oprations de
maintenance
Isolement complet de
l'quipe, interdiction
d'interrompre un sprint en
cours ou un projet en
cours.
- Oprations reportes en fin de
projet et traites efficacement
- Meilleure productivit de l'quipe
Oui
Oui
Oui
d - 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. Sil est montr quelle a permis un rel gain de productivit et
de qualit, elle sera probablement gnralise tous les dveloppeurs. Il est galement
envisageable quelle 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. Cest un atout tant pour le client,
qui voit que le projet avance, que pour lquipe, qui voit quelle 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.
Rapport de stage
Frdric Monjo
01/09/2006
Page 30 sur 35
Lutilisation des User Stories a aussi t fructueuse en ce sens quelles ont permis
dexprimer 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 lavancement du
travail, tout en identifiant les problmes pour quils soient traits au plus vite.
Enfin, outre la mthode Scrum, lutilisation dun SNI pour modliser linterface de
lapplication 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 linterface sans avoir rflchir
son contenu, ce qui permet dtre plus efficace ;
Enfin, sa lecture facile permet aux clients davoir un aperu de linterface de
leur application.
f - Difficults
Le projet pilote tant l pour tester la mthode Scrum, lquipe a normalement
rencontr quelques difficults :
Le changement dhabitudes 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 sengage vis--vis de lquipe ;
Communication dquipe : la confrontation de points de vue 4 est difficile,
notamment avec les problmes daffinits ;
Le respect du concept de timebox : le manque dhabitude de lquipe et
des clients entrane des runions qui peuvent staler 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, sest confirme dans la pratique : la difficult dans lexpression des besoins par
les clients de la partie logicielle. En effet, comme expliqu prcdemment, les clients nen
sont pas vraiment, et nous leur avons demand de bien vouloir jouer ce rle. Un temps
dadaptation 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 sattendre en temps normal.
Rapport de stage
Frdric Monjo
01/09/2006
Page 31 sur 35
2 - Bilan personnel
a - 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 loccasion de dcouvrir une autre approche du monde informatique,
dacqurir quelques techniques rudimentaires, et de travailler mon regard critique sur les
mthodes et les pratiques.
La formation et lencadrement quotidien dune quipe de dveloppeurs expriments
ont t un vritable dfi au niveau de la communication. Le fait dtre encore scolaris et en
stage rend plus difficile lobtention de confiance et de crdibilit vis--vis de personnes
dexprience.
Dcouvrir les mthodes Agiles et les mettre en application en situation relle ma
permis galement dapprendre 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 denseignements dispenss pendant ma scolarit lIUP 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 dInterface ;
BE : premire exprience de Scrum, et outillage de la mthode avec IceScrum ;
c - Connaissances complmentaires
Jai eu besoin pour ce stage dacqurir de nouvelles connaissances :
Mthodes Agiles : un gros travail dautoformation a t ncessaire laide de
documentation sur Internet fournie par des spcialistes du domaine ;
Formation : produire un support de formation est quelque chose de difficile, et il
ma fallu beaucoup de temps pour mettre au point ces supports, en minspirant
des enseignements dispenss lIUP ;
Enfin, accompagner une quipe au quotidien nest pas non plus quelque chose
de simple. Jai pu apprendre beaucoup sur ce sujet.
d - De lintrt dun blog
Si le blog sest popularis pour servir de journal intime public, cest un outil professionnel
puissant. En effet, il permet de dialoguer avec dautres professionnels sur des sujets mtier
dactualit. Les mthodes Agiles prsentent donc un sujet de blog trs intressant.
Rapport de stage
Frdric Monjo
01/09/2006
Page 32 sur 35
Cest pourquoi jai dcid rapidement douvrir mon propre blog, dune part pour
raconter lexprience de mon stage vis--vis des mthodes Agiles, et dautre part pour
dbattre de points de vue sur les diffrentes pratiques de ces mthodes.
Les blogs, support de publication darticles, permettent aujourdhui deffectuer des
trackbacks (ou rtroliens ), qui consistent publier un article sur son blog en rponse
un article dun autre blog. Ce mcanisme permet ainsi de crer des liens entre blogs et
dentrer en contact avec dautres personnes.
Cest de cette faon que jai eu la chance dtre contact par OCTO Technology,
socit de conseil en urbanisme et mthodologies Paris, qui ma suggr de dposer ma
candidature chez eux. Je nai malheureusement pas pu postuler du fait que je navais pas
termin ma scolarit.
e - Contributions au monde libre
Ce stage a t aussi pour moi loccasion de contribuer au monde libre. Jai 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, jai galement rcrit larticle Scrum dans
Wikipedia, lencyclopdie libre dInternet. Larticle existant tait plus ou moins la traduction
dune publication ancienne des fondateurs de Scrum. Certains concepts exprims dans
cette publication ont depuis volus, et il tait ncessaire de remettre plat larticle et de le
structurer comme un article encyclopdique.
f - Objectifs personnels
Au tout dbut du stage, je mtais donn comme objectif de russir faire migrer
officiellement le service des dveloppements internes vers des mthodes Agiles. Ce dfi, trs
ambitieux, je nai pas russi le relever compltement.
Nanmoins, le projet pilote est bien mis en place, et la mthode a au moins convaincu
lquipe pilote. Les autres dveloppeurs nayant pas pu encore lexprimenter, ils ne sont
peut-tre pas autant favorables.
Pour linstant le projet pilote na pas fourni assez dlments pour prsenter la
direction le projet de migration complte du service RIL. On peut esprer que dici 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 lIUP ISI mont permis de dcouvrir plusieurs approches des
mtiers de linformatique : le dveloppement, la prise en main MOE et MOA dun projet, et
cette anne le conseil et la formation. Ma dernire anne touchera le domaine de lIHM, o
je dcouvrirais probablement encore une autre facette de linformatique.
Il est donc difficile pour moi aujourdhui de savoir avec prcision quel projet
professionnel je peux envisager, mais jespre mtre assur de possder un champ de
connaissances suffisamment vaste pour pouvoir rebondir sur les opportunits qui se
prsenteront dans ma carrire.
Rapport de stage
Frdric Monjo
01/09/2006
Page 33 sur 35
Conclusion
Les IUP ont fait le choix dintgrer 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 jai pu dcouvrir un
nouveau contexte dentreprise. Il ma 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 lutilisation dune mthode Agile : Scrum.
Une telle mthode ncessite beaucoup de changements dans lorganisation de lentreprise,
et une nouvelle faon de voir un projet informatique. Tous ces lments sont des risques
dchec 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 lobjectif tait de mettre
lpreuve la mthode Scrum dans le contexte de linformatique locale. Ce projet nest pas
encore termin lheure 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. Jai 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 dune formation. Si je ne peux aujourdhui avoir la prtention de devenir
rapidement consultant, jai dcouvert une nouvelle orientation possible pour mon futur, et
ajout une exprience riche mon champ de connaissances.
Jespre 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 linformatique locale de la caisse de Toulouse comme un exemple dadaptation et
dvolution, et comme un pionnier vis--vis des autres caisses dassurance maladie.
Rapport de stage
Frdric Monjo
01/09/2006
Page 34 sur 35
Glossaire et Acronymes
Agile
Nom dune famille de mthodes de dveloppement de logiciels qui possdent des caractristiques
communes particulires
Backlog de produit Liste des fonctionnalits que devra raliser le logiciel une fois termin
Backlog de sprint Liste des tches faire par lquipe lintrieur dun sprint
Base de donnes
Ensemble de fichiers permettant le stockage permanent de donnes, respectant un certain
modle propre la nature de la base de donnes (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 dveloppeurs.
CNAM Caisse Nationale dAssurance Maladie, qui rgit toutes les caisses primaires
CPAM Caisse Primaire dAssurance Maladie (ici, celle de Toulouse)
Ergonomie
Capacit dune interface entre un outil et un utilisateur tre facilement utilisable et
interprtable.
IHM (Interface Homme Machine)
Dsigne lensemble des interfaces (virtuelles ou relles) entre un utilisateur et une machine. Dans
le cas dun logiciel, dsigne la fois les mthodes de saisie et la reprsentation visuelle
lutilisateur.
Item de backlog Un lment dans un backlog
Itration
Priode de temps de quelques semaines au bout de laquelle est accomplie un ensemble
dactivits lies la mthode utilise
Mthode / Processus Processus mis en uvre pour concevoir, raliser, et tester un logiciel.
Release Priode de temps au bout de laquelle est publie une version de logiciel aboutie
RIL Rseau et Informatique Locale
Scrum Mthode de dveloppement faisant partie de la famille des mthodes Agiles
SNI (Schma Navigationnel
dInterface)
Modle permettant la modlisation de linterface utilisateur dun logiciel. Il a t mis au point par
M. JB. Crampes, enseignant chercheur de lUniversit Paul Sabatier Toulouse.
Sprint
Itration lintrieur de la mthode Scrum, au terme de laquelle un logiciel partiel est prsent
et doit fonctionner
XP (eXtreme Programming) Mthode de dveloppement faisant partie de la famille des mthodes Agiles
Rapport de stage
Frdric Monjo
01/09/2006
Page 35 sur 35
Bibliographie
IUP ISI Master I. Ingnierie du logiciel , 2006.
IUP ISI Master I. Ingnierie des systmes , 2006.
MARTIN, Robert C. Agile methods: The bottom line.
COHN, Mike. Project Economics: Selecting and prioritizing high-value projects.
COHN, Mike. Whats 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
Prsentation clients :
Mener bien un projet Agile
Annexe V
Article Scrum dans Wikipedia
Annexe VI
Extraits de mon blog :
Billets sur Scrum et mon stage

Rapport de Stage 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

Rapport de Stage PDF

Transféré par

Droits d'auteur :

Formats disponibles

Rapport de stage

Migration Agile du RIL

Vous aimerez peut-être aussi