Coma Informatique

Le développement en binôme est LA pratique la plus contestée de l’eXtreme Programming. A tel point que j’ai rencontré des partisans de XP qui n’avaient même pas essayé de la mettre en oeuvre.

Le contexte

Alors comment mettre en oeuvre cette pratique dans le contexte difficile d’une dotcom en 2002 ? Un certain nombre d’éléments étaient cependant favorable.

Tout d’abord il existait déjà un esprit d’équipe, sans doute liée à une certaine homogénéité en terme d’age et d’ancienneté. Cet esprit d’équipe s’exerçait plutôt dans des activités extra-professionnelle (repas, loisirs), alors que la culture d’entreprise centré sur la performance personnelle n’encourageait pas vraiment le travail en équipe.

C’est pourquoi le développement en binôme n’est pas facile à mettre en oeuvre. Parce qu’il est contraire aux pratiques habituelles dans l’entreprise. Ce n’est pas propre à l’entreprise, d’ailleurs. On a tellement l’habitude d’être évalué selon ses performances individuelles, durant sa scolarité et sa vie professionnelle, que la notion de performance collective est assez peu connue, à moins d’avoir joué de la musique dans un orchestre ou pratiqué un sport collectif.

La méthode

Le secret pour réussir tient essentiellement au coaching. Un changement de mentalité passera par de la pédagogie, et bien sur la pédagogie c’est d’abord répéter souvent les principes.

Il faut d’abord convaincre de l’intérêt de cette pratique. Au départ cela semble hasardeux. On a l’impression qu’un seul travaille (et il faut éviter que ce soit le “meilleur” du binôme qui soit systematiquement au clavier) et que l’autre s’ennuie. Et franchement au début ce n’est pas faux.

Alors il faut forcer les binômes à changer souvent. C’est à dire après chaque tache. Et verifier que ce n’est pas toujours le même équipier en face du clavier. Avec une bonne organisation des postes de travail c’est déjà plus facile de voir comment les gens travaillent et d’intervenir gentillement en cas de besoin.

Synchronisation

Evidement le problème qui peut arriver lorsqu’on veut souvent changer la composition des binômes c’est la synchronisation. Pour éviter cela il faut essayer de découper chaque scénario utilisateur en tâches techniques réalisable en quelques jours au plus (l’idéal étant une journée).

Lorsqu’un binôme a terminé sa tache et qu’aucun autre équipier n’est disponible pour former un autre binôme, chaque équipier peut effectuer un travail individuel en attendant de former un autre binôme. Car il ne faut pas oublier que seuls le développement de code utilisé en production doit se faire en binôme. Les autres taches comme la rédaction de document, le prototypage, l’exploration technique se font individuellement. Sans compter tous les taches par nature personnelles (lecture d’email, surf, etc). Éventuellement le binôme peut aussi commencer une autre tâche.

Les résultats

Petit à petit l’équipe voit les résultats arriver :

• Revue de code : La pratique du binômage revient à effectuer constamment une revue de code. Cela évite les erreurs de conceptions, favorise les solutions élégantes et simples, facilite la correction d’erreur.
• Transfert de compétences : Comme la composition des binômes varie souvent, les compétences techniques sont très vite partagés. Dans le cas qui nous intéresse, la maîtrise de la plateforme .Net au sein de l’équipe s’est faite sans organiser une formation générale de l’équipe, mais simplement grâce à la formation en amont du projet de 2 personnes sur 8.
• Partage de l’information : C’est un point crucial pour l’adoption de la méthode par les membres de l’équipe. En effet très rapidement on constate qu’il n’y a plus de chasse gardé dans le code. Cela évite le phénomène fréquent de surcharge du responsable d’un module critique. Le stress est moindre puisque personne n’est vraiment indispensable (bien que globalement l’équipe le soit).

Rien n’est acquis

Malgré l’unanimité qui se fait dans l’équipe à propos des avantages de la méthode, on constante quand même une tendance naturelle à l’abandon du binômage et un retour à un travail individuel. C’est là qu’interviendra à nouveau le coach. Et aussi la mise en place d’un système incitatif dans la politique de rémunération. Mais c’est une autre histoire

