Table ronde méthodes agiles : RATP
Upcoming SlideShare
Loading in...5
×
 

Table ronde méthodes agiles : RATP

on

  • 1,176 views

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.

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.

Statistics

Views

Total Views
1,176
Views on SlideShare
1,176
Embed Views
0

Actions

Likes
0
Downloads
15
Comments
3

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • @lcottereau
    Inviter des manager et des responsables à la rétrospective est une bonne idée pour vendre les méthodes agiles. En effet, le management est un appui nécessaire pour un tel changement de méthodologie. Toutefois, dans mes expériences précédentes, nous avions dû prendre des mesures:
    1- une personne invitée externe à l'équipe, ne doit pas participer à la réunion et se contente d'observer, certains appellent ce rôle 'la poule' dans le jargon agile. En effet, il ne faut pas qu'elle perturbe notre bilan.
    2- Outre cela, ce genre d’invités (management), perturbaient la spontanéité de l'équipe et sa liberté d'expression pendant le bilan. L'équipe a tendance à ne pas oser parler de certains problèmes délicat.
    Dans ton équipe, jusqu'à quel point ces deux remarques sont-elles vrai ?

    Cordialement.
    Are you sure you want to
    Your message goes here
    Processing…
  • Bonjour, le bilan projet est une retrospective (terminologie scrum) mais que nous faisons aussi avec des membres extérieurs au projet (management) afin de faire de la publicité sur la méthode.
    Nous ne changeons pas la spécification ou la priorité à l'intérieur d'une itération.
    Are you sure you want to
    Your message goes here
    Processing…
  • Bonjour,

    Je suis curieux sur les deux points ci-dessous ( Slide4) :
    * C'est quoi un bilan Projet? Qui le fait et quel est son livrable ?
    * Pendant une même itération, vous tolérez un changement de spécification et de priorité. Comment est-ce possible en Scrum ou XP ? comment vous vous y prenez si le changement est gros?
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Table ronde méthodes agiles : RATP Table ronde méthodes agiles : RATP Presentation Transcript

  • RatpLes méthodes « Agiles » à laRATP
  • Historique de la démarche Agile à la RATP Historiquement, le département SIT (Systèmes dInformation 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
  • Historique de la démarche Agile à la RATPItérations et Spécifications au juste nécessaire Projets simples Fin 2007Un 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
  • 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
  • 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 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
  • Enseignements et préconisations - Avoir une MOA plus présente et prenant desUn besoin pas toujours mûr voire décisionsinexistant - 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 deet Développeur Scrum Master et la transférer à la MOADifficile de faire des gros projets avec - Interfaces définies et connuesbeaucoup d’interfaces - Architectures classiquesInteraction difficile avec des projets non - Ne pas hésiter à refuser de faire du Scrumagiles 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
  • Exemples de projetsProjet Conditions de réussite identifiées Risques identifiés DécisionProjet 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 importantProjet 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