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 le déploiement. Ainsi, l’indicateur associé à cette métrique (coin supérieur droit) reflète le temps de cycle total moyen sur l’ensemble de la durée considérée.

Essentiellement, les revues de codes traversent quatre phases :

• Programmation
• Prise en charge
• Revue

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).

Exemple d’utilisation

Le graphique suivant illustre la répartition du temps de cycle pour la période sélectionnée, soit les trois derniers mois, et affiche les données par sprint. Selon votre préférence, vous pouvez également afficher les données par jour ou par mois.

De plus, l’indicateur associé à chaque étape du temps de cycle indiquera le pourcentage d’augmentation (flèche rouge) ou de diminution (flèche verte) quant au temps accordé à cette étape.

• La phase de programmation reflète le temps passé entre le premier commit et l’ouverture de la revue de code. 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 ».
    
    
• La phase de prise en charge représente le temps passé entre l’ouverture de la revue de code et la première interaction reçue (ex. : commentaire, réaction, approbation). 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.
      
      

• La phase de revue représente le temps passé entre la première interaction reçue (ex. : commentaire, réaction, approbation) et l’intégration d’une revue de code. 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.

Vous désirez ajouter le temps de déploiement à vos observations? Consultez plutôt le graphique Délai de changement.

Pour en savoir plus sur les indicateurs de variation, référez-vous à cet article!