Du CMMI agile et vice versa : Gestion des Exigences [fr] Extending the Flex ComboBox to log any information, actions, events…
Jul 31

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 :

  • “suivre l’évolution de la vélocité de l’équipe”
  • “suivre l’avancement du traitement du backlog produit”
  • “suivre les résultats des tests”

Toutefois, CMMI demande à mesurer tous les Process Area. Il faudra alors que le projet Agile définisse des objectifs pour chaque aspect du CMMI :

  • Gestion de configuration : nombre de check-in par jour
  • Requirement Development : évolution de la taille du backlog produit
  • Risk Management : évolution du risque global du projet, nombre de risques avérés
  • Product Integration : nombre de builds instables par semaine, mois

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 ;) ). 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.

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”.


Exemples de base de métriques :

Exemple de définition de métrique


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 ?

Aubry Conseil

Related posts

Written by Arnaud
Creative Commons License
Tags: , , , ,

Share/Save/Bookmark

Help me improve my blog by rating this post or sending a comment.

not goodquite goodgoodvery goodexcellent (No Ratings Yet)
Loading ... Loading ...


Comments