Peut-on gérer sans métriques ?

points_background

Dans cette article, Bernard Homès nous présente la nécessité des métriques informatiques pour la gestion de projet.

Il répond à plusieurs questions, telles que le nombre de métrique différentes, leur pertinence, leur fréquence d’utilisation etc. pour ensuite nous expliquer comment optimiser son projet pour viser le succès.

 

 

Conduisez-vous les yeux fermés ?  Non, alors pourquoi gérez-vous sans métriques ?

Pas de métriques, pas de gestion !

 

Gérer c’est contrôler et s’organiser pour que des objectifs puissent être atteints ; c’est aussi se donner les moyens de voir clair. Avant de « voir clair », il faut pouvoir « voir ». Ceci implique des instruments pour voir et mesurer.

Envisageriez-vous de diriger un bateau sans boussole, sextant, cartes ou autre système type GPS ? C’est possible si nous naviguons à vue, mais trop risqué hors de vue des côtes. Sans informations sur votre vitesse ou votre dérive, vous ne pouvez connaître votre position et rien ne vous permet d’anticiper les récifs, les hauts fonds ou les grains.

C’est la même chose pour gérer un projet informatique ou une entreprise : pour les mener à bien nous devons mesurer l’avancement des tâches, la réalisation des livrables et leur niveau de qualité.

Combien de métriques ?

 

Devons-nous avoir les yeux rivés sur de très nombreuses métriques et les mesurer à chaque instant ? Non ! Une précision trop importante est inutile. Par contre il est nécessaire de mesurer les bonnes choses, avec la bonne fréquence.

 

Où les trouver ?

 

De nombreuses sources de métriques existent, tels que des standards comme ISO9126-2, -3 et -4, et des mesures sont proposées par des outils du marché. Restons pragmatiques, nous n’avons besoin que d’un sous-ensemble pertinent.

 

Quelle fréquence de mesure et quelle précision ?

 

Il nous faut des informations globales pour gérer le projet, même si elles ont une marge d’erreur, et il faut estimer cette marge d’erreur (est-elle d’un pourcent ou de cinquante ?).

Le rafraîchissement des mesures dépend de l’avancement du projet et de chaque tâche.

 

Quelles sont les métriques pertinentes ?

 

Gérer implique contrôler par rapport à un objectif. Donc il faut premièrement définir un objectif puis comparer l’avancement réalisé par rapport à cet objectif. Cela nécessitera le contrôle à la fois du produit et des processus qui le conçoivent. Nous ne pouvons faire l’impasse ni sur l’un ni sur l’autre.

Contrôler le produit, c’est vérifier sa complétude (respect des exigences fonctionnelles) et de son niveau de qualité (respect d’exigences non-fonctionnelles). Contrôler le projet regardera le respect des contraintes (délais et charges) et des processus (efficacité et efficience).

 

Les données à mesurer varient selon la granularité et la portée des tâches :

  • Si un projet séquentiel (cycle en V) implique l’identification en début du projet de tous les objectifs et de toutes les questions auxquelles il faudra répondre, une tâche unitaire ne peut nécessiter qu’un ensemble réduit de mesures.
  • Dans un développement agile, (Scrum ou XP) comme l’objectif est proche (par exemple : itération de 3 ou 4 semaines), le nombre de mesures peut être restreint au niveau de l’itération, même si d’autres métriques seront nécessaires au niveau du projet.

Des informations différentes selon les personnes concernées

 

Mesurer le produit répond à la question « avons-nous conçu ce qui a été demandé ? », et la réponse variera selon le point de vue du lecteur :

  • Si nous voulons informer le client, cela implique de mesurer la complétude du produit sur base d’un référentiel que le client comprend, par exemple sur base des exigences ou des fonctionnalités.
  • Si nous voulons mesurer la conception du produit, nous devrons mesurer sur la base de critères compris par les concepteurs et les développeurs, par exemple l’architecture et les éléments qui la composent, les flux et transactions qui interagissent avec le produit, etc.
  • Si nous voulons mesurer le coût du produit, nous allons devoir mesurer d’autres éléments tels que les frais de personnel, les frais de structure, la sous-traitance, les logiciels etc.

Le client

 

Informer le client sur le produit implique de comprendre ses demandes. Ceci nécessite d’évaluer les exigences, de vérifier qu’elles sont exhaustives, non ambigües et non contradictoires. Des revues et des inspections d’exigences, voire l’utilisation d’outils spécifiques permettent cela.

