Télécharger la présentation de Laurent Cottereau

Transcription

Télécharger la présentation de Laurent Cottereau
Ratp
Les méthodes « Agiles » à la
RATP
Historique de la démarche Agile à la RATP

Historiquement, le département SIT
Télécommunications)
(Systèmes d'Information et de
 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
Historique de la démarche Agile à la RATP
Itérations et Spécifications au juste nécessaire
Un interlocuteur MOA sur le plateau chaque semaine
Projets
simples
Fin 2007
Backlog
Priorisation
Implication des utilisateurs
Points d’effort
Projets
moyens
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
La méthode Agile à la RATP

SCRUM et XP

Démarche par itérations :
Itération 1
2 à 3semaines
Itération n
Bilan de
projet
TMA
Gestion du changement
Documentation

Détail d’une itération
Recette
Spécifications
et priorisation
Réalisation
Page N°4
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
Enseignements et préconisations
MOA
Entente et confiance
MOE
Interlocuteur unique et pouvant
prendre la majorité des
décisions
MOE interne : profil technique car
prenant part au développement et
notamment à l’intégration
Disponibilité importante
La MOE peut jouer dans certains
cas le rôle d’AMOA
Réflexion initiale réalisée en amont
: méthode agile ne veut pas dire
zéro cadrage
Intervention souple de prestataire
pour le développement
Page N°6
Enseignements et préconisations
Un besoin pas toujours mûr voire
inexistant
-
Avoir une MOA plus présente et prenant des
décisions
Bénéficier d’un retour utilisateur très tôt
Fonctionnel non figé
Une MOE à la fois
- AMOA et MOE
- Scrum Master, Product Owner
et Développeur
-
Difficile de faire des gros projets avec
beaucoup d’interfaces
Interaction difficile avec des projets non
agiles ou des applications en production
-
Interfaces définies et connues
Architectures classiques
Ne pas hésiter à refuser de faire du Scrum
pour certains projets
-
S’assurer de la qualité technique de
l’application (plateforme qualité,
documentation technique, …)
Disposer d’une bonne documentation
fonctionnelle
-
Reprise en maintenance difficile
-
Avoir une MOA plus présente et prenant des
décisions
Séparer la fonction de Product Owner de
Scrum Master et la transférer à la MOA
Page N°7
Exemples de projets
Projet
Conditions de réussite identifiées
Risques identifiés
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
• MOA disponible avec un fort pouvoir de
décision
• Pas d’interface complexe
• Architecture complexe
• Progiciel (peu de flexibilité
dans les fonctionnalités)
Projet 4
• MOA disponible
• Demande
d’isofonctionnalité
Décision
?
Page N°8