Cas concret d’utilisation des métriques à Pentalog

Dans la présentation du nouvel organigramme Pentalog, nous avons annoncé la mise en place des Business Liners.
Une de leurs responsabilités consiste à décliner sur le terrain les travaux de fond sur l’amélioration des pratiques, réalisés sous l’égide de la Direction Technique et la Direction Qualité.

Régulièrement, chaque BL s’exprimera sur l’avancée de ces mises en œuvre sur le terrain.
Un premier article, réalisé par Pierre Peutin, le BL IS (Information Systems), présente ainsi les métriques appliquées sur l’un de nos projets.

D’autres sujets d’intérêt vont suivre.
Monica JIMAN
===========================

Après plusieurs mois de travaux de fond sur l’amélioration des processus d’estimation des charges, et pour donner une suite au post de Fred sur la mise en place des métriques à Pentalog, je souhaitais évoquer la généralisation de l’utilisation des métriques sur la plupart des projets Pentalog.

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 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 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 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 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, 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.

Je me suis attaché ici à montrer les premiers exemples de l’industrialisation des métriques à Pentalog en expliquant notamment comment il est possible d’accroître la productivité d’un projet. Dans un prochain post, j’expliquerai sur un autre exemple la mise en place d’un référentiel.