Make it Work, Make it Right, Make it Fast

Systèmes d'information - le 1 Mai 2014 par Mathieu WEBER

Nous menons actuellement une étude pour améliorer notre application principale. Aujourd'hui l'outil n'est pas jugé satisfaisant par les utilisateurs et pourtant ils se déclarent satisfait de la couverture fonctionnelle. Les discussions ont souvent tendance à tourner autour des fonctionnalités de l'outil, mais ce n'est pas un critère suffisant pour juger de sa qualité.

Pour cela, nous avons découpé le projets en 3 axes:

  • fonctionnalités
  • qualité
  • performance

Pour chacun de ces axes, nous avons déterminé des KPI qui nous permettrons de suivre les améliorations attendues.

Fonctionnalités

Nous allons rédiger des spécifications pour les fonctionnalités clés qui sont aujourd'hui manquantes. L'indicateur de suivi est ici assez simple car il suffit de faire le ratio nbre d'item développés/nbre d'item total.

Qualité

La qualité du logiciel peut se mesurer au nombre de bugs reportés par les utilisateurs. Les bugs sont catégorisés en 3 niveaux de SLA:

  • SLA 1: Bug bloquant, à corriger "à chaud" au plus vite. Délai de résolution sous 4h.
  • SLA 2: Bug sévère, mais non bloquant. A corriger sous une semaine suivant un process d'Emergency Release
  • SLA 3: Bug mineur non bloquant. Ajouté à la liste des bugs et corrigé lors d'un release standard.

L'indicateur ici est le nombre de bug SLA 1 et SLA 2 par mois.

Performance

En plus des tests de non régression, nous allons déterminer des scénarii type couvrant les fonctionnalités clés de l'outil. A chaque scénario nous allons attribuer un délai maximum de réalisation au dessus duquel l'application sera jugée non conforme. L'idéal est de jouer 5 fois le scénario, d'enlever la valeur la plus haute et la plus basse et de faire une moyenne sur les 3 médianes.