#til Aujourd'hui je me suis posé la question de notre capacité de réalisation en tant qu'équipe de dev agile.
D'obédience #noestimate ce qui m'intéresse ce sont le nombre de tickets qu'on délivre, le ratio feature / bugfix / tech.
Ainsi que le *lead time* moyen par ticket, soit le temps en jours le plus effectif entre le moment où on prend la tâche et le moment où on la considère finie.
Dans mon cas, une approximation acceptable est depuis le premier commit d'une PR jusqu'à sa fusion.
Le projet - Carnet de bord ~ https://github.com/gip-inclusion/carnet-de-bord - est open source et hébergé sur GitHub.
J'ai commencé par utiliser la CLI #github pour récupérer des infos sur les PRs depuis ces 2 derniers mois.
https://cli.github.com → brew install gh
⚠️ Quand on ajoute le champs "commits", on peut rapidement dépasser le nombre de "nodes" autorisés.
J'ai répété la commande pour les mois de septembre, octobre et novembre. Puis j'ai concaténé les 3 fichiers dans un nouveau `input.json`.
Service public numérique 🇫🇷 qui a pour objectif de faciliter la coordination des échanges entre acteurs et de simplifier la lecture des parcours d’insertion. - GitHub - gip-inclusion/carnet-de-bord...
Je me suis ensuite fait un petit script Node.js qui parcours chacune des PR et calcule le #leadtime et le #reviewtime pour chacune.
cf. https://gist.github.com/jbuget/918a31ac9af459f4c4a8ae3d498ad062
A la fin, j'obtiens un fichier `output.json` que je peux filer à manger à `jq`, un petit utilitaire ultra pratique pour manipuler et analyser du JSON.
On pourrait aller beaucoup plus loin.
Ex : calculer la moyenne sur les 3, 5 et 7 dernières itérations (de 2 semaines).
Ex : calculer le temps moyen par ttypologie de tâche (bugfix, feature, tâche tech).
Ex : voir grosso modo quel membre de l'équipe travaille le plus sur quel pan fonctionnel / technique
⚠️ Mais attention ! De grands pouvoirs, impliquent de grandes responsabilités. Attention de ne pas se servir de cet outillage pour traquer n'importe comment les gens. Ça n'est "que" de la data…
@jhelou j'ai dû m'intéresser au commit dans ce cas là précisément car la date de création d'une PR était trop imprécise.
Certains devs créent la PR quand la feature est développée. D'autres la créent dès le 1er commit.
A noter qu'il faut aussi tenir compte des rebasages interactifs ou des force pushes
@jhelou quand je prends la casquette Delivery Manager sur un projet, je suis les 4 métriques du mouvement #accelerate et en tout premier lieu, la fréquence de mise en prod.
Je m'attends à ce que l'équipe mette en prod tous les 2 ou 3 jours "en moyenne". J'accepte qu'il y ait des exceptions.
Mais à partir de 2 occurrences au cours de 3 périodes (en général 1 période = 1 sprint de 2 semaines), alors ça *sent* le problème d'équipe.
@jhelou De façon générale, je m'autorise pas mal de flous et *d'imprécisions*. Avec l'expérience, j'ai constaté que l'important est ailleurs.
Pour moi c'est ok que la variance soit proche de la moyenne.
Plutôt que chiffrer (en jours/hommes ou en complexité relative ou en carottes / patates), je préfère mettre l'effort sur faire en sorte que chaque ticket pèse 2-3 jours de dev (dont tests auto) max.
Là aussi, c'est ok si des tickets semblent gros. Au pire, on redécoupe en faisant.
Jérémy
Jean Helou ⌨️