CMMI et Agile sont dans un (même) bateau...
De retour de formation CMMI, je partage le point de vue de QualityStreet et plus généralement ce que j'avais déjà souligné ici, à savoir que CMMI et Agile peuvent faire bon ménage et converger. Ils partagent certains fondements notamment celui d'apporter plus de valeurs au client dans une démarche d'amélioration continue alignée avec le métier.
Si le CMMI adresse le "Quoi" via les objectifs et propose bonnes pratiques et activités typiques pour y répondre, les méthodes Agiles implémentent des "Comment" alternatifs et acceptables pour le CMMI. Ce n'est pas nouveau mais je l'ai vraiment ressenti pendant ces trois jours avec des échos côté Lean, 6 sigma, RUP, Scrum ou XP.
Compatible aux niveaux de maturités 3 & 5
On trouve une littérature assez complète sur le mapping ici ou là entre pratiques Agile et objectifs CMMI, en français avec afoucal.
Le niveau de maturité 3 du CMMI est bien couvert avec des modèles comme MSF et son implémentation Agile par David Anderson ou encore Agile+.
On peut lire récemment des retours d'expérience sur le niveau de maturité 5 par Jeff Sutherland.
La revue par les pairs en Agilité?
Le mapping n'est pas suffisant pour se rendre compte de ce que la convergence implique. Je propose pour cela de faire un focus sur l'activité de revue de pairs du domaine de processus Vérification SG2 (Niveau de maturité 3)
Les revues par les pairs consistent en un examen méthodique des produits d'activité par les pairs de ceux qui les ont réalisés, afin d'identifier les défauts à éliminer et de recommander les modifications nécessaires
Et la pratique correspondante XP le binomage (Pair programming): Puisque la revue de code est une bonne pratique autant la faire en permanence!
Mais le pair programming ne se limite pas à cela: c'est aussi une séance de conception et de revue de conception continue grâce au refactoring.
Les critères de vérification et la préparation de ces revues sont constitués par les pratiques XP liées au pair programming : coding standards, simple design, métaphore, testing.
Source igan sur Flickr
En plus du pair programming, on pourrait également parler de toutes les réunions collectives qui sont autant d'occasions de revues informelles.
- Les revues de conception / estimation / planification pour l'aspect technique
- Les rétrospectives, les cercles de qualité du Kaizen pour l'aspect processus
- Et plus généralement la transparence, vis à vis de l'organisation avec le radiateur d'informations ou les daily scrum, qui créée les conditions pour des revues potentielles.
Omni présente mais est-elle suffisante?
On voit que l'on est bien armé face à cet objectif de revue par les pairs à différents niveaux.
Mais le fait de ne pas avoir de revue structurée telle que l'inspection Fagan et de la faire à l'écran, selon Watts Humphrey, ne permettrait de remonter que 20 à 40% des anomalies contrairement au 60-80% d'une revue structurée. J'ajouterais qu'en binomage on est à la fois juge et partie.
En XP, le but n'est pas de trouver des anomalies mais de ne pas en introduire en couplant cette pratique avec le TDD.
Mais la pratique, malgré son bénéfice, n'est pas suffisante pour le dispositif CMMI dans une perspective d'amélioration continue: Il faut pouvoir suivre quantitativement l'effet de ces pratiques et faire des analyses causales (5W, Ishikawa, ...) des non-conformités.
L'analyse des données de la revue de pairs par le CMMI tourne autour du rendement de la revue (pourcentage de défauts détectés), le taux de revue (page par heure) et le cout (heures passées) par défaut découvert, entre autre...
Alors quelles métriques dans une équipe XP? Le nombre de défauts non introduit dans le processus? Ou bien estimer la dette technique comme le propose récemment Martin Fowler, bref difficile à quantifier... Et à mettre en pratique?
Des pistes pour converger?
D'abord côté CMMI et plus généralement, les spécificités des équipes et projet Agiles se retrouvent dans le domaine IPPD (Integrated Product and Process Development) qui
[...] recouvre aussi l'établissement d'une vision commune du projet et l'établissement d'une structure d'équipe pour les équipes intégrées qui vont favoriser la satisfaction des objectifs du projet".
Une équipe auto-gérée Scrum/XP est une équipe intégrée avec le client sur site, les développeurs, les testeurs...
De l’autre, pour la revue de pairs, le binomage n'exclut pas une revue par les pairs formelle en fin d'itération qui, elle, peut être quantifiée avec des éléments d'actions à suivre. Cela peut avoir un sens pour une équipe en plateau de vélocité: Les analyses causales sont intéressantes sur des processus stables sans quoi le signal émis n'est pas forcément pertinent.
Cette approche quantitative/statistique est peu présente dans l'approche Agile, délibérément puisque d'un côté Lean nous rappelle de ne suivre qu'une poignée d'indicateurs qui font sens plutôt qu'une multitude de métriques qui ne servent pas: La collecte et l'analyse de ces métriques a un cout important; d'avoir un management visuel (Radiateur d'info) et des métriques orientées client (Business Value cumulée, Story points implémentées, ...) et beaucoup moins processus et organisation.
Malgré tout, on a des mesures "agiles" à suivre, les radars des rétrospectives, les enquêtes à la Yahoo sont autant d'indicateurs dans un contexte d'adoption d'un processus au niveau projet ou organisation et pour la remettre dans son contexte.
Des pistes pour s'améliorer?
Les méthodes Agiles s'adaptent et s'améliorent dans leur contexte projet de manière qualitative avec les rétrospectives, les suivis de tendances (burndown chart, vélocité). Pour dépasser ce stade projet et se répandre dans l'organisation, un suivi plus quantitatif et contextuel est donc important. Mais n'est pas suffisant, comme le note encore Watts Humphrey, et met en avant avec le CMMI le support de transition: Le framework de transition de Mike Cohn en est une bonne illustration.
Conclusion
Nous avons vu qu'une simple réflexion autour du binomage XP et des revues de pairs CMMI permet déjà de mesurer l'effort pour converger là ou il semblait que le mapping était suffisant. Que cet effort pointe du doigt la gouvernance des projets Agiles, leur contextualisation pour atteindre l'organisation elle-même, sujet d'actualité, et qui explique qu'on puisse se tourner vers le CMMI pour avancer sur cette question.
--Ajout 12/11/08
Le SEI (Software Engineering Institute) a publié aujourd'hui le papier CMMI or Agile : Why Not Embrace Both! co écrit par le SEI et David Anderson entre autres.
Ils scellent leur volonté d'être compatibles voir complémentaires en faisant un appel aux experts CMMI d'un côté et aux experts Agile de l'autre pour aller dans ce sens. Une demande de changement a été émise pour inclure l'approche et les principes Agiles dans les modèles CMMI. La machine est en marche!
-- Ajout 23/11/08
La machine n'est pas en marche pour tous dans la communauté XP France!
Messages
