« Quatre Indicateurs Clés Accelerate » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| Ligne 18 : | Ligne 18 : | ||
* Lean Management et Monitoring | * Lean Management et Monitoring | ||
* Culture | * Culture | ||
'''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''' | ||
| Ligne 24 : | Ligne 24 : | ||
* '''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''' | ||
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 mesures sont puissantes et utiles, que vous fonctionniez en mode Agile ou Cycle en V, que vos environnements de travail soient dans le cloud public ou sur du matériel dédié dans un datacenter, et que votre temps d'exécution soit un mainframe monolithique ou des microservices conteneurisés. Ils ne dépendent d'aucune technologie et sont tout aussi utiles pour une petite équipe technique dans une startup que pour de multiples équipes orientées flux de valeur dans de grandes entreprises complexes.<br/> | |||
<br/> | |||
Les données de l'étude Accelerate montrent que les organisations technologiques les plus performantes ont les capacités suivantes : | |||
* Déploiements de logiciels très fréquents | |||
* Lead times courts entre l'engagement et le déploiement | |||
* Délais courts de reprise après un temps d'arrêt | |||
* Taux d'échec des changements plus faible | |||
==Pourquoi les utiliser?== | |||
Que votre organisation soit fortement axée sur la fiabilité et la stabilité, ou sur les itérations rapides de produits et la rapidité de mise sur le marché de nouvelles fonctionnalités, toutes ces mesures sont importantes.<br/> | |||
<br/> | |||
Il s'agit d'indicateurs basés sur les résultats, et non sur les entrées ou les sorties. En d'autres termes, elles mesurent ce qui "se passe", et non ce que quelqu'un a fait (heures de travail, par exemple) ou ce qu'il a produit (lignes de code écrites, par exemple). Les mesures de résultats décrivent un état souhaité du monde, par exemple "haute fiabilité" (mesurée par le MTTR) ou "livraison rapide de la valeur" (mesurée par le lead time du changement).<br/> | |||
<br/> | |||
Ces mesures reflètent les résultats souhaités qui sont communément partagés par toutes les équipes d'une organisation. L'un des dangers des mesures est qu'elles peuvent inciter les équipes à se faire concurrence ; si les équipes ont des mesures différentes, il peut en résulter une relation conflictuelle où le succès d'une équipe nuit à l'autre. Les équipes de développement et d'exploitation cloisonnées en sont un exemple : les développeurs proposent autant de fonctionnalités que possible (parce que leur mesure est la livraison de nouvelles fonctionnalités), sans se soucier de la maintenabilité (parce que c'est la mesure de l'équipe d'exploitation, pas la leur), et l'équipe d'exploitation s'efforce d'assurer le fonctionnement fiable des services sous l'assaut de nouvelles modifications et d'un code difficile à maintenir.<br/> | |||
<br/> | |||
Lorsque ces quatre indicateurs sont en tension les uns avec les autres, ils sont de puissants moteurs de performance. Les équipes ne peuvent pas jouer consciemment ou inconsciemment avec leurs indicateurs en augmentant l'un d'entre eux alors que l'autre en pâtit. Les équipes doivent être en mesure de s'optimiser elles-mêmes, mais une trop grande importance accordée à l'optimisation localisée peut déboucher sur une organisation peu performante où les performances d'une équipe font souffrir une autre équipe.<br/> | |||
<br/> | |||
Il est essentiel de les combiner. L'utilisation isolée d'un seul indicateur n'apporte aucun avantage et peut même être préjudiciable. Par exemple, mesurer le taux de changement sans mesurer le taux d'échec des changements pourrait entraîner des changements très fréquents et de mauvaise qualité qui auraient un impact sur les niveaux de service et l'expérience des clients. Mesurer uniquement le temps moyen entre les défaillances sans mesurer le temps moyen de rétablissement pourrait entraîner des temps d'arrêt peu fréquents mais à fort impact en encourageant des stratégies de déploiement "big bang".<br/> | |||
<br/> | |||
Penchons-nous sur chaque indicateur, sur sa signification et sur la manière dont les équipes peuvent l'améliorer :<br/> | |||
<br/> | |||
