La traduction officielle en français de CMMI-DEV de quelques 608 pages est disponible sur le site du SEI (Software Engineering Institute). Bravo pour l’effort de traduction. Je n’ai pas résisté au plaisir de vous faire découvrir CMMI. Notez qu’à la fin de cet article vous serez convaincu que c’est un mal nécessaire pour structurer une entreprise, mais que ce n’est pas une solution à adopter sans recul et sans prendre en compte les dernières recherches en gestion du développement informatique.
CMMI-DEV est un ensemble de pratiques destinées à améliorer les processus d’une entreprise dans le cadre du développement, de l’exploitation et du support d’un logiciel informatique. Basé sur une échelle de 1 à 5, 5 étant le niveau le plus avancé de l’utilisation des recommandations de CMMI (Capacity Model Maturity), c’est un système de qualité de plus en plus examiné par les responsables informatiques. Une entreprise certifiée CMMI 3 par exemple met en place un ensemble de structuration et de techniques afin de couvrir l’ensemble de la chaîne de production d’un logiciel. Cela va de la capture du besoin, de la définition de critères de qualité, aux méthodes de recettes, en passant par la production.
CMMI n’est pas une méthode de développement de logiciel. Ce n’est pas non plus une méthode qui vous apporte des techniques de génie logiciel comme XP. C’est un cadre de pratiques en vue d’améliorer les processus métiers de votre service informatique, du développeur à la production en passant par l’équipe qualité. Si vous ne voyez pas la nuance, je vous propose de vous plonger dans l’excellente FAQ de CMMI en anglais.
De plus, c’est un modèle vers lequel il faut tendre (d’où ces niveaux de 1 à 5) mais il faut bien entendu prendre en compte le contexte de votre métier.
Les 5 niveaux du classement CMMI sont (article de Wikipedia)
* Initial (niveau de maturité 1) : Il n’y a pas de grand pilier directionnel, aucune façon de faire ou standard ne sont établis (ou bien ils sont documentés mais ne sont pas utilisés), tout doit être fait. Il n’y a pas de surveillance (monitoring), aucune évaluation de performance et la communication est absente. Les faiblesses ne sont pas identifiées et les employés ne sont pas au courant de leurs responsabilités de façon définie et absolue. Les réactions aux incidents se font en mode urgence, sans identification claire des priorités. À ce niveau les solutions ainsi que les projets sont décidés, développés et instaurés par un individu. Les compétences et les ressources propres de cet individu sont la raison du succès ou de l’échec du projet (par dérision, ce niveau est aussi nommé héroïque ou chaotique). Il n’y a pas de description du niveau de maturité 1 dans le modèle.
* Discipliné (niveau de maturité 2) : Une discipline est établie pour chaque projet et se matérialise essentiellement par des plans de projet (plan de développement, d’assurance qualité, de gestion de configuration …). Le chef de projet a une forte responsabilité dans le niveau 2 : il doit définir, documenter, appliquer et maintenir à jour ses plans. D’un projet à l’autre, il capitalise et améliore ses pratiques de gestion de projet et d’ingénierie.
* Ajusté (niveau de maturité 3) : Ce niveau est caractérisé par une standardisation adéquate des pratiques, une capitalisation centralisée (en particulier sur les mesures réalisées dans les projets) et une maîtrise du référentiel interne (ou Système Qualité). Il existe des lignes directrices, un plan stratégique et une planification de l’amélioration de processus pour le futur, en ligne avec les objectifs d’affaire de l’organisation. Les employés sont formés et conscients de leurs responsabilités ainsi que de leurs devoirs.
* Géré quantitativement (niveau de maturité 4) : Les projets sont pilotés sur la base d’objectifs quantitatifs de qualité produit et processus. La capabilité des activités (ou sous-processus) critiques est déterminée par l’organisation, ainsi que les modèles de performance et de prédiction associés. L’expression de la qualité demandée par le client est prise en compte pour quantifier les objectifs du projet et établir des plans selon la capacité des processus de l’organisation.
* En optimisation (niveau de maturité 5) : Les processus qui sont gérés quantitativement pour le pilotage de projet (niveau de maturité 4) sont en optimisation constante afin d’anticiper les évolutions prévues (besoins clients, nouvelles technologies…).
[Fin de la citation de l’article de Wikipedia]
De ce que j’ai lu, CMMI n’est pas non plus une méthode de gestion de projet. C’est une démarche qui permet de faire monter en compétence une entreprise afin d’atteindre une maturité suffisante pour réaliser avec succès ses projets. Pour cela CMMI s’attache à proposer des moyens pour structurer tout un département. Il s’agit donc d’un road-book qui vous accompagne pour créer une équipe assurance qualité, une équipe support, une équipe de production ou une équipe de la gestion du risque. La structuration d’une entreprise ou d’un service avec des standards reconnus doit logiquement apporter une meilleur qualité ou réussite des projets.
Bien que CMMI soit formalisé depuis presque 10 ans, il n’y a pas de mentions de cycle itératif ou de livraison par lot. Michel VOLLE qui a fait une lecture et un commentaire vraiment intéressant sur CMMI dit ainsi sur son site:
On ne trouve pas dans CMMI la recommandation de découper la livraison en lots exploitables pour éviter l’« effet tunnel » et tirer parti, en cours de réalisation, des indications fournies par de premiers utilisateurs. CMMI ne met pas en garde non plus contre les difficultés logistiques que comporte l’organisation des réunions avec des parties prenantes qui ont d’autres priorités.
Au niveau de maturité 3, CMMI dans la partie perfectionnement de projet renforce l’idée que la spécification fonctionnelle, puis technique avant l’implémentation apporte une meilleur qualité. Quelle perte d’énergie. Qui croit encore qu’un document formalisé, qui plus est non contractuel, est une garantie de réussite ? Depuis quand un document Word dans un processus de développement informatique serait le Saint-Graal de la réussite des projets ?
[…]CMMI dit que les spécifications doivent être validées, mais il n’indique pas qui doit faire cette validation. S’il s’agit de s’assurer que les spécifications répondent bien aux besoins des utilisateurs la responsabilité de leur validation appartiendra à la maîtrise d’ouvrage (à l’exception de la solution technique, qui relève de la maîtrise d’œuvre). L’expérience montre combien il est difficile de présenter les spécifications de telle sorte que l’on puisse obtenir, de la part de la maîtrise d’ouvrage, une validation authentique (c’est-à-dire une validation qui engage véritablement son expertise professionnelle et sa responsabilité).
On ne voit pas apparaître dans CMMI les étapes de modélisation (MCD ou UML) pourtant nécessaire pour assurer la qualité sémantique des données et des référentiels ; les revues de pairs (peer reviews) sont, étrangement, mentionnées après la livraison du produit alors qu’elles sont surtout utiles lors de la conception de la solution.
(extrait du site de M.VOLLE)
Scrum et CMMI ?
Scrum est un outil léger et simple qui permet de maximiser le canal de communication entre le responsable du produit et l’équipe de développement (Eric Mignot). C’est donc une méthode de gestion de projet adaptée pour livrer par itération une quantité de travail (l’incrément) prêt à fonctionner et parfaitement fonctionnel. On reproche à Scrum de ne pas avoir de pratiques logiciels. En effet ce n’est pas une méthode de développement. Sur le terrain, les équipes de développement utilisent souvent l’eXtreme Programming (XP) pour renforcer la qualité et la communication au sein de l’équipe. Scrum est un outil qui permet de s’assurer que l’équipe développe et livre régulièrement les fonctions les plus importantes d’un projet. Cela permet au responsable produit d’intégrer régulièrement les demandes de changement. C’est donc une méthode de communication entre l’équipe et le client.
Je placerai CMMI sur un plan plus large, au niveau de l’organisation d’une entreprise, voire d’un service. Les pratiques de CMMI sont des repères pour structurer dans le temps une organisation. Sachez qu’il faut entre 20 et 30 mois pour passer d’un niveau CMMI 2 à un niveau 3 par exemple ) (référence: paragraphe Les cinq niveaux de CMMI du document de M.VOLLE).
Si quelqu’un vous dit un jour que « vous devriez faire du ci-aime-aime-aie au lieu de Scrum » je vous autorise à rigoler très fort et à lui faire suivre ce lien.
On se marra à plusieurs.
Références:
Article de M.Volle analyse de CMMI
La FAQ en anglais à propos de CMMI
http://blog.xebia.fr/2007/09/17/revue-de-presse-xebia-23/#AMagicPotionforCodeWarriors
CMMI® or Agile: Why Not Embrace Both! une approche qui montre que l’Agile et CMMI sont amenés à travailler ensemble (10 pages)
Hallucinant les publicités Google ciblées sur CMMI affichées juste à côté… la poule aux oeufs d’or pour les consultants ?
On vient de publier un article sur cmmi et méthodes agiles. Ca se passe par ici : http://blog.octo.com/synergies-entre-cmmi-et-les-methodes-agiles/