Coma Informatique

Je n’ai pas parlé de XP et de qualité depuis quelques temps, mais cet article pointant vers un de mes vieux billets est très intéressant.

J’ai particulièrement apprécié l’explication sur la sur-qualité, qui est un peu le défaut que j’ai constaté sur certains projets, notamment quand le management à demandé que le produit ne sorte que quand il sera parfait. Et on se retrouve avec des réponses à des problèmes qui n’en sont pas.

Cela me rappelle une réflexion sur l’innovation, qui n’est le fait d’ajouter sans fin des fonctionnalités, mais plutôt d’enlever celles qui sont futiles pour se concentrer sur l’essentiel.

Ainsi voici donc le secret d’un projet logiciel réussi :

• On ne s’intéresse qu’aux fonctions utiles, et on les étudie complètement.
• On ne fait que ce qui est nécessaire, mais on le fait comme il faut.

Avec eXtreme Programming, on écrit les tests avant d’écrire le code

De même, avec eXtreme Marketing on vend les produits avant de les créer.

Après un longue pause, voici le retour du feuilleton sur la mise en place de l’eXtreme programming dans une dotcom. Et pour ce grand retour, quel meilleur sujet que la responsabilité collective du code ?

Rappelons que la responsabilité collective du code consiste, dans un projet, à donner à tous les membres de l’équipe le droit de modifié la totalité du code source. C’est donc contraire au principe souvent utilisé de responsabilité individuelle du code, dans lequel chaque développeur est responsable du code qu’il a écrit et reste le seul à avoir le droit et le devoir de le modifier.

La responsabilité collective du code s’est avérée, dans le cas qui nous occupe, l’une des pratiques qui semblait la plus naturelle (à l’opposé du travail en binôme, par exemple), mais dont la mise en place c’est le plus heurté à des barrières psychologiques.

Voyons lesquelles.

Je suis le meilleur

Il y a d’abord le caid, le dieu vivant du développement. Tellement bon et conscient de son niveau qu’il ne peut pas laisser les autres toucher à son code. Ou alors il faut qu’il refasse tout derrière.

Alors même s’il souffre d’être le seul à pouvoir toucher son code, il aura du mal à le partager. De la rétention de code, en somme.

Je ne suis pas digne

De l’autre côté, il y a le programmeur humble (très rare, mais il existe). Face au caid, il est impressionné. Tellement qu’il n’ose même pas imaginer qu’il pourrait faire la même chose.

Alors l’idée qu’il puisse toucher au code de son idole le paralyse.

Et comment on fait ?

Le binômage, le binômage. Tout est là. On mélange les niveaux, la connaissance du code se partage, le niveau technique général s’améliore.

Du moins en théorie. Ce fut même globalement le cas. Mais pas sans heurt.

L’euphorie

Après la phase initiale de méfiance, la propriété collective code écrit sur le nouveau projet s’instaura sans restriction. Ce ne fut pas le cas de l’existant tout de suite. Mais comme la majorité du travail était lié au nouveau projet ce ne fut pas un problème.

En fonction des scénarios utilisateur et des tâches de développeur, chaque binôme intervenait sur toute les parties du code sans autocensure ni blocage.

Mais on vit apparaitre un nouveau comportement chez les caïds, finalement assez voisin de la rétention de code.

Le remaniement des caïds

Un binôme réalise une tâche de développement. Par la suite un binôme de caïds doit travailler sur le code, et décide de faire un remaniement. En fait remaniement, c’est presque une réécriture qui est réalisée.

Quelque soit l’humilité du binôme, voir son code complètement réécrit est une sacrée remise en cause.

Le pire, c’est même qu’après un certain temps les caïds commencent à systématiquement remanier le code des autres binôme.

Voyant cela j’étais un peu pessimiste quand à la productivité de l’équipe. En effet quel intérêt de tout refaire systématiquement, autant tout faire faire par les caïds.

