Nous avons vu dans les deux posts précédents qu’un certain nombre de cas d’utilisation – assez fréquents – ne nécessitaient qu’un nombre restreint de métriques. Ces cas d’utilisation sont les suivants :

• Valider la livraison d’une nouvelle version de l’application (Quality Gate).
• Disposer de données objectives pour les SLAs des fournisseurs.
• Gérer les processus d’Intégration / Amélioration continue des équipes de développement.

La question posée en commentaires du premier post est la suivante : quelles sont ces 10 ou 20 métriques les plus importantes ?

Voyons tout d’abord les cas d’utilisation qui peuvent vous concerner.

Quality Gate

Processus de vérification et de validation de la qualité d’une livraison applicative.

Pourquoi ce nom de ‘Gate’ ?

Parce qu’il s’agit d’une porte entre deux phases, qui laisse passer – ou non – les délivrables de la phase antérieure à la phase suivante.

Nous rencontrerons le plus souvent deux types de Quality Gate :

• Pré-QA: inutile de perdre du temps (et donc de l’argent) en tests s’il est possible de rencontrer de manière simple et facile des défauts avec une analyse automatique du code source. Et si ces défauts sont trop nombreux, le code fait demi-tour en direction de l’équipe de projet pour qu’elle les corrige. On peut mettre en place cette Quality Gate au niveau des équipes internes (de développement ou de QA) d’un client final ou d’un provider.
• Pré-production: avec pour objectif de vérifier s’il reste des bugs. Vous voulez que vos utilisateurs rencontrent ces bugs ? Bien sûr que non: le coût est trop élevé pour votre image et celle du département informatique.

Laquelle de ces Quality Gate implémenter ? Tout dépend du contexte. Si l’application est développée en interne :

• Quality Gate pré-QA fortement recommandée.
• Quality Gate pré-production afin de vérifier que les corrections de défauts rencontrés lors de la QA n’ont pas provoquées de nouvelles ‘bad practices’.

Si l’application est développée par un provider (Outsourcing) :

• Quality Gate pré-production obligatoire.

Il est souhaitable que le provider possède sa propre QA.

Integration continue / Amélioration continue

Processus d’analyse de code au niveau des équipes de développement, afin de détecter les défauts le plus tôt possible.

Il est souhaitable d’automatiser ce processus afin d’éviter une charge de travail supplémentaire, ce qui nécessite un outillage approprié :

• Un outil de gestion de version pour la traçabilité des modifications et pouvoir construire une nouvelle version de l’application à tout moment.
• Un outil de génération de ‘build’ (compilation) de la version de l’application qui puisse lancer automatiquement une analyse de code. Nous en avons vu un exemple : Sonar – Analyse avec Jenkins.

Les bénéfices d’un tel processus sont multiples :

• Intégration continue : correction des défauts au plus tôt.
• Amélioration continue : la répétition fréquente des analyses favorise l’efficacité des équipes de projet dans le respect des bonnes pratiques de programmation et d’architecture.
• Il est beaucoup plus facile de réussir une Quality Gate.

L’équipe de projet peut présenter à l’équipe de QA un rapport avec les résultats de la dernière analyse du code source. De nouveau, selon le contexte :

• Développement interne : l’équipe de QA peut décider de passer à la phase suivante simplement en approuvant le rapport.
• Developpement externe : l’équipe de QA examine le rapport fourni par le provider. Elle peut décider qu’il reste trop de défauts et demander une nouvelle version de meilleure qualité, ce qui nécessitera d’ajuster le planning. Ou elle peut approuver le rapport et réaliser une Quality Gate dans son propre environnement.

Gérer les SLAs

Un Service Level Agreement (SLA) ou Accord de Niveau de Service est un contrat entre un fournisseur de services (SSII) et son client, ayant pour objectif de définir le niveau de qualité dudit service. La difficulté réside dans l’obtention de données fiables et objectives pour mesurer la qualité de l’application et c’est là qu’un outil d’analyse de code se révèle précieux.

Le contexte ici est uniquement d’Outsourcing. Bien sûr, il est possible d’utiliser des SLAs pour mesurer la performance d’équipes de projet internes, mais cela ne se rencontre habituellement qu’au niveau d’organisations très importantes avec de nombreuses équipes agissant en mode client-fournisseur comme SSII internes.

Un accord de niveau de service se vérifie à chaque livraison d’une version applicative avec les résultats de la Quality Gate. Le client peut choisir entre 3 différentes possibilités, normalement définies dans l’accord :

• OK : acceptation de la livraison, lorsque tous les objectifs de qualité sont atteints.
• OK avec réserves : acceptation de la livraison, mais certains objectifs n’ont pas été atteints et le fournisseur devra livrer au plus tôt une nouvelle version avec les corrections demandées. Cela arrive fréquemment, afin d’éviter tout retard dans la mise en production de l’application, mais seulement si les défauts restants sont mineurs ou n’impactent pas l’utilisateur final (nous verrons ce point avec les métriques qui accompagnent ce processus).
• KO : il reste trop de défauts dans la nouvelle version, ou ceux-ci sont trop graves. Rejet de la livraison.

Un processus de SLA est conseillé pour les clients qui travaillent avec différents fournisseurs, car il devient possible de réaliser un benchmarking de providers, avec pour conséquence de créer une certaine émulation, pour ne pas dire une franche compétition entre eux. Vous savez, pouvoir dire : « Vous êtes en dernière position dans le ranking de nos fournisseurs ». Ceci explique pourquoi qu’il n’est pas facile d’imposer quelque chose à un provider unique : dans ce cas, le client n’a que peu de poids.

Il est conseillé de mettre en marche ces 3 processus afin d’obtenir une meilleure synergie et d’en maximiser les bénéfices, mais cela dépend une nouvelle fois du contexte :

• Développement interne : intégration continue fortement recommandée, Quality Gate plus simple et moins coûteuse, pas de SLAs mais les données en matière de qualité peuvent être intégrées dans un un tableau de bord de pilotage des projets, notamment pour les grands départements informatiques.
• Outsourcing : Quality Gate indispensable et SLAs souhaitables. Il est recommandé que le provider mette en place un processus d’intégration continue au niveau de ses équipes.

Le bénéfice principal d’un outil d’analyse de code au niveau des SLAs provient des métriques de qualité, qui permettent d’objectiver et donc de faciliter la relation avec le fournisseur.

Comme tous ces processus fonctionnent ensemble, ils vont s’appuyer sur un éventail de métriques assez semblables. Nous verrons celles-ci dans notre prochain post.

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.