Quatre Indicateurs Clés Accelerate - Historique des versions

Fabrice Aimetti le 9 mars 2024 à 09:40

Fabrice Aimetti — Sat, 09 Mar 2024 09:40:48 GMT

← Version précédente		Version du 9 mars 2024 à 09:40
Ligne 1 :		Ligne 1 :
	[[Category: Accelerate]]		[[Category: Accelerate]]
			[[Category: Pair Programming]]
	Auteure : Tom Geraghty<br />		Auteure : Tom Geraghty<br />
	Source : [https://openpracticelibrary.com/blog/accelerate-metrics-software-delivery-performance-measurement/ Accelerate Metrics - Software Delivery Performance Measurement]<br />		Source : [https://openpracticelibrary.com/blog/accelerate-metrics-software-delivery-performance-measurement/ Accelerate Metrics - Software Delivery Performance Measurement]<br />

Fabrice Aimetti : /* Que sont les indicateurs d'Accelerate ? */

Fabrice Aimetti — Mon, 04 Mar 2024 09:05:19 GMT

Que sont les indicateurs d'Accelerate ?

← Version précédente		Version du 4 mars 2024 à 09:05
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''' ~~(LTC)~~		* '''Lead time de mise en œuvre du changement (LTC)'''
	* '''Fréquence de déploiement''' ~~(DF)~~		* '''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''' ~~(CFR)~~		* '''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é.

Fabrice Aimetti le 4 mars 2024 à 09:04

Fabrice Aimetti — Mon, 04 Mar 2024 09:04:42 GMT

Fabrice Aimetti le 13 octobre 2023 à 15:15

Fabrice Aimetti — Fri, 13 Oct 2023 15:15:04 GMT

← Version précédente		Version du 13 octobre 2023 à 15:15
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 : 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/>

Fabrice Aimetti : /* Informations complémentaires et liens */

Fabrice Aimetti — Fri, 13 Oct 2023 12:48:25 GMT

Informations complémentaires et liens

← Version précédente		Version du 13 octobre 2023 à 12:48
Ligne 93 :		Ligne 93 :
	* 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		* Résumé du rapport The State of DevOps 2020 : https://tomgeraghty.co.uk/index.php/the-state-of-devops-report-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

Fabrice Aimetti : /* Utiliser les quatre indicateurs en même temps */

Fabrice Aimetti — Fri, 13 Oct 2023 12:48:12 GMT

Utiliser les quatre indicateurs en même temps

← Version précédente		Version du 13 octobre 2023 à 12:48
Ligne 88 :		Ligne 88 :
	==Utiliser les quatre indicateurs en même temps==		==Utiliser les quatre indicateurs en même temps==
	Dans l'ensemble, ces mesures reflètent la compétence DevOps d'une équipe au fil du temps. Il est important de se rappeler que les mesures peuvent aller dans le sens contraire de ce que vous souhaitez, mais en utilisant des boucles de feedback efficaces, un bon leadership et de bonnes pratiques de management, une équipe peut être en mesure d'améliorer ces quatre mesures et d'atteindre une haute performance.		Dans l'ensemble, ces mesures reflètent la compétence DevOps d'une équipe au fil du temps. Il est important de se rappeler que les mesures peuvent aller dans le sens contraire de ce que vous souhaitez, mais en utilisant des boucles de feedback efficaces, un bon leadership et de bonnes pratiques de management, une équipe peut être en mesure d'améliorer ces quatre mesures et d'atteindre une haute performance.

			==Informations complémentaires et liens==
			* 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/
			* 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/
			* Holistics.io : https://www.holistics.io/blog/accelerate-measure-software-development/
			* Loi de Goodhart : https://towardsdatascience.com/unintended-consequences-and-goodharts-law-68d60a94705c
			* Théorie des jeux : https://plato.stanford.edu/entries/game-theory/
			* Pelorus : https://github.com/konveyor/pelorus
			* Canary releases : https://martinfowler.com/bliki/CanaryRelease.html
			* 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
			* CI/CD : https://www.redhat.com/en/topics/devops/what-cicd-pipeline

Fabrice Aimetti : /* Indicateur : Taux d'échec des changements (CFR) */

Fabrice Aimetti — Fri, 13 Oct 2023 12:44:23 GMT

Indicateur : Taux d'échec des changements (CFR)

← Version précédente		Version du 13 octobre 2023 à 12:44
Ligne 85 :		Ligne 85 :
	<br/>		<br/>
	Remarque : il n'est peut-être pas souhaitable de chercher à réduire le CFR à zéro. Étant donné que tous les déploiements comportent un degré de risque non nul, un CFR nul sur une longue période peut indiquer que l'équipe pourrait améliorer d'autres indicateurs en augmentant la tolérance au risque des déploiements. Bien entendu, cela dépendra de la tolérance au risque de l'entreprise et du fait qu'elle se concentre sur la fiabilité et la sécurité ou sur la rapidité de mise sur le marché.		Remarque : il n'est peut-être pas souhaitable de chercher à réduire le CFR à zéro. Étant donné que tous les déploiements comportent un degré de risque non nul, un CFR nul sur une longue période peut indiquer que l'équipe pourrait améliorer d'autres indicateurs en augmentant la tolérance au risque des déploiements. Bien entendu, cela dépendra de la tolérance au risque de l'entreprise et du fait qu'elle se concentre sur la fiabilité et la sécurité ou sur la rapidité de mise sur le marché.

			==Utiliser les quatre indicateurs en même temps==
			Dans l'ensemble, ces mesures reflètent la compétence DevOps d'une équipe au fil du temps. Il est important de se rappeler que les mesures peuvent aller dans le sens contraire de ce que vous souhaitez, mais en utilisant des boucles de feedback efficaces, un bon leadership et de bonnes pratiques de management, une équipe peut être en mesure d'améliorer ces quatre mesures et d'atteindre une haute performance.

Fabrice Aimetti : /* Indicateur : Taux d'échec des changements (CFR) */

Fabrice Aimetti — Fri, 13 Oct 2023 12:43:22 GMT

Indicateur : Taux d'échec des changements (CFR)

← Version précédente		Version du 13 octobre 2023 à 12:43
Ligne 83 :		Ligne 83 :
	<br/>		<br/>
	Pour mesurer cela, nous devons connaître le volume de déploiements et le volume d'incidents. Nous devrions également être en mesure d'établir un lien et de démontrer la causalité entre le déploiement et l'incident, qui peut n'être évident que quelque temps après le fait, et peut se produire des semaines ou des mois après le changement initial.<br/>		Pour mesurer cela, nous devons connaître le volume de déploiements et le volume d'incidents. Nous devrions également être en mesure d'établir un lien et de démontrer la causalité entre le déploiement et l'incident, qui peut n'être évident que quelque temps après le fait, et peut se produire des semaines ou des mois après le changement initial.<br/>
			<br/>
			Remarque : il n'est peut-être pas souhaitable de chercher à réduire le CFR à zéro. Étant donné que tous les déploiements comportent un degré de risque non nul, un CFR nul sur une longue période peut indiquer que l'équipe pourrait améliorer d'autres indicateurs en augmentant la tolérance au risque des déploiements. Bien entendu, cela dépendra de la tolérance au risque de l'entreprise et du fait qu'elle se concentre sur la fiabilité et la sécurité ou sur la rapidité de mise sur le marché.

Fabrice Aimetti : /* Indicateur : Temps moyen de rétablissement (MTTR) = */

Fabrice Aimetti — Fri, 13 Oct 2023 12:42:35 GMT

Indicateur : Temps moyen de rétablissement (MTTR) =

← Version précédente		Version du 13 octobre 2023 à 12:42
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 : Temps moyen de rétablissement (MTTR)==
	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 74 :		Ligne 74 :
	<br/>		<br/>
	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)==
			Répond à : "À quelle fréquence nos déploiements entraînent-ils une défaillance en production ?"<br/>
			<br/>
			Différentes estimations ont été faites pour montrer combien de changements dans la production entraînent des défaillances du système, et elles vont de 5% à plus de 50%. Les défaillances résultant des changements ont un impact sur l'expérience du client et obligent l'équipe à passer de la livraison de la valeur planifiée à un travail de lutte contre les incendies non planifié. Le travail non planifié a toujours la priorité sur le travail planifié.<br/>
			<br/>
			Les risques de défaillance augmentent avec les systèmes complexes et de grande envergure dont les composants sont étroitement liés. De même, si les processus de développement n'incluent pas de tests unitaires ou d'intégration appropriés ni d'analyse statique du code, et si les pratiques de l'équipe de développement n'incluent pas le pair programming ou la peer review, les risques d'échec sont plus élevés. Pour réduire le taux d'échec des modifications, il faut renforcer la capacité à intégrer la qualité plus tôt dans le cycle de développement des logiciels.<br/>
			<br/>
			Pour mesurer cela, nous devons connaître le volume de déploiements et le volume d'incidents. Nous devrions également être en mesure d'établir un lien et de démontrer la causalité entre le déploiement et l'incident, qui peut n'être évident que quelque temps après le fait, et peut se produire des semaines ou des mois après le changement initial.<br/>

Fabrice Aimetti le 13 octobre 2023 à 12:39

Fabrice Aimetti — Fri, 13 Oct 2023 12:39:00 GMT

← Version précédente		Version du 13 octobre 2023 à 12:39
Ligne 65 :		Ligne 65 :
	<br/>		<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/>		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) ===
			Répond à : "Combien de temps nous faut-il pour rétablir la situation après une panne en production ?<br/>
			<br/>
			Les pannes sont inévitables. Qu'il s'agisse des conséquences imprévues des changements, qui peuvent entraîner une défaillance partielle ou totale des services, de problèmes de capacité, de menaces malveillantes ou accidentelles, de certificats arrivant à expiration ou, comme d'habitude, de pannes DNS, pannes de système font partie de la vie quotidienne.<br/>
			<br/>
			Plus les changements peuvent être annulés rapidement, ou les systèmes adaptés manuellement ou automatiquement pour restaurer les services, plus les performances de l'équipe sont élevées et plus l'expérience client et la valeur fournie sont bonnes. Pour améliorer le temps moyen de restauration, il faut réduire la taille des lots de changements, construire et utiliser des systèmes plus résilients et distribués, permettre des défaillances graduelles des composants grâce à un découplage et à une mise en file d'attente appropriés, ainsi qu'à une surveillance et à des alertes efficaces.<br/>
			<br/>
			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é.

← Version précédente		Version du 4 mars 2024 à 09:04
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

Quatre Indicateurs Clés Accelerate - Historique des versions

Fabrice Aimetti le 9 mars 2024 à 09:40

Fabrice Aimetti : /* Que sont les indicateurs d'Accelerate ? */

Fabrice Aimetti le 4 mars 2024 à 09:04

Fabrice Aimetti le 13 octobre 2023 à 15:15

Fabrice Aimetti : /* Informations complémentaires et liens */

Fabrice Aimetti : /* Utiliser les quatre indicateurs en même temps */

Fabrice Aimetti : /* Indicateur : Taux d'échec des changements (CFR) */

Fabrice Aimetti : /* Indicateur : Taux d'échec des changements (CFR) */

Fabrice Aimetti : /* Indicateur : Temps moyen de rétablissement (MTTR) = */

Fabrice Aimetti le 13 octobre 2023 à 12:39

Fabrice Aimetti : /* Que sont les indicateurs d'Accelerate ? */

Fabrice Aimetti : /* Informations complémentaires et liens */

Fabrice Aimetti : /* Utiliser les quatre indicateurs en même temps */

Fabrice Aimetti : /* Indicateur : Taux d'échec des changements (CFR) */

Fabrice Aimetti : /* Indicateur : Taux d'échec des changements (CFR) */

Fabrice Aimetti : /* Indicateur : Temps moyen de rétablissement (MTTR) = */