Montre moi et j’apprendrais

En fait le simple fait d’avoir écrit un code et les tests associés rendait quand même le travail de remaniement plus facile pour les caïds que s’il avait du tout faire eu même. Donc la perte de productivité n’était pas si évidente.

Et le remaniement des caïds eut finalement un effet pédagogique. Le fait de voir son code réécrit par les caïds permit aux autres binômes de mieux comprendre ce qu’il fallait faire. De plus le code existant étant souvent la base des nouveaux développements, le fait de laisser les caïds faire du remaniement tend à améliorer la qualité du code.

L’esprit d’équipe

Finalement si le remaniement des caïds n’a pas eu l’effet dévastateur que l’on pouvait craindre, c’est parce qu’il existait un vrai esprit d’équipe. Mais avant la responsabilité partagée du code, l’esprit était là, mais pas la pratique. Avec la responsabilité partagé, le code est vraiment devenue une œuvre collective, et non plus une collection d’œuvres individuelles.

Et non cher lecteur, le feuilleton eXtreme Programming n’est pas fini ! J’ai seulement eu d’autres projets quelque peu prenants (nDumbster entre autre).

Parlons donc du remaniement constant (constant refactoring). Il ne s’agit pas de déplacer régulièrement les personnes dans l’open space, même si cette pratique était aussi en vogue dans notre dotcom (on parlait de réorganisation spatiale !), mais de ne pas hésiter à modifier le code afin de le rendre plus propre, plus simple, plus maintenable.

Le remaniement est rendu possible par la présence de tests unitaires suffisants pour permettre des changements plus ou moins profonds dans le code sans risquer d’en perturber le fonctionnement (du moins une fois que tous les tests passent, bien sur). Sans une couverture complète du code par des tests unitaires, le remaniement constant devient une activité proche du saut à l’élastique sans élastique. Je parle de couverture complète, et non pas totale, pour signifier qu’il s’agit d’avoir voir suffisamment de tests pour tester “tout ce qui peut casser”.

Harnaché avec ses tests unitaires, le développeur peut donc se lancer dans les remaniements les plus audacieux, et cela sans le moindre risque. Enfin presque. Du moins nous avons constaté la fin de cette peur de perturber du code existant dont l’effet le plus visible chez nous était la tendance à dupliquer le code plutôt qu’a l’adapter à un nouveau besoin. Nous avions ainsi dans notre code ASP une pléthore de fonctions presque identiques à quelque variation près. Tout le monde avait peur de modifier une fonction existant en introduisant une variable supplémentaire afin d’éviter du code redondant, par exemple.

L’ouvrage

Refactoring de Martin Fowler, bien qu’illustré par des exemples en Java est très bien adapté à C# (quel hasard !). L’auteur y présente une liste de remaniement unitaire type qui permettent d’améliorer l’architecture d’une application.

Et c’est bien là ce que permet le remaniement constant. A partir de petites améliorations, mais que l’on fait constamment, on obtient une application dont l’architecture est bonne tout au long de sa vie.

C’est bien évidement à l’encontre de l’approche classique, dans laquelle un architecte définira en détail l’architecture de l’application à partir de son cahier des charges. Comme en XP le cahier des charges détaillé n’existe pas, l’architecture détaillé non plus. Disons plutôt qu’on la construit au fur et à mesure.

Ceci ne rend cependant pas inutile tout notion d’architecture, mais change seulement la façon dont on la construit. En fait en XP on construit quasiment en même temps le cahier des charges, l’architecture et le code !

Dans le contexte d’un logiciel dont la définition n’est pas figé, sur un marché changeant, avec des clients ayant du mal à exprimer explicitement leurs besoins, mais capable de formuler précisément des demandes d’évolution, eXtreme Programming s’est révélé efficace. Et le remaniement permet d’obtenir une architecture homogène et non un patchwork de fonctionnalités collés ensembles.

