Facebook EmaiInACirclel
Développement front-end, back-end

Cas concret d’utilisation des métriques à Pentalog

Pierre Peutin
Pierre Peutin
Chief Data Officer et Consultant en SI comptable et financier

Après plusieurs mois de travaux de fond sur l’amélioration des processus d’estimation des charges je souhaitais évoquer la généralisation de l’utilisation des métriques sur la plupart des projets IT de la SSII Pentalog et comment il est possible d’accroître la productivité d’un projet IT.

Avant de passer à l’exemple, je vais faire un bref rappel sur la philosophie des métriques.
Un métrique est un indicateur d’avancement ou de qualité des développements logiciels. Je vais m’attacher plus précisément ici à définir l’utilisation des métriques pour mesurer et comparer les temps de développements. Pour cela, la première étape est la décomposition d’un projet IT en exigences puis un découpage de chacune de ces exigences en unités d’œuvres. Chaque unité d’œuvre appartient à un type (simple, moyen, complexe par exemple) et se définie par l’attribution d’un certain nombre de caractéristiques. En classant ces unités d’œuvres, il est alors possible d’attribuer une charge qui se chiffre en nombre de jour de développement (ou en nombre d’heure, cela dépend de la granularité choisie).
Si l’on prend l’exemple d’un formulaire, les caractéristiques pourraient être le nombre de zones de saisie, le nombre de liste déroulante, le fait ou non d’avoir une image, la complexité des actions liées aux différents boutons, etc.
Cette première étape de définition permet d’avoir un référentiel pour le projet.

Après avoir défini le référentiel, qui est en général utilisé dans un premier temps pour accélérer et uniformiser les estimations, il faut valider les charges attachées à chaque unité d’œuvre en la corrélant avec le temps réellement passé lors du développement de chaque exigence. Je souligne au passage que le référentiel permet également d’avoir une totale transparence des temps pour les développements et le client.
 

Lorsque le référentiel a atteint une certaine maturité (équivalence entre les charges des unités d’œuvres et les temps passés lors des développements), il est alors possible de mesurer la productivité et donc de mettre en place des objectifs pour améliorer les performances de l’équipe de développement. L’idée ici est de baisser progressivement les charges des unités d’œuvres dans le référentiel pour accroître la vitesse de développement. C’est précisément ce processus que je vais vous présenter ci-dessous.

Le projet IT dont il est question dans cet exemple est le développement d’une solution de gestion de points de vente pour l’un de nos clients français. Le développement est réalisé par 5 équipes réparties sur 3 sites Offshore Pentalog (Roumanie, République de Moldavie et Vietnam) et compte 40 collaborateurs.

Pour ce projet IT de plus de 6000 jours hommes pour 2009 réalisé selon la méthode SCRUM (méthode AGILE), l’utilisation des métriques est destinée avant tout à améliorer la productivité des développements en augmentant le nombre d’exigences contenues dans chaque Sprint; le référentiel ayant été fourni en début de projet par le client.

La travail du chef de projet IT consiste donc à analyser à chaque fin de Sprint les unités d’œuvres pour ajuster les charges de développement (en augmentant la charge au début pour respecter le contenu des Sprints puis en la diminuant lorsque l’équipe a atteint sa vitesse de croisière pour améliorer la productivité). Le fait d’avoir ce référentiel commun permet également de mesurer précisément la performance de chaque équipe et d’ajuster le management en continue.

Sur le schéma ci-dessous qui est issue de ce projet IT, le chef de projet a mis en comparaison les résultats obtenus sur le développement des interfaces par chacune des 5 équipes pour voir celles qui sont les plus performantes et celles qui le sont moins. L’idée étant ici de lisser les performances de toutes les équipes d’abord sur celle qui est la plus rapide puis sur les temps du référentiel.
 

En analysant ce graphique, on remarque une disparité sur les temps de développement entre toutes les équipes. Le chef de projet s’est donc attelé à prendre les mesures nécessaires pour uniformiser les temps de toutes équipes.

Après avoir amener toutes les équipes au même niveau de développement, le chef de projet pourra s’atteler à améliorer la productivité en réduisant progressivement les charges de chaque type.


Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.