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