Parmi les effets néfastes du refactoring si l’on n’y prend pas garde, c’est qu’il devient l’excuse du perfectionniste en retard. “D’accord j’ai passé trois jours sur cette tache prévue pour un jour, mais j’ai fait deux jours de refactoring”. Dans ce cas, je rappelle que le remaniement doit être constant, c’est à dire répartie durant les taches de développement, et non pas considéré comme une tache indépendante. On ne fait pas du remaniement sur n’importe quelle partie du code, mais sur une partie de code que l’on doit modifier pour une tâche en cours.

Il y a une bonne comparaison (je crois qu’elle vient de Kent Beck) entre le remaniement et le fait de nettoyer sa cuisine. Il vaut mieux cuisiner dans une cuisine propre (donc développer avec un code propre), mais on peut soit nettoyer sa cuisine avant de cuisiner, soit après avoir cuisiné, soit pendant qu’on cuisine. Et évidement si on nettoie pendant qu’on cuisine, le temps que l’on passe dans la cuisine n’est pas tellement plus long, alors que nettoyer avant de cuisiner risque de prendre plus de temps, surtout les casseroles bien sales ! Bref c’est lorsque l’on remanie son code durant l’écriture que le remaniement est le moins couteux.

Il reste encore quelques pratiques d’eXtreme Programming à traiter avant la fin de ce feuilleton. Si vous avez des questions ou des points que vous voudriez voir traiter, n’hésitez pas. Amis eXtreme Programmers, ne soyez pas triste à l’annonce de la fin proche, j’ai encore d’autres expériences à raconter. Notamment de l’eXtreme Programming en solo !

A suivre…

Continuons notre série en parlant un peu d’une pratique qui n’est pas propre à XP, mais tout processus de développement discipliné : l’intégration continue.

Le but est d’éviter un phénomène classique de rétention de source : Un développeur garde du code sur son poste plusieurs jours (semaines/mois ?) sans le réintégrer dans le système de gestion de source. Lorsqu’il effectue la réintégration, il peut passer un long moment à régler les conflits avec d’autres modifications effectué. Et dans certains cas, une réintégration un peu brutale peut provoquer d’autre problèmes (le fameux effet papillon).

Pour éviter cela, l’intégration continue consiste à réintégrer très régulièrement les sources dès que le développeur a atteint un état stable de l’application (c’est à dire dès que ses tests passent).

Un élément nécessaire pour l’intégration continue est l’utilisation d’un outil de gestion de version comme CVS ou Subversion. Dans notre cas, vu l’utilisation de Visual Studio, nous avons naturellement utilisé Visual Source Safe (VSS). VSS était configuré en mode verrou partagé. Cela signifie que plusieurs développeurs peuvent travailler sur le même fichier (C’est un peu comparable au mode de fonctionnement de CVS). C’est lors de la réintégration que l’on gère les conflits éventuels.

Lors de la présentation de l’organisation spatiale, j’avais parlé de la machine de build. Lorsqu’un binôme a terminé une tâche élémentaire, et que tous les tests passent sur sa machine, les sources sont réintégrés dans VSS, puis le binôme se rends devant sur la machine de build, récupère tous les sources de VSS (et pas seulement ceux qu’ils ont modifiés), recompile l’application et lance les tests. Si un problème se produit, ils doivent le corriger avant de retourner à leurs poste (ou de rentrer chez eux).

Lorsque les tests se passent bien sur la machine de build, les binaires sont copié dans un répertoire de livraison et installé sur le serveur de pré-production, avant d’éventuellement mis en production si l’équipe marketing valide cette version. Au départ afin de signaler qu’une livraison a été faite, on utilisait une crécelle, mais le bruit était un peu trop fort et son utilisation n’a pas duré.

Après une réintégration réussie, le binôme peut récupérer sur son poste de travail les dernières versions de code sur VSS, puis démarrer une nouvelle tâche. Et systématiquement avant de commencer à travailler le matin on récupère les dernières versions.