Une fois les exigences stabilisées, nous pouvons mesurer le produit de diverses façons :

  • Reprendre chaque exigence fonctionnelle ou non-fonctionnelle et utiliser le résultat des tests pour déterminer si l’exigence a ou non été satisfaite. Cette mesure peut permettre d’avoir un pourcentage d’avancement de la réalisation du produit, mais elle est limitée à l’exhaustivité et la pertinence des exigences. Si des exigences sont implicites, ou de criticité différente, une simple mesure quantitative n’apportera pas assez d’information.
  • Regrouper les exigences en fonctionnalités ou en caractéristiques (caractéristiques qualité, priorité ou criticité) et mesurer le pourcentage de satisfaction des exigences selon le niveau de regroupement choisi. Cette manière de faire permet de prioriser les informations selon les critères de regroupement choisis.

L’information au client dépendra du modèle de développement : elle sera périodique dans un développement séquentiel (cycle en V), alors qu’elle sera continue dans un cycle agile (via le product owner).

Les réalisateurs

 

Informer les équipes de réalisation du produit est nécessaire, surtout quand plusieurs équipes se répartissent le travail. L’information assure la coordination des activités de conception, de codage, d’intégration et de test.

Les questions seront ici focalisées sur la complétude des livrables et leur niveau de qualité. Ce dernier impacte la charge de travail pour corriger le produit et la capacité du produit livré à atteindre ses objectifs. Une mesure est le nombre de défauts selon la taille du livrable pour définir une densité de défauts. Scinder cette densité selon le niveau de criticité du défaut permettra des comparaisons intéressantes.

Des techniques éprouvées permettent d’évaluer la maturité et la qualité des livrables (ODC – Orthogonal Defect Classification, AMDEC – Analyse des Modes de Défaillances Et de leurs Criticités, etc.).

La hiérarchie

 

La hiérarchie s’intéresse principalement aux problématiques de coûts. Ceci inclut la réalisation normale, mais aussi les coûts liés aux changements d’exigences, aux corrections des livrables, etc.

Mesurer le coût total du produit inclura des éléments comme les frais de personnel, de structure, d’encadrement, de sous-traitance, les coûts liés au développement, à la maintenance et aux tests, etc.

Sur un produit, la hiérarchie s’intéressera généralement aux causes des dépenses, c’est-à-dire aux processus, mais aussi à l’efficience et à l’efficacité de ces processus.

Informations attendues sur le projet

 

Mesurer le projet revient à répondre à la question « les charges et délais sont-ils respectés ? ». Ces informations importent aux clients (délais de livraison) et à la hiérarchie (charges et effort de réalisation). L’estimation initiale servira de référence, à comparer avec l’avancement réel tout au long du projet.

Dans les projets séquentiels, une mesure des charges (utilisées et restantes) et des dérives de jalons peut suffire. La prise en compte des aléas est souvent lente vu l’obligation d’analyser leur impact sur les autres activités. Par contre, dans les projets agiles, des réunions fréquentes (mêlée quotidienne) permettent à chacun d’informer l’équipe sur les activités réalisées et restant à faire.

Estimation initiale

 

Une prévision des charges avec un niveau de précision suffisant est difficile, voire impossible. La difficulté croît avec le nombre de tâches et la durée du projet. Il peut exister des abaques et des statistiques, mais sont-elles applicables sur votre projet ?

Dans un projet séquentiel, l’incertitude est souvent importante vu le besoin d’identifier et d’estimation toutes les tâches prévues tout au long du projet. La tendance à prendre des marges de sécurité est forte.

Dans des projets Agiles, l’incertitude est réduite : la durée courte des itérations limite la complexité et les aléas de chaque itération. Cependant, les équipes Agiles doivent aussi traiter des objectifs du projet dans son ensemble.

Charge ou durée ?

 

La mesure des charges est à prendre dès le début du projet, ou de l’itération pour les projets Agiles, sur base des actions à réaliser. Au fur et à mesure de l’avancement du projet, nous pouvons mesurer le RAF (Reste à Faire) et l’ajouter au total des charges déjà dépensées pour obtenir le Coût total. La mesure de charge de travail est souvent sujette à caution, remplacée par une mesure de durée affectée à la tâche. Cette durée, incluant des interruptions (emails, réunions, etc.) est encore plus sujette à caution, mais permet de définir une date de livraison.

Optimiser

 

