« Quatre Indicateurs Clés Accelerate » : différence entre les versions

De Wiki Agile
Aucun résumé des modifications
Aucun résumé des modifications
Ligne 20 : Ligne 20 :


'''Les quatre indicateurs Accelerate sont les suivants :'''
'''Les quatre indicateurs Accelerate sont les suivants :'''
* '''Lead time de mise en œuvre du changement'''
* '''Lead time de mise en œuvre du changement''' (LTC)
* '''Fréquence de déploiement'''
* '''Fréquence de déploiement''' (DF)
* '''Temps moyen de rétablissement (Mean Time To Restore ~ MTTR)'''
* '''Temps moyen de rétablissement (Mean Time To Restore ~ MTTR)'''
* '''Taux d'échec des changements'''
* '''Taux d'échec des changements''' (CFR)


Les deux premiers s'orientent vers l'objectif classique du développement, qui est d'apporter des changements, tandis que les deux autres s'orientent vers l'objectif classique de l'exploitation, qui est d'assurer la stabilité.
Les deux premiers s'orientent vers l'objectif classique du développement, qui est d'apporter des changements, tandis que les deux autres s'orientent vers l'objectif classique de l'exploitation, qui est d'assurer la stabilité.
Ligne 48 : Ligne 48 :
Penchons-nous sur chaque indicateur, sur sa signification et sur la manière dont les équipes peuvent l'améliorer :<br/>
Penchons-nous sur chaque indicateur, sur sa signification et sur la manière dont les équipes peuvent l'améliorer :<br/>


==Indicateur : Lead time de mise en œuvre du changement==
==Indicateur LTC : Lead time de mise en œuvre du changement==
Répond à : "Combien de temps faut-il pour qu'un commit soit exécuté en production ?"<br/>
Répond à : "Combien de temps faut-il pour qu'un commit soit exécuté en production ?"<br/>
<br/>
<br/>
Ligne 57 : Ligne 57 :
Remarque : certaines équipes peuvent mesurer le cycle time total au lieu du délai entre le commit et le déploiement, mais le cycle time total (à partir du moment où une exigence est identifiée et où le travail est commencé) peut dépendre de facteurs confus échappant au contrôle de l'équipe et n'est donc pas un indicateur aussi fiable.<br/>
Remarque : certaines équipes peuvent mesurer le cycle time total au lieu du délai entre le commit et le déploiement, mais le cycle time total (à partir du moment où une exigence est identifiée et où le travail est commencé) peut dépendre de facteurs confus échappant au contrôle de l'équipe et n'est donc pas un indicateur aussi fiable.<br/>


==Indicateur : Fréquence de déploiement==
==Indicateur DF : Fréquence de déploiement==
Répond à : "Quelle est la fréquence de déploiement en production ?<br/>
Répond à : "Quelle est la fréquence de déploiement en production ?<br/>
<br/>
<br/>
Ligne 66 : Ligne 66 :
C'est l'un des indicateurs les plus faciles à mesurer, car les déploiements sont généralement bien enregistrés, quels que soient les méthodes ou les systèmes utilisés. Veillez toutefois à définir un déploiement de manière appropriée : dans votre contexte, une modification d'une seule ligne de code est-elle considérée comme un déploiement ? Une modification de plusieurs lignes de code est-elle prise en compte si elle concerne un système qui reçoit très peu de trafic ?<br/>
C'est l'un des indicateurs les plus faciles à mesurer, car les déploiements sont généralement bien enregistrés, quels que soient les méthodes ou les systèmes utilisés. Veillez toutefois à définir un déploiement de manière appropriée : dans votre contexte, une modification d'une seule ligne de code est-elle considérée comme un déploiement ? Une modification de plusieurs lignes de code est-elle prise en compte si elle concerne un système qui reçoit très peu de trafic ?<br/>


==Indicateur : Temps moyen de rétablissement (MTTR)==
==Indicateur MTTR : Temps moyen de rétablissement==
Répond à : "Combien de temps nous faut-il pour rétablir la situation après une panne en production ?<br/>
Répond à : "Combien de temps nous faut-il pour rétablir la situation après une panne en production ?<br/>
<br/>
<br/>
Ligne 75 : Ligne 75 :
En termes de mesure, vous devez savoir quand l'incident s'est produit (et pas seulement quand il a été observé ou enregistré pour la première fois) et quand il a été résolu. Veillez à définir ce que signifie "résolu" : "résolu" peut-il signifier que le système fonctionne dans un état dégradé mais qu'il est disponible, ou existe-t-il un état optimal "souhaité" du système ? Dans ce dernier cas, vous aurez probablement besoin d'indicateurs de niveau de service (SLI) pour vous assurer que tout le monde est d'accord sur l'état souhaité.
En termes de mesure, vous devez savoir quand l'incident s'est produit (et pas seulement quand il a été observé ou enregistré pour la première fois) et quand il a été résolu. Veillez à définir ce que signifie "résolu" : "résolu" peut-il signifier que le système fonctionne dans un état dégradé mais qu'il est disponible, ou existe-t-il un état optimal "souhaité" du système ? Dans ce dernier cas, vous aurez probablement besoin d'indicateurs de niveau de service (SLI) pour vous assurer que tout le monde est d'accord sur l'état souhaité.


==Indicateur : Taux d'échec des changements (CFR)==
==Indicateur CFR : Taux d'échec des changements==
Répond à : "À quelle fréquence nos déploiements entraînent-ils une défaillance en production ?"<br/>
Répond à : "À quelle fréquence nos déploiements entraînent-ils une défaillance en production ?"<br/>
<br/>
<br/>
Ligne 90 : Ligne 90 :


==Informations complémentaires et liens==
==Informations complémentaires et liens==
* Accelerate, par Nicole Forsgren, Jez Humble et Gene Kim : https://itrevolution.com/book/accelerate/
* ''Accelerate'', par Nicole Forsgren, Jez Humble et Gene Kim : https://itrevolution.com/book/accelerate/
* Measure Software Delivery Performance With Four Key Metrics : https://itrevolution.com/measure-software-delivery-performance-four-key-metrics/
* ''Measure Software Delivery Performance With Four Key Metrics'' : https://itrevolution.com/measure-software-delivery-performance-four-key-metrics/
* Rapport The State of DevOps 2019 : https://services.google.com/fh/files/misc/state-of-devops-2019.pdf
* ''Rapport The State of DevOps 2019'' : https://services.google.com/fh/files/misc/state-of-devops-2019.pdf
* Résumé du rapport The State of DevOps 2020 : https://tomgeraghty.co.uk/index.php/the-state-of-devops-report-2020/
* ''Résumé du rapport The State of DevOps 2020'' : https://tomgeraghty.co.uk/index.php/the-state-of-devops-report-2020/
* Holistics.io : https://www.holistics.io/blog/accelerate-measure-software-development/
* ''Holistics.io'' : https://www.holistics.io/blog/accelerate-measure-software-development/
* Loi de Goodhart : https://towardsdatascience.com/unintended-consequences-and-goodharts-law-68d60a94705c
* ''Loi de Goodhart'' : https://towardsdatascience.com/unintended-consequences-and-goodharts-law-68d60a94705c
* Théorie des jeux : https://plato.stanford.edu/entries/game-theory/
* ''Théorie des jeux'' : https://plato.stanford.edu/entries/game-theory/
* Pelorus : https://github.com/konveyor/pelorus
* ''Pelorus'' : https://github.com/konveyor/pelorus
* Canary releases : https://martinfowler.com/bliki/CanaryRelease.html
* ''Canary releases'' : https://martinfowler.com/bliki/CanaryRelease.html
* Feature Flags : https://launchdarkly.com/blog/what-are-feature-flags/
* ''Feature Flags'' : https://launchdarkly.com/blog/what-are-feature-flags/
* Travailler par petits lots : https://cloud.google.com/architecture/devops/devops-process-working-in-small-batches
* ''Travailler par petits lots'' : https://cloud.google.com/architecture/devops/devops-process-working-in-small-batches
* CI/CD : https://www.redhat.com/en/topics/devops/what-cicd-pipeline
* ''CI/CD'' : https://www.redhat.com/en/topics/devops/what-cicd-pipeline