L’utilisation de la machine de build s’est vite généralisé, et finalement peu de problème de conflit ont eu lieu, ce qui fut un grand changement par rapport au passé (alors même qu’il y avait peu de code dont la responsabilité était partagée). Aujourd’hui la machine de build serait sans doute remplacé par un serveur de construction automatique comme CruiseControl.Net.

Malgré cela, l’intégration continue, couplée avec les tests unitaires, est la clé du succès de la responsabilité partagé du code. On en reparlera.

A suivre

Après avoir traité de pratique de gestions de projet, revenons aux pratiques de programmation avec les règles de codage.

Ces règles furent discutées lors d’une réunion de l’équipe, en suivant les principes de simplicité et la contrainte suivante : moins de 10 pages pour les règles complètes, et la possibilité d’une version compacte tenant sur 2 pages que l’on placerait sur chaque poste de développement. L’expérience montrant que les règles trop complexes et nombreuses ne sont jamais suivit, ces contraintes sur la taille réduite en rendaient l’application plus probable. Il est vrai qu’aujourd’hui de nombreux outils permettent de valider automatiquement le respect de règles lors de la compilation ou avant la réintégration de fichier dans le système de gestion de source, mais nous devions faire avec les moyens du bord, à savoir l’équipe (ce qui est d’ailleurs conforme à l’esprit XP, qui privilégie les hommes plutôt que les outils).

A l’issue de la réunion, un document récapitulatif a été rédigé, ainsi qu’un guide synthétique de 2 pages. Placé dans un protège document transparent, ce guide sera utilisé en référence par tous les développeurs.

Mais voyons plus en détails les règles issues de la réunion.

Style de codage

Ce terme désigne la manière de présenter le code dans un but de faciliter la compréhension. Il comprend les méthodes d’indentation et de déclaration de variables.

Indentation

On choisi d’utiliser le style dit « côte ouest », par opposition à K&R. C’est-à-dire le style supporté par défaut par Visual studio. Et nous utilisions une tabulation de 2 espaces configurée dans l’éditeur (plutôt qu’avec le caractère tabulation) afin d’avoir une présentation identique sur tous les postes.

Ce qui donne quelque chose comme ceci :

try

{

  line = unputStream.ReadLine();

}

catch (Exception e)

{

  throw e;

}

Longueur des lignes et césure

Plutôt que de définir une stratégie de césure des lignes trop longues, nous décidons de remanier systématiquement ces lignes.

Ainsi

    if (val = 52 && val1 = 5 || (val1 = 3 && val2 = 1) … )

Sera remplacé par :

    if ( CheckValues() )

De même une fonction possédant une grande collection de paramètre sera traité en regroupant les paramètres dans une classe. Naturellement ce principe ne s’applique que pour des fonctions ayant une grande collection de paramètre. Il s’agit d’une certaine façon d’un remaniement qui consiste à regrouper des paramètres liés entre eux dans une structure ayant un sens, le nombre de paramètre élevé étant un indicateur (code smell) de ce remaniement nécessaire.

public String formatMessage(string message, int val1, int val2,

                     int val3);

public String formatMessage(formatMessage, ValuesBag vals);

Déclaration des variables

Les noms des variables devront avoir une signification claire. De plus la déclaration d’une variable devra se faire au début du bloc de code l’utilisant. Ceci est un bon compromis entre la lisibilité (déclaration des variables regroupé) et la performance (il faut éviter de déclarer des variables qui pourrait ne pas être utilisé).

Conventions de nommages

Il s’agit ici de définir la manière dont on nommera un élément en fonction de son type ou son usage. Il existe de nombreuses conventions, notamment la notation hongroise qui consiste à utiliser un préfixe définissant le type d’une variable. Cette notation peut vite devenir lourde à gérer, et surtout n’est plus vraiment adapté à des langages objet, puisque la plupart des variables seront d’un type non prévue par la notation. De plus avec les éditeurs modernes on trouve très facilement le type d’une variable si nécessaire.

