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

Un retour d’expérience avec STRATOR

L’Agile à grande échelle

OCTO Technology

Agilité

OCTO accompagne depuis plus de 6 ans ses clients sur la mise en place et le suivi des projets agiles

Coaching d’équipe projet

Accompagnement produit / métier

Accompagnement technique

Développements agile

Formation & Séminaires

Architecture : cœur de métier Audit applicatifs

Stratégie, démarche de tests et productivité des développements

Etudes d’architecture (opportunité / faisabilité / POC)

Sécurité applicative et gestion des identités et des accès

Expertise sur des sujets techniques : ESB, RIA, BI, Cloud, NoSQL, Spring, …

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

Cabinet de conseil en architecture de SI

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

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)

6

Contexte projet

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

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

9

Contexte technique

DB

Middle OfficeMiddle Office

Middle Office

Devices

XYZ

Suppliers

Back-office

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

11

Suivre l’avancement réel des projets

S’adapter aux changements tout au long des projets

Apporter rapidement de la valeur au Métier

Réduire rapidement les risques

Les promesses de l’Agile

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

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

14

Nous nous concentrerons aujourd’hui sur les changements constatés à

grande échelle

15

Agenda

Créer le Flux

La qualité à grande échelle

S’adapter au flux

Piloter le flux

S’améliorer

16

1

CRÉER LE FLUX

17

CRÉER LE FLUX

Matérialiser le flux

Rituels à large échelle

Le rythme

18

CRÉER LE FLUX



Le rythme

19

20

A large échelle, le flux doit être plus détaillé

En aval, comme en amont des développements

21

… et en version électronique pour les équipes distantes

22Story Map

23

CRÉER LE FLUX



Le rythme

24

Dev. TesteurTech LeadTeam Lead

Ops

Amba

ssad

eurs

d’é

quip

e

Coachméthodo

25« Scrum de Scrum » meeting

Ops Leader

Team Leaders

Test Leader

Support Leader

DirecteurTechnique

Problèmesuniquement !

Démo multi-site

Roumanie1 équipe

Moldavie3 équipes

Vietnam2 équipes

France3 équipes

Skype Mikogo

27

CRÉER LE FLUX



Le rythme

Modèle de coûts en itératif

Coordination et pilotage

Transaction Entrante

Transaction Sortante

Travail à Valeur ajoutée

Coûts

Tempsdébut d’itération fin d’itération

Sur le projet





Coûts


1 semaine 1 semaine

TOTAL : 4 à 5 semaines

~6 ETP

30

Le manque de

FEEDBACK

Sur le projet





Coûts


1 semaine 1 semaine


~6 ETP

Failure Load

Objectif : 2 semaines




Coûts


1 jour 1 semaine


~6 ETP

Failure Load

33

Agenda

Créer le Flux


S’adapter au flux

Piloter le flux

S’améliorer

34

2

LA QUALITE A GRANDE ECHELLE

35

Une seule intégration continue

SVN

Intégration Continue

Hudson/Maven

Site 1 Site 2 Site 3 …

45 développeurs

36

Développement piloté par les tests ? (TDD)

37

Adoption des pratiques de TDD

Source : Version One - State of agile development survey 2011

38Il va falloir recetter tout ça !

39

Spécification par les tests, acceptance automatisée

• sd

40

Spécification par les tests, acceptance automatisée

41

STOP THE LINE

SVN

Développeurs

GreenPepper Intégration Continue

Hudson/Maven

Fonctionnels


L’usine de développement

43

44

You Build it ?

You Fix it !

2 semaines !!



Coûts


1 jour ½ journée

Failure Load

46

Agenda

Créer le Flux


S’adapter au flux

Piloter le flux

S’améliorer

47

3

S’ADAPTERAU FLUX

48

Sprint planning


Coûts


1 jour ½ journée

Failure Load


50

SPRINT

Sprint planning



Coûts


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 »

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

54

Backlog produit

BUFFER

Spécification (par les tests)

BUFFER BUFFER

Validationau fil de l’eau

DevAcceptance

Sas infra(perf, sécu…)

DONE et en PROD

VERIFIER LES RUPTURES DE CHARGE

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

56

Equipes orientées composants

57

58

59

60

61

62

Equipe multi-techno

Team Leader

Développeurs

Testeur

63

Equipe multi-techno ET distribuée

Développeurs

Testeur

Equipe étendue

Team Leader

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

65

Feature Team

En contrepartie…

66

67

Communautés de pratiques

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

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 »

70

Hands On

71

DESIGNCOLLABORATIF

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 …

73

•Tabac•Inventaire•Autres pdts•Migration

•Presse•Librairie

•Pdts dématérialisés•BOSS•Provisionning & outils•Finances•Gestion des Tiers

Lead

ers

Mét

iers

Leaders Technologiques

.NET

RSI

DME

BFE

MDE MMO YDA

Release management AZO

Animation & Méthodologie BFE

JAVA TESTS

L’organisation en place aujourd’hui

74

Agenda

Créer le Flux


S’adapter au flux

Piloter le flux

S’améliorer

75

4

PILOTER LE FLUX

76

Mesurer l’avancement global

77

PILOTER L’AVANCEMENT GLOBAL(Story Map)

78

Mesurer l’avancement local

79

Story Points

80

Story Points

81

82métaphore originale de Jeff Patton

83

Lead time dev

Story = 37j Bug = 10j Tâche Tech = 15j

84

Quelques nombres aujourd’hui

Fréquence des livraisons : Chaque mois : une livraison majeure Chaque semaine : une livraison mineure

Lead-time :

85

Agenda

Créer le Flux


S’adapter au flux

Piloter le flux

S’améliorer

86

5

(S’) AMELIORER

87

L’amélioration continue

Amélioration des outils

La formation

Gérer les problèmes

88



La formation


89

Collaboration DevOps

Prête tes jouets !

SVN

Développeurs

GreenPepperIntégration Continue

DEV

Fonctionnels


Déploiement automatisé

PROD

TEST

Ops

• Une chaine de build et de déploiement automatisée

• Déploiements serveur + terminaux en 1 clic

• Une centaine de déploiements en PROD en 18 mois

91

Métriques tech et métiercomme boucle de feedback

Transactions Métier

€ Mbps

Charge machine

Clients déclarés

Clients connectés

92



La formation


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

94



La formation

Gérer les problèmes…

95

« Les mauvaises nouvelles sont fatales à celui qui les apporte »

Shakespeare

96

Installer un climat de confiance

97Rétrospectives

98

YOU SAY IT ?

YOU OWN IT !

99

Et en off shore aussi !

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

101

Agenda ouvert de la dernière réunion team-leads

102

!

CONCLUSIONS

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 »

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

105

?

QUESTIONS / REPONSES

Documents

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