#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.
@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 ⌨️