Notre convention portera donc surtout sur la capitalisation des noms en fonction de l’objet nommé.

Classes et interface

Le nom commencera par une majuscule, et chaque mot accolé au premier commencera aussi par une majuscule.

Une classe n’aura pas de préfixe particulier, alors qu’une interface commencera par la lettre I.

On essayera de ne pas utiliser d’abréviation, sauf pour des termes très répandu.

Par exemple :

MyClass

IMailManager

MailManagerSMTP

Méthodes

Comme pour une classe, le nom commencera par une majuscule, et chaque mot accolé au premier commencera aussi par une majuscule.

On utilisera plutôt un verbe indiquant l’action que la méthode effectue.

Pour faciliter la compréhension, on inclura dans le nom des paramètres une information sur l’unité utilisé si nécessaire.

Par exemple :

WaitFor(int seconds) ;

Est plus clair que :

Wait(int delay) ;

Variables membres d’une classe et variables globales

On utilisera une minuscule pour le premier mot, et une majuscule sur les mots suivant.

Variable locale et paramètre d’une méthode

Le nom sera entièrement en minuscule.

Constantes et Macro C

Le nom sera entièrement en majuscule. On séparera les noms par un caret : _.

Enumérations

Les noms des énumérations utiliseront la règle s’appliquant aux classes, et les valeurs celle des constantes.

Documentation

