Répartition du temps de cycle (Axe Technique)

Le graphique Répartition du temps de cycle vise à mesurer l’intervalle de temps entre le premier commit sur la branche (programmation) et la fusion pour déploiement. Vous pouvez afficher ces données par jour, semaine, mois, ou par sprint, selon votre préférence. À titre informatif, si un tableau de type kanban a été lié à votre projet Axify, l'option "sprint" ne sera pas disponible dans les filtres situés au haut de la page. De plus, les périodes "6 derniers mois" et "dernière année" ne permettent pas l'affichage par jour.

Psst ! Attention à ne pas confondre ce graphique avec celui du même nom disponible dans l’Axe Processus, puisqu’ils n’utilisent pas les mêmes données (différentes sources pour les deux Axes). De plus, si vous souhaitez obtenir plus de visibilité sur la portion déploiement du cycle, tant en termes de temps que de nombre de déploiements, nous vous invitons à configurer un webhook et à consulter les métriques DORA.

Lecture du graphique

Pour le graphique suivant, la période affichée correspond aux 3 derniers mois et le mode d'affichage est par semaine. Nous pouvons voir que le temps de cycle moyen d'une PR est de 20 heures pour cette équipe. Nous pouvons également consulter la répartition du temps selon les 3 phases traversées.

• La phase de programmation, c'est-à-dire le temps passé entre le premier commit et l'ouverture de la revue de code.
• La prise en charge, soit le temps passé entre l’ouverture de la revue de code et la première interaction reçue (ex. : commentaire, réaction, approbation).
• Et la revue, donc le temps passé entre la première interaction reçue (ex. : commentaire, réaction, approbation) et l’intégration d’une revue de code.

L'objectif ici est d'identifier les bloquants dans votre flow de livraison au niveau des PRs. En portant attention à divers éléments, dont le temps passé à chaque étape du cycle, la taille des revues de code ou encore le travail en cours, l'équipe sera en mesure d'adresser les bloquants potentiels et réduire son temps de cycle.

Pour cette équipe, nous pouvons constater une amélioration du temps de cycle, tant de façon globale que pour chaque phase, grâce aux indicateurs de variation. Ces derniers, en vert pour notre exemple, comparent le temps moyen (pour le temps de cycle entier ainsi que chaque étape) de la période courante à celui de la période précédente. Pour en savoir plus sur les indicateurs de variation, référez-vous à cet article!

Calcul de la métrique

Dans l'ensemble, nous considérons le premier commit comme étant le début du temps de cycle de chaque PR, alors que le moment où la PR est fusionnée marque la fin du temps de cycle. L'indicateur visible au coin supérieur droit du graphique (20 heures pour notre exemple) se veut une moyenne du temps de cycle de chaque PR fusionnée pour la période sélectionnée.

Le même calcul est ensuite appliqué à chaque phase, selon la logique présentée dans la section Lecture du graphique ci-dessus.

Particularités de chaque phase.

• Programmation : Dans le cas où l’ouverture de la revue de code survient avant le 1er commit, la phase de programmation sera considérée à 0. 
  
  • Dans le cas de GitLab, le temps passé entre la mise à draft d’une pull request et le moment où elle est mise à ready est accumulé dans la phase de « programmation ». Si une pull request est mise à draft sans jamais être mise à ready, l’entièreté du cycle de vie de la pull request jusqu’à son intégration sera considéré comme de la « programmation ».
    
    
• Prise en charge : Cette phase s’amorce lors de la première révision, y compris provenant de l’auteur de la merge request. En l’absence de révision, la date de fusion de la pull request est utilisée pour marquer la fin de cette phase. Cette phase permet d’identifier les goulots d’étranglement dans le flot de travail tels que des revues de code inactives ou bloquées.
  • Dans le cas de GitLab, une révision prend la forme d’une interaction effectuée sur la revue de code telle qu’un commentaire, une approbation ou bien des emojis. Dans le cas de GitHub, cette révision prend la forme de la première revue faite sur la revue de code.

    • La première révision considérée doit être survenue lors de l’état ready de la pull request en question.

    • Tout le temps en draft de la pull request n’est pas considéré dans la phase de pick up.
      
      

• Revue : Dans le cas où il n’y a pas de révision effectuée sur la revue de code, cette phase aura un temps de cycle de 0.
  
  • Dans le cas de GitLab, le début de la phase revue correspond à l’ajout d’une révision sur une pull request à l’état ready. Si la première révision survient lorsque la pull request est en draft, cette dernière ne sera pas considérée comme le début de la phase revue. Tout le temps en draft de la pull request n’est pas considéré dans la phase de revue.