Coma Informatique

La mise en place d’eXtreme Programming se fait petit à petit, quand une question apparaît fondamentale :

Et comment va-t-on faire avec la partie variable de la rémunération quand on aura mis en place eXtreme Programming ?

Lorsque l’un des développeurs pose la question, ce n’est pas innocent. Le système en place avant XP ne donne pas vraiment satisfaction.

Mais pourquoi un variable ?

Afin de motiver l’équipe, la direction a souhaité que tous les salariés ait une partie de rémunération variable sur objectif personnels payé chaque trimestre. Évidement pour certains métier commerciaux le calcul est assez simple, mais pour les développeurs c’est plus difficile. La méthode utilisé consiste à définir en début de trimestre entre 3 et 5 objectifs et le nombre d’objectifs atteints permet de calculer le taux de rémunération.

Le problème de cette méthode est qu’elle ne tient pas compte de la qualité produite, et surtout qu’elle impose un rythme trimestriel pour la planification. Ce qui fait que tout changement d’objectif en cours de trimestre entraînait une renégotiation quelque fois difficile des objectifs personnels. Et évidement l’objectif de livraison en fin de trimestre entraînait quelquefois un travail bâclé, au détriment de la qualité. Sans compter que le débuggage n’étant jamais un objectif, les problèmes clients n’étaient pas traité prioritairement de façon naturelle.

Si il y avait un consensus sur le fait que la méthode en place ne donnait pas de bons résultats, les solutions de faisaient pas l’unanimité.

Évidement les développeurs (et le marketing produit d’ailleurs) étaient partisans de la réintégration de la partie variable dans leurs salaire fixe. C’est à dire donner 100 % de variable automatiquement. Par contre, naturellement, la direction ne souhaitait pas se passer de cet outil de management, même si quelquefois l’évaluation de la partie variable était souvent le théâtre de sombre négociation qui ne devraient pas avoir lieu avec une méthode de calcul plus scientifique (comme le chiffre d’affaire ou le profit généré grâce à un commercial, par exemple).

Sortons nos métriques

Notre CTO, en bon scientifique, se dit qu’il doit définir une métrique dont le calcul soit sinon simple, du moins incontestable. Et que la partie variable des développeurs ne sera calculé qu’a partir cette métrique.

Lorsqu’on décide d’une métrique, il convient d’éviter d’utiliser des éléments dont la manipulation serait trop aisé. Par exemple si on choisit de mesurer le nombre de ligne de code écrit, on verra comme par hasard le nombre de ligne de code inutile augmenté. Et si on mesure le nombre d’intervention dans le gestionnaire de source (qu’on appelle quelquefois l’activité), très vite le nombre de réintégration augmentera sans que la quantité de travail réelle ne change vraiment. Je ne dis pas que suivre ces chiffres est inintéressant, au contraire, mais si les développeurs savent qu’ils sont utilisés pour calculer leur rémunération, ils seront naturellement tentés de modifier leur comportement pour les améliorer.

L’objectif ne sera pas de mesurer la quantité de code produit, mais plutôt de rémunérer les développeurs en fonction

• Du respect des procédures et de la qualité du code produit.
• De leur capacité à fournir du feedback sur leur avancement.
• De leur respect des engagements de délais.

Reste à déterminer une méthode pour mesurer cela.

Le principe

Lors du planning game le temps nécessaire à réaliser chaque scénario est discuté jusqu’à obtenir un consensus entre les développeurs et le client. Un seul responsable est nommé pour un scénario. Charge à lui de trouver un binôme (ou de travailler seul).

S’il s’avère que le chiffrage était trop optimiste, et que le responsable peut justifier cela, un nouveau chiffrage sera accepté. Par contre cette réévaluation ne peut avoir lieu qu’une fois pour une tache, et seulement avant la moitié du temps prévu initialement. Le but est de favoriser le feedback en cas de problème de retard tout en évitant les retard glissants.

A la fin de la tache, et seulement si elle est validé par le client, chaque développeur impliqué obtient un score correspondant au chiffrage éventuellement réévalué de la tache. Le responsable a un bonus de 20 % s’il a travaillé en binôme. Le deuxième développeur du binôme ne perçoit que 80 % du total. Ainsi le fait de travailler en binôme pour un responsable sera mieux rémunéré (20 %) que s’il travaille seul.

Pour éviter que les même développeurs qui soient toujours responsable, les développeurs ayant reçut les plus mauvais scores seront prioritaire dans le choix des tâches de développement.

Une correction de bug ne sera considéré comme une tâche rémunéré que si elle n’est pas lié à un développement de mauvais qualité. Évidement ce point fera l’objet d’une négociation entre développeurs et client. Ceci limite les livraisons dont la qualité n’est pas considérer comme bonne par le binôme.

A la fin d’un trimestre, le pourcentage de la rémunération sera le rapport de la somme du poids des tâches réalisées par 80% des jours travaillés.

Si un développeur a travaillé plus vite que prévu, il pourrait dépasse 100 % de rémunération. Évidemment si cela est systématique la négociation lors du planning game deviendra plus difficile. D’autre part la rémunération sera limité à 120 % pour éviter les abus. Par expérience le taux n’a pas souvent dépassé 100 % car sur un trimestre on ne peut pas systématiquement surévaluer ses chiffrages.

Pour les mathématiciens, la formule est donc :

Taux de rémunération = (NJCTR comme responsable * 1.2 + NJCTR comme binôme * 0.8 + NJCTR seul) / (NJT * 0.8)

   NJCTR : nombre de jours de chiffrage des taches réalisé (éventuellement révisé).
   NJT : nombre de jours travaillé (on enlève les congés).

Les résultats

Malgré quelques craintes, le système n’a pas été contourné. Les chiffrages sont restés honnêtes. Les résultats ont souvent été cohérent avec les niveaux relatifs des développeurs. Les mauvais score ont souvent été lié au phénomène de fuite en avant sur une tache qu’on n’arrive pas à finir. Mais sur un trimestre et avec des taches de quelques jours on évite ainsi les catastrophes.

La moyenne des rémunération a ainsi augmenté. Mais comme le respect des délais et la qualité produite aussi, ce n’était pas vraiment un problème. Quelquefois une méthode de management arrive à satisfaire tout le monde.

A suivre…

Cet article a été publié par Alexis KARTMANN le Vendredi 13 mai 2005 à 15:19 et est classé dans Tags:extreme programming, programmation
.
Vous pouvez en suivre les commentaires par le biais du flux RSS 2.0.
Vous pouvez laisser un commentaire, ou faire un trackback depuis votre propre site.