Les choses les plus importantes ne peuvent être mesurées. Les problèmes les plus importants, à long terme, ne peuvent être mesurés à l’avance.

—W. Edwards Deming

Le logiciel de travail est la principale mesure de progrès.

—Agile Manifesto

Métrique

Les mesures sont des mesures convenues utilisées pour évaluer dans quelle mesure l’organisation progresse au niveau portofolio, large solution, program et les objectifs commerciaux et techniques de l’équipe.

Grâce à sa physique de travail, ses systèmes Kanban, ses boîtes de temps et son retour rapide, Agile est intrinsèquement plus mesurable que son prédécesseur basé sur le proxy, le processus en cascade. De plus, avec Agile, le «système fonctionne toujours». Ainsi, la meilleure mesure provient directement de l’évaluation objective du système en fonctionnement. La livraison continue et les pratiques DevOps fournissent encore plus de choses à mesurer. Toutes les autres mesures, même l’ensemble complet de mesures Lean-Agile décrites ci-dessous, sont secondaires à l’objectif primordial qui consiste à mettre l’accent sur la fourniture rapide de solutions de haute qualité.

Mais les métriques sont en effet importantes dans le contexte de l’entreprise. SAFe fournit des métriques pour chaque niveau du cadre.

Métriques Portofolio

Mesures de portefeuille lean

L’ensemble de mesures de portefeuille Lean fourni ici est un exemple d’un groupe de mesures complet mais lean qui peut être utilisé pour évaluer les progrès internes et externes d’un portefeuille entier. Dans l’esprit du «groupe de mesures le plus simple qui puisse fonctionner», la figure 1 présente le plus maigre que quelques portefeuilles Lean-Agile utilisent efficacement pour évaluer la performance globale de leurs transformations.

Figure 1. Mesures du portefeuille lean

Tableau de bord équilibré d’entreprise

Le tableau de bord équilibré des entreprises offre quatre perspectives pour mesurer la performance de chaque portefeuille – bien que la popularité de cette approche ait diminué au fil du temps en faveur de la gestion de portefeuille allégée (LPM), comme le montre la figure 2. Ces mesures sont les suivantes:

• Efficacité
• Livraison de valeur
• Qualité
• Agilité

Ces résultats sont ensuite mappés dans un tableau de bord exécutif, comme illustré aux figures 2 et 3.

Figure 2. Une approche de tableau de bord équilibré, divisant les mesures en quatre domaines d’intérêt

Figure 3. La conversion des métriques ci-dessus en un classement alphabétique et la synthèse des données pour l’entreprise fournissent une image plus globale des performances.

Pour plus d’informations sur cette approche, reportez-vous au chapitre 22 de Mise à l’échelle de l’agilité logicielle: meilleures pratiques pour les grandes entreprises [2].

Auto-évaluation de la gestion du portefeuille Lean

Le Lean Portfolio Management (LPM) évalue et améliore continuellement leurs méthodes. Le LPM effectue périodiquement un questionnaire d’auto-évaluation pour mesurer leurs performances, qui produit automatiquement un diagramme radar similaire à celui présenté à la figure 4. Il met en évidence les forces et les faiblesses relatives.

Figure 4. Carte radar d’auto-évaluation du portefeuille

Métriques Large Solution

Mesure de prévisibilité du train de solutions

Les mesures de prévisibilité des Agiles Release Train (ART) sont résumées pour calculer la mesure de prévisibilité de la solution, comme illustré à la figure 5.

Figure 5. Mesure de prévisibilité du train de solutions

Mesures de performance du train de solutions

Les mesures de performance de l’ART sont résumées pour calculer les mesures de performance du Solution Train, comme illustré à la figure 6.

Figure 6. Mesures de performance du Train de Solution

Métriques Program

Rapport de progression des Features

Le rapport de progression des Features suit l’état des fonctions et des outils lors de l’exécution du PI. Il indique quelles fonctionnalités sont sur la bonne voie ou en retard à tout moment. Le graphique comporte deux barres:

• Planifier – Représente le nombre total d’histoires planifiées.
• Réel – Représente le nombre de stories terminées. La barre est ombrée en rouge ou en vert, selon que l’élément est sur la bonne voie ou non.

La figure 7 donne un exemple de rapport de progression d’une fonctionnalité.

Figure 7. Rapport de progression des fonctionnalités, soulignant le statut de chaque fonctionnalité par rapport au plan incrément de programme.

Mesure de prédictibilité du programme

Les rapports de performance des équipes sont résumés pour déterminer la mesure de prévisibilité du programme, comme illustré à la Figure 8.

Figure 8. Mesure de prévisibilité du programme, montrant deux des équipes du train et du programme (cumulatif)

Le rapport compare la valeur commerciale réelle obtenue à la valeur commerciale planifiée (voir la figure 19). Pour plus d’informations sur cette approche, reportez-vous au chapitre 15 de la section Configuration logicielle requise pour le logiciel agile: pratiques de configuration lean requise pour les équipes, les programmes et l’entreprise [1].

Mesures de performance du programme

La fin de chaque PI est un point de mesure naturel et significatif. La figure 9 illustre un ensemble de mesures de performance pour un programme.

Figure 9. Diagramme des mesures de performance d’un train

Diagramme de flux cumulés

Le diagramme de flux cumulatifs (CFD) est constitué d’une série de lignes ou de zones indiquant la quantité de travail effectuée dans différents États Kanban. Par exemple, les états typiques du programme Kanban sont les suivants:

• Funnel
• Analyzing
• Backlog
• Implementing
• Validating on staging
• Deploying to production
• Releasing
• Done

La figure 10 indique le nombre de fonctionnalités de chaque état Kanban par jour. Les zones plus épaisses dans le CFD représentent des goulots d’étranglement potentiels.

Figure 10. Exemple d’auto-évaluation du programme kanban CFD

Agile Release Train Self-Assessment

L’exécution du programme étant une valeur essentielle de SAFe, l’ART s’efforce en permanence d’améliorer ses performances. Le RTE remplit le questionnaire d’auto-évaluation aux limites des PI ou chaque fois que le train souhaite faire une pause et réfléchir à leurs progrès. La tendance de ces données dans le temps est un indicateur de performance clé. La figure 11 donne un exemple de résultats dans un diagramme radar.

Figure 11. Carte radar d’auto-évaluation de l’ART

Télécharger Agile Release Train Assesment

Efficacité continue du pipeline de distribution

L’efficacité du pipeline compare le temps de réponse au temps d’attente. Certaines informations peuvent être obtenues automatiquement à partir d’outils, notamment l’intégration continue et le déploiement continu, tandis que d’autres données nécessitent un enregistrement manuel dans une feuille de calcul. La technique de mappage des flux de valeur est souvent appliquée pour analyser les problèmes identifiés dans ce rapport. Remarque: le temps de contact représente le moment où l’équipe ajoute de la valeur. En règle générale, le temps de toucher ne représente qu’une petite partie du temps de production total, la plupart du temps est consacré à l’attente, par exemple lors d’un déplacement de travail, d’une file d’attente, etc.

Figure 12. Efficacité du pipeline de distribution continue

Déploiements et Release par timebox

Cette mesure a pour but de démontrer si le programme progresse vers le déploiement et la release plus fréquemment. Il peut être visualisé par PI, comme illustré à la figure 13.

Figure 13. Déploiements et éditions par incrément de programme

Nous pouvons également effectuer un zoom avant pour voir comment les éditions sont gérées au milieu du PI, comme illustré à la figure 14.

Figure 14. Déploiements et versions par itération

Récupération sur la durée

Ce rapport mesure le nombre de restaurations effectuées physiquement ou en désactivant les fonctionnalités. La date à laquelle une solution a été déployée ou mise en production est également indiquée ici pour déterminer s’il existe une relation entre les deux.

Figure 15. Récupération dans le temps

Comptabilité de l’innovation et indicateurs avancés

L’un des objectifs du pipeline de livraison continue est de permettre à l’organisation de mener des expériences rapidement pour permettre aux clients de valider les hypothèses. Par conséquent, les caractéristiques minimales négociables (MMF) et les produits minimaux viables (MVP) doivent définir les indicateurs avancés permettant de mesurer les progrès accomplis dans la réalisation de l’hypothèse de bénéfice. Évitez de vous fier à des indicateurs de vanité qui ne mesurent pas les progrès réels. La figure 16 illustre certaines mesures collectées sur le site Web SAFe pour illustrer les indicateurs avancés de nos efforts de développement.

Figure 16. Indicateurs avancés pour la comptabilité des innovations de sites Web SAFe

Radar de santé DevOps

Le radar de santé DevOps est un outil permettant d’évaluer les progrès de votre programme en termes d’amélioration du flux de valeur grâce au pipeline de distribution continue. La figure 17 illustre les 16 sous-dimensions que les programmes devraient utiliser pour évaluer leur maturité. Il est utile d’identifier les sous-dimensions dans lesquelles nous sommes assis, rampons, marchons, courons ou volons et identifions les points à améliorer.

Figure 17. Radar de santé DevOps

Vous pouvez également vous rendre sur le site de notre partenaire, Agile Transformation, pour obtenir une version en ligne de l’évaluation à l’adresse https://agilityhealthradar.com/safe-devops-assessment.

Métriques Team

Métriques d’itération

Chaque équipe agile rassemble les métriques d’itération qu’elle a accepté de collecter. Cela se produit dans la partie quantitative de la rétrospective de l’équipe. La figure 18 illustre le tableau des mesures d’une équipe.

Figure 18. Graphique des métriques d’itération d’une équipe

Rapport de performance de l’équipe PI

Au cours de la PI System Demo, les Business Owners, les clients, les équipes agiles et d’autres parties prenantes clés évaluent la valeur commerciale réelle atteinte pour les objectifs PI de chaque équipe, comme indiqué dans la figure 19.

Figure 19. Rapport de performance de l’équipe PI

Des trains fiables devraient fonctionner dans la plage de 80 à 100%; Cela permet à l’entreprise et à ses parties prenantes externes de planifier efficacement. Vous trouverez ci-dessous quelques remarques sur le fonctionnement du rapport:

• La BV total prévu n’inclut pas d’objectifs d’étirement contribuant à la fiabilité du train.
• La BV total effectif inclut les objectifs d’étirement.
• Le pourcentage de réalisation est la BV réel ÷ BV prévu.
• Une équipe peut atteindre un niveau supérieur à 100 pour cent (en raison des objectifs ultimes atteints)

Les totaux individuels de chaque équipe sont cumulés dans la mesure de prévisibilité du programme (voir la figure 19).

Auto-évaluation des équipes SAFe

Les équipes agiles évaluent et améliorent en permanence leurs processus. L’un de ces outils est une simple évaluation des pratiques de l’équipe SAFe. Lorsque l’équipe remplit la feuille de calcul, elle produira automatiquement une carte radar semblable à celle illustrée à la Figure 20, qui met en évidence les forces et les faiblesses relatives.

Figure 20. Carte radar d’auto-évaluation de l’équipe SAFe

Apprendre encore plus

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.

[3] https://www.youtube.com/watch?v=VOjPpeBh40s

© Scaled Agile, Inc.