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

1. L’Agile à grande échelle
Un 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,[…] agile
development methods will be
utilized 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
XYZ
Devices DB Suppliers
Back-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 aux
Suivre changements
l’avancement tout au long des
réel des projets projets
Apporter
rapidement de Réduire
la valeur au rapidement
Mé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. Agenda
Créer le Flux
La qualité à grande échelle
S’adapter au flux
Piloter le flux
S’améliorer
15

16. 1
CRÉ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 flux
doit ê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éthodo
Ambassadeurs 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 équipes
Skype Mikogo

27. CRÉER LE FLUX
 Matérialiser le flux
 Rituels à large échelle
 Le rythme
27

28. Modèle de coûts en itératif
Coû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 projet
Coû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 de
FEEDBACK
30

31. Sur le projet
Coû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 semaines
Coû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. Agenda
Créer le Flux
La qualité à grande échelle
S’adapter au flux
Piloter le flux
S’améliorer
33

34. 2
LA QUALITE A GRANDE ECHELLE
34

35. Une seule intégration continue
45 développeurs
Site 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 TDD
Source : 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 …
SVN
Fonctionnels 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. Agenda
Créer le Flux
La qualité à grande échelle
S’adapter au flux
Piloter le flux
S’améliorer
46

47. 3
S’ADAPTER
AU FLUX
47

48. 48

49. Sprint planning
Coordination et pilotage
Coû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 planning
Coû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 DONE
produit (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éveloppeurs
Team Leader Testeur
62

63. Equipe multi-techno ET distribuée
Développeurs
Team Leader Testeur
Equipe étendue
63

64. Feature Teams : Gains
Cré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. DESIGN
COLLABORATIF
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 Technologiques
Animation & Méthodologie BFE
MDE MMO YDA
Release 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. Agenda
Créer le Flux
La qualité à grande échelle
S’adapter au flux
Piloter le flux
S’améliorer
74

75. 4
PILOTER 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 dev
Story = 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. Agenda
Créer le Flux
La qualité à grande échelle
S’adapter au flux
Piloter le flux
S’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 DevOps
Prê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 feedback
Transactions 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