1.
Apprendre le Craft
en 1 mois… HELP!
REX - Société Générale
◢

2.
Agenda
● Qui sommes-nous ?
● Contexte et enjeux
● Dispositif
● Déroulement
● Résultats
● Take away
● Q&A
◢

3.
Qui sommes-nous ?
◢

4.
Jean-Louis Rigau
● Coach Craft & DevOps
● Adepte du clean code, du
continuous delivery et des
conteneurs
● Créateur du Paris Container Day
● Organisateur du meetup DevOps 🖤
Containers
@jlrigau
linkedin.com/in/jlrigau
◢

5.
Christophe Schreiber
@Schreiber_Chris
linkedin.com/in/christopheschreiber
● Développeur Java depuis 2005
● Promoteur des bienfaits du Craft
et de l’Agilité
● Tech Lead et Coach Craft à la
Société Générale
◢

6.
Contexte et enjeux
◢

7.
Société Générale Securities Services (SGSS)
● SGSS est responsable du métier de gestion de titres pour
les clients institutionnels du groupe Société Générale
● Nouvelle organisation depuis Janvier 2020
○ Business Unit à part regroupant IT et métier
■ Volonté de rapprochement avec le métier
○ Au sein de cette BU : nouvelle entité TTD
■ Responsable de la transformation digitale et du delivery
● Stratégie de SGSS
○ Moderniser ses systèmes pour répondre aux exigences des clients et
des régulateurs
○ Améliorer la qualité des développements et la stabilité des systèmes
○ Augmenter son attractivité
◢

8.
Tribu Clearing and SEttlement (CSE)
● Au sein de TTD, CSE est responsable de la chaîne de
règlement/livraison pour les opérations sur titres
● Une organisation hétérogène et silotée
○ Équipes dans plusieurs régions géographiques (Paris, Nantes, Inde)
○ Diversité des technologies (Java, C++, Cobol)
○ Systèmes vieillissants et complexes à maintenir
○ Forte séparation entre Devs et Ops
● Volonté d’aller vers une organisation DevOps
○ Casser les silos
○ Redonner responsabilité et autonomie aux équipes
○ Élever le niveau sur les pratiques
○ Montrer l’exemple chez SGSS
◢

9.
Projet T2T2S
● Projet de refonte avec des contraintes réglementaires
○ Un existant développé en C++ (gros monolithe)
○ Des coûts de maintenance élevés
■ Peu d’évolution et beaucoup d’incidents...
■ ...avec beaucoup de support
■ ...et des livraisons peu fréquentes
● Une opportunité de gagner en maîtrise
○ Revue du fonctionnel de l’application
○ Remise à l’état de l’art sur les pratiques de développement
○ Changement de technos et montée en compétence
■ Java / API / architecture hexagonale
◢

10.
Équipe Cash
● Composition de l’équipe pour cette refonte
○ 3 développeurs de l’équipe existante dont le Tech Lead
○ 1 Senior Craft qui rejoint l’équipe en tant qu’expert technique
● L'équipe doit être accompagnée dans sa montée en
compétence
○ Sur ses nouvelles pratiques
■ A déjà été sensibilisée aux pratiques Craft
● Sans vraiment pouvoir les mettre en oeuvre
● Beaucoup de legacy, pas forcément applicable
■ Réticence sur l’intérêt et le coût d’apprentissage de ses
pratiques
○ Sur la nouvelle stack technique
■ Java, API, Spring Boot
◢

11.
De multiples enjeux et challenges...
● Projet de refonte stratégique
● Volonté d’améliorer rapidement les pratiques de
développement
● Équipe inexpérimentée sur les technologies retenues
● Période de confinement qui démarre
Les modèles de coaching traditionnels ne sont pas adaptés,
il va falloir innover !
◢

12.
Du coaching intensif en totale immersion
◢

13.
Intention de départ
● Développer une fonctionnalité de l’application à l’état
de l’art des pratiques
● Aboutir à un produit livrable et démontrable
● Prouver l’intérêt des pratiques Craft
● Amorcer la transformation de l’organisation
Notre stratégie : opérer un changement
dans la culture et les pratiques de l’équipe
puis la faire rayonner
◢

14.
Ce qui nous a inspiré...
● Shu-Ha-Ri
○ Suivre les règles, comprendre les règles et transcender les règles
● Pédagogie active
○ C’est en faisant que j’apprends le mieux !
● Valeurs du manifeste Craft
○ Élever le niveau pour redonner de la maîtrise
● Transmission / Compagnonnage
○ Faire monter en compétence et donner de l’autonomie
● Technical Agile Coaching
○ Du coaching technique centré sur les pratiques au coeur de l’équipe
◢

