OCTO 2012 - L'agilité à grande échelle, retour d'expérience avec Strator
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

OCTO 2012 - L'agilité à grande échelle, retour d'expérience avec Strator

  • 737 views
Uploaded on

Un projet de développement logiciel impliquant 80 personnes, distribuées sur 9 équipes réparties dans 4 pays. ...

Un projet de développement logiciel impliquant 80 personnes, distribuées sur 9 équipes réparties dans 4 pays.
Un produit devant soutenir une activité de plus de 5 000 000 de transactions de vente par jour.
Une première mise en production au bout de 6 mois.
Et de nouvelles fonctionnalités tous les deux mois.

Qui a dit que l’agile n’était pas adapté aux gros projets ?
Strator et OCTO Technology se proposent de partager avec vous un retour d’expérience sur la mise en place de méthodes agiles à large échelle : feature-teams, communautés de pratique, interactions avec des équipes off-shore, livraisons fréquentes et mises en production par un simple clic, prise de décisions collaboratives…
A l’issue de ce séminaire nous aurons partagé avec vous :
Nos Do’s & Don’t à propos des méthodes agiles lorsqu’elles sont appliquées à de gros projets
Les modèles d’organisation que nous avons mis en oeuvre
Nos meilleures pratiques pour diriger des équipes projets géographiquement distribuées
Les outils et les compétences clés pour démarrer un tel projet

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
737
On Slideshare
737
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
17
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • HLO
  • Utilisation de plusieurs gestionnaire de code source (SVN)Intégration des devs en provenance des différentes équipesOpération de merge du codeTemps pour builder la solution – Alors que ça ne devrait pas être un problème
  • HLO
  • HLO
  • PCH
  • CYM

Transcript

  • 1. L’Agile à grande échelleUn retour d’expérience avec STRATOR
  • 2. OCTO Technology Cabinet de conseil en architecture de SI  13 ans d’expérience sur les SI Banque, Assurance, Industrie, Services, Media  CA 2011 : 18,2 M€  Effectif 2012 : 150 personnes  Implantations internationales : France, Brésil, Maroc, Belgique, Suisse  Compétences : IT / Métier / Ergonomie / Coaching Architecture : cœur de métier  Agilité Audit applicatifs OCTO accompagne depuis plus de 6 ans ses clients sur la mise en place et le suivi Stratégie, démarche de tests et productivité des projets agiles des développements  Coaching d’équipe projet Etudes d’architecture (opportunité / faisabilité / POC)  Accompagnement produit / métier Sécurité applicative et gestion des identités et  Accompagnement technique des accès  Développements agile Expertise sur des sujets techniques :  Formation & Séminaires ESB, RIA, BI, Cloud, NoSQL, Spring, …
  • 3. L’agilité à grande échelle 8h45 Accueil 9h00 L’agile à grande échelle… Retour d’expérience 10h30 Questions – Réponses 11h00 Fin 3
  • 4. Intervenants Philippe Chevalier - STRATOR, Directeur Technique Romuald Simon - STRATOR, Team Leader Mathieu Despriée - OCTO Technology, Architecte Hervé Lourdin - OCTO Technology, Directeur de mission 4
  • 5. « By 2012,[…] agiledevelopment methods will beutilized in 80% of all software development projects » Thomas Murphy and David Norton, Gartner’s analysts (2010) 5
  • 6. Contexte projet 6
  • 7. STRATOR en quelques mots Filiale d’Altadis Distribution France Conception et réalisation de Terminaux Points de Vente dédiés aux Buralistes et diffuseurs de presse 7
  • 8. Contexte projet Projet stratégique pour l’entreprise  9500 clients  5 M de transactions de vente par jour à la cible Volonté de créer un produit innovant Utilisation de nouvelles technologies  Tactile pour le front office  Web pour le back office 8
  • 9. Contexte technique Middle Office Middle Office Middle Office XYZDevices DB SuppliersBack-office 9
  • 10. Contexte projet Projet stratégique pour l’entreprise  9500 clients  5 M de transactions de vente par jour à la cible Volonté de créer un produit innovant Utilisation de nouvelles technologies  Tactile pour le front office  Web pour le back office Choix de la méthodologie agile SCRUM 10
  • 11. Les promesses de l’Agile S’adapter auxSuivre changementsl’avancement tout au long desréel des projets projetsApporterrapidement de Réduirela valeur au rapidementMétier les risques 11
  • 12. Après 6 mois de développement L’expérience de l’agile à large échelle est très consommatrice en gestion de projet Les 7 équipes distribuées ont du mal à intégrer leurs développements ensemble Les recettes s’effectuent dans la douleur sur une base trop instable La première version majeure est attendue par le marché 6 mois plus tard 12
  • 13. Hypothèses Les méthodes agiles ne vont sont pas inconnues Vous savez ce que veut dire :  User Story  Story Point  TDD  Intégration continue  Rétrospective Vous connaissez SCRUM 13
  • 14. Nous nous concentrerons aujourd’hui sur les changements constatés à grande échelle 14
  • 15. AgendaCréer le FluxLa qualité à grande échelleS’adapter au fluxPiloter le fluxS’améliorer 15
  • 16. 1CRÉER LE FLUX 16
  • 17. CRÉER LE FLUX Matérialiser le flux Rituels à large échelle Le rythme 17
  • 18. CRÉER LE FLUX Matérialiser le flux Rituels à large échelle Le rythme 18
  • 19. 19
  • 20. A large échelle, le fluxdoit être plus détaillé En aval, comme en amont des développements 20
  • 21. … et en version électronique pour les équipes distantes 21
  • 22. Story Map 22
  • 23. CRÉER LE FLUX Matérialiser le flux Rituels à large échelle Le rythme 23
  • 24. Team Lead Tech Lead Dev. Testeur Coach méthodoAmbassadeurs d’équipe Ops 24
  • 25. Team Test Ops Support Directeur Leaders Leader Leader Leader Technique Problèmes uniquement !« Scrum de Scrum » meeting 25
  • 26. Démo multi-site France 3 équipes Moldavie 3 équipes Roumanie 1 équipe Vietnam 2 équipesSkype Mikogo
  • 27. CRÉER LE FLUX Matérialiser le flux Rituels à large échelle Le rythme 27
  • 28. Modèle de coûts en itératifCoûts Coordination et pilotage Transaction Travail à Transaction Entrante Valeur ajoutée Sortante Temps début d’itération fin d’itération
  • 29. Sur le projetCoûts Coordination et pilotage ~6 ETP Transaction Travail à Transaction Entrante Valeur ajoutée Sortante 1 semaine 1 semaine Temps début d’itération fin d’itération TOTAL : 4 à 5 semaines
  • 30. Le manque deFEEDBACK 30
  • 31. Sur le projetCoûts Coordination et pilotage ~6 ETP Transaction Travail à Transaction Entrante Valeur ajoutée Sortante 1 semaine 1 semaine Failure Load Temps début d’itération fin d’itération TOTAL : 4 à 5 semaines
  • 32. Objectif : 2 semainesCoûts Coordination et pilotage ~6 ETP Travail à Transaction Valeur ajoutée Sortante 1 jour 1 semaine Failure Load Temps début d’itération fin d’itération TOTAL : 4 à 5 semaines
  • 33. AgendaCréer le FluxLa qualité à grande échelleS’adapter au fluxPiloter le fluxS’améliorer 33
  • 34. 2LA QUALITE A GRANDE ECHELLE 34
  • 35. Une seule intégration continue 45 développeursSite 1 Site 2 Site 3 … SVN Intégration Continue Hudson/Maven 35
  • 36. Développement piloté par les tests ? (TDD) 36
  • 37. Adoption des pratiques de TDDSource : Version One - State of agile development survey 2011 37
  • 38. Il va falloir recetter tout ça ! 38
  • 39. Spécification par les tests, acceptance automatisée• sd 39
  • 40. Spécification par les tests, acceptance automatisée 40
  • 41. STOP THE LINE 41
  • 42. L’usine de développement Développeurs Site 1 Site 2 Site 3 … SVNFonctionnels GreenPepper Intégration Continue Hudson/Maven
  • 43. 43
  • 44. You Build it ? You Fix it ! 44
  • 45. 2 semaines !!Coûts Coordination et pilotage Travail à Valeur ajoutée 1 jour ½ journée Failure Load Temps début d’itération fin d’itération
  • 46. AgendaCréer le FluxLa qualité à grande échelleS’adapter au fluxPiloter le fluxS’améliorer 46
  • 47. 3S’ADAPTER AU FLUX 47
  • 48. 48
  • 49. Sprint planning Coordination et pilotageCoûts Travail à Valeur ajoutée 1 jour ½ journée Failure Load Temps début d’itération fin d’itération
  • 50. 50
  • 51. Sprint planningCoûts Coordination et pilotage Travail à Valeur ajoutée Temps début d’itération fin d’itération
  • 52. Passage en « pur » flux : Gains Plus d’adaptabilité pour le PO : planification continue Les équipes estiment au fil de l’eau Il n’est plus nécessaire de « calculer ce que l’on peut faire en une itération » Il n’y a plus de story « à moitié terminée » 52
  • 53. Passage en « pur » flux : Points de vigilance Plus de sprint planning ne signifie pas ne plus faire  de démo ou  de rétrospective ! Plus de planification par itération mais vérifier les buffers 53
  • 54. Backlog Spécification Validation DONEproduit (par les tests) au fil de l’eau Acceptance et en PROD Dev Sas infra BUFFER BUFFER BUFFER (perf, sécu…) VERIFIER LES RUPTURES DE CHARGE 54
  • 55. Passage en « pur » flux : Points de vigilance « Avec de grands pouvoirs viennent de grandes responsabilités » Le P.O. doit être constamment disponible pour soutenir les équipes sur :  La planification  Les questions fonctionnelles 55
  • 56. Equipes orientées composants 56
  • 57. 57
  • 58. 58
  • 59. 59
  • 60. 60
  • 61. 61
  • 62. Equipe multi-techno DéveloppeursTeam Leader Testeur 62
  • 63. Equipe multi-techno ET distribuée DéveloppeursTeam Leader Testeur Equipe étendue 63
  • 64. Feature Teams : GainsCréer expertise métier et autonomie : Les équipes/personnes doivent pouvoir décider seules Les équipes peuvent vivre à un rythme de livraison différent en fonction de leur backlog 64
  • 65. Feature Team En contrepartie… 65
  • 66. 66
  • 67. Communautés de pratiques 67
  • 68. Communautés de Pratiques Contre-poids nécessaire à l’organisation feature-team « business first » Responsable : leader technique Son rôle :  S’assurer que le logiciel est construit de la meilleure façon  Animer le partage des pratiques 68
  • 69. Diffusion du standard« Le standard est la meilleure pratique constatée à ce jour dans l’équipe projet pour réaliser un certain type de tâche » 69
  • 70. Hands On 70
  • 71. DESIGNCOLLABORATIF 71
  • 72. Communauté de pratiques des testeurs Même approche : diffusion du standard Echanges sur  la répartition des jeux de données de tests  la meilleure façon d’organiser les pages GreenPepper  … 72
  • 73. L’organisation en place aujourd’hui Leaders TechnologiquesAnimation & Méthodologie BFE MDE MMO YDARelease management AZO .NET JAVA TESTS •Tabac •Inventaire RSI •Autres pdts •Migration DME •Presse •Librairie Leaders Métiers •Pdts dématérialisés •BOSS BFE •Provisionning & outils •Finances •Gestion des Tiers 73
  • 74. AgendaCréer le FluxLa qualité à grande échelleS’adapter au fluxPiloter le fluxS’améliorer 74
  • 75. 4PILOTER LE FLUX 75
  • 76. Mesurer l’avancement global 76
  • 77. PILOTER L’AVANCEMENT GLOBAL (Story Map) 77
  • 78. Mesurer l’avancement local 78
  • 79. Story Points 79
  • 80. Story Points 80
  • 81. 81
  • 82. métaphore originale de Jeff Patton 82
  • 83. Lead time devStory = 37j Bug = 10j Tâche Tech = 15j 83
  • 84. Quelques nombres aujourd’hui Fréquence des livraisons :  Chaque mois : une livraison majeure  Chaque semaine : une livraison mineure Lead-time : 84
  • 85. AgendaCréer le FluxLa qualité à grande échelleS’adapter au fluxPiloter le fluxS’améliorer 85
  • 86. 5(S’) AMELIORER 86
  • 87. L’amélioration continue Amélioration des outils La formation Gérer les problèmes 87
  • 88. L’amélioration continue Amélioration des outils La formation Gérer les problèmes 88
  • 89. Collaboration DevOpsPrête tes jouets ! 89
  • 90. Développeurs Site 1 Site 2 Site 3 … SVN Intégration Fonctionnels GreenPepper Continue DEV• Une chaine de build et de déploiement automatisée TEST• Déploiements serveur + Déploiement terminaux en 1 clic automatisé• Une centaine de déploiements Ops en PROD en 18 mois PROD
  • 91. Métriques tech et métier comme boucle de feedbackTransactions Métier Clients déclarés € Mbps Charge machine Clients connectés 91
  • 92. L’amélioration continue Amélioration des outils La formation Gérer les problèmes 92
  • 93. La formation : Une nécessité pour travailler avec l’offshore Une équipe complète venue en France pendant 6 semaines pour s’imprégner des méthodes mises en place à Strator Des déplacements dans les pays pour aider à la mise en place d’une intégration continue centralisée Des venues régulières des chefs d’équipe offshore en France 93
  • 94. L’amélioration continue Amélioration des outils La formation Gérer les problèmes… 94
  • 95. « Les mauvaises nouvelles sont fatales à celui qui les apporte » Shakespeare 95
  • 96. Installer un climat de confiance 96
  • 97. Rétrospectives 97
  • 98. YOU SAY IT ?YOU OWN IT ! 98
  • 99. Et en off shore aussi ! 99
  • 100. Réunions Team Leaders Pas une réunion de planification On y échanges des points qui semblent importants …  Problèmes  Besoins  Risques  Infos etc… … et des idées d’amélioration 100
  • 101. Agenda ouvert de la dernière réunion team-leads 101
  • 102. !CONCLUSIONS 102
  • 103. Bilan à 18 mois (après plus de 40 itérations !) 2500 clients en production avec une croissance de 400 installations par mois Des équipes qui ont ré-internalisé le métier, la technique et la méthodo Des rythmes de livraison soutenus et des délais tenus Une collaboration main dans la main Dev et Ops Une collaboration dans les faits entre le marketing et la technique Des équipes qui ne pourraient pas « retourner en arrière » 103
  • 104. Facteurs clés du projet Maîtrise du flux de production de valeur Autonomisation & Responsabilisation  Le pari de la confiance par défaut Amélioration continue  Pas de recette agile miracle : il faut s’adapter sans cesse 104
  • 105. ?QUESTIONS / REPONSES 105