« Mesurer et grandir (SAFe) » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
|||
| (7 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 168 : | Ligne 169 : | ||
[[Fichier:DevOps Health Radar.png|border|link=|500px|center]]<br/> | [[Fichier:DevOps Health Radar.png|border|link=|500px|center]]<br/> | ||
<div style="text-align: center;">'''Figure 14. Le radar de santé SAFe DevOps.'''</div><br/> | <div style="text-align: center;">'''Figure 14. Le radar de santé SAFe DevOps.'''</div><br/> | ||
<br/> | |||
Téléchargez l'évaluation gratuite DevOps Health Radar [https://scaledagileframework.com/wp-content/uploads/2023/07/SAIDevOpsHealthRadarAssessment-v4.xlsx ici]. AgilityHealth propose également une [https://agilityhealthradar.com/safe-devops-assessment version en ligne de cette évaluation].<br/> | |||
===Quatre facteurs critiques de succès pour une mesure efficace=== | |||
La mesure de la performance organisationnelle est l'un des domaines les plus sensibles de toute entreprise, souvent soumis à la politique et à divers dysfonctionnements. En outre, comme la mesure implique inévitablement l'interprétation des données, elle est sujette à des biais cognitifs, à des problèmes de communication et à des défauts d'alignement. Tout cela conduit à un danger substantiel dans tout système de mesure : si elles ne sont pas correctement mises en œuvre, certaines mesures peuvent faire plus de mal que de bien. Les facteurs de succès suivants aideront à guider l'entreprise vers des mesures plus efficaces et, plus important encore, vers de meilleurs résultats métiers.<br/> | |||
====Utiliser les mesures en conjonction avec d'autres outils de découverte==== | |||
Aussi bien conçu soit-il, tout système de mesure ne fournit qu'une image partielle de la réalité, et l'ajout de nouveaux indicateurs n'améliore pas nécessairement la visibilité. Derrière chaque chiffre se cache une histoire, et cette histoire contient souvent des informations plus importantes que le chiffre lui-même ne peut transmettre. L'observation directe (Gemba), c'est-à-dire l'observation de l'environnement réel où la valeur est créée et où elle parvient au client, est un outil puissant à utiliser en conjonction avec les mesures. Les mesures formelles et les observations informelles se renforcent mutuellement. Mais si elles sont utilisées isolément, la "gestion par les chiffres" peut conduire à des résultats médiocres et à un moral encore plus bas. | |||
====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. | |||
====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== | ||
