Le Chef De Projet Et La Lampe Magique – Une fable sur le CMMI
Il était
une fois un chef de projet. Son projet intégrait des composants
électroniques, à des procédures administratives et des composants logiciels.
Déjà, lecteurs, vous savez que c’est une histoire qui va finir mal. Comment
peut-il en être autrement aujourd’hui?
La majorité des projets échouent n’est-ce pas?[1] Ils sont en retard. Ils
dépassent honteusement les budgets. Les dates de livraison excèdent
largement celles annoncées. Les utilisateurs découvrent plein de défauts qui
n’ont pas été détectés en cours de développement. S’ils paient, ils le font
à contre cœur. Car tout a été mal et ils se sentent floués.
Rome ne s’étant pas bâtie en 1 jour, il ne faut pas espérer que la
discipline toute jeune du développement de systèmes et du logiciel soit
aussi mature que celle de la construction qui a ses racines jusque dans
l’Égypte antique! Il y a eu déjà de nombreuses tentatives pour rehausser le
taux de succès des projets de logiciel et de système. Sans faire une liste
exhaustive et au risque d’oublier des tentatives importantes, songeons à
tous ces apports positifs à notre métier :
– les méthodes de développement;
– les techniques d’architecture, d’analyse, de programmation, d’essais,
d’intégration…;
– les normes et les guides;
– les outils de soutien aux différentes étapes du développement;
– les infrastructures de développement;
– les formations spécialisées pour chefs de projets, développeurs et autres;
– l’assurance qualité, la gestion de configuration, les mesures (métriques);
– etc.
Il faut pas mal de temps à nos organisations de développement pour « digérer
» tous ces additifs vitaminiques et en montrer les vertus dans des
réalisations concrètes et mesurables.
Il y a encore hélas des soirs de désespoir dans la vie de nos chefs de
projet. Ces soirs où on constate que:
– on a encore accepté de faire un changement urgent mais anodin (ah oui?)
demandé par un utilisateur à un développeur sans passer par le circuit
d’autorisation;
– on a préparé des estimations sur la base de jugement d’experts qui n’ont
pas documenté leurs hypothèses et qui ont quitté depuis;
– le reste à faire ajouté au déjà fait dépasse au moins de 50% les
estimations originales; on vient de s’en apercevoir, à 3 semaines de la
livraison prévue;
– lors de l’intégration d’un sous-système en vue d’une recette utilisateur,
on s’est rendu compte qu’une modification récente avait écrasée des
corrections faites sur au moins 10 modules dans le mois précédent; on ne
sait pas exactement où…
– les risques de non disponibilité d’un progiciel devant être intégré à
notre solution n’avaient pas du tout été analysés; or, le fournisseur
annonce deux mois de délai;
– notre architecte principal fait un burn-out et doit s’absenter au moins 3
mois;
– les utilisateurs finaux (les vrais) n’ont pas participé à la préparation
des jeux d’essais et les premiers essais in situ suscitent la grogne car
l’ergonomie des interfaces est nulle selon eux;
– tous les développeurs se plaignent de la lenteur de leur poste de travail
et perdent un temps fou à attendre les résultats de leurs tests unitaires.
Si par miracle, il trouve une lampe magique sur son chemin de retour à la
maison (il est très tard et après minuit, tout peut arriver!), que va-t-il
demander au génie de la lampe? Si j’étais lui, je demanderais au génie de
visiter mes managers jusqu’au plus haut niveau pour leur insuffler l’idée de
déployer enfin dans l’organisation le CMMI.
Le « Capability Maturity Model Integration » est un modèle des meilleures
pratiques (“best practices”) pour le développement des systèmes et du
logiciel. Fruit d’une longue et fructueuse évolution depuis les années 80,
il est maintenant dans le domaine public dans sa version 1.2 publiée en août
2006 par le SEI («Software Engineering Institute»)[2]. Pavé de plusieurs
centaines de pages, il est cependant très bien structuré autour de 22
domaines de processus. La somme de ceux-ci représente la «palette» des
activités requises quand on développe un système. C’est un peu comme si on
avait réuni les meilleurs développeurs du monde et qu’on leur avait demandé
de nous livrer leurs secrets. Des scribes auraient tout noté puis organisé
et synthétisé pour livrer à la communauté du développement : managers, chefs
de projets, développeurs, utilisateurs, soutien, testeurs, etc. Tous ceux
qui de près ou de loin sont impliqués dans le développement peuvent tirer
profit du CMMI.
De plus, le modèle propose une démarche de déploiement progressif et des
critères pour identifier à quel niveau d’institutionnalisation on se situe.
Si on adopte la représentation étagée du modèle (la plus populaire), on se
voit proposer un itinéraire en cinq étapes : du niveau de maturité 1 (il n’y
a pas de zéro – c’est toujours ça de pris!) au niveau 5, l’organisation qui
déploie le CMMI se transforme progressivement et les résultats sont évidents
dès les premiers mois.
Ainsi le passage au niveau 2 requiert de maîtriser 7 domaines de processus :
– Gestion des exigences (Comment éviter la perte de contrôle sur le
périmètre du projet)
– Planification de projet (Comment mettre un projet sur des rails bien
droits dès le départ avec des estimations fiables et des engagements clairs
des intervenants)
– Surveillance et contrôle de projet (Comment surveiller le bon tableau de
bord et réagir de façon appropriée quand un signal d’alarme se déclenche)
– Mesures et analyse (Comment se doter d’indicateurs – mesures, métriques –
significatifs et fiables et les faire « parler » intelligemment)
– Gestion des accords avec les fournisseurs (comment établir une relation
saine avec ses prestataires de services et ses fournisseurs de produits et
éviter qu’ils ne deviennent le maillon le plus faible)
– Assurance qualité processus et produit (comment avoir une visibilité
objective sur le respect des normes et des règles que les projets doivent
suivre)
– Gestion de configuration (comment garder le contrôle des milliers de
composants générés en cours de projet et que l’on doit versionner,
assembler, faire migrer, protéger contre les accès non autorisés, etc.).
Chacun des domaines est associé à un nombre limité d’objectifs spécifiques
(en général 2 ou 3) à atteindre. Ainsi, pour décréter que l’on maîtrise la
Planification de projet, il faut que chacun de ces trois objectifs soient
satisfaits par l’ensemble des projets dans une organisation :
– avoir préparé des estimations sur la base d’attributs clairement établis
(volume, complexité, nombre d’occurrences, etc.) et des règles de calcul
documentées
– avoir assemblé dans un ensemble documenté tout ce qu’il faut pour asseoir
la gestion de projet sur un « PLAN » complet
– avoir obtenu un engagement sur ce PLAN des intervenants concernés.
Pour savoir si un objectif est atteint ou pas, on doit examiner les
pratiques qui y sont attachées et qui contribuent à expliciter ce que l’on
s’attend de voir réalisé dans un projet. Par exemple, une pratique attachée
au second objectif décrit ci-dessus demande que l’on ait identifié les
risques; une autre, que l’on ait identifié les parties prenantes du projet;
une autre encore, que l’on ait réfléchi aux besoins de formation et qu’on
ait prévu ce qu’il faut s’il manque certaines connaissances aux personnes
affectées au projet. Le CMMI propose des moyens très concrets de juger si
oui ou non ces bonnes pratiques sont déployées. Des indicateurs de
déploiement des pratiques sont documentées dans le CMMI, ce qui est
drôlement utile quand on fait de l’assurance qualité ou des audits internes
ou externes.
Et ce n’est pas tout! Sous chacune des centaines de bonnes pratiques, on
trouve des notes explicatives riches en suggestions, exemples, lignes
directrices d’interprétation. Ceci explique qu’au total le modèle fait
plusieurs centaines de page.
Le CMMI est devenu une norme de facto dans l’industrie des systèmes et du
logiciel. Plusieurs grands donneurs d’ordre demandent maintenant aux
répondants à leurs appels de propositions de démontrer leur maturité sur
l’échelle du CMMI. Le taux de pénétration du CMMI à travers le monde est
impressionnant.[3]
Le SEI a aussi publié une famille de méthodes d’évaluation qui se nomme
SCAMPIms (« Standard CMMI Appraisal Method for Process Improvement ») qui se
présente en trois variantes pour couvrir un éventail de besoins : de la
classe C qui sert à vérifier si une méthode sur étagère est conforme aux
exigences du CMM, à la classe B qui permet de juger la distance entre ses
pratiques actuelles et les pratiques cibles du niveau N du CMMI, à la classe
A qui seule permet de confirmer officiellement un niveau de maturité. Le SEI
forme très rigoureusement et certifie (après un parcours du combattant) des
chefs évaluateurs SCAMPIs ainsi que des instructeurs CMMI. Ceux-ci doivent
travailler chez des partenaires autorisés par le SEI, triés sur le volet
selon des règles strictes. Le tout vise maintenir très crédibles les
résultats des évaluations réalisées sur la base du CMMI.
Un parcours CMMI est un abonnement à vie à une sorte de club d’exercice. On
développe des aptitudes sans cesse croissantes qui sont rapidement très
rentables pour les organisations! Pour chaque euro investi, on en récupère
rapidement 4 ou 5! Qui dit mieux?[4] N’est-ce pas une sorte de trésor qu’il
est tout à fait raisonnable d’espérer trouver dans une lampe magique?
Cette lampe magique est devant vos yeux et à votre portée. Il suffit de la
prendre et de la frotter pour exaucer votre vœu! Et l’histoire finit assez
bien finalement…
*Richard Basque (33 années d’expérience) a fondé la société
Alcyonix en 1998. Il est autorisé par le SEI en tant que chef évaluateur
avec les méthodes SCAMPI (Classe A, B et C). Il est aussi autorisé par le
SEI comme instructeur pour les cours officiels du SEI sur CMMI 1.2. De plus,
en tant que “SEI Visiting Scientist” à temps partiel, il est
occasionnellement invité par le SEI à former ou observer (dans le cadre de
leur certification) des candidats chefs évaluateurs SCAMPI ou des candidats
instructeurs CMMI. Richard fut impliqué dans une trentaine d’évaluations de
processus officielles au Canada, aux États-Unis, en Europe et en Amérique du
Sud. Il a publié le premier livre en français sur le CMMI chez DUNOD, un
prestigieux éditeur français.
CMMI – Un itinéraire fléché vers le Capability Maturity
Model Intégration – Version 1.2
Par Richard Basque, Préfaces de Mike Konrad et Mike Phillips, Dunod/01
Informatique
Collection InfoPro – 175 x 250 mm – 288 pages – 2006 – 2e édition
ISBN : 2100497111
Il était
*Richard Basque (33 années d’expérience) a fondé la société
© CMMI et Capability Maturity Model sont enregistrés au U.S. Patent &
