Vous connaissez tous CMMI, je pense ? Ce modèle développé par le Software Engineering Institute prévoit cinq niveaux de maturité afin de mesurer la qualité des services informatiques, ainsi que les bonnes pratiques associées à cette échelle de niveaux et permettant de progresser à travers celle-ci. Je ne vais pas écrire tout un post sur ce modèle, ce n’est d’ailleurs pas le sujet de cet article, mais simplement le présenter comme je pourrais le résumer à quelqu’un qui n’y connaît rien en matière de gestion de projets et de développements d’applications.

CMMI, les différent niveaux

Le modèle commence au niveau 1, où aucun processus n’est défini. C’est ce que j’appelle le niveau des champions ou encore, l’étoffe des héros, car la réussite d’un projet dépendra de la présence d’un champion, par exemple un expert des technologies employées ou un chef de projet expérimenté. Bref, d’au moins une personne, généralement connue, toujours convoitée et qui se retrouvera le plus souvent affectée aux projets prioritaires. L’échec des autres projets n’incite pas l’organisation à s’améliorer.

L’objectif du niveau 2 (« Managed » dans la terminologie CMMI) est de mettre en place des processus qui permettent justement de s’affranchir des champions et d’assurer la réussite des projets par toute équipe qui les met en œuvre. C’est ce que j’appelle ‘reproduire le succès’ indépendamment des individus.

Ces processus sont ensuite ajustés (niveau 3 « Defined »), c’est-à-dire personnalisés selon les projets, avec des boucles d’amélioration pour capitaliser sur chaque expérience et les améliorer. Le niveau 4 (« Quantitatively Managed ») implémente des métriques et des statistiques de mesure et de contrôle des processus, et ainsi poser les bases du niveau 5 (« Optimized ») dans lequel l’organisation travaille dans une optimisation constante des processus.

CMMI, le niveau zéro

J’ai toujours été surpris que le modèle commence au niveau 1, puisqu’en fait à ce niveau, il n’y a rien, aucun processus, du parfait amateurisme. Mais cela m’a permis de définir ce que j’appelle le « CMMI niveau zéro », qui colle bien à certaines organisations que j’ai pu connaître, et pour lesquelles la culture d’entreprise favorise et encourage l’émergence de champions. Au lieu de chercher à évoluer vers un niveau 2 où les « personnes indispensables » ne sont pas nécessaires à la réussite d’un projet, les managers voient au contraire d’un mauvais œil toute tentative de mise en place de processus un tant soit peu organisés, considèrent comme une perte de temps la moindre documentation permettant de reproduire les tâches de projet et d’assurer sa continuité en l’absence de « champions », voire même contribuent à mettre en place des situations inextricables et de difficulté extrême afin de prouver justement qu’ils sont de l’étoffe des héros. Genre « Changeons tout la veille afin de travailler toute la nuit et livrer demain matin dans l’urgence ».

Généralement, ces managers divisent le monde entre les winners – dont ils considèrent bien évidemment qu’ils font partie – et les loosers, ces pauvres hères faibles et capricieux qui, éventuellement savent mais généralement rechignent à travailler dans le chaos permanent généré par une hiérarchie élitiste. Ces managers ne veulent surtout pas progresser vers le haut mais bien au contraire évoluer vers le bas: un niveau CMMI zéro de la qualité, où toute idée d’amélioration est suspecte et fantaisiste.

Un modèle de maturité de la qualité logicielle

Le modèle CMMI a perdu en popularité depuis que certaines entreprises censées certifiées au plus haut niveau se sont en fait révélées incapables de délivrer un service de qualité correcte. Mais il présente selon moi l’avantage d’être logique et immédiatement compréhensible par tout le monde, et ce dans de nombreux domaines.

J’ai donc imaginé le modèle suivant que je propose aux clients qui souhaitent mesurer leur niveau de maturité en matière de qualité logicielle.

Au premier niveau, il n’existe pas de processus ou de structure de gestion de la qualité logicielle. Cela ne signifie pas qu’il n’existe pas d’initiatives dans ce domaine, mais ce sera justement le fait de quelques champions qui décident d’eux-mêmes d’installer sur leur projet un outil d’analyse de code, de contrôle de versions ou de suivi des bugs et des évolutions.

