Quels enseignements peut on tirer si l’on applique au domaine de la qualité de code les principes ITIL en matière de Capacity Management ?

Nous avons vu dans le post précédent que, selon cette approche, délivrer la Qualité dans le respect des accords de niveaux de service, des plannings et des budgets nécessitait de connaître ce que l’on a, c’est-à-dire son parc applicatif, mais également la qualité de celui-ci.

Cette connaissance basée sur des métriques quantitatives et qualitatives permet de mieux répondre aux besoins des utilisateurs, comme nous allons le voir dans ce second et dernier article de cette série.

Répondre aux nécessités des métiers

Faire plus, mieux, plus vite avec moins constitue le défi principal des équipes de projet à l’heure actuelle. Le management cherche constamment à ajuster les ressources au niveau d’activité des projets, notamment chez les outsourceurs, et il n’est pas rare de voir un ou plusieurs développeurs passer dans une autre équipe à la fin d’un projet. La connaissance du code est alors perdue, et avec elle la fiabilité dans la prévision des charges de réalisation des évolutions pour une nouvelle version.

Même lorsque les spécifications fonctionnelles sont précises, la charge d’implémentation peut varier du simple au double voire plus encore, en fonction de la taille du code, sa complexité, sa lisibilité, la difficulté avec laquelle introduire une modification sans défaut.

Connaître l’application et son état d’un point de vue quantitatif et qualitatif permet alors de définir une stratégie :

• Des changements dans cette zone qui présente des risques pour la maintenabilité ? S’il faut vraiment toucher à un de ces composants, alors prévoir de tester de manière exhaustive afin d’éviter toute régression.
• Un refactoring préalable de cette partie de l’application est nécessaire car il y a trop de code dupliqué qui va coûter beaucoup d’efforts pour implémenter les modifications demandées. Il vaut mieux réécrire certains composants plutôt que de perdre du temps à identifier toutes les portions de code copiées-collées dans lesquelles coder les évolutions. Les charges de test seront également moindres et le risque de bug également.
• Cette application est mal documentée, avec un taux de commentaires très faible, et il y a trop de nouveaux développeurs dans l’équipe. Mieux vaut prévoir quelques jours supplémentaires de découverte du code, voire de redocumentation, au début du projet. Cela pourra éviter quelques mauvaises surprises par la suite, et peut-être même pourra-t-on rattraper le temps perdu, surtout si les spécifications fonctionnelles changent en cours de projet.

Il n’est pas possible de définir un plan d’actions, un niveau de ressources nécessaires et un planning sans connaître ce que vous avez et le niveau de qualité de ce que vous avez.

Optimiser la prise de décision

Autre enseignement que l’on peut tirer de l’analogie avec le Capacity Management et que je trouve particulièrement intéressant : la faculté à orienter la demande des utilisateurs en se basant sur des données objectives.

ITIL précise bien que la gestion de l’infrastructure doit être réalisée :

• Dans le respect des accords de niveau de service, qui portent le plus souvent sur la disponibilité des ressources.
• De manière rentable : une disponibilité de 100% n’est pas l’objectif, car elle serait trop coûteuse.

Un exemple pour concrétiser cela.

Au sein d’un service marketing, les utilisateurs d’un progiciel de CRM (Customer Relationship Management) se plaignent de lenteurs et ralentissements lors des fêtes de fin d’année, époque à laquelle il est le plus utilisé, et que les SLAs ne sont pas respectés. Ils demandent donc un upgrade du serveur à la Production, et que celle-ci tienne ses engagements, sans surcoût pour eux.

Le Capacity Manager se réunit alors avec ces derniers et leur explique que la puissance disponible sur le serveur est de 8 000 MIPS, que cette puissance est insuffisante pour une disponibilité optimale pendant les deux dernières semaines de l’année, mais que seulement 6 000 MIPS sont utilisés durant les 11 mois et demi restants. Sur l’année, les accords de niveau de service sont tenus.

En se basant sur cette connaissance, il peut dés lors proposer plusieurs solutions :

• Upgrader le serveur tel que le souhaitent les utilisateurs, mais avec un surcoût correspondant aux ressources additionnelles.
• Mettre à disposition 50 semaines par an la puissance de 6 000 MIPS, ou un peu plus afin de se garder une marge de sécurité, et passer à 9 000 MIPS les 2 semaines restantes. La facture informatique sera moins élevée, même si un coût d’intervention lui sera ajouté afin de gérer cette flexibilité additionnelle.
• Une dernière solution possible : downgrader le serveur afin de ne délivrer que 6 000 MIPS durant toute l’année, au prix d’une dégradation encore plus forte des ressources pendant les fêtes de fin d’année. Cette solution pourrait s’envisager en période de restriction de budgets et/ou si les campagnes de marketing sont revues à la baisse.

En matière de développement applicatif, on part du principe que la qualité est forcément maximale, alors que les priorités vont généralement aux délais et aux budgets qui doivent être impérativement tenus. Or l’on sait bien que vite et pas cher ne riment pas avec qualité. D’autant que les délais sont le plus souvent décidés au début des projets, alors que les spécifications ne sont pas encore figées et que les charges de travail vont bien souvent fluctuer, á la hausse bien sûr.

Si cette situation survient sur un de vos projets et que vous prévoyez des retards, l’utilisation d’un outil d’analyse de code au sein d’un processus d’Intégration Continue permettra, à l’instar de ce Capacity Manager :

• De démontrer avec des mesures qualitatives (nombre de violation bloquantes, critiques, etc.) que la dette technique est contrôlée et le niveau de qualité du code se maintient.
• De justifier les délais additionnels en montrant l’évolution á la hausse des fonctionnalités implémentées dans le code, qui accroissent la complexité des développements et les exigences de test (sur ces thèmes, cf. Complexité et effort de test et La métrique ABC).
• De proposer des solutions.

Celles-ci peuvent être multiples :

• Repousser la date de livraison afin de maintenir la qualité au niveau attendu, par le contrôle de la dette technique et un plan de tests exhaustif.
• Respecter les délais mais en acceptant un risque sur la qualité et les bugs potentiels pour les utilisateurs. Un refactoring sera probablement nécessaire ultérieurement.
• Livrer une première version de l’application sans toutes les fonctionnalités attendues, mais dans les délais et avec une qualité correcte, sans risque excessif pour les utilisateurs. Une seconde version livrée dans un second temps complétera les fonctionnalités, et corrigera les erreurs éventuelles de la première version.

« Plus avec moins » ne signifie pas de produire plus de code pour moins cher, comme je vois souvent beaucoup de managers ou de clients le penser. Cela signifie d’être capable de répondre de manière satisfaisante aux demandes de plus en plus exigeantes des utilisateurs, en matière de fonctionnalités, de délais et de budgets.

Mettez en place un processus d’Intégration Continue avec un outil d’analyse de code, des Quality Gate au niveau des tests et de la production, des SLA (cf. Cas d’utilisation – Ensemble et sans heurts) et vous pourrez disposer des données objectives qui vous permettront d’offrir des stratégies alternatives à vos clients et vos managers, sur la base d’une connaissance et d’une maîtrise optimale de votre portfolio d’applications.

Comme le montre le Capacity Management selon ITIL, mieux répondre aux besoins des utilisateurs et faciliter la décision des managers nécessite des données objectives et la connaissance quantitative et qualitative des applications. Plus et mieux avec moins: délivrez la qualité dans les délais et les budgets.