A suivre…

Pour continuer notre feuilleton, nous allons nous intéresser au développement conduit par les tests (Test Driven Development).

Pour mettre en oeuvre le développement conduit par les tests, il convient d’utiliser un framework de test. Parmi les outils existants, le choix qui a été effectué il y plus de 2 ans était :

• CppUnit pour le code en C++. L’écriture des tests n’est pas aussi facile qu’en C#, mais l’intégration dans Visual Studio permet d’automatiser l’exécution des tests à l’issue d’une compilation.
• NUnit pour le code en C#. NUnit est plus qu’un portage de JUnit car il utiliser les attributs pour définir les classes et les fonctions de test. Depuis d’autre framework utilisant ce système ont été réalisé (notamment l’excellent MBUnit).
• NUnitAsp pour le test des pages ASP.Net. NUnitAsp est une extension de NUnit qui permet d’appeler des pages ASP, de les interpréter et de manipuler les objets d’interface constituant la page. Par rapport à HTTPUnit, NUnitAsp facilite l’interprétation de l’HTML généré. Par contre certains objets standard n’étant pas supporté par NUnitAsp à l’époque, il a fallut étendre NUnitAsp, c’est l’avantage de l’open-source !

Une fois les outils choisis, il faut former l’équipe au principe même du développement par les tests. Pour cela on procède en deux temps, avec d’abord une formation magistrale, puis du développement en binôme avec le coach (dans notre cas, c’est le CTO qui était aussi coach).

La formation

Pour effectuer une formation, il suffit d’un PC portable, d’un vidéo-projecteur et d’un mur blanc (ce fut le plus dur à trouver).

Tout d’abord on écrit un test pour une classe qui n’existe pas. Le test bien sur ne compile pas.

[TestFixture]

class MyClassOfTest

{

[Test]

MyTest

{

MyClass test = new MyClass()

Assertion.Assert("Init Failed", MyClass.Init(10));

Assertion.AssertEqual("Balance is 10", 10, MyClass.Balance);

}

}

Puis on écrit le squelette de la classe et de ses méthodes.

class MyClass

{

private int balance;

bool Init(int initialBalance)

{

return false;

}

int Balance

{

get { return 0; }

}

}

Le test compile mais ne passe pas. Puis en écrit le code des méthodes et le test passe.

class MyClass

{

private int balance;

bool Init(int initialBalance)

{

balance = initialBalance;

return true;

}

int Balance

{

get { return balance; }

}

}

Le tout sur grand écran. Il faut voir les yeux des développeurs quand ils voie la barre verte des tests. Pour beaucoup c’est une révélation !

On n’a plus grand chose à montrer ensuite. En fait il faut aussi parler des bouchons (mock objets). Un bon exemple est l’envoi d’email qu’il faut mieux de pas effectuer pour de vrai (l’email toto@mail.com existe vraiment).

Coaching

Le principe est assez simple à comprendre à partir d’exemple. Pour faciliter l’apprentissage, le coach travaille en binôme avec chaque développeur pour montrer l’utilisation des tests lors de cas réels. Petit à petit le niveau des tests progressent, jusqu’à ce que cela deviennent un réflexe (”j’écris un test avant d’écrire du code”).

Ceci demande au coach beaucoup d’implication. Il faut d’un part aider à l’écriture des test, car dans certains cas ce n’est trivial. L’utilisation de mock objects permet souvent de contourner les difficultés.

De même la lourdeur d’utilisation de NUnitAsp oblige à séparer la logique applicative et l’accès aux données dans des librairies testables directement du code d’interface que l’on testera avec NUnitAsp.

Même si très vite tout le monde est convaincu par l’intérêt des tests, il faut régulièrement inciter la généralisation de cette pratique.

Pour cela il faut régulièrement évaluer le pourcentage de ligne de test par rapport aux ligne de code. Afin de faciliter cette mesure, on séparera systématiquement le code de production du code de test en deux projets jumeaux. Une répartition de 50 % doit être un objectif, souvent difficile à atteindre au début.