Le niveau deux se caractérise par une attitude réactive aux problèmes de qualité : l’organisation cherche à identifier les défauts logiciels, le non-respect des bonnes pratiques de programmation qui pourraient impacter les utilisateurs et mettre en danger les métiers de l’entreprise, ou occasionner des retards dans la livraison des applications et aggraver les coûts de maintenance. A ce niveau, la gestion de la qualité logicielle est généralement confiée à une structure dédiée, qui installe et gère de manière centralisée une plate-forme Qualité composée d’outils auxquels les projets peuvent éventuellement adhérer, selon des processus pas toujours très souples et souvent considérés comme contraignants. Cette équipe réalise à la demande des Quality Gates, généralement pour valider la livraison d’une version applicative par un fournisseur externe, et parfois des audits à la demande de la direction.

Le niveau trois permet de passer à une attitude proactive dans laquelle on ne se contente plus simplement d’identifier et de réagir aux défauts en matière de qualité logicielle, mais de prévenir ceux-ci, et ce le plus tôt possible lors du cycle de vie du projet. Ceci suppose un processus de Continuous Integration et généralement certaines pratiques Agile.

Au niveau quatre, les métriques de qualité sont utilisées afin de mesurer et contrôler la qualité logicielle dans tous les aspects de la gestion de projet. Les prestataires de service doivent respecter des SLAs (Service Level Agreement ou Accord de niveau de service) qui intègrent celles-ci. Des benchmarkings sont effectués afin de mesurer la qualité entre les fournisseurs et les répartir selon un classement très apprécié par les services Achats : « Monsieur, vous êtes passés de la 5ème à la 7ème place ce trimestre. Il va falloir vous ressaisir. J’attends de vous un effort ». Les directions informatiques utilisent les mesures de qualité afin de dessiner une cartographie de leur système d’information et définir une stratégie pour chaque bloc applicatif.

Au niveau cinq, les projets sont encouragés à optimiser la gestion de la Qualité par l’expérimentation de nouvelles pratiques, telles que des revues de code en binôme, le développement piloté par les tests (Test Driven Development) ou l’eXtrême Programming (XP). Les résultats sur la qualité logicielle sont mesurés et comparés afin de déterminer lesquelles de ces pratiques se révèlent les plus profitables, à court, moyen ou long terme. Des formations et des ateliers sont réalisés afin de diffuser les meilleures pratiques et d’encourager leur adoption.

Maturité et Technical Debt

La mesure de la Dette Technique peut être utilisée à tous les niveaux de ce modèle. Pas au niveau un évidemment, sauf par quelques champions qui connaissent la métaphore, mais il s’agira là encore d’initiatives isolées, et d’ailleurs pas toujours comprises par le management.

Les audits au niveau 2 peuvent s’appuyer sur une évaluation de la Dette Technique, notamment lorsque la direction hésite quand à la stratégie à adopter pour une application. Je l’utilise très fréquemment lors d’assesments, en fonction de certains critères, comme la criticité de l’application, et son alignement sur le business. Par exemple, au sein d’une même entreprise, de nouveaux métiers à forte croissance donneront naissance à des applications nouvelles pour lesquelles le time-to-market, la fiabilité et la performance seront critiques afin de se différencier de la concurrence et gagner de précieuses parts de marché. Sur les métiers plus anciens, la stratégie sera orientée sur le maintien des marges, et donc le respect des budgets informatiques : notre appréciation de la dette technique sera dés lors alignée sur la maintenabilité des applications.

Il est toujours important d’aligner la dette technique sur le business afin de répondre aux questions que se pose le management et proposer différentes stratégies et les plans d’actions associés: outsourcing de l’application, transfert vers une autre équipe interne (éventuellement composée de développeurs externes), refactoring, reengineering (voir notre série de post sur le sujet). Pour un assessment applicatif, l’évaluation de la Dette Technique constitue une véritable valeur ajoutée pour le client.

Au niveau 3, la dette technique est mesurée au quotidien, ou tout au moins de manière fréquente par l’équipe de projet, afin d’éviter au plus tôt toute inflation de la dette et de ses intérêts. La dette technique est dés lors gérée à chaque itération du projet et non pas de manière spécifique, à la fin de celui-ci (Quality Gate) ou occasionnelle (audit) comme au niveau 2.

Au niveau 4, la Dette Technique est mesurée, avec l’objectif de contenir celle-ci est de ne pas faire croître les intérêts de la dette. Ceci se traduit par des SLAs pour des fournisseurs externes. Par exemple:

• Pas de nouvelle classe de haute complexité / Pas de God class additionnelle.
• 0 défaut Blocker (KO de la Quality Gate).
• 0 défaut Critical (OK si résolu dans la prochaine release).
• La couverture de code par les tests n’a pas diminuée.
• La documentation n’a pas baissée.

Si l’on normalise les SLAs entre les différents outsourceurs, il devient possible d’effectuer les benchmarkings dont nous avons parlé auparavant. Evidemment, on pourra effectuer ces mêmes mesures au niveau des équipes internes, et répondre donc à cette question universelle des directeurs informatiques: pourquoi certaines équipes livrent leurs projets en temps et en heure et dans le respect des budgets, alors que d’autres n’y parviennent pas ?

Les mêmes mesures pourront être utilisés afin de construire une cartographie de la dette technique au niveau du portfolio d’applications (par métier). Il est possible de construire diverses sortes de représentation du portfolio selon différents axes comme par exemple :

• Treemap selon les axes Taille x Dette technique.
• Quadrant selon les axes Criticité x Dette technique.
• Représentation en cité 3D du portfolio applicatif sur les axes Complexité x Dette Technique.

Ces représentations fourniront au management de précieux éléments de décision, et croyez moi, il n’y a rien qu’une direction informatique apprécie plus que des informations permettant la décision. Je pense dédier un post spécifique à ce sujet, celui-ci est déjà trop long.

Je ne fais pas de différence importante entre le niveau 4 et le niveau 5 : on y trouvera généralement les mêmes processus, avec pour différence, au niveau 5, l’idée généralisée d’expérimenter de nouvelles méthodes qui contribue à contenir voire à réduire la dette technique, et la diffusion des pratiques couronnées de succès par des formations ou des ateliers (workshops).

Utilisation du modèle

Que les puristes de CMMI me pardonnent, mais l’on comprendra que j’utilise le modèle ci-dessus non pas comme un cadre d’implémentation de processus ou dans un but de certification, sinon comme un modèle explicatif logique et facile à comprendre. D’ailleurs, je considère qu’il est possible de mixer les niveaux, c’est-à-dire d’avoir certaines équipes au niveau 1 et d’autres au niveau 3, au sein d’une même organisation.

Par exemple, il m’arrive souvent de rencontrer des entreprises (ou des services publics) que l’on pourrait considérer au niveau 2 de ce modèle de maturité avec une gestion de la Qualité sous la responsabilité d’une structure spécifique. Parce qu’elle est centralisée, la gestion de la Qualité n’est pas toujours présente dans les projets. Et en même temps, j’ai vu des cas dans lesquels certaines équipes mettaient en place leurs propres outils et processus, indépendamment de la cellule Qualité, ce qui aboutit généralement à ce que celle-ci se retrouve isolée, pour ne pas dire inemployée.

Autre utilité de ce modèle : il favorise l’implication de la hiérarchie, de plus en plus importante au fur et à mesure que l’on progresse à travers les niveaux. Vous pouvez très bien avoir certaines équipes aux niveaux 2 ou 3, mais en l’absence de processus supportés par la direction, vous resterez toujours bloqués au niveau 1, avec simplement quelques équipes de « champions ».

Autre avantage – et dernier point en guise de conclusion de ce post : le modèle montre bien que la Qualité vient du bas et se répand par le haut dans l’organisation. Pour atteindre le niveau 4 où les mesures de qualité et de la dette technique sont utilisées par le management comme éléments de décision stratégique, il faut d’abord que ces mesures soient effectuées au sein des projets internes ou par les fournisseurs externes. Or, la Qualité ne se décrète pas. Même si la direction se montre volontaire et motrice dans la mise en place de programmes de gestion de la Qualité, il faudra cependant emporter l’adhésion des équipes, souvent réticentes face à des initiatives qu’elles jugent destinées à les contrôler ou à mesurer leur productivité selon des règles peu claires voire arbitraires.

C’est là que la dette technique, parce qu’elle est objective et mesurable, se révèle un outil précieux. La mesure de la dette technique est implémentée aujourd’hui sur de nombreux projets, grâce d’ailleurs aux outils d’analyse de code qui la supportent. Les méthodes Agile, également de plus en plus présentes, favorisent son adoption et son utilisation. Deux ingrédients indispensables pour la réussite des projets et une recette gagnante pour le management.

Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.