Réunion de planification Scrum, dans une PME d’une douzaine d’employés, dont 5-7 personnes dans l’équipe de devs. Elles passent en revue les stories en haut du backlog, par ordre de nombre de points descendant. Pour chaque, découpage en tâches techniques¹ et estimation grossière du nombre de jours de travail, pour déterminer ce qui devrait rentrer dans le sprint et quand arrêter d’en prendre².

Au bout d’un moment, l’équipe arrive à une story d’apparence simple : sur l’application mobile Android qu’elle maintient et édite en marque blanche pour ses clients B2B, il est demandé d’ajouter une pastille sur les contenus offerts avec l’appli, pour permettre aux utilisateurs (= les clients des clients de la PME) de mieux identifier ces cadeaux au milieu de leurs achats.

Vu de loin et sans entrer dans les détails, ça n’a pas l’air d’être une très grosse évolution et l’équipe estime qu’il y en a pour deux jours de travail.
Quelque chose comme 0,25 jour pour bien cadrer le besoin³ et déterminer quel pictogramme afficher, 0,25 jour pour monter un environnement de développement, 1 jour pour coder et tester/valider la fonctionnalité et 0,5 jour pour rebuilder les déclinaisons de l’application pour chacun des clients et les déployer sur le store Android.

Mais…

Daily, I hear developers say “my¹ user story is finished”. And, almost always, they utter this sentence when they have deployed a feature to production².

But I don’t think a User Story should be considered as “done” at that time!

This article is, more or less, a follow-up to “Your git log is not a changelog!”, published by @aureliengateau a few days ago.

Aurélien says an application’s changelog should not be generated from its commit history. And that commits should not be squashed in order to produce a changelog. And I agree 100% with these ideas!

For me, the changelog of your application should be built from your User Stories. Not from your Git history.

Mon employeur a pris possession de nos nouveaux locaux il y a bientôt deux ans. Nous y travaillons en flex-office : chacun, chacune, en arrivant le matin, s’assoit où il ou elle veut, pour peu que la place soit libre.

À cause du Covid, nous n’avons repris un rythme « aller au bureau » normal que depuis environ un an. J’en ai parlé quand j’ai dressé mon bilan de un an de pire-que-du-télétravail.

Depuis, plusieurs fois, on m’a demandé ce que je pensais du flex-office, comment ça se passait. Après un an, je commence à avoir un peu de recul et à y voir du positif… Et du négatif.

J’étais à la conférence Sunny Tech, à Montpellier, vendredi : j’ai eu la chance d’y parler de « préparez et donnez votre premier talk », pour essayer d’encourager la prochaine génération à se lancer.

Pendant mon intervention, je préviens les futurs et futures speakeurs : préparer un talk, ça prend du temps !

Je précise même que préparer une conférence demande souvent 30 à 50 heures de travail, que c’est une durée moyenne fréquente pour des speakeurs qui commencent.

Cette fois, après ma présentation, une personne est venue me poser une question à laquelle je n’avais pas encore répondu en public : « et pour une conférence que tu as déjà faite, combien de temps ça prend de la redonner ? »

Et bien, voyons voir !