Synergies entre CMMI et les Méthodes Agiles

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 !« .

Le point sur CMMI

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.


Trois dimensions critiques

Trois dimensions critiques


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.

Synergies entre CMMI et Méthodes Agiles

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.

Préjugés et Idées reçues

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.

Utilisation conjointe de CMMI et des méthodes Agiles

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]. 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] : 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.

Références

  1. « CMMI or Agile : Why Not Embrace Both » Hillel Glazer [Entinex Inc.], Jeff Dalton [Broadsword Solutions Corporation], David Anderson [David J. Anderson & Associates Inc.], Mike Konrad et Sandy Shrum [SEI]
  2. « Scrum and CMMI Level 5 : The Magic Potion for Code Warriors » Jeff Sutherland [Patientkeeper Inc.], Carsten Ruseng Jakobsen [Systematic Software Engineering], Kent Johnson [AgileDigm Inc]
  3. « An Approach for Using CMMI in Agile Software Development Assessments: Experiences from Three Case Studies » Minna Pikkarainen et Annukka Mäntyniemi [VTT Technical Research Centre of Finland]
  4. « Mapping CMMI Project Management Process Areas to SCRUM Practices » Ana Sofia C. Marçal et Arnaldo D. Belchior [ University of Fortaleza],  Bruno Celso C. de Freitas et Felipe S. Furtado Soares [C.E.S.A.R – Recife Center of Advanced Systems and Studies]
  5. « Agile Methods and CMMI: Compatibility or Conflict ? «  Martin Fritzsche et Patrick Keil [Technische Universitat Munchen]
  6. « Stretching Agile to fit CMMI Level 3 » David J. Anderson [Microsoft Corporation]

8 commentaires sur “Synergies entre CMMI et les Méthodes Agiles”

  • Je ne suis pas pleinement satisfait. Vous me présentez un verre à moitié plein, 50% des pratiques CMMI sont couverts par les méthodes AGILE. Vous me dites que le lean va permettre d’éviter à l’implémentation de CMMI de devenir trop bureaucratique et de produire trop de documentation. C’est des critères déjà établis par la philosophie Agile qui émanent elle-même du Lean de Toyota. D'ailleurs, ce n’est pas le problème, bon nombre d’organisations sont CMMI et ne sont pas bureaucratique et cela avant même l’arrivée du Lean. Le CMMI est un modèle qui se veut par nature "prédictible" alors que les méthodes Agile, sont "Agile". La question est donc qu’arrivera-t-il de la philosophie Agile lorsque le verre sera plein de prédictibilité. Est-ce que l'agilité et la prédictibilité peuvent co-exister? Et comment? Référence à Jean-Pierre Vickoff (http://www.rad.fr/)
  • Un vieil article de Ron Jeffries s'attaquait aussi à ce sujet : http://www.xprogramming.com/xpmag/xp_and_cmm.htm
  • Les niveaux les plus hauts de CMMI imposent des indicateurs de qualité et de performance des sous-processus, permettant la comparaison avec le modèle de performance des processus de l'entreprise et ainsi la prédictibilité. Pour fonder cette comparaison, les sous-processus doivent être stables et prévisibles du point de vue de ce qu'on mesure. Les méthodes agiles (et incrémentales en général) permettent cette comparaison en imposant des ressources et des délais fixes pour chaque itération. Cela n'est pas possible avec des méthodes pour lesquelles les sous-processus ne sont pas reproductibles (ex: cascades enchaînant des cahiers des charges différents) : on ne peut pas comparer les mesures... Ce sujet est abordé dans le livre blanc d'OCTO : "Une Politique pour le Système d'Information".
  • Pour info, j'ai traduit l'excellent article de Jeff Sutherland en français (dans la mesure du possible) : Scrum et CMMI Niveau 5 La Potion Magique pour les Guerriers du Code.
  • Merci pour cet article et des références liées que je me suis permis de référencer (dans mon Blog http://gestion-projet-mature.blogspot.com/2009/08/agile-ou-mature-13.html), de mon point de vue l'agilité pour le chef de projet est de savoir définir un cycle de vie/planning adapté à son contexte projet, pour l'organisation l'enjeux est de définir des processus matures pragmatiques applicables naturellement qui permettront la capitalisation et l'amélioration continue.
  • Bonjour Je me permets un petit aparté ici. C'est quand même un comble de parler de CMMI et Agiles sans mentionner la méthode Agile du SEI. Je sais bien que SCRUM et XP ont la cote, mais n'empêche. En effet depuis 1994, le créateur du CMM, Watts Humphrey, a continué de déveloper des méthodes CMM agiles appelées Personal Software Process (PSP) et Team Software Process (TSP). http://www.sei.cmu.edu/tsp/index.cfm. Le Personal Software Process (PSP) consiste à inculquer à vos membres d’équipes, de façon individuelle, des méthodes de travail comme le développement itératif, le découpage des activités et l’organisation des tâches, l’autocontrôle et l’amélioration continue. Juste ce qu'il faut de formalisme CMM qui leurs permettront de participer avec succès à la réalisation de vos projets. En complément aux bonnes pratiques INDIVIDUELLES enseignées à travers le PSP, il est important d’assurer un fonctionnement mature (au sens CMMI) d’un ensemble d’individus qui forme l’équipe de projet. En ce sens, le Team Software Process (TSP) accompagne une équipe à être plus engagée, totalement autodirigée et pleinement autonome en appliquant des méthodes de coaching et de leadership. Juste ce qu'il faut de formalisme pour une équipe CMM. Le TSP, jumelé au PSP, s’avère une approche gagnante valorisant les individus et permettant de terminer les projets à temps, dans le respect des budgets, à la satisfaction des clients et avec un haut niveau de qualité. Amicalement, Frédérick Lussier Conseiller senior/Senior Consultant "SEI-Certified PSP Developer" "SEI-Authorized Instructor for PSP" "Certified SCRUM Master" Tel.: +1 450 653 3533 Mob.: +1 418 262 4175 [email protected] SKYPE: fredlussier Alcyonix inc. (www.alcyonix.com) Groupe SQLI (www.sqli.com) "Software Engineering Institute (SEI) Partner" 1494 Montarville, #205, St-Bruno (QC) J3V 3T5 CANADA
  • Il faut différencier les processus d'actions-décision de gestion, des opérations techniques de production (comme dans un réseau de distribution, où il y a un réseau pyramidal de postes de commande et un réseau pipeline des postes opérateurs de production (3 niveaux de détails qui sont poste-équipe-section productive). Les actions, les processus, sont liées à des cycles circulaires d'acteurs hiérachisés, en paires de couches niveaux ayant chacun la forme d'une croix scout ou d'un PHI majuscule (un cycle en Y refermé sur le haut pour intégrer le poste de manager décideur et son sous fifre. Chaque action à 4 sous actions, conduites par 4 paires d'acteurs. Un processus est basé sur des cycles en PHI posés sur un cycle en V ou V inversé
  • Un article sur les synergies entre CMMI et les méthodes Agiles
    1. Laisser un commentaire

      Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha