Table ronde sur l'Agile à l'Atelier BNP Paribas

Transcript

1. Ratp Les méthodes « Agiles » à la RATP
2. Page N°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
3. Page N°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 Backlog Priorisation Implication des utilisateurs Points d’effort MOA présence permanente Amélioration des users stories et des tests Utilisation GreenHopper Fin 2007 Fin 2011 Projets simples Projets moyens Projets complexes (charges > 500 j.h)
4. Page N°4 La méthode Agile à la RATP Itération 1 Itération n 2 à 3semaines Recette Spécifications et priorisation Réalisation Bilan de projet Gestion du changement Documentation TMA  SCRUM et XP  Démarche par itérations :  Détail d’une itération
5. Page N°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
6. Page N°6 Enseignements et préconisations MOA Interlocuteur unique et pouvant prendre la majorité des décisions Disponibilité importante Réflexion initiale réalisée en amont : méthode agile ne veut pas dire zéro cadrage MOE MOE interne : profil technique car prenant part au développement et notamment à l’intégration La MOE peut jouer dans certains cas le rôle d’AMOA Intervention souple de prestataire pour le développement Entente et confiance
7. Page N°7 Enseignements et préconisations - 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é - 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 - 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 Un besoin pas toujours mûr voire inexistant 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 Reprise en maintenance difficile
8. Page N°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) • Manque de disponibilité • Possibilité de dérive du périmètre 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é ?