Mesurer la charge ne permet pas de s’assurer de l’efficacité des processus de conception. Comparer les processus (par rapport à eux-mêmes ou par rapport à d’autres) répond à la question « nos processus sont-ils efficaces et efficients, sont-ils optimisés ?

Dans un projet traditionnel, la comparaison portera sur des processus similaires d’un projet précédent. Dans un projet Agile, voire DevOps, la comparaison s’effectuera par rapport à une itération précédente du même processus.

Une comparaison des taux de succès des projets Agiles vs. Séquentiels – selon Gartner – montre que le taux de succès des projets agiles est nettement supérieur à celui des projets séquentiels. Ces chiffres suggèrent :

  • Sur les projets séquentiels (projets de durée importante) :

– Pas de mise en œuvre de politique pertinente de métriques et de mesures

– Peu de retours d’expérience et d’optimisation des processus

  • Sur les projets agiles (itérations de 3 à 4 semaines) :

– Retours sur expérience fréquents (quotidien et en fin de chaque itération)

– Mesure des résultats, de l’efficacité et de l’efficience (via les mêlées quotidiennes), et application de mesures correctives.

Nous apercevons ainsi l’intérêt de mesures et de retour d’expérience fréquents.

Viser le succès

 

Considérons le succès comme l’atteinte des objectifs qualité dans le respect des contraintes (budget et délais). Plusieurs métriques sont nécessaires, du début du projet et tout au long de celui-ci. Des mesures initiales (pour créer une référence) et périodiques (pour identifier des tendances et mesurer l’impact des améliorations) seront nécessaires. Nous devons :

  • Mesurer le niveau de qualité du produit (taux de défauts, typologie des défauts trouvés)
  • Mesurer l’efficacité et l’efficience des processus (mesure et optimisation)
  • Tirer des enseignements de ce que nous identifions.

Les informations doivent être combinées dans des dashboards simples, mis à jour automatiquement et facilement compréhensibles. Les fonctions d’export de données présentes dans la plupart des outils permettent de réduire la charge de travail des prises de mesures. Ces données peuvent ensuite facilement être intégrées dans des dashboards à partir desquels il sera possible de prendre des décisions avisées.

Et pourtant…

 

Le besoin et l’importance des mesures est connu mais n’est pas encore totalement bien rentré dans les mœurs. Selon le CHAOS report de 2015, seuls 29% des projets de développement informatique se terminent avec succès. 52% des projets dépassent soit les budgets, soit les délais ou possèdent un niveau de qualité inférieur à ce qui était prévu. 19% des projets sont purement et simplement abandonnés, entrainant une perte sèche pour les clients.

Conclusion

 

Nous retrouvons généralement chez nos clients de nombreuses métriques, mais celles-ci ne sont pas utilisées pour identifier des améliorations et leur mesure n’est pas automatisée. Nous ne trouvons que rarement des politiques de mesures complètes et cohérentes. C’est dommage. Vous pourriez confirmer – comme l’a fait Gartner – que chez vous aussi, les projets Agiles (mesurés et outillés) ont plus de succès que les projets séquentiels.

 

 

Bernard homes 2016

Bernard Homès
PDG TESSCO sas
Fondateur et ex-président du Comité Français des Tests Logiciels
bhomes@tesscogroup.com )

Bernard Homès bénéficie d’une expérience de plus de 35 ans dans le domaine de la Qualité et des Tests de logiciels.  Il a occupé différents postes clefs à dimension internationale, en Amérique du Nord et en Asie.  Depuis 2000, il exerce en qualité de Consultant Senior pour le compte d’entreprises renommées : Eurocopter, Thalès Alénia Space ou encore Orange France.  Bernard possède de nombreuses certifications en test (ISTQB CTFL, CTAL-TM, CTAL-TA, CTAL-TTA, CMAP) et en gestion des exigences (IREB et REQB), et se spécialise en systèmes-de-systèmes.

Bernard est également intervenu en dernière année du Mastère au sein de l’École des Mines de Paris et de HEC, dispense de nombreuses conférences chaque année.

Auteur de deux ouvrages sur les tests de logiciels, il s’implique au sein de nombreuses organisations professionnelles (jury de l’Académie d’experts de FT R&D, auteur et éditeur des Syllabus Avancés de l’ITQSB, membre du bureau exécutif de l’IEEE France, membre fondateur de l’Association for Software Testing aux USA, du GASQ et du CFTL).