15.
Le dispositif que nous avions en tête
● Immerger totalement un coach technique dans l’équipe
● Développer avec l’équipe une fonctionnalité du backlog
○ Facile à comprendre, indépendante, avec des enjeux techniques
○ Ayant des problématiques de design et des règles métier à implémenter
● Mettre le focus sur l’apprentissage des pratiques
● Apprendre tous ensemble
○ Partager nos connaissances techniques
○ S’appuyer sur les connaissances fonctionnelles de l’équipe
◢

16.
Déroulement
◢

17.
Comment ça a démarré ?
● 1 première session de mob
○ Sans la nommer
○ L’équipe adhère et en redemande !
● Puis une seconde
○ Avec la même émulation
● Pour finir par les sanctuariser
○ En les nommant cette fois
○ Mise en place de sessions quotidiennes (minimum 2h)
◢

18.
Choix de la fonctionnalité à développer
● 1er essai : Modélisation du compte Cash
○ Sujet qui avait déjà démarré
○ Fonctionnalité purement technique
Pas suffisamment de règles métier pour illustrer les pratiques
● 2ème essai : Règles de contrôles sur les comptes Cash
○ Cas métier simple et isolé
○ Enchaînement de règles fonctionnelles
○ Besoin exprimé en pseudo code et très proche du legacy
Propose des opportunités d’amélioration
à la fois sur l’expression du besoin et l’implémentation
◢

19.
Découverte des
pratiques
◢

20.
L’équipe découvre le craft...
● Au cours de ces sessions, le coach avec l’expert
technique font du live coding pour montrer chaque
nouvelle pratique
○ TDD
○ Principes SOLID
○ Clean Code
○ Refactoring
● L’équipe nous fait profiter de sa connaissance métier ce
qui facilite l’avancement
● Recueil du feedback en live pour adapter le contenu des
sessions
◢

21.
… le métier est embarqué...
● Nous l’impliquons dans des sessions de BDD
○ Pour clarifier les besoins métier à travers des exemples
■ Utilisation de la méthode Example Mapping
○ En mode 3 amigos
■ Avec le PO, le BA et les développeurs
● Ces exemples alimentent les tests d’intégration
○ Écrit directement en Gherkin dans le code
○ Mise en place de Cucumber
○ Double boucle TDD
◢

22.
… non sans douleur !
● Des premiers retours mitigés mais prévisibles
○ Ça coûte cher !
○ C’est trop compliqué !
○ On a toujours fait comme ça, pourquoi on ferait autrement ?
● Le Tech Lead freine l’initiative en raison de sa posture
○ Remise en question de son rôle et de sa légitimité
○ Vision très design first à réfréner
● Des réticences côté métier apparaissent également
○ Projet stratégique à fort enjeux
○ Deadline serrée, il faut délivrer !
Il nous faut rassurer, démontrer, désapprendre
◢

23.
Montée en
compétence
◢

24.
Le dispositif s’améliore...
● Le setup et le déblocage des problèmes techniques se font
en pair programming en amont des sessions
○ Setup Cucumber
○ Test d’intégration
○ Configuration de l’authentification
○ Mise en conformité sécurité
● Le dispositif évolue au fur et à mesure pour se
concentrer sur ce qui apporte le plus de valeur
○ Refactoring
○ Principes SOLID
○ Écriture de tests unitaires ou d’intégration
○ Spécificités du langage
◢

25.
… les pratiques sont approfondies...
● Les développeurs sont curieux et expérimentent
○ Ils s’intéressent à la littérature sur le Craft
○ Ils commencent à appliquer les pratiques sur leurs autres tâches
● À la demande, nous les accompagnons pour approfondir les
pratiques
○ En pair programming hors des sessions de mob
○ Coaching individuel
○ Centré sur leur quotidien
◢

26.
… et ainsi, l’équipe gagne en autonomie !
● Les membres de l’équipe gagnent en confiance
○ Ils proposent de prendre la main lors des sessions de mob
○ Ils maîtrisent de mieux en mieux les pratiques et les partagent aux
autres
○ Ils sont fiers
● Effet d'entraînement dans le groupe
○ Les plus réticents commencent à s’intéresser et à s’impliquer
○ La curiosité est aiguisée
Il nous faut encourager, valoriser, célébrer
◢

27.
Rayonnement
◢

28.
L’équipe fait le bilan...
● Au bout de 4 semaines, l’expérience se termine
○ Le travail réalisé est démontré au métier
○ Le résultat est conforme aux besoins métier
○ L’équipe est satisfaite du travail accompli
● L’équipe prend alors du recul sur les pratiques...
○ Quels en ont été les bienfaits ?
○ Quels sont les points négatifs ?
○ Quelles sont les axes d’amélioration ?
● ... et les compare à son ancienne façon de travailler
○ Que faut-il garder ?
○ Quelle valeur apportée ?
◢

29.
… elle partage au sein de l’organisation...
● Devant cet engouement, nous proposons à l’équipe de
partager son expérience
○ D’abord en interne dans sa tribu
○ Puis au top management
● Elle rayonne et devient visible
○ Elle est écoutée sur les freins rencontrés
○ Elle est force de proposition pour améliorer son quotidien
● Elle sert d’exemple pour les transformations d’autres
équipes
◢

30.
… et s’approprie durablement cette culture !
● Ayant le soutien de l’organisation, l’équipe souhaite
aller plus loin
○ Une démarche d’amélioration continue est mise en place
○ L’équipe est suffisamment mature pour poursuivre par elle-même sa
montée en compétence
○ Le coach devient dispensable
● La culture Craft s’installe pour de bon !
○ Les doutes ont été levés et la plus value est claire pour tous
○ Elle se propage autour de l’équipe
Il leur faut maintenir, approfondir, diffuser
◢

31.
Résultats
◢

32.
Mob programming
Objectifs :
➖ Partager des pratiques en apprenant
ensemble
➖ Faire émerger le design
collectivement
Organisation :
➖ 1 session quotidienne (2h minimum)
➖ Toute l’équipe est invitée
➖ Une personne écrit le code et les
autres la guident
✅ Partage des problèmes et solutions
en continu
✅ La pensée collective apporte de
meilleures solutions
❌ Avoir des sessions dynamiques à
distance
❌ Engager tout le monde
Le mob programming est une méthode de développement logiciel où toute l'équipe
travaille sur le même sujet, en même temps, dans le même espace et sur le même
ordinateur.
◢

33.
Pair programming
Objectifs :
➖ Résoudre les problèmes techniques
➖ Préparer les sessions de mob
programming
➖ Approfondir les pratiques en
sessions individuelles
Organisation :
➖ Entre les sessions de mob
programming (si nécessaire)
✅ Sessions de mob programming plus
efficaces
✅ Travailler en pair se fait
naturellement
✅ Suppression des points de blocage
✅ Coaching personnalisé
❌ Nécessite un outillage spécifique à
distance
Deux développeurs travaillent ensemble sur un même poste de travail. Le conducteur
rédige le code assisté par l’observateur qui décèle les imperfections et suggère des
alternatives de développement. Les rôles s'échangent régulièrement.
◢

34.
Revue de code
Objectifs :
➖ Améliorer la qualité du code
➖ Trouver les défauts
➖ Partager la connaissance
Organisation :
➖ Aucun code ne peut être poussé sans
revue préalable
➖ Le code est revu avec son auteur
pour clarifier les intentions
✅ Les Pull Requests simplifient la
revue de code
✅ Les décisions d’implémentation sont
systématiquement revues
✅ Oblige l’équipe à définir une
stratégie de versionning du code
❌ Pas nécessaire dans le cadre du
mob/pair programming
Une ou plusieurs personnes vont faire une revue des changements dans le code avant
qu’ils soient intégrés sur la branche principale, afin de permettre de détecter les
problèmes plus tôt et d’améliorer la qualité.
◢

35.
Test Driven Development (TDD)
Objectifs :
➖ Laisser le design émerger des tests
➖ Appliquer le Clean Code
➖ Avoir une couverture complète du
code
Organisation :
➖ Pas de code de production sans un
test qui échoue
➖ Se forcer à refactorer régulièrement
✅ Code couvert par des tests
pertinents
✅ Qualité du code indiscutable
✅ Meilleure lisibilité du code
✅ Refactoring facilité
❌ Gestion des mocks difficile à mettre
en place
❌ Pas facile de savoir quand s’arrêter
dans le refactoring
Processus de développement qui repose sur la répétition de cycles très courts. Les
exigences sont transformées en cas de test très spécifiques, puis le code minimal
est écrit afin que les tests passent, enfin le code est amélioré (refactoring).
◢

36.
Acceptance Test Driven Development (ATDD)
Objectifs :
➖ Renforcer la stratégie de tests
➖ Valider les fonctionnalités
développées
Organisation :
➖ Transformation des scénarios en
tests d’intégration (via Cucumber)
➖ Point de départ pour l’écriture du
code
✅ La structure du code peut être
initiée à partir des tests
✅ Documentation vivante
❌ La mise en place des tests
d’intégration est complexe
❌ Les scénarios de tests doivent
parfois être adaptés pour être
exploitable avec Cucumber
Extension du TDD qui permet de découper l’implémentation d’une fonctionnalité en une
succession de cycles de développement. ATDD se concentre sur l'écriture de tests
d'acceptation qui guident le développeur dans l’implémentation des fonctionnalités.
◢

37.
Behavior Driven Development (BDD)
Objectifs :
➖ Améliorer le partage de
connaissances
➖ Favoriser la collaboration
➖ Mieux comprendre les besoins métier
Organisation :
➖ Écriture des scénarios durant un
workshop avec les 3 Amigos
➖ Utilisation de Gherkin
✅ Révèle les critères d'acceptation
✅ Supprime les doutes et ambiguïtés
sur le besoin
✅ Casse les silos en impliquant tout
le monde
❌ Convaincre des bénéfices de cet
investissement est difficile
❌ Le Gherkin n’est pas évident à
écrire et comprendre
Pratique qui encourage la collaboration entre les développeurs, les testeurs et les
représentants du métier (3 Amigos) pour définir ensemble le comportement attendu de
l’application au travers d’exemples.
◢

38.
Clean Code
Objectifs :
➖ Définir les standards de code de l’
équipe
➖ Améliorer la qualité
Organisation :
➖ Application des principes SOLID
➖ Refactoring en continu
➖ Nettoyage systématique du code
(boyscout rule)
✅ Code plus lisible
✅ Design évolutif
❌ Tout le monde n’a pas la même
définition
❌ Attention à la surqualité
Le code est propre s’il peut être compris et modifié facilement, par n’importe
qui dans l’équipe et pas seulement son auteur. Pour cela, il doit être
lisible, extensible et maintenable.
◢

39.
Refactoring
Objectifs :
➖ Pousser la qualité de code à l’état
de l’art
➖ Faire entrer la pratique dans la
culture de l’équipe
Organisation :
➖ Focus sur le refactoring dans le
cycle TDD
➖ Détection et correction des code
smells
✅ Facile grâce aux autres pratiques
✅ Remise en question du design initial
✅ Apprentissage du langage
❌ Savoir se fixer des limites
❌ Impacte parfois les tests
❌ Constamment revoir le code peut être
ressenti comme superflu
Refactorer du code consiste à le modifier afin d’améliorer son design, revoir
sa structure, améliorer sa performance sans changer son comportement ce qui
permet de conserver les mêmes fonctionnalités.
◢

40.
Stratégie de tests
Objectifs :
➖ Respecter la pyramide des tests
➖ Automatiser autant que possible
➖ Améliorer la connaissances sur les
pratiques de tests
Organisation :
➖ Tests Unitaires sur tous les
composants
➖ Automatisation des tests
d’acceptance (tests d’intégration)
✅ Couverture de toutes les couches
✅ Code modifiable sans crainte de
régression
✅ Le test automatisé entre dans la
culture de l’équipe
❌ Courbe d’apprentissage importante
❌ Tests d’intégration complexes à
configurer
On définit les niveaux de tests à inclure dans le cycle de développement afin
d’assurer la qualité du logiciel produit (des tests unitaires de composants
jusqu’au tests de bout en bout).
◢

41.
“Tout changement est difficile au début,
compliqué au milieu et magnifique à la fin.”
Robin Sharma
◢

42.
Ce que nous avons retenu de cette expérience
● Ne jamais sous-estimer les réticences au changement
● Avoir un soutien au sein l’équipe est primordial pour
avancer
● Avoir un coach en immersion permet de progresser beaucoup
plus vite qu’avec du coaching traditionnel
● Apprendre une nouvelle pratique est un investissement
important
● Embarquer les décideurs donne à l’équipe les moyens de
réussir
◢

43.
6 mois plus tard...
◢

44.
L’équipe s’est transformée en profondeur et durablement
● Elle est stable
○ Forte cohésion de l’équipe
■ bon état d’esprit
■ pas de turn over
○ Centrée sur les solutions plutôt que les problèmes
● Elle maîtrise son code
○ La plupart des pratiques introduites sont toujours appliquées
■ Pair & Mob programming, TDD, Clean Code, refactoring, Code review
○ D’autres ont émergé
■ Architecture hexagonale, DDD, Continuous Delivery, conteneurs
○ D’autres ont été délaissées par manque de mise en oeuvre et la
difficulté à les maintenir
■ BDD, ATDD
◢

45.
Cette transformation a des impacts positifs et concrets
● Des retombées directes pour l’équipe...
○ L’expérience acquise par l’équipe valide les bienfaits du Craft
■ L’amélioration des pratiques a une incidence directe et visible
sur sa capacité de delivery
○ Le management et le métier prennent conscience de la nécessité de
maîtriser son cycle de développement
■ L’équipe est soutenue dans sa démarche d'amélioration continue et
peut expérimenter plus librement
● ... ainsi qu’au niveau de l’organisation !
○ Le rayonnement de l’équipe est réel
■ Elle promeut le Craft au sein de SGSS
■ D’autres équipes chez TTD veulent suivre le même chemin
■ Le management souhaite passer la démarche à l’échelle
◢

46.
Q&A
◢