Et ça marche !

Un événement a définitivement convaincu tout le monde. Pour de multiples raisons, il a été décider de changer de système de base de donnée. Cela a été effectué par un binôme en quelques jours, sans aucun problèmes à l’issue de la mise en production. Heureusement les tests avaient permit de détecter plus de 10 régressions qui ont été réglés lors du développement.

A bientôt pour parler un peu plus du travail en binômes…

A suivre

Comment faire travailler 8 personnes en binôme ? Il suffit 4 table avec 4 PC, et 8 chaises !

On ajoute une petite table pour la machine de build.

Évidement il manque sur le schéma les bureaux personnels de développeurs (à côté dans l’open space), ainsi que le serveur qui héberge le gestionnaire de source (dans la salle machine).

Le fait de séparer les postes de développements et les bureaux des développeurs a permit à l’équipe de mettre en place un auto-contrôle. En effet un développeur à son poste personnel ne produit pas de code. Évidement il peut faire de la veille sur internet, réaliser un prototype (spike), lire ses mails, mais la position géographique est un bon indicateur du type de travail effectué. C’est peut-être l’une des explications de l’amélioration de la productivité que l’on a constaté après l’adoption de XP !

Chaque PC est configuré à l’identique grâce à un outil de copie d’image disque. Il contient uniquement les outils de développement. L’avantage c’est qu’avec l’intégration continue et l’utilisation d’un serveur de code source, en cas de panne d’un PC de développement on peut en configurer un autre en moins d’une heure. Fini la journée perdue quand un développeur avait à subir un crash disque (et cela arrivait plus qu’on ne le croit quand on avait certains modèle de disque dur IBM).

Tout autour de la zone de développement on a placé des tableau blanc effaçable pour pouvoir réaliser des schémas.

Un tableau permet l’affichage des scénarios en cours et de suivre l’avancement des taches listées.

Et évidement le client sur site est tout près !

Maintenant tout est prêt pour mettre en oeuvre les pratiques XP !

A suivre

Voici la suite de notre grand feuilleton sur la mise en place d’eXtreme progamming. Notre CTO, après avoir convaincu le management, va-t-il convaincre l’équipe ?

De l’importance de l’équipe

Au delà du management, c’est surtout avec l’équipe qu’on réussit la mise en place d’une méthodologie (quel qu’elle soit).

Alors pour une méthode comme eXtreme Programming, centré sur l’équipe plus que les process, c’est crucial.

On commence d’abord par une présentation, plus complète que celle prévue pour le management. Après un “teasing” d’enfer, avec convocation de toute l’équipe sans préciser la raison, et une question sur le mode de l’auto-analyse, la méthode est présentée.

Première présentation

L’équipe accepte globalement bien les valeurs, malgré une certaine ironie. Finalement l’ironie est une autre manière qu’exprimer les mêmes réserves que le management quand à l’incompatibilité des valeurs de XP par rapport aux valeurs de l’entreprise.

Concernant les pratiques, la discussion a été plus rude, sur le mode “c’est bien, mais pas pour nous !”, ou alors “ça a l’air bien , mais comment on va faire ?”.

Le développement conduit par les tests, qu’il est difficile à expliquer de façon abstraite, alors qu’une démonstration rend l’explication évidente, est un particulièrement saillant durant cette présentation. On décide donc d’organiser une formation spécifique sur ce sujet.

L’acceptation des tests de recette se heurte à une vrai difficulté du développement le tests des interfaces. On en parlera plus plus tard avec NUnitAsp.

Le remaniement est un peu difficile à accepter, d’autant que la doctrine en place était plutôt d’éviter les “optimisations” intempestives. Mais au final ce n’est pas vraiment la même chose, d’autant que le remaniement n’est possible que si on dispose de tests unitaires complets.

La métaphore ne provoque pas de réaction, ce qui prédestine un peu son avenir dans le projet, c’est à dire son absence !

