Tech Rōnins

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)

Programme:

Composition d’équipe

Principe Agile du mois du Juillet

Problématiques actuelles

Les outils de l’épisode

Mais pour commencer, on voulait vous remercier pour tous vos retours sur le premier épisode. On a compilé tout ça et on a pu débriefer ensemble, faire le tri, réfléchir encore plus à ce qu’on recherchait vraiment dans ce podcast, quel était notre cible et ce qu’on voulait que les auditeurs en retirent comme information.

Ça nous a aussi permis de voir qu’on était toujours tous les deux alignés sur tout ça, ce qui est évidemment important.

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

“Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.”

Julien:

M’évoque le waterfall ou cycle en V appris à l’école.

Un évidence

Demande de découper le travail en petits morceaux

si on veut commencer les taches nouvellement prioritaires, il faut pouvoir terminer les taches en cours rapidement.

Sujet principal

Composition d’équipe

Quelle serait la taille idéale? Comment balancer les skills dans cette équipe?

La règle de Scrum de 3 à 9 personnes dans la même équipe est-elle viable? Est-ce une bonne idée d'avoir plus de 9 personnes dans une équipe, et si oui pourquoi?

Sous question: Comment créer une nouvelle équipe? Tous les nouveaux dans une nouvelle équipe? Ou un mix de nouveaux et d'anciens?

Pierre:

Rappel principe Scrum (3 -9) une pizza large pour toute l’equipe?

Fullstack team VS stack-based team?

Problématiques actuelles

Pierre:

Quand créer une nouvelle équipe? (metrics? / besoins?)

New joiners doivent passer quelques mois dans une équipe déjà existante? (Team DNA)

Julien:

Comment garder une équipe tech engagée?

prise de décisions, d’initiatives, rédaction de blog tech

comment aller plus loin que la simple coopération autour des taches

en remote

Outils de l’épisode

Pierre:

https://miro.com/ (Miro Board)

Sprint Rétrospective en remote

En temps réel - Possibilité infinie

Gratuit pour 3 boards / users illimité

Utile pour discuter/sketcher une solution / architecture

Julien:

https://marketplace.atlassian.com/apps/1220209/issue-checklist-for-jira-free?hosting=cloudandtab=overview (Issue Checklist for Jira Free)

checklist sur Epic / User Story / Tâche / Bug / etc

condition sur les transition

parfait pour Definition of Done ou Kanban policies

gratuit

lien dans les notes de l'émission

Programme:

Doit-on forcément publier ce tout premier épisode? Serait-ce vraiment “agile” de se donner une seconde chance?

Problématiques actuelles

Les outils de l’épisode

Principe Agile du mois de Juin

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

“Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.”

Pierre:

“satisfaire le client”

qui est le client? Est ce que tous les clients se valent?

distinguer le “client” interne et externe

“rapidement et régulièrement"

Scrum cadence toutes les 2 semaines

de + en + de “livraison mid-sprint”, petit enhancement traite comme hotfix

“grande valeur ajoutee”

comment mesurer?

valeur pour le client OU valeur pour l’entreprise?

Julien:

“satisfaire le client”

pas de problème

“rapidement et régulièrement”

ça va

application mobile rallonge lead time

pas aussi rapide que je voudrais mais va dans le bon sens

plus rapide que beaucoup d’autres entreprises quand mis en perspectives

“grande valeur ajoutée”

très à l’écoute de notre communauté

Sujet principal

Doit-on forcément publier ce tout premier épisode?

Jamais fait de podcasts, ce sera très loin d’être parfait.

On devrait avoir droit à une seconde chance.

L’agilité nous dit que le mieux est l'ennemie du bien.

Pierre:

Pour progresser il faut se frotter a la realite, le parallèle des startups qui passent des mois a faire un produit et ne le lance jamais car “jamais assez bien”

Feedback obsess

Si on ne livre pas avec Scrum, pas de retour client. Idem pour ce podcast.

Julien:

Le premier épisode sera toujours moins bien que les suivants, donc autant s’ouvrir aux critiques tout de suite

Pourquoi pas?

Quel niveau de qualité est si mauvais qu’on ne publie pas?

Bonne raison: si on sent que ça n’apporte pas de valeur?

Même si seulement 1% est utile aux auditeurs, c’est toujours plus que 0% si on ne publie pas.

Problématiques actuelles

Pierre:

recruitment

scaler les équipes (on double le nombre d’ingenieurs)

Julien:

répartition des équipes (feature team, en silo, fluides, etc)

court terme vs long terme

habitudes, seniors

recrutement

Outils de l’épisode

Pierre:

https://retromat.org/en/?id=1-89-118-48-83 (Retromat)

Julien:

Rétro - Gather Data - https://retromat.org/en/?id=97 (Tweet My Sprint)