Pour continuer sur mon élan du CMMI agile, voici un nouveau chapitre qui va être rapide et s’inscrit dans la lignée de certains articles sur les métriques.
Il est clair que les méthodes Agiles nécessitent une rigueur à toute épreuve pour rester efficace. Elles ont par conséquent besoin de métriques pour avoir et apporter de la visibilité mais aussi mesurer leur performance en vue de s’améliorer. CMMI réclame de son côté un certain formalisme dans la définition et l’utilisation des métriques.
Comment donc peut-on répondre aux pratiques CMMI concernant les métriques et être Agile ?
On trouve des métriques partout chez CMMI et ce, dès le niveau 2. Partout car il y a la terrible “GP2.8 : Monitor and Control the Process” pour chaque Process Area : gestion des exigences, project planning, configuration management, technical solution et même pour les métriques… les métriques des métriques quoi…
Le vif du sujet :
Donc si je devais mettre en place ou évaluer un projet Agile, SCRUM ou XP notament, sur le Process Area “Measurement and Analysis”, voici ce que je pourrais chercher :
| Pratique et Objectif CMMI | Explication CMMI |
Réponse Agile possible |
|
Measurement and Analysis |
||
|
SG 1 Align Measurement and Analysis Activities |
||
| SP 1.1 Establish Measurement Objectives | Etablir et maintenir les objectifs de mesures qui sont dérivés des besoins et objectifs en information |
S’agissant de se doter d’objectifs de mesure, les méthodes Agile ont déjà une panoplie d’objectif :
Toutefois, CMMI demande à mesurer tous les Process Area. Il faudra alors que le projet Agile définisse des objectifs pour chaque aspect du CMMI :
Le meilleur endroit pour les définir est un plan projet. Mais Agile n’a pas forcément de plan projet (bien que ce soit aussi bénéfique que le document de Vision mais ne polémiquons pas, ce n’est pas le sujet Enfin encore, une possibilité serait de compléter le document de Vision avec une partie “Organisation du projet” et un chapitre ou annexe sur les métriques que le projet suivra. Livrables / preuves : Plan projet, Vision, base de métrique. |
|
SP 1.2 Specify Measures |
Spécifier les mesures pour répondre à un objectif de mesure |
L’identification de métriques peut être facilitée par la méthode GQM. Chaque mesure est spécifiée : nom, formule, représentation… Il convient de spécifier où trouver les données nécessaires à l’élaboration, qui les collecte et quand ; ainsi que comment et où, sous quelle forme sont stockées ces mesures. Enfin, une procédure d’interprétation doit être élaborée. Tout ce travail qui semble très laborieux tient en fait en quelques colonnes dans une spreadsheet… Livrables / preuves : Plan projet, vision, base de métrique |
|
SP 1.3 Specify Data Collection and Storage Procedures |
Spécifier comment les données seront obtenues et stockées |
|
|
SP 1.4 Specify Analysis Procedures |
Spécifier comment les données seront analysées et rapportées |
|
|
SG 2 Provide Measurement Results |
||
|
SP 2.1 Collect Measurement Data |
Obtenir les données de mesure spécifiées |
Il s’agit juste d’appliquer ce qui a été défini par le SG1. Et c’est ce que fait naturellement Agile et n’importe quelle organisation quand elle utilise des métriques. CMMI demande tout de même d’avoir une trace de l’analyse des métriques : commentaires ou actions prises suites à un résultat. Livrables / preuves : minutes de réunions, logs d’outils, backlog de problèmes, mail, burndown chart… |
|
SP 2.2 Analyze Measurement Data |
Analyser et interpréter les données de mesure |
|
|
SP 2.3 Store Data and Results |
Gérer et stocker les données de mesure, les spécifications de mesures et les résultats d’analyse |
|
|
SP 2.4 Communicate Results |
Rapporter les résultats de mesures et les activités d’analyse à toutes les parties prenantes pertinantes |
Si la métrique n’est pas partagée, elle ne sert à rien. Il suffit juste de l’insérer dans un rapport, l’afficher dans un portlet d’un portail, l’afficher dans un coin d’un tableau blanc… Livrables / preuves : minute de réunions, backlog de problèmes, affichage “publique”. |
). Donc une autre solution serait directement une base de métriques (même sous forme Excel) qui regroupe des métriques sous des objectifs de mesures.Exemples de base de métriques :
Comment renforcer la conformité au CMMI ? (ou faciliter sa démonstration)
Agile, dans son mode de fonctionnement et sa philosphie (efficacité, feedback, amélioration de l’équipe), est très portée sur les métriques, la culture est présente d’office, personne ne viendra mettre en doute l’intérêt d’un burndown chart ou de la mesure de la vélocité - ce qui est loin d’être le cas de certaines organisations se lançant dans CMMI. Mais c’est tout le SG1 qu’Agile a à mettre en place selon moi. Il existe déjà toute une ribambelle de métriques pour les méthodes agiles qui ont juste à les mettre en place. Le formalisme demandé par CMMI peut toutefois être traité sans trop d’effort : étant donné qu’il existe déjà une base de métrique Agile dans la litterature, il suffit d’enrober un peu et de faire évoluer cette enrobage léger lorsque nécessaire.
Où trouver un peu plus d’infos ?
Related posts
Written by Arnaud
Tags: Agile, CMMI, métriques, Scrum, XP
(No Ratings Yet)
Loading ...Comments are closed.