L’autre point bloquant est la programmation en binôme, d’abord parce que certains individualistes forcenés s’y opposent, et que les autres commencent déjà à chercher leur binôme permanent. Il faut donc rappeler fermement que les binômes changent fréquemment, quitte à décevoir les couples déjà formés !

Pour les règles de codage, le fait que les règles sont définies par l’équipe fait l’unanimité. On planifie une réunion consacrée à ce sujet.

La conception simple et la responsabilité collective du code font l’unanimité, sans réserve. L’intégration continue, les livraisons fréquentes, la planification itérative et le client sur site sont quasiment déjà en place. Et quand au rythme durable, grâce aux 35 heures, est déjà bien en place !

Évidement les plannings games intéressent paradoxalement beaucoup plus les développeurs que les fonctionnels du marketing produit. Encore cette crainte de devoir assumer plus de responsabilité dans la gestion des projets. Décidément le coté “boite noire” des équipes de développement ne profite pas qu’aux développeurs !

La présentation est ensuite suivie par un grand classique des consultant XP, le fameux XP-Game.

Et bien jouez maintenant.

On trouve un peu partout des exemples de XP-Games, notamment ici.

Le but du XP-Games est d’illustrer de façons ludique les pratiques XP dans un contexte non-informatique, afin de les faire comprendre pas tous.

Le pair programming s’illustre notamment par un dessin réalisé en binôme après avoir demandé à chacun de réaliser le même dessin seul. On se rend compte que les dessins en binômes sont globalement mieux réussis que les dessins réalisés seuls (sauf s’il y a un très bon dessinateur).

Ensuite on illustre la méthode de travail itérative avec un projet simple et fictif, par exemple créer un réfrigérateur. Le marketing écrit des scénarios d’utilisation et détermine leurs valeurs, les développeurs estime leurs coûts. Ensuite on classe les scénarios en combinant leurs valeurs et leur coût. Puis les développeurs les réalisent. On peut même illustrer le développement conduit par les tests en rédigeant les tests de validation en amont. Souvent on arrive à obtenir un four plutôt qu’un réfrigérateur, ce qui illustre bien les dérives naturelles des projets !

Au final un bon moment de détente, plein d’enseignements et de promesses pour la suite.

Tout reste à faire

Le risque après une journée de sensibilisation comme celle ci, c’est que tous le monde retourne à son poste et continue à travailler comme avant. Pour éviter cela, une réorganisation spatiale s’impose.

A suivre…

Voici la suite de notre grand feuilleton sur l’installation d’eXtreme Programming dans une dotcom. Notre directeur technique a donc décidé de mettre en oeuvre XP en même temps que la migration sous .Net. Mais il doit d’abord convaincre le management et les équipes.

Mission impossible ?

Ce n’est un secret pour personne que l’opposition des managers entraîne à coût sûr l’échec d’un changement de méthode de travail. Si les chefs n’y croient pas, les équipes n’y croiront pas non plus. Il faut donc d’abord convaincre les responsables. Et aussi les équipes, mais c’est une autre histoire (ou un autre épisode).

Dans le monde de l’entreprise on a un vieux complexe qui fait qu’on préfère s’acharner plutôt qu’avouer qu’on se trompe et corriger le tir. Ce qui fait qu’on préfère réfléchir très longtemps avant d’agir, quitte à arriver toujours en retard (et avec une solution qui n’est plus adapté). Alors vendre une méthode comme XP qui va à l’encontre de cette habitude est doublement difficile, de part sa nature poussée vers l’action plutôt que la planification, et par le fait qu’il faut d’abord avouer que l’on travaillait mal avant.

Un contexte favorable

Heureusement dans le cas qui nous occupe, le PDG de l’entreprise avait bien compris que l’absence de déploiement chez les clients, propre aux sites webs, rendait possible une politique de livraison très fréquente. Le développement se faisait donc déjà sous forme d’itérations très courte (1 par semaine en moyenne). Le client, c’est à dire l’équipe marketing produit était présent sur le site. D’ailleurs les bureaux n’étaient qu’un immense un open-space sans cloisons (c’est tellement Internet, tu comprends). Ce qui était gênant quand on travaille seul, à cause du bruit, allait devenir un vrai avantage pour le travail en binôme. Mais on en reparlera plus tard.

