« Mesurer et grandir (SAFe) » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
|||
| (24 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
[[Category: Agilité à grande échelle]] | [[Category: Agilité à grande échelle]] | ||
[[Catégorie:Portail Exactimation]] | |||
[[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 12 : | 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 28 : | 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 126 : | Ligne 129 : | ||
'''Pourquoi est-ce important?''' Une prédictibilité faible ou irrégulière rend les engagements de livraison irréalistes et met souvent en évidence des problèmes sous-jacents liés à la technologie, à la planification ou aux performances de l'organisation, qui doivent être résolus. Les trains fiables devraient fonctionner entre 80 et 100 %, ce qui permet à l'entreprise et à ses parties prenantes de planifier efficacement.<br/> | '''Pourquoi est-ce important?''' Une prédictibilité faible ou irrégulière rend les engagements de livraison irréalistes et met souvent en évidence des problèmes sous-jacents liés à la technologie, à la planification ou aux performances de l'organisation, qui doivent être résolus. Les trains fiables devraient fonctionner entre 80 et 100 %, ce qui permet à l'entreprise et à ses parties prenantes de planifier efficacement.<br/> | ||
<br/> | <br/> | ||
[[Fichier:Measure and Grow F11-2.png|border|link=|800px|center]]<br/> | |||
<div style="text-align: center;">'''Figure 11. Mesure de prédictibilité de l'ART.'''</div> | |||
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. | |||
===Mesurer la compétence=== | ===Mesurer la compétence=== | ||
L'agilité métier requiert un niveau d'expertise important dans les [https://scaledagileframework.com/business-agility/ 7 compétences clés de SAFe]. Bien que chaque compétence puisse apporter de la valeur indépendamment, elles sont également interdépendantes dans la mesure où la véritable agilité métier ne peut être atteinte que lorsque l'entreprise atteint un niveau significatif de maîtrise de chacune d'entre elles.<br/> | |||
<br/> | |||
La mesure du niveau de compétence organisationnelle s'effectue au moyen de deux mécanismes d'évaluation distincts, conçus pour des publics et des objectifs différents. L'évaluation de l'agilité métier SAFe est destinée aux parties prenantes de l'entreprise et du portefeuille afin d'évaluer leur progression globale vers l'objectif ultime d'une véritable agilité métier, comme le montre la Figure 12.<br/> | |||
<br/> | |||
[[Fichier:Measure and Grow F11-1.png|border|link=|800px|center]]<br/> | |||
<div style="text-align: center;">'''Figure 12. Une évaluation complète de l'agilité métier.'''</div><br/> | |||
La version tableur de l'évaluation peut être téléchargée [https://salsa.scaledagile.com/wp-content/uploads/Business-Agility-Assessmentv2New_EN.xlsx ici]. | |||
'''Note pour les membres du Studio SAFe''' : Toutes les évaluations SAFe sont disponibles en ligne pour les membres du Studio SAFe par l'intermédiaire de notre partenaire Comparative Agility. Cela permet de collecter des données supplémentaires, de les analyser, de les comparer et de dégager des tendances qui peuvent être utilisées pour améliorer la performance. Vous pouvez y accéder à partir de la page [https://community.scaledagile.com/s/measure-and-grow Measure and Grow SAFe Studio]. | |||
Les évaluations des compétences clés de SAFe aident les équipes et les formations à améliorer les pratiques techniques et métiers dont elles ont besoin pour contribuer à l'atteinte de l'objectif global du portefeuille. Il en existe une pour chacune des sept compétences de base. L'évaluation de l'agilité technique et de l'équipe est un exemple de la figure 13.<br/> | |||
<br/> | |||
[[Fichier:Measure and Grow F12.png|border|link=|800px|center]]<br/> | |||
<div style="text-align: center;">'''Figure 13. Rapport d'une évaluation des compétences en matière d'agilité technique et d'esprit d'équipe.'''</div><br/> | |||
Chaque évaluation suit un processus standard qui consiste à effectuer l'évaluation, à analyser les résultats, à prendre des mesures et à célébrer les succès. De plus, une analyse comparative avec la concurrence est possible grâce aux outils d'évaluation en ligne mis à la disposition des membres de la communauté SAFe. Des informations et des conseils supplémentaires peuvent être trouvés dans l'article du thème avancé [https://scaledagileframework.com/facilitating-safe-assessments/ Faciliter avec succès les évaluations SAFe].<br/> | |||
<br/> | |||
Le tableau suivant fournit des liens de téléchargement pour chacune des évaluations des compétences de base : | |||
* [https://scaledagileframework.com/wp-content/uploads/delightful-downloads/2020/05/Organizational-Agility-Assessment-V3.xlsx Agilité Organisationnelle] | |||
* [https://scaledagileframework.com/wp-content/uploads/delightful-downloads/2022/09/Lean-Portfolio-Management-v1-New_EN-1.xlsx Gestion Lean du Portefeuille] | |||
* [https://scaledagileframework.com/wp-content/uploads/delightful-downloads/2023/03/Enterprise-Solution-Delivery-Assessment-V3.xlsx Fabrication de Solutions d'Entreprise] | |||
* [https://scaledagileframework.com/wp-content/uploads/delightful-downloads/2023/03/Agile-Product-Delivery-v2-New_EN.xlsx Fabrication Agile de Produits] | |||
* [https://scaledagileframework.com/wp-content/uploads/delightful-downloads/2022/04/Team-And-Technical-Agility-v2-New_EN.xlsx Agilité Technique et d'Équipe] | |||
* [https://scaledagileframework.com/wp-content/uploads/delightful-downloads/2020/05/Continuous-Learning-Culture-Assessment-V2.xlsx Culture d'apprentissage continu] | |||
* [https://scaledagileframework.com/wp-content/uploads/delightful-downloads/2020/05/Lean-Agile-Leadership-Assessment-V2.xlsx Leadership Lean-Agile] | |||
====Mesurer et faire évoluer la maturité de DevOps==== | |||
En plus des évaluations de l'agilité métier et des compétences de base, le SAFe DevOps Health Radar (Figure 14) est une évaluation qui aide les ART et les Solution Trains à optimiser la performance de leur chaîne de valeur. Il fournit un bilan de santé DevOps systémique en évaluant la maturité des 4 aspects et des 16 activités du pipeline de livraison continue. Le Radar de Santé est utilisé pour mesurer la maturité de base à tout moment de la transformation DevOps et pour guider les progrès rapides et incrémentaux par la suite.<br/> | |||
<br/> | |||
'''Note''' : Le Radar de santé DevOps doit être utilisé parallèlement à l'évaluation Agile Product Delivery pour garantir une couverture complète des trois dimensions de la compétence de base APD.<br/> | |||
<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/> | |||
<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== | ||
