Plus qu’une simple tendance, le rapprochement des Méthodes Agiles et du CMMI (Capability Maturity Model Integration), ou plus exactement l’usage de pratiques de développement Agiles (qui ont le vent en poupe) dans une dynamique de processus guidée par le CMMI (version1.2 DEV d’aout 2006) est bel et bien réel.
Les exemples concernant XP et SCRUM (voir les études de Mickael Spayd, Mark Paulk, Hillel Glazer ou encore Jeffrey Dutton) se multiplient depuis quelques années.
Dernier exemple en date (trés bien documenté d’ailleurs), celui de Codice Software (un éditeur espagnol), « SCRUM Meets CMMi, Agility and discipline combined« , avec à la clé l’atteinte d’un niveau 2 de maturité et une vision trés pragmatique de la combinaison des deux approches (un vrai travail sur REQM, « Gestion des exigences », des domaines complètement nouveaux et pas des plus simples dans un contexte Agile: PPQA, « Assurance Qualité Processus et Produit » et MA, « Mesure et Analyse »….).
Dans un contexte plus général, cette démarche de réconciliation Agile CMMI (c’est un bien grand mot !) est soutenue, et c’est trés positif, par des acteurs majeurs des deux « camps », mais elle implique aussi, selon moi, à notre niveau, l’acceptation de certains prérequis:
- D’abord considèrer le CMMI tel qu’il est, à savoir, un modèle, un guide, et non pas un processus ou une méthode de développement.
- Se souvenir que le CMMI définit seulement le QUOI (par ses objectifs par exemple) et non pas le COMMENT, même si le modèle propose quelques pistes. Et c’est vrai que cette absence de COMMENT a laissé la part belle aux méthodes dites traditionnelles (cascade ou V) toujours bien ancrées.
- Ne pas oublier que seule l’atteinte des objectifs généraux (GG, liés à un niveau de maturité) et spécifiques (SG,liés à un domaine de processus) est requise lors d’une évaluation SCAMPI (méthodes standards d’évaluation). Les pratiques (GP, génériques liées à un niveau et SP, spécifiques liées à un domaine de processus) ne sont quant à elles pas obligatoires, et des alternatives (Agiles notamment) sont envisageables : c’est un bon point d’entrée.
- S’arracher des idées reçues concernant les deux Mondes … (vaste débat), rechercher l’ouverture, et d’un point de vue pratique, au quotidien, s’appuyer sur des leviers organisationnels exploitables.
David Anderson a su trouver les mots justes lors de l’Agile2005:
A key to achieving more agility with the CMMI is to realize that the practices are primarily advisory or indicative only. To meet a CMMI appraisal, an organization must demonstrate that the goals of a process area are being achieved. This is done by identifying evidence of practices. However, the practices need not be the ones described in the CMMI specification. The organization is free to propose alternatives practices and appropriate evidence. The appraisal team must then agree to whether this is appropriate to demonstrate the goal. This provides a process designer with a great deal of freedom.
En conclusion, si vous entendez les mots Agile et CMMI dans la même phrase, ne fuyez pas … soyez curieux … et dites OUI à la convergence.
Je suis à 100% d’accord avec toi. C’est ce que je pratique au maximum au quotidien.
Nous avons à notre dispos aujourd’hui beaucoup d’outils et de méthodes qui permettent de se conformer à CMMI (et même à ISO9000 !) en douceur et de manière adaptée. Il est effectivement primordial de se rappeler que CMMI ne donne qu’un cadre et que les moyens sont totallement libres.
C’est d’ailleurs pourquoi je dis "adapté" et pas agile car si pour certaines organisations les méthodes Agile peuvent convenir pour d’autres, ce n’est pas le cas et il faut trouver autre chose ou s’en inspirer.
La douce d’alchimie de l’assurance qualité…