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

Transcription

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 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

4 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 Détail d une itération Documentation Recette Spécifications 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 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

7 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 - 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 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 Reprise en maintenance difficile - S assurer de la qualité technique de l application (plateforme qualité, 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 pouvoir affiner Demande forte de la MOA très satisfaite 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 Manque de disponibilité Possibilité de dérive du périmètre Architecture complexe Progiciel (peu de flexibilité dans les fonctionnalités) Projet 4 MOA disponible Demande? d isofonctionnalité Page N 8