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
Principe Agile du mois de Septembre
https://agilemanifesto.org/iso/fr/principles.html (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)