Comme toutes les valeurs, celles de XP sont positives, donc difficilement contestables. Mais il faut quand même qu’elles raisonnent en nous pour qu’on les suivent. Le feedback était assez facile à accepter, surtout lorsqu’on travaille sur internet où tout est très rapide. Le moindre problème après une mise en ligne d’une nouvelle version entraîne beaucoup de mail d’internaute se plaignant. A tel point que le nombre de mail reçut était un des indicateurs suivi en comité de direction (à chaque gros problème le nombre de mail reçus dans la journée augmentait fortement).

La simplicité était aussi évidente. Le navigateur n’est pas appelé le client léger pour rien. Et quand on doit sortir une fonctionnalité par semaine, on doit forcement faire simple

La communication est paradoxalement plus difficile. Pourtant avec les mails, les messageries instantanés, l’open-space, cela aurait du être une évidence. Malheureusement dans un contexte difficile, avec les licenciements passés et peut-être à venir, beaucoup d’échanges se font afin de se couvrir, pas toujours pour partager de l’information.

Quand au courage, et pour les mêmes raisons, il était un peu en berne.

La préparation

Lors d’un entretien avec le PDG, il est décidé que le directeur technique proposerait sa méthode lors d’un comité de direction.

“Mais avant tu me montreras tes slides.”

“Donc il va valoir utiliser Powerpoint. Pas de problème, après C++, c’est ma seconde langue…”

Quelques heures plus tard (et moult pompage et traduction et adaptation de documents anglais), voici la présentation. Ce n’est que le support d’une présentation orale qui dure plus de 30 minutes.

Il faut comprendre que la situation n’était pas si difficile pour l’équipe technique. Malgré la difficulté à maintenir un bon niveau de qualité, la situation était sous contrôle. Il n’y avait pas de gros feux à éteindre, mais il fallait souvent réagir en mode pompier. Notre directeur technique bénéficiait d’un crédit de confiance suffisant pour pouvoir imposer sa méthode. C’est sans doute un point crucial dans le succès de ce type de démarche.

Le grand jour

Le PDG est convaincu par la présentation, puis vient le jour du comité de direction.

Évidement puisque le PDG est d’accord, tout est joué d’avance, XP sera mis en oeuvre. Par contre il faut convaincre les autres managers de ce que cette méthode va leur apporter, parce que sinon l’échec est garanti.

La réunion se passe plutôt bien.

Le responsable relation client, un pur méthodiste, est globalement satisfait qu’on se décide enfin à utiliser une méthode, même si elle lui semble exotique.

Le directeur marketing est plus méfiant. Il sent que ce qui est une force de XP, l’implication du client, et le fait qu’il est seul à décider de ce qui est fait et du planning, sans pouvoir imposer les délais autrement qu’en réduisant la porté fonctionnelle, lui donne une plus grande responsabilité. Évidement, quand les développeurs redonne du pouvoir au client, il a forcement une plus grande responsabilité. Mais un manager ne peut pas refuser une responsabilité, surtout quand elle était déjà dans ses attributions. Alors il accepte de bonne grâce.

Le directeur commercial ne comprend pas de quoi on parle, alors évidement il accepte.

Quand au directeur financier, vu qu’aucun achat de matériel ou de prestation n’est nécessaire, il n’a aucune objection.

Dans la foulé, devant tant d’enthousiasme, on décide aussi de mettre en oeuvre la méthode en même temps que le passage à .Net, lors de la réécriture d’un des produits.

Maintenant il faut convaincre les équipes, et surtout mettre la méthode en oeuvre

A suivre

Note : Bien qu’inspirés de faits réels, les personnages et les situations sont inventés de toute pièce… évidement.

Depuis longtemps j’ai envie de raconter une expérience de mise en oeuvre des principes de l’eXtreme Programming. Mais plutôt que d’écrire un unique billet, trop long mais forcement incomplet, je lance le premier billet à épisodes de ce blog !