L’un des principes de XP est que la documentation est dans le code. Plutôt que d’avoir un code obscur nécessitant une documentation pour le comprendre, on s’appliquera à obtenir un code simple et clair. Par contre dans le cas ou une documentation est nécessaire, notamment pour les APIs, on utilisera un outil de génération de documentation (comme XMLDoc pour C# ou doxygen pour C++) pour maintenir la documentation dans le code source. Cette pratique limite fortement le risque de divergence entre la documentation et la réalité du code.

Bilan

Même si les règles n’étaient pas toujours respectées, le fait d’avoir un consensus sur l’objectif s’est avéré très positif sur l’évolution du code. On a ainsi évité les discussions lié à la responsabilité collective du code sans que des règles claires soit définis (les fameux : « qui a foiré mon indentation ». et autres joyeusetés). On en reparlera bientôt en traitant justement de la responsabilité collective du code.

A suivre.

Pour la suite de notre feuilleton traitant de la mise en place d’eXtreme Programming, nous allons traiter du planning game.

Un changement dans la gestion des plannings

Avant la mise en place de XP, nous avions des réunions roadmap (plan de développement en français) stratégiques tous les trimestre et tactiques toutes les semaines.

La réunion tactique a été remplacée par les standup meetings matinaux.

La réunion trimestrielle a été remplacée par le planning game. Mais sa fréquence n’était plus fixe, mais fonction des besoins.

Quand ?

Nous avons d’abord fait un planning game initial, ou macroscopique, afin de définir les fonctions à développer d’une manière générales et faire un chiffrage approximatif.

Par la suite à chaque grande étape nous faisions un planning game pour définir le contenu de la prochaine release en détail.

Nous pouvions aussi décider lors d’un standup meeting de programmer un nouveau planning game si le besoin s’en faisait sentir, par exemple si suite à l’arrivée de beaucoup de demandes non prévues le planning devait être remis en cause.

Chiffrage

Le planning game se déroulait dans une salle fermée pour éviter toute distraction.

Dans un premier temps l’ensemble des scénarios utilisateur (ou fonctions), noté sur des fiches bristol, était chiffré collectivement par les développeurs, en fonction du coût de scénarios équivalents déjà réalisés. Au début nous étions forcement peu efficace sur les chiffrages, mais une fois que l’on avait à disposition une banque de fiches de scénario, les chiffrages étaient plus faciles, en procédant par analogie : « Ce scénario ressemble à tel autre qui nous a coûté tant, donc nous utiliseront le coût du réalisé pour le futur scénario ».

Planification

Une fois tous les scénarios chiffrés, le client classé les scénarios par priorité client ou marché. Parallèlement les développeurs classaient les scénarios par risque (facile, moyen, risqué). Le risque est différent du coût, en ce sens qu’il indique la difficulté technique, ce qui n’a rien à voir avec la durée. L’idée est de ne pas mettre trop de scénario risqué dans une même release pour d’une certaine manière repartir le risque entre les itérations.

Ensuite on calcule le coût réalisable par itération (en fonction des dates de release visé, et des effectifs disponible), et on repartie les scénario sur les releases à venir. On peut même planifier l’ensemble des fonctions voulues.

Et on itère

Evidement à partir de la première itération les plannings prévus n’ont jamais été respectés. Les raisons sont multiples et assumées : changement de priorité, ajout de nouveau scénario, problèmes techniques.

Chaque planning game permettait d’affiner le contenu le la prochaine release, tout en gardant une vision des futures releases. Le fait de ne plus avoir deux planifications (stratégique et tactique) réalisés séparément a permit d’avoir une vision plus correcte de ce qui sera disponible à une date donnée.

Bilan

Globalement on a obtenu une planification plus réaliste.

Par contre la durée du projet a largement dépassé le planning initial prévu, surtout parce que le niveau des fonctionnalités livrées a largement dépassé ce qui été prévu au départ.

A suivre

Et pour la suite du feuilleton traitant de la mise en place d’eXtreme programming dans une start-up, nous allons parler du stand-up meeting.

Le stand-up meeting n’est pas toujours cité parmi les pratiques de l’eXtreme programming. C’est dommage car c’est finalement l’une des meilleurs façon de diagnostiquer et de corriger les problèmes dans l’équipe.

Déroulement

Comme son nom l’indique, le stand-up meeting se déroule debout. En fait ce n’est pas une obligation, le but étant surtout que la réunion dure moins d’une demi-heure. La station debout devant théoriquement améliorer la brièveté des interventions.

Le stand-up meeting a lieu tous les matin, à heure fixe.

La réunion se déroule ainsi : chaque membre de l’équipe expose rapidement ce qu’il a fait la veille, les problèmes qu’il a rencontré, ce qu’il va faire dans la journée. Chacun peut réagir en complétant les information.

Pour que les interventions soit rapides, si un problème est exposé sans qu’une solution ait été trouvé, on peut décider d’une réunion “d’expert” qui aura lieu après le stand-up meeting pour régler le problème.

Et c’est là que le rôle du coach est primordial. Il ne doit pas hésiter à interrompre une discussion qui s’éternise en proposant l’organisation d’une réunion.

Dialogue et management

Le stand-up meeting est un outil important dans la constitution d’une équipe. Il facilite la communication utile.

La réunion ayant lieu tous les jours, on échange rapidement peu d’informations. Cela a tendance à rendre plus facile l’assimilation par rapport aux grande réunions très formelle. C’est un peu l’effet machine à café institutionnalisé.

L’autre aspect positif en terme de management est l’obligation d’assister à la réunion qui a lieu à une heure précise en début de matinée (enfin ça dépend ce que l’on appelle matinée). Ainsi on a la certitude qu’à l’issue du stand-up meeting tous les binômes seront au complet pour démarrer les développements. Ceux qui arrivent avant le début du stand-up meeting peuvent réaliser des tâches personnelles.

Un outil de diagnostic

La façon dont se déroule ces réunions journalières est assez révélatrice de l’état de l’équipe.

Si tout le monde arrive à l’heure et que la réunion se déroule rapidement parce que tous les points sont déjà traités de manière naturelle, on peut en déduire que l’équipe fonctionne bien.

S’il faut battre le rappel systématiquement, que certains arrivent dans les bureaux après l’heure de la réunion, que les discussions tournent en boucle, que des conflits apparaissent, alors l’équipe est en danger.

Et s’il n’y a plus de stand-up meeting, c’est un signe de crise grave.

Expérience

Dans le cas qui nous occupe, l’équipe est au départ passée par toutes les phases : absentéisme, discussions animés, réunions qui s’éternisent.

Puis petit à petit, grâce à un coach acharné et l’utilisation de diverses subterfuges (dont du vrai café servi lors du stand-up), la mécanisme c’est mise en place. Conjugué à un travail en binôme de plus en plus efficace, l’équipe de copains est devenu une vrai équipe professionnelle.

A propos de réunion, il faudrait encore parler du planning game. Mais ceci est une autre histoire, et fera l’objet d’un autre épisode.

A suivre

Continuons notre feuilleton en parlant de ce qui, je l’ai découvert plus tard, peut-être considéré comme le symbole de l’eXtreme Programming : les fiches bristol.

En effet le seul outil à acheter lorsqu’on veut mettre en place eXtreme Programming c’est plusieurs paquet de fiche bristol au format A6.

Ces feuilles servent à écrire les scénarios utilisateurs avant les planning games.

Durant le planning games, on écrit dessus la priorité et le coût de chaque scénario. On peut facilement organiser la planification en disposant les fiches sur une table.

Les scénario non traités sont stocké dans l’ordre de priorité décidé lors du planning game. Lorsqu’un développeur doit traiter un nouveau scénario, il prend la fiche au sommet de la pile.

Lorsqu’un développeur prend en charge un scénario, il prend la fiche et la garde tant que le développement n’est pas finie. Tout détail important lors d’échange entre le binôme et le client peut-être noté sur la fiche.

Lorsque le scénario est réalisé, la fiche est archivé.

Lorsqu’un bug est signalé, on l’inscrit sur un fiche bristol. On peut le traiter directement ou le rajouter dans la piles des fiches à traiter, dans l’ordre souhaité.

L’avantage d’utiliser un support comme les fiches bristol, c’est bien sur la simplicité. Il n’y a aucune contrainte lié à une application trop rigide. Tout information jugé utile peut être inscrite sur un bristol.

Un autre avantage psychologique tient à l’évolution de la taille du paquet de fiche traité qui permet bien de visualiser l’avancement d’un projet.

Bien sur les fiches ne sont pas parfaite. On peut les perdre (ce n’est pas arrivé souvent).

Une autre contrainte est la proximité géographique entre tous les membres de l’équipe, ce qui était notre cas. En cas d’éloignement la solution peut venir de la mise en place d’un wiki.

A ce propos, et devant l’insistance du client d’utiliser un support informatique, un wiki avait été mis en place. Après quelques doubles saisie bristol/wiki, l’utilisation du wiki s’est brutalement arrêté. La preuve que lorsqu’il n’y a pas de distance dans l’équipe, les fiches bristol sont largement suffisante.

J’ai découvert récemment que pour beaucoup de praticiens l’utilisation des fiches bristol est très caractéristique d’eXtreme Programming, sans être aussi typé que le développement en binôme. Durant une conversation avec un CTO j’ai dit : “pour les spécification je préfère utiliser des fiches bristol”. Sa réponse a été : “eXtreme Programming ?”. Il m’a ensuite parlé de son expérience de mise en oeuvre de XP. Et je suis presque sur que sans cette phrase clé il ne m’en aurai pas parlé. Car comme je l’ai vu depuis que j’en parle, il y a beaucoup de praticiens qui n’ose pas le dire. Sans doute parce que XP n’a pas très bonne presse en France. En tout cas parler de fiche bristol semble un bon moyen de se reconnaître entre praticiens honteux.

On reparlera sans doute des fiches lors de l’épisode sur le planning game, mais c’est une autre histoire.

A suivre…

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…