Agilité « cmmi-déploiement

Archive pour le mot-clef ‘Agilité’

CMMI et Agilité, deux faces opposées d’une même médaille

Lundi 19 octobre 2009

 

La communauté CMMI, d’une façon générale, adhère à l’idée que le CMMI et les méthodes agiles sont compatibles. Je ne suis pas entièrement d’accord avec cette position. Sans aucun doute, le cycle de vie itératif, ou les méthodes de travail que préconisent XP et autres Scrum sont applicables dans un environnement CMMI. Par contre, sur un autre front, l’agilité se définit elle-même comme une démarche peu formaliste, en opposition nette avec le CMMI sur ce point : anti-documentation, anti-planification, anti-contractualisation et anti-processus, pour reprendre les quatre axes du manifeste agile, et même si celui-ci tempère sa position en post-scriptum.

 

Ce à quoi les auteurs d’un article au caractère officiel, et auquel participe le SEI, “CMMI or Agile : why not embrace both !”, répondent que le CMMI est adaptable au contexte de chaque organisation ou projet : déterminer d’abord le juste degré de formalisme pour le contexte en question, et construire un système autour.

 

Sauf que, pour le moment, et je prends uniquement l’exemple de la documentation, une évaluation Scampi de niveau 3 examine en moyenne 400 types de documents. Selon Dalton (sur une présentation que l’on peut trouver sur le site de l’ASQ), un projet agile produit en moyenne 39 artefacts. Dalton estime que par consolidation on peut passer de 400 à 70 types de documents pour CMMI. Pour qu’il y ait compatibilité entre CMMI et agilité, il faudra que les évaluateurs CMMI acceptent cette consolidation, d’une part, et d’autre part que les agilistes acceptent de produire deux fois plus de documents, passant de 39 à 70, tout en se trouvant toujours “agiles”. Ce n’est pas rien, et je ne crois pas que l’on y soit encore.

 

Plus généralement, la question d’un “juste degré de formalisme pour un contexte donné” ne peut pas être résolue de façon purement analytique : même en s’aidant d’une liste de critères détaillée il restera toujours une large part de subjectivité dans le choix que l’on pourra en faire. Simplement, certains individus sont naturellement portés au formalisme, d’autres moins. Et je n’ai pas pu observer dans la pratique que les premiers étaient forcément de meilleurs chefs de projets que les seconds, ou qu’ils se voyaient confier les projets les plus critiques au sein de leur organisation. Pour cette raison, je crois qu’il restera toujours une tension, et une alternance, au sein des organisations comme dans la recherche, entre tendances formalistes et non formalistes.

 

Dans l’immédiat, l’agilité a donné un coup de boutoir au CMMI, obligeant le SEI à s’occuper des excès qui, selon les auteurs même du “why not embrace both”, ont alimenté la révolte agile.

 

Selon ces auteurs, les excès bureaucratiques de certains déploiements CMMI proviennent de ce que certaines organisations se sont intéressées au CMMI non pour améliorer leurs pratiques, mais pour obtenir l’évaluation. Je trouve cette analyse trop courte, simplement parce que le CMMI, pour le meilleur ou pour le pire, est un modèle nativement formalisateur : les 400 types de documents dont nous parlions plus haut sont une moyenne, ce ne sont pas que les organisations en course pour la médaille.

 

D’une façon plus générale, là où le CMMI fut conçu comme un modèle de performance, c’est-à-dire optimisant le rapport qualité-prix, pour un contexte donné, il est aujourd’hui perçu, en tout cas dans les organisations que j’ai connues, comme un modèle de qualité au sens étroit. En d’autres mots, on ne se pose pas suffisamment la question de la valeur ajoutée des procédures que l’on met en place au nom du CMMI. Le SEI devrait davantage inciter les organisations à mener cette réflexion au quotidien. Et les évaluateurs ne devraient pas donner une évaluation positive à des organisations trop bureaucratiques pour le contexte qui est le leur. La médaille CMMI a deux faces, et il ne faut pas négliger l’une pour l’autre.


il-y-a-cmmi-et-cmmi1