Prise de conscience

Voici donc l’histoire du directeur technique d’une startup internet, qui doit se battre avec un code écrit trop rapidement, par trop de développeurs de passage, qui a atteint l’état fameux de “code spaghetti” propre à beaucoup de projets.

Si la partie de back-office, écrite en C++, est de bonne qualité et reste maintenable, l’interface web, bien que dépourvu de bugs, souffre de l’utilisation de la technologie ASP de Microsoft dans sa version uniquement procédurale (le code date de NT4 et ASP 2.0), qui rend la réutilisation difficile. A tel point qu’il y a beaucoup de code redondant, et que la moindre modification nécessite de nombreux tests pour éviter les régressions, que l’on commence à considérer comme une fatalité.

Vu de l’extérieur la situation parait correcte, le site fonctionne bien, la qualité perçu est bonne, mais c’est au prix d’une attention de tous les instants, notamment lors des montés de version. De plus les coûts de développement sont de plus en plus élevés, au point que l’on essaie de limiter au maximum les modification sur l’interface web.

Évidement la sortie de .Net et de Visual Studio.Net devrait être le signal d’une migration vers ASP.Net, mais l’ampleur de la tâche, vu la qualité du code original, reste un frein.

Cette situation est loin d’être exceptionnelle, la plupart des développeurs la vivent au quotidien, c’est même enseigné dans les manuels de gestion de projet (les coût de modifications augmentent dans la vie d’un projet).

Évidement ce n’était pas satisfaisant, mais pour le moment le management est plutôt focalisé sur la nécessité de trouver de l’argent pour financer le développement de l’entreprise. Argent qui n’arrivera pas, pour pleins de raisons qui sont hors sujets. Alors le plan B est déclenché. Et c’est malheureusement un plan connu et peu agréable :

• Réduction des effectifs.
• Blocage des salaires.
• Réduction des coût.

Bref il faut faire plus avec moins. Et évidement continuer à faire évoluer les produits pour résister à la concurrence. Mission impossible ?

La rencontre

Tout commence par l’achat de l’ouvrage :

Tout de suite le directeur technique accepte les valeurs de l’eXtreme programming, et sent bien que les pratiques peuvent l’aider à régler ses problèmes d’amélioration de qualité et de productivité.

La participation à une conférence organisé par l’un des auteurs de l’ouvrage achève de le convaincre. Il achète toute la collection Addison Wesley consacré à XP et se forme aux pratiques XP, notamment la conception par les tests (Test Driven Development) et la reconception permanente (constant refactoring) notamment grâce à l’ouvrage de Martin Fowler.

C’est décidé, le prochain projet sera une réécriture d’une des application Web en ASP.Net, couplé avec la mise en oeuvre des pratiques d’XP !

Mais d’abord, il faut convaincre le comité de direction et l’équipe…

A suivre.

Curieusement on reparle du CMM en France en ce debut d’année chez SPIN et Tubbydev en faisant référence à une article de 01.net datant de Juin 2004.

On trouvera quelques informations interessantes dans cet articles. Il y a quand même quelques erreurs ou imprecisions :

• CMM n’est plus maintenu par le SEI, mais remplacé par CMMI depuis 2000 !
• Il existe une norme internationale (ISO 9001:2000) alors que CMMI est américain.
• CMMI est surtout utilisé (et utilisable) dans des grands projets

A mon avis l’interet principal de CMM consiste à definir plusieurs niveaux de maturité et de proposer les pratiques pour les atteindre. Par contre les pratiques peuvent, ou même doivent être définies par ailleurs (à ce titre RUP est souvent cité comme la méthode la plus en vogue).

L’utilisation de l’extreme programming ou d’autre méthodologie agile pour des petits projets n’est donc pas incompatible avec le CMM, au contraire. C’est souvent le seul moyen de mettre en place une méthodologie dans une petite équipe. En effet quelle équipe de moins de 10 personnes peut se permettre d’avoir un responsable audit qualité, un bibliothèquaire, un gestionnaire de configuration, etc, comme le demande les méthodolgies comme RUP ?