« Mesurer et grandir (SAFe) » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
|||
| (4 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 2 : | Ligne 2 : | ||
[[Catégorie:Portail Exactimation]] | [[Catégorie:Portail Exactimation]] | ||
[[Catégorie:Portail Planification]] | [[Catégorie:Portail Planification]] | ||
[[Category: Accelerate]] | |||
[[Category: SAFe]] | [[Category: SAFe]] | ||
Auteur : © 2010-2023 Scaled Agile, Inc.<br /> | Auteur : © 2010-2023 Scaled Agile, Inc.<br /> | ||
| Ligne 14 : | Ligne 15 : | ||
[[Fichier:Measure and Grow 6.0 nav icon.png|left|border|link=https://www.scaledagileframework.com/]] ''Ce qui est formidable avec les décisions basées sur des faits, c'est qu'elles outrepassent la hiérarchie.''<br/> | [[Fichier:Measure and Grow 6.0 nav icon.png|left|border|link=https://www.scaledagileframework.com/]] ''Ce qui est formidable avec les décisions basées sur des faits, c'est qu'elles outrepassent la hiérarchie.''<br/> | ||
<br/> | <br/> | ||
- Jeff Bezos, fondateur d'Amazon''<br/> | - Jeff Bezos, fondateur d'Amazon [1]''<br/> | ||
<br/> | <br/> | ||
__TOC__ | __TOC__ | ||
| Ligne 30 : | Ligne 31 : | ||
* '''Résultats''' : Nos solutions répondent-elles aux besoins de nos clients et de l'entreprise ? | * '''Résultats''' : Nos solutions répondent-elles aux besoins de nos clients et de l'entreprise ? | ||
* '''Flux''' : Quelle est l'efficacité de l'organisation à fournir de la valeur au client ? | * '''Flux''' : Quelle est l'efficacité de l'organisation à fournir de la valeur au client ? | ||
* '''Compétence''' : | * '''Compétence''' : Dans quelle mesure l'organisation maîtrise-t-elle les pratiques qui favorisent l'agilité métier ? | ||
En outre, ces trois domaines de mesure sont applicables à tous les niveaux d'une organisation. Comme l'illustre la figure 2, ils peuvent être utilisés pour mesurer la performance d'un portefeuille SAFe, d'un Solution Train, d'un Agile Release Train , ou même d'une simple Équipe Agile. | En outre, ces trois domaines de mesure sont applicables à tous les niveaux d'une organisation. Comme l'illustre la figure 2, ils peuvent être utilisés pour mesurer la performance d'un portefeuille SAFe, d'un Solution Train, d'un Agile Release Train , ou même d'une simple Équipe Agile. | ||
[[Fichier:Measure and Grow F02 WEB-1.png|border|center|link=|1000px]]<br/> | [[Fichier:Measure and Grow F02 WEB-1.png|border|center|link=|1000px]]<br/> | ||
| Ligne 131 : | Ligne 132 : | ||
<div style="text-align: center;">'''Figure 11. Mesure de prédictibilité de l'ART.'''</div> | <div style="text-align: center;">'''Figure 11. Mesure de prédictibilité de l'ART.'''</div> | ||
Note sur les indicateurs DORA : | Note sur les indicateurs DORA : dans et entre les trois domaines de mesure, il peut souvent être utile de rassembler des mesures complémentaires pour fournir une vue spécifique de la performance. Les mesures DORA utilisées pour mesurer la performance des capacités DevOps d'une organisation en sont un exemple [4]. Les quatre mesures DORA sont 1) la fréquence de déploiement, 2) le lead time des changes, 3) le délai de rétablissement du service et 4) le change failure rate (taux d'échec des changements). | ||
Chacune de ces mesures est une application d'une mesure de flux conçue pour un cas d'utilisation particulier. La fréquence de déploiement est une mesure de productivité et un exemple de vélocité du flux. Au lieu de mesurer le nombre de stories terminées par itération, elle mesure le nombre de déploiements sur une période donnée. Le lead time des changes et le délai de rétablissement du service sont des exemples de mesures de temps de flux, qui se concentrent sur des étapes spécifiques du flux de travail. Enfin, le change failure rate représente le pourcentage de changements qui nécessitent une correction après leur mise en production. En d'autres termes, à quelle fréquence le travail qui arrive à l'étape "déploiement en production" du flux de travail contient-il des erreurs ? Lors de la création de la value stream map pour mesurer l'efficience du flux, cet aspect est pris en compte dans le pourcentage de travail complete et accurate (%C&A) pour chaque étape, c'est-à-dire le pourcentage de travail que l'étape suivante peut traiter sans nécessiter de rework. Des taux élevés d'échec de change failure contribuent de manière significative à une faible efficience du flux. | Chacune de ces mesures est une application d'une mesure de flux conçue pour un cas d'utilisation particulier. La fréquence de déploiement est une mesure de productivité et un exemple de vélocité du flux. Au lieu de mesurer le nombre de stories terminées par itération, elle mesure le nombre de déploiements sur une période donnée. Le lead time des changes et le délai de rétablissement du service sont des exemples de mesures de temps de flux, qui se concentrent sur des étapes spécifiques du flux de travail. Enfin, le change failure rate représente le pourcentage de changements qui nécessitent une correction après leur mise en production. En d'autres termes, à quelle fréquence le travail qui arrive à l'étape "déploiement en production" du flux de travail contient-il des erreurs ? Lors de la création de la value stream map pour mesurer l'efficience du flux, cet aspect est pris en compte dans le pourcentage de travail complete et accurate (%C&A) pour chaque étape, c'est-à-dire le pourcentage de travail que l'étape suivante peut traiter sans nécessiter de rework. Des taux élevés d'échec de change failure contribuent de manière significative à une faible efficience du flux. | ||
| Ligne 179 : | Ligne 180 : | ||
====Appliquer les mesures lorsqu'elles permettent d'améliorer la prise de décision==== | ====Appliquer les mesures lorsqu'elles permettent d'améliorer la prise de décision==== | ||
Un piège courant lors de la mise en œuvre d'indicateurs est de trop mesurer par peur de ne pas mesurer assez. Bien que de nombreuses mesures puissent être automatisées, plus leur nombre et leur fréquence augmentent, plus les efforts nécessaires à la collecte et à l'analyse des données s'accroissent. Lorsque vous envisagez d'inclure une mesure supplémentaire dans votre système de mesure, il peut être prudent de vous poser la question suivante : "Quelles décisions cette mesure permettra-t-elle de prendre et qui ne sont pas prises en compte aujourd'hui par nos mesures existantes ? Une autre question à clarifier est la suivante : "Avons-nous besoin de mesurer cela maintenant ? Cette question tient compte du fait que les mesures que nous utilisons évolueront au fil du temps, à mesure que les décisions que nous devons prendre changeront au cours du processus de développement. | Un piège courant lors de la mise en œuvre d'indicateurs est de trop mesurer par peur de ne pas mesurer assez. Bien que de nombreuses mesures puissent être automatisées, plus leur nombre et leur fréquence augmentent, plus les efforts nécessaires à la collecte et à l'analyse des données s'accroissent. Lorsque vous envisagez d'inclure une mesure supplémentaire dans votre système de mesure, il peut être prudent de vous poser la question suivante : "Quelles décisions cette mesure permettra-t-elle de prendre et qui ne sont pas prises en compte aujourd'hui par nos mesures existantes ? Une autre question à clarifier est la suivante : "Avons-nous besoin de mesurer cela maintenant ? Cette question tient compte du fait que les mesures que nous utilisons évolueront au fil du temps, à mesure que les décisions que nous devons prendre changeront au cours du processus de développement. | ||
====Comprendre l'effet des mesures sur les comportements==== | |||
Dans une culture positive, les ingénieurs du savoir sont motivés pour fournir des solutions gagnantes et travailler dans un but précis, avec maîtrise et autonomie. Cependant, lorsque l'on accorde trop d'importance à un indicateur numérique spécifique et que cet indicateur est directement lié à la rémunération ou aux possibilités d'évolution de carrière, la réalisation de ce chiffre devient l'objectif plutôt que la création de solutions efficaces.<br/> | |||
<br/> | |||
En outre, les pressions exercées pour réussir conduisent souvent à une mauvaise utilisation des indicateurs. Par exemple, l'efficience des flux peut être utilisée pour imputer la responsabilité d'une date de livraison manquée à un ART particulier qui est devenu un goulot d'étranglement, au lieu d'utiliser cette information pour identifier les problèmes systémiques qui doivent être résolus. La cause profonde est peut-être un manque de ressources ou un changement de priorités indépendant de la volonté de l'ART.<br/> | |||
<br/> | |||
Dans tous les cas, [https://scaledagileframework.com/safe-core-values/ les valeurs fondamentales de SAFe], à savoir la transparence et l'alignement, doivent fournir les bases d'un système de mesure efficace, tout en créant un environnement où les faits sont toujours accueillis avec bienveillance. | |||
====Interpréter soigneusement les mesures==== | |||
Il ne suffit pas de collecter des mesures spécifiques. S'il est interprété sans être bien compris, un indicateur peut être très trompeur. Par exemple, lorsque l'on mesure le temps de déroulement du flux, les éléments de travail doivent être des fonctionnalités réelles et utiles (stories, etc.) qui apportent des bénéfices à l'entreprise ; sinon, le train peut rapporter des améliorations dans le flux de travail mais peiner à obtenir une valeur réelle à la sortie. | |||
==En savoir plus== | ==En savoir plus== | ||
