L’objet de cet article est de faire état des synergies possibles entre CMMI et les méthodes agiles, celles-là même qui ont poussé Jeff Sutherland (co-auteur de Scrum) à écrire récemment l’article "Scrum and CMMI Level5 : The Magic Potion for Code Warriors" et le SEI (Software Engineering Institute) à publier le rapport "CMMI and Agiles : Why not Embrace Both !".
Dans les années 80, le Département de la Défense des Etats-Unis demande l’élaboration d’un référentiel de critères permettant d’évaluer ses fournisseurs de logiciels : Cette tâche est confiée au SEI.
Pendant la maturation du modèle, le SEI fait deux constats. Les personnes changent d’entreprise tout au long de leur vie et les outils évoluent rapidement. Ainsi, des trois dimensions critiques pour la création de logiciels, il ne reste qu’un levier d’actions permettant de maximiser l’utilisation des ressources humaines et technologiques : Les procédures et les méthodes.
C’est sur ces fondations que naît le CMM en 1991 qui deviendra en 2001 le CMMI (Capability Maturity Model + Integration). CMMI est un modèle intégrant des exemples de bonnes pratiques permettant d’appréhender, d'évaluer et d'améliorer les activités de l’entreprise d’ingénierie.
CMMI propose une échelle de mesure de maturité (c'est-à-dire de la capacité à produire des produits correspondant aux besoins exprimés avec des contraintes de budget et de temps respectées) pour les entreprises. Comme l’explique le SEI, CMMI est un modèle. Il doit être implémenté au sein de l’entreprise pour améliorer les processus. Ce n’est pas un standard et ne doit/peut pas être appliqué tel quel. En particulier, CMMI ne contient pas de processus, ni de procédures à appliquer mais des exemples de pratiques permettant d’atteindre les buts préconisés. CMMI autorise l’utilisation de pratiques alternatives pour atteindre un but mais ne les définit pas.
Nous ne présenterons pas ici les méthodes agiles, le lecteur assidu d’Octo Talks pourra se référer aux articles décrivant ces méthodes.
Les méthodes agiles et le CMMI partagent les mêmes objectifs qui sont bien sûr ceux de toutes les méthodes, pratiques et outils visant à produire du logiciel (satisfaction du client, respect du planning et des coûts, …). Cependant les préjugés d’une communauté contre l’autre font que les agilistes et les adeptes de CMMI s’entremêlent peu. Ces préjugés sont tout d’abord historiques, CMMI a été mis en place dans de grandes structures où le besoin de confidentialité est important tandis que les méthodes agiles ont d’abord pénétré de petites structures dans lesquelles le besoin de confidentialité est faible. Ils sont aussi lexicaux, CMMI parle de maturité et de responsabilité tandis que les méthodes agiles utilisent le vocabulaire de la souplesse et de la performance. Ces idées reçues font que les agilistes dénigrent la rigueur et la documentation jugée excessive de CMMI, tandis que la communauté CMMI n’imagine pas que l’efficacité et la flexibilité agile puissent être compatibles avec les exigences CMMI.
Pourtant les articles décrivant l’utilisation des deux paradigmes en synergie se multiplient. De nombreux mappings entre CMMI et les méthodes agiles ont été publiés récemment [5,[4]("Mapping CMMI Project Management Process Areas to SCRUM Practices" )]. Un résumé rapide permet de penser que SCRUM et XP intègrent respectivement les exigences du CMMI à 46% et 60%. Certaines pratiques génériques (fournir les ressources nécessaires, définir et affecter les responsabilités, identifier et impliquer les parties prenantes, conduire et maîtriser le processus, rendre compte aux dirigeants) sont déjà implémentées par SCRUM. D’autres (organiser la planification des processus, planifier le processus, construire puis gérer la documentation du processus, évaluer l’exécution du processus) ne sont pas traitées par SCRUM tout en étant compatibles. Enfin, l’implémentation de la collection d’informations d’amélioration nécessite un aménagement de SCRUM, par exemple en modifiant le déroulement du Sprint Retrospective Meeting.
Au delà des préjugés et des idées reçues, nous observons que ces méthodes sont défendues par des populations différentes. Les méthodes agiles sont portées par des personnes qui construisent des applications informatiques, du développeur au responsable MOA (bottom up), tandis que CMMI est soutenu par la hiérarchie de la DSI et ses cellules transverses (top down), souvent dans le but de fournir un point de comparaison entre les DSI. Ainsi on entendra un DSI ou un manager de cellule transverse se féliciter d'être certifié CMMI, ce n'est pas le discours d'un développeur ou d'un chef de projet. Le premier apport observé de la cohabitation entre méthodes agiles et CMMI est donc la création d'un climat apaisé entre opérationnels, managers et cellules transverses.
Ce premier bénéfice de l'utilisation conjointe de CMMI et des méthodes Agiles permet par ailleurs de comprendre l'un des "prérequis" à l'implémentation réussie de toute démarche d'amélioration: Tout le monde doit avoir décidé d'y participer. On observe que l'agile "télécommandé depuis le haut" n'est jamais aussi efficace que l'agile dont les pratiques émergent du "bas de l'échelle". C'est d'ailleurs l'une des "recettes" culturelles du succès de Toyota, qui possède une forme de bureaucratie "bottom up" très puissante, dans laquelle les équipes opérationnelles mettent à jour elles mêmes leur standard.
Ainsi, l'implémentation des méthodes Agiles conjointement à CMMI permettra de ne pas ignorer la correlation entre la qualité des interactions dans l'équipe et la qualité du produit, celle-ci échappant à nombre d'experts (un coach me confiait avoir géré des projets pendant 10 ans en se figurant que la qualité de l'équipe devait essentiellement au hasard des recrutements et aux bonnes manières). Il faut donc un processus pour le produit et un processus pour l'équipe, sans oublier un alignement de l'équipe sur les processus et le produit. Et pour assurer cet alignement : du leadership!
Enfin, en ce qui concerne les évaluations CMMI, elles ont pour but de valider l’implémentation des objectifs imposés, les méthodes utilisées sont à choisir. Ce choix peut être en partie celui des méthodes agiles. Celles-ci guideront l’entreprise vers une implémentation plus efficace de CMMI [[2]](The Magic Potion for Code Warriors") : le CMMI impose un « Quoi ? », les méthodes agiles implémentent un « Comment ? » acceptable pour CMMI permettant souvent une amélioration de la productivité et de la qualité. En outre, une approche Lean permettra d’éviter à l’implémentation de CMMI de devenir trop bureaucratique et de produire trop de documentation, ce qui est plus souvent le fait des « implémentateurs » que de CMMI lui-même. En conséquence, cela permettra aux organisations désirant atteindre un certain niveau de maturité de mieux percevoir les apports de CMMI. Quant aux entreprises agiles, CMMI les aidera à institutionnaliser les méthodes agiles avec plus de consistance.