{"id":2498,"date":"2015-12-06T13:03:32","date_gmt":"2015-12-06T12:03:32","guid":{"rendered":"http:\/\/qualilogy.com\/fr\/?p=2498"},"modified":"2015-12-07T09:42:57","modified_gmt":"2015-12-07T08:42:57","slug":"software-quality-maturity-model-technical-debt","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/fr\/software-quality-maturity-model-technical-debt\/","title":{"rendered":"Software Quality Maturity Model & Technical Debt"},"content":{"rendered":"

\"Software<\/a>Vous connaissez tous CMMI, je pense ? Ce mod\u00e8le d\u00e9velopp\u00e9 par le Software Engineering Institute pr\u00e9voit cinq niveaux de maturit\u00e9 afin de mesurer la qualit\u00e9 des services informatiques, ainsi que les bonnes pratiques associ\u00e9es \u00e0 cette \u00e9chelle de niveaux et permettant de progresser \u00e0 travers celle-ci. Je ne vais pas \u00e9crire tout un post sur ce mod\u00e8le, ce n’est d’ailleurs pas le sujet de cet article, mais simplement le pr\u00e9senter comme je pourrais le r\u00e9sumer \u00e0 quelqu’un qui n’y conna\u00eet rien en mati\u00e8re de gestion de projets et de d\u00e9veloppements d’applications. <\/p>\n

CMMI, les diff\u00e9rent niveaux<\/h2>\n

Le mod\u00e8le commence au niveau 1, o\u00f9 aucun processus n’est d\u00e9fini. C’est ce que j’appelle le niveau des champions ou encore, l’\u00e9toffe des h\u00e9ros, car la r\u00e9ussite d’un projet d\u00e9pendra de la pr\u00e9sence d’un champion, par exemple un expert des technologies employ\u00e9es ou un chef de projet exp\u00e9riment\u00e9. Bref, d’au moins une personne, g\u00e9n\u00e9ralement connue, toujours convoit\u00e9e et qui se retrouvera le plus souvent affect\u00e9e aux projets prioritaires. L’\u00e9chec des autres projets n’incite pas l’organisation \u00e0 s’am\u00e9liorer.<\/p>\n

L’objectif du niveau 2 (\u00ab\u00a0Managed\u00a0\u00bb dans la terminologie CMMI) est de mettre en place des processus qui permettent justement de s’affranchir des champions et d’assurer la r\u00e9ussite des projets par toute \u00e9quipe qui les met en \u0153uvre. C’est ce que j’appelle ‘reproduire le succ\u00e8s’ ind\u00e9pendamment des individus.<\/p>\n

Ces processus sont ensuite ajust\u00e9s (niveau 3 \u00ab\u00a0Defined\u00a0\u00bb), c’est-\u00e0-dire personnalis\u00e9s selon les projets, avec des boucles d’am\u00e9lioration pour capitaliser sur chaque exp\u00e9rience et les am\u00e9liorer. Le niveau 4 (\u00ab\u00a0Quantitatively Managed\u00a0\u00bb) impl\u00e9mente des m\u00e9triques et des statistiques de mesure et de contr\u00f4le des processus, et ainsi poser les bases du niveau 5 (\u00ab\u00a0Optimized\u00a0\u00bb) dans lequel l’organisation travaille dans une optimisation constante des processus.<\/p>\n

CMMI, le niveau z\u00e9ro<\/h2>\n

J’ai toujours \u00e9t\u00e9 surpris que le mod\u00e8le commence au niveau 1, puisqu’en fait \u00e0 ce niveau, il n’y a rien, aucun processus, du parfait amateurisme. Mais cela m’a permis de d\u00e9finir ce que j’appelle le \u00ab\u00a0CMMI niveau z\u00e9ro\u00a0\u00bb, qui colle bien \u00e0 certaines organisations que j’ai pu conna\u00eetre, et pour lesquelles la culture d’entreprise favorise et encourage l’\u00e9mergence de champions. Au lieu de chercher \u00e0 \u00e9voluer vers un niveau 2 o\u00f9 les \u00ab\u00a0personnes indispensables\u00a0\u00bb ne sont pas n\u00e9cessaires \u00e0 la r\u00e9ussite d’un projet, les managers voient au contraire d’un mauvais \u0153il toute tentative de mise en place de processus un tant soit peu organis\u00e9s, consid\u00e8rent comme une perte de temps la moindre documentation permettant de reproduire les t\u00e2ches de projet et d’assurer sa continuit\u00e9 en l’absence de \u00ab\u00a0champions\u00a0\u00bb, voire m\u00eame contribuent \u00e0 mettre en place des situations inextricables et de difficult\u00e9 extr\u00eame afin de prouver justement qu’ils sont de l’\u00e9toffe des h\u00e9ros. Genre \u00ab\u00a0Changeons tout la veille afin de travailler toute la nuit et livrer demain matin dans l’urgence\u00a0\u00bb.<\/p>\n

G\u00e9n\u00e9ralement, ces managers divisent le monde entre les winners – dont ils consid\u00e8rent bien \u00e9videmment qu’ils font partie – et les loosers, ces pauvres h\u00e8res faibles et capricieux qui, \u00e9ventuellement savent mais g\u00e9n\u00e9ralement rechignent \u00e0 travailler dans le chaos permanent g\u00e9n\u00e9r\u00e9 par une hi\u00e9rarchie \u00e9litiste. Ces managers ne veulent surtout pas progresser vers le haut mais bien au contraire \u00e9voluer vers le bas: un niveau CMMI z\u00e9ro de la qualit\u00e9, o\u00f9 toute id\u00e9e d’am\u00e9lioration est suspecte et fantaisiste.<\/p>\n

Un mod\u00e8le de maturit\u00e9 de la qualit\u00e9 logicielle<\/h2>\n

Le mod\u00e8le CMMI a perdu en popularit\u00e9 depuis que certaines entreprises cens\u00e9es certifi\u00e9es au plus haut niveau se sont en fait r\u00e9v\u00e9l\u00e9es incapables de d\u00e9livrer un service de qualit\u00e9 correcte. Mais il pr\u00e9sente selon moi l’avantage d’\u00eatre logique et imm\u00e9diatement compr\u00e9hensible par tout le monde, et ce dans de nombreux domaines.<\/p>\n

J’ai donc imagin\u00e9 le mod\u00e8le suivant<\/a> que je propose aux clients qui souhaitent mesurer leur niveau de maturit\u00e9 en mati\u00e8re de qualit\u00e9 logicielle.<\/p>\n

\"Qualilogy_Software_Quality_Maturity_Model\"<\/a><\/p>\n

Au premier niveau, il n’existe pas de processus ou de structure de gestion de la qualit\u00e9 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\u00e9cident d’eux-m\u00eames d’installer sur leur projet un outil d’analyse de code, de contr\u00f4le de versions ou de suivi des bugs et des \u00e9volutions.<\/p>\n

Le niveau deux se caract\u00e9rise par une attitude r\u00e9active aux probl\u00e8mes de qualit\u00e9 : l’organisation cherche \u00e0 identifier les d\u00e9fauts logiciels, le non-respect des bonnes pratiques de programmation qui pourraient impacter les utilisateurs et mettre en danger les m\u00e9tiers de l’entreprise, ou occasionner des retards dans la livraison des applications et aggraver les co\u00fbts de maintenance. A ce niveau, la gestion de la qualit\u00e9 logicielle est g\u00e9n\u00e9ralement confi\u00e9e \u00e0 une structure d\u00e9di\u00e9e, qui installe et g\u00e8re de mani\u00e8re centralis\u00e9e une plate-forme Qualit\u00e9 compos\u00e9e d’outils auxquels les projets peuvent \u00e9ventuellement adh\u00e9rer, selon des processus pas toujours tr\u00e8s souples et souvent consid\u00e9r\u00e9s comme contraignants. Cette \u00e9quipe r\u00e9alise \u00e0 la demande des Quality Gates, g\u00e9n\u00e9ralement pour valider la livraison d’une version applicative par un fournisseur externe, et parfois des audits \u00e0 la demande de la direction.<\/p>\n

Le niveau trois permet de passer \u00e0 une attitude proactive dans laquelle on ne se contente plus simplement d’identifier et de r\u00e9agir aux d\u00e9fauts en mati\u00e8re de qualit\u00e9 logicielle, mais de pr\u00e9venir ceux-ci, et ce le plus t\u00f4t possible lors du cycle de vie du projet. Ceci suppose un processus de Continuous Integration et g\u00e9n\u00e9ralement certaines pratiques Agile.<\/p>\n

Au niveau quatre, les m\u00e9triques de qualit\u00e9 sont utilis\u00e9es afin de mesurer et contr\u00f4ler la qualit\u00e9 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\u00e8grent celles-ci. Des benchmarkings sont effectu\u00e9s afin de mesurer la qualit\u00e9 entre les fournisseurs et les r\u00e9partir selon un classement tr\u00e8s appr\u00e9ci\u00e9 par les services Achats : \u00ab\u00a0Monsieur, vous \u00eates pass\u00e9s de la 5\u00e8me \u00e0 la 7\u00e8me place ce trimestre. Il va falloir vous ressaisir. J’attends de vous un effort\u00a0\u00bb. Les directions informatiques utilisent les mesures de qualit\u00e9 afin de dessiner une cartographie de leur syst\u00e8me d’information et d\u00e9finir une strat\u00e9gie pour chaque bloc applicatif.<\/p>\n

Au niveau cinq, les projets sont encourag\u00e9s \u00e0 optimiser la gestion de la Qualit\u00e9 par l’exp\u00e9rimentation de nouvelles pratiques, telles que des revues de code en bin\u00f4me, le d\u00e9veloppement pilot\u00e9 par les tests (Test Driven Development) ou l’eXtr\u00eame Programming (XP). Les r\u00e9sultats sur la qualit\u00e9 logicielle sont mesur\u00e9s et compar\u00e9s afin de d\u00e9terminer lesquelles de ces pratiques se r\u00e9v\u00e8lent les plus profitables, \u00e0 court, moyen ou long terme. Des formations et des ateliers sont r\u00e9alis\u00e9s afin de diffuser les meilleures pratiques et d’encourager leur adoption.<\/p>\n

Maturit\u00e9 et Technical Debt<\/h2>\n

La mesure de la Dette Technique peut \u00eatre utilis\u00e9e \u00e0 tous les niveaux de ce mod\u00e8le. Pas au niveau un \u00e9videmment, sauf par quelques champions qui connaissent la m\u00e9taphore, mais il s’agira l\u00e0 encore d’initiatives isol\u00e9es, et d’ailleurs pas toujours comprises par le management.<\/p>\n

Les audits au niveau 2 peuvent s’appuyer sur une \u00e9valuation de la Dette Technique, notamment lorsque la direction h\u00e9site quand \u00e0 la strat\u00e9gie \u00e0 adopter pour une application. Je l’utilise tr\u00e8s fr\u00e9quemment lors d’assesments, en fonction de certains crit\u00e8res, comme la criticit\u00e9 de l’application, et son alignement sur le business. Par exemple, au sein d’une m\u00eame entreprise, de nouveaux m\u00e9tiers \u00e0 forte croissance donneront naissance \u00e0 des applications nouvelles pour lesquelles le time-to-market, la fiabilit\u00e9 et la performance seront critiques afin de se diff\u00e9rencier de la concurrence et gagner de pr\u00e9cieuses parts de march\u00e9. Sur les m\u00e9tiers plus anciens, la strat\u00e9gie sera orient\u00e9e sur le maintien des marges, et donc le respect des budgets informatiques : notre appr\u00e9ciation de la dette technique sera d\u00e9s lors align\u00e9e sur la maintenabilit\u00e9 des applications.<\/p>\n

Il est toujours important d’aligner la dette technique sur le business afin de r\u00e9pondre aux questions que se pose le management et proposer diff\u00e9rentes strat\u00e9gies et les plans d’actions associ\u00e9s: outsourcing de l’application, transfert vers une autre \u00e9quipe interne (\u00e9ventuellement compos\u00e9e de d\u00e9veloppeurs externes), refactoring, reengineering (voir notre s\u00e9rie de post sur le sujet<\/a>). Pour un assessment applicatif, l’\u00e9valuation de la Dette Technique constitue une v\u00e9ritable valeur ajout\u00e9e pour le client.<\/p>\n

Au niveau 3, la dette technique est mesur\u00e9e au quotidien, ou tout au moins de mani\u00e8re fr\u00e9quente par l’\u00e9quipe de projet, afin d’\u00e9viter au plus t\u00f4t toute inflation de la dette et de ses int\u00e9r\u00eats. La dette technique est d\u00e9s lors g\u00e9r\u00e9e \u00e0 chaque it\u00e9ration du projet et non pas de mani\u00e8re sp\u00e9cifique, \u00e0 la fin de celui-ci (Quality Gate) ou occasionnelle (audit) comme au niveau 2.<\/p>\n

Au niveau 4, la Dette Technique est mesur\u00e9e, avec l’objectif de contenir celle-ci est de ne pas faire cro\u00eetre les int\u00e9r\u00eats de la dette. Ceci se traduit par des SLAs pour des fournisseurs externes. Par exemple:<\/p>\n