Episode 3

full
Published on:

14th Sep 2021

Livraisons Agiles, comment synchroniser sans coupler

Programme:

  • Livraisons Agiles, comment synchroniser sans coupler
  • Problématiques actuelles
  • Les outils de l’épisode
  • Mais pour commencer, intéressons nous au principe Agile du mois de <mois>

Principe Agile du mois de Septembre

https://agilemanifesto.org/iso/fr/principles.html

“Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.”

Pierre:

  • “quelques semaines à quelques mois” à l’époque, du aux contraintes, mais plutôt quelques jours à notre époque?
  • “opérationnel” comment avoir un testing qui supporte du CD daily?
  • Comment faire avec plusieurs équipes qui travaillent sur la même app, en même temps? → feature flags?
  • Problème actuel: 2 équipes doivent release en même temps le même jour.

Julien:

  • évidence: jamais connu autre chose
  • loin l’époque où il fallait qu’un logiciel soit parfait avant de graver des milliers de CDs et les envoyer dans des magasins.
  • l'avènement du SaaS et du CI/CD permet une boucle de feedback plus courte
  • et donc de prendre plus de risques (technique, business)
  • plus efficace de répondre à des bugs
  • combat actuel: plus petites fonctionnalités dans le board Kanban
  • même si on livre fréquemment au niveau de l’entreprise, le lead time sur les epics est trop long à mon gout.
  • peut de découpage des epics
  • il y a un niveau en dessous duquel découper n’est pas efficace, mais je ne pense pas qu’on y soit

Sujet principal

Livraison Agile, découplée des équipes lorsqu’on travaille sur le même produit.

Pierre:

  • Utiliser les features flags? Permettre au code d'être “ready” en prod mais non accessible aux users tant que tout n’est pas prêt - comment faire si DB migration?

Julien:

  • 1) Monolithe modulaire avec mono répo
  • chaque équipe a son/ses modules et déploie en poussant sur Master / Main
  • + facile à mettre en place
  • - une équipe peut crasher toute l’application
  • - temps de compilation / packaging / déploiement
  • 2) Go Pierre Feature flags
  • 3) Micro services
  • + séparation des préoccupations (SoC)
  • + livraisons découplées
  • - doit publier des librairies pour le code commun
  • - log tracing
  • - monitoring

Problématiques actuelles

Pierre:

  • 2 equipes Scrum, mais qui travaille sur les memes produits
  • Livraison en prod le Mercredi toutes les 2 semaines
  • Comment faire pour ne plus attendre que l’autre equipe soit prête? 

Julien:

  • Tentative de Shape Up
  • Définition: 
  • Basecamp
  • Scrum de 8 semaines (6 semaines de Sprint + 2 semaines de cooldown)
  • 2 tracks en parallèle: 
  • 1 track produit qui prépare les prochains items pendant le Sprint et sélectionne ce qui part en prod au prochain cycle
  • 1 track ingénierie qui produit les items sélectionnés
  • Les équipes sont composées en fonction des items du cycle (souvent petites 3-4 personnes)
  • Pas d’estimations, mais un appétit qui est “grand” ou “petit”   
  • grand = 6 semaines
  • petit = ~2 semaines
  • Les équipes ont donc soit 1 grand soit plusieurs petit à produire pendant 1 cycle.
  • On s’est rendu compte que les cycles de 8 semaines étaient trop long pour nous à notre étape de développement
  • Doit comprendre ce qu’on voulait tirer de Shape Up, en extraire des pratiques et les introduire dans notre méthode actuelle (Kanban)
  • Equipe produit a créé un framework qui permet de bien prioriser et shaper les items à venir
  • très important
  • 50% de la qualité d’une feature est dans la qualité de sa spec
  • Les deux équipes principales affectée vont être fusionnées
  • - de rétro (1 / deux-trois mois) -> + de débrief (au niveau épic)
  • des sous-équipes (squads) autonomes / epics
  • résultat espéré:
  • plus de commande décentralisée (epic leader)
  • un meilleur partage des connaissances
  • les gens travailleront avec plus de personnes au total mais avec moins de personnes simultanément
  • Conclusion
  • On a du être agiles par rapport à nos pratiques et méthodes (réagir aux événements plutôt que suivre le plan - manifest agile)
  • Comprendre une méthode, en extraire certains principes et les introduire à notre méthode.
  • Ce que je fais avec ma méthode d'organisation personnelle
  • Tiendrai au courant de l’avancement de la mise en place

Outils de l’épisode

Pierre:

  • Figjam (https://www.figma.com/figjam/)

Julien:

  • Mind Node
  • Pas totalement lié à l’agilité mais très utile et très agile dans son utilisation
  • Logiciel de mind mapping (carte mentale)
  • Jamais trop compris l’intérêt mais il a une fonctionnalité qui a tout changé pour moi: la possibilité de linéariser l’arbre.
  • Passe d’un arbre à une liste à puces indentée
  • Permet de diverger (facile de rajouter un élément où on veut et descendre les niveaux d’abstraction)
  • Puis de converger (on linéarise et on a plus qu’à suivre le plan)
  • L’utilise pour faire mes présentations (diverge pour définir le contenu, puis converge pour rédiger les slides)
  • L’utilise pour écrire mon livre de la même façon (créé une soixantaine d’arbres reliés entre eux pour divergé, puis converge sur l’écriture du livre maintenant que le contenu est créé et organisé)

Listen for free

Show artwork for Agilistes

About the Podcast

Agilistes
Le podcast francophone de l'Agilité
Le podcast Francophone de l'Agilité où on vous partage tous les mois nos conversations et réflexions autour des méthodes, techniques et outils.

Animé par Julien Déray (http://julien.deray.fr) et Pierre Feray-Ferrand (https://www.linkedin.com/in/pierre-feray-ferrand-44575ab1 )

About your host

Profile picture for Julien Déray

Julien Déray

Agiliste convaincu depuis ma découverte de Scrum, j'ai eu la chance de pouvoir expérimenter rapidement divers approches au fil de mes pérégrinations dans les start-ups londoniennes.
Développeur Scala devant l'éternel, j'ai finalement décidé de me tourner vers le management pour orienter ma carrière moins vers le code et d'avantage vers l'humain.