Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
Apprendre le Craft
en 1 mois… HELP!
REX - Société Générale
◢
Agenda
● Qui sommes-nous ?
● Contexte et enjeux
● Dispositif
● Déroulement
● Résultats
● Take away
● Q&A
◢
Qui sommes-nous ?
◢
Jean-Louis Rigau
● Coach Craft & DevOps
● Adepte du clean code, du
continuous delivery et des
conteneurs
● Créateur du Par...
Christophe Schreiber
@Schreiber_Chris
linkedin.com/in/christopheschreiber
● Développeur Java depuis 2005
● Promoteur des b...
Contexte et enjeux
◢
Société Générale Securities Services (SGSS)
● SGSS est responsable du métier de gestion de titres pour
les clients institu...
Tribu Clearing and SEttlement (CSE)
● Au sein de TTD, CSE est responsable de la chaîne de
règlement/livraison pour les opé...
Projet T2T2S
● Projet de refonte avec des contraintes réglementaires
○ Un existant développé en C++ (gros monolithe)
○ Des...
Équipe Cash
● Composition de l’équipe pour cette refonte
○ 3 développeurs de l’équipe existante dont le Tech Lead
○ 1 Seni...
De multiples enjeux et challenges...
● Projet de refonte stratégique
● Volonté d’améliorer rapidement les pratiques de
dév...
Du coaching intensif en totale immersion
◢
Intention de départ
● Développer une fonctionnalité de l’application à l’état
de l’art des pratiques
● Aboutir à un produi...
Ce qui nous a inspiré...
● Shu-Ha-Ri
○ Suivre les règles, comprendre les règles et transcender les règles
● Pédagogie acti...
Le dispositif que nous avions en tête
● Immerger totalement un coach technique dans l’équipe
● Développer avec l’équipe un...
Déroulement
◢
Comment ça a démarré ?
● 1 première session de mob
○ Sans la nommer
○ L’équipe adhère et en redemande !
● Puis une seconde...
Choix de la fonctionnalité à développer
● 1er essai : Modélisation du compte Cash
○ Sujet qui avait déjà démarré
○ Fonctio...
Découverte des
pratiques
◢
L’équipe découvre le craft...
● Au cours de ces sessions, le coach avec l’expert
technique font du live coding pour montre...
… le métier est embarqué...
● Nous l’impliquons dans des sessions de BDD
○ Pour clarifier les besoins métier à travers des...
… non sans douleur !
● Des premiers retours mitigés mais prévisibles
○ Ça coûte cher !
○ C’est trop compliqué !
○ On a tou...
Montée en
compétence
◢
Le dispositif s’améliore...
● Le setup et le déblocage des problèmes techniques se font
en pair programming en amont des s...
… les pratiques sont approfondies...
● Les développeurs sont curieux et expérimentent
○ Ils s’intéressent à la littérature...
… et ainsi, l’équipe gagne en autonomie !
● Les membres de l’équipe gagnent en confiance
○ Ils proposent de prendre la mai...
Rayonnement
◢
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
○ L...
… elle partage au sein de l’organisation...
● Devant cet engouement, nous proposons à l’équipe de
partager son expérience
...
… et s’approprie durablement cette culture !
● Ayant le soutien de l’organisation, l’équipe souhaite
aller plus loin
○ Une...
Résultats
◢
Mob programming
Objectifs :
➖ Partager des pratiques en apprenant
ensemble
➖ Faire émerger le design
collectivement
Organi...
Pair programming
Objectifs :
➖ Résoudre les problèmes techniques
➖ Préparer les sessions de mob
programming
➖ Approfondir ...
Revue de code
Objectifs :
➖ Améliorer la qualité du code
➖ Trouver les défauts
➖ Partager la connaissance
Organisation :
➖...
Test Driven Development (TDD)
Objectifs :
➖ Laisser le design émerger des tests
➖ Appliquer le Clean Code
➖ Avoir une couv...
Acceptance Test Driven Development (ATDD)
Objectifs :
➖ Renforcer la stratégie de tests
➖ Valider les fonctionnalités
déve...
Behavior Driven Development (BDD)
Objectifs :
➖ Améliorer le partage de
connaissances
➖ Favoriser la collaboration
➖ Mieux...
Clean Code
Objectifs :
➖ Définir les standards de code de l’
équipe
➖ Améliorer la qualité
Organisation :
➖ Application de...
Refactoring
Objectifs :
➖ Pousser la qualité de code à l’état
de l’art
➖ Faire entrer la pratique dans la
culture de l’équ...
Stratégie de tests
Objectifs :
➖ Respecter la pyramide des tests
➖ Automatiser autant que possible
➖ Améliorer la connaiss...
“Tout changement est difficile au début,
compliqué au milieu et magnifique à la fin.”
Robin Sharma
◢
Ce que nous avons retenu de cette expérience
● Ne jamais sous-estimer les réticences au changement
● Avoir un soutien au s...
6 mois plus tard...
◢
L’équipe s’est transformée en profondeur et durablement
● Elle est stable
○ Forte cohésion de l’équipe
■ bon état d’esprit...
Cette transformation a des impacts positifs et concrets
● Des retombées directes pour l’équipe...
○ L’expérience acquise p...
Q&A
◢
Prochain SlideShare
Chargement dans…5
×

Apprendre le Craft en 1 mois… HELP! (REX Société Générale) - Agile en Seine 2020

59 vues

Publié le

Présenté par Christophe Schreiber et ean-Louis Rigau lors du meetup Agile en Seine le 12 novembre 2020
http://agileenseine.com

Vidéo de la conférence disponible sur Youtube :
https://youtu.be/cTJHyQrhF1A

Dans le cadre de la refonte d’une application de gestion des flux cash, l’entité Clearing and SEttlement (CSE) de la Société Générale Securities Services (SGSS) a su saisir l'opportunité de se mettre à l’état de l’art sur la culture et les pratiques craft.

Afin d’avoir un impact fort et rapide, nous avons commencé par mettre en place un dispositif de mentoring intensif sur une équipe. En immersion total, un coach craft associé à l’expert technique se sont concentrés sur la montée en compétence de l’ensemble de l’équipe sur ses pratiques pour lui permettre de maîtriser son code ! L’objectif était de faire de cette équipe un point de référence sur lequel le reste de l’entité pourra prendre exemple.

Plutôt que de faire des katas, nous avons mis en place des sessions de mob programming quotidiennes pour développer les fonctionnalités du backlog via la pratique du TDD, des principes SOLID et du Clean Code. Passé l’effet waouh de la découverte et les réticences initiales, l’équipe s’est prise au jeu et a commencé à s’approprier les nouvelles pratiques en les expérimentant jusqu’à les maîtriser, permettant au coach de s'effacer progressivement.

Cette démarche a été une réussite pour toute l’organisation car elle a permis d’amorcer le changement culturel attendu d'abord dans l’équipe puis, par rayonnement, sur l’ensemble des équipes de CSE.

Ce REX vous est présenté par:

Christophe Schreiber
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
Twitter : @Schreiber_Chris
LinkedIn : linkedin.com/in/christopheschreiber

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
Twitter : @jlrigau
LinkedIn : linkedin.com/in/jlrigau

Publié dans : Business
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Apprendre le Craft en 1 mois… HELP! (REX Société Générale) - Agile en Seine 2020

  1. 1. Apprendre le Craft en 1 mois… HELP! REX - Société Générale ◢
  2. 2. Agenda ● Qui sommes-nous ? ● Contexte et enjeux ● Dispositif ● Déroulement ● Résultats ● Take away ● Q&A ◢
  3. 3. Qui sommes-nous ? ◢
  4. 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. 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. 6. Contexte et enjeux ◢
  7. 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. 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. 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. 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. 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. 12. Du coaching intensif en totale immersion ◢
  13. 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. 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. 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. 16. Déroulement ◢
  17. 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. 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. 19. Découverte des pratiques ◢
  20. 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. 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. 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. 23. Montée en compétence ◢
  24. 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. 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. 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. 27. Rayonnement ◢
  28. 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. 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. 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. 31. Résultats ◢
  32. 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. 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. 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. 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. 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. 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. 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. 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. 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. 41. “Tout changement est difficile au début, compliqué au milieu et magnifique à la fin.” Robin Sharma ◢
  42. 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. 43. 6 mois plus tard... ◢
  44. 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. 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. 46. Q&A ◢

×