Présentation sur l'expérience d'implémentation des méthodes agiles à la RATP. Dans le cadre d'une table ronde Oresys à l'Atelier BNP Paribas.

1. Ratp
Les méthodes « Agiles » à la
RATP

2. Historique de la démarche Agile à la RATP
 Historiquement, le département SIT (Systèmes d'Information et de
Télécommunications)
 Fonctionne avec une méthodologie classique
 Est plutôt dédié aux gros projets (longs et complexes)
 Traite ~25% des projets RATP en nombre, soit ~ 65% des projets en
montant
 Fin 2007, SIT se fixe comme objectifs de :
 Proposer de nouvelles offres au sein de la RATP pour attirer les MOA
 En particulier de réduire le « Time To Market »
• Sans diminuer la qualité
• Pas nécessairement moins cher, mais le juste nécessaire
– 20% des fonctionnalités utilisées 80 % du temps
– Réduire l’effet tunnel
 L’offre Développement Rapide à la RATP est amorcée
Page N°2

3. Historique de la démarche Agile à la RATP
Itérations et Spécifications au juste nécessaire Projets
simples Fin 2007
Un interlocuteur MOA sur le plateau chaque semaine
Backlog
Priorisation
Implication des utilisateurs Projets
moyens
Points d’effort
MOA présence permanente
Amélioration des users stories et des tests
Fin 2011 Utilisation GreenHopper
Projets complexes
(charges > 500 j.h)
Page N°3

4. La méthode Agile à la RATP
 SCRUM et XP
 Démarche par itérations : Bilan de
Itération 1 2 à 3semaines Itération n TMA
projet
Gestion du changement
Documentation
 Détail d’une itération
Spécifications
Recette
et priorisation
Réalisation
Page N°4

5. La méthode Agile à la RATP
 Engagement sur
 La date de mise en service
 Le coût
• Estimation sur un macro-périmètre initial
• Provision importante pour aléas
 La qualité de service
 Priorisation des fonctionnalités faites par la MOA
 Possibilité de changer le périmètre fonctionnel
• Prise en compte des changements
• Sans remettre en cause le budget et le planning
 Contractualisation avec un externe
 Le maitre d’œuvre interne prend en charge la majorité des
responsabilités et notamment l’intégration
 Le prestataire réalise uniquement les développements ciblés
Page N°5

6. Enseignements et préconisations
MOA Entente et confiance MOE
Interlocuteur unique et pouvant MOE interne : profil technique car
prendre la majorité des prenant part au développement et
décisions notamment à l’intégration
La MOE peut jouer dans certains
Disponibilité importante
cas le rôle d’AMOA
Réflexion initiale réalisée en amont
Intervention souple de prestataire
: méthode agile ne veut pas dire
pour le développement
zéro cadrage
Page N°6

7. Enseignements et préconisations
- Avoir une MOA plus présente et prenant des
Un besoin pas toujours mûr voire décisions
inexistant - Bénéficier d’un retour utilisateur très tôt
- Fonctionnel non figé
Une MOE à la fois - Avoir une MOA plus présente et prenant des
- AMOA et MOE décisions
- Scrum Master, Product Owner - Séparer la fonction de Product Owner de
et Développeur Scrum Master et la transférer à la MOA
Difficile de faire des gros projets avec - Interfaces définies et connues
beaucoup d’interfaces - Architectures classiques
Interaction difficile avec des projets non - Ne pas hésiter à refuser de faire du Scrum
agiles ou des applications en production pour certains projets
- S’assurer de la qualité technique de
l’application (plateforme qualité,
Reprise en maintenance difficile documentation technique, …)
- Disposer d’une bonne documentation
fonctionnelle
Page N°7

8. Exemples de projets
Projet Conditions de réussite identifiées Risques identifiés Décision
Projet 1 • Pilotage par les délais
• Disponibilité MOA
• Périmètre fonctionnel à faire converger
au fur et à mesure de la réalisation
• Accompagnement du changement très
important
Projet 2 • Début de spécification mais volonté de • Manque de disponibilité
pouvoir affiner • Possibilité de dérive du
• Demande forte de la MOA très satisfaite périmètre
de la méthode
• Périmètre complexe mais encadré (pas
d’interface externe complexe)
Projet 3 • Pilotage par les délais • Architecture complexe
• MOA disponible avec un fort pouvoir de • Progiciel (peu de flexibilité
décision dans les fonctionnalités)
• Pas d’interface complexe
?
Projet 4 • MOA disponible • Demande
d’isofonctionnalité
Page N°8