Joel on Software

Joel on Software   Joël à propos de logiciel

 

D'autres articles de "Joel on Software" en Français

D'autres articles de "Joel on Software" en Anglais

Contacter l'auteur (En Anglais uniquement)

 

Mener à bien le travail lorsque vous êtes un simple tâcheron


Par Joël Spolsky
Traduit par Boris Fontaine
Vérifié par Moez Mahfoudh
25 décembre 2001

Ce site traite en principe de la gestion du développement logiciel. Mais vous n'avez pas parfois l'autorité nécessaire dans votre organisation pour amener des changements par décret administratif. Évidemment, si vous n'êtes qu'un programmeur tâcheron en bas de la hiérarchie, vous ne pouvez pas vraiment exiger de vos collègues ou de vos supérieurs d'établir des horaires ou des bases de données de bogues. Et même si vous étiez un superviseur, vous aurez probablement découvert que diriger des développeurs ressemble beaucoup à dresser des chats, sauf que ce n'est pas aussi amusant. Faire passer des ordres n'est pas une mince affaire.

 

Il peut être frustrant de travailler au sein d'une organisation qui obtient un faible score au Test de Joël. Peu importe à quel point votre code est bon, vos collègues écrivent du si mauvais code que l'association de votre nom avec le projet vous embarrasse. Ou alors c'est la direction qui prend de mauvaises décisions à propos du code à écrire, ce qui vous force à gaspiller votre talent en déboguant la version AS/400 d'un jeu de planification de retraite pour enfants.

 

Vous pourriez simplement partir, j'imagine. Mais il y a, vraisemblablement, une raison qui vous y retient. Vos stock options n'ont pas vraiment rapporté, il n'y a pas de meilleur endroit pour travailler en ville, ou peut-être votre patron tient-il en otage quelqu'un que vous aimez. En tout cas, faire face à la musique d'une mauvaise équipe peut être exaspérant. Mais il existe des stratégies pour améliorer votre équipe par la base, et j'aimerais partager quelques-unes d'entre elles.

 

Stratégie No 1 Le faire soi-même

 

Beaucoup peut être fait pour améliorer le projet lorsqu'une seule personne donne l'exemple. Vous n'avez pas un serveur de builds quotidiens ? Faites-en un. Mettez en fonction dans votre machine un séquenceur de tâches qui va générer des builds la nuit et envoyer les résultats par courrier électronique. Est-ce que le processus de génération comporte trop d'étapes? Écrivez un fichier makefile. Personne n'effectue de tests d'utilisabilité? Appliquez vos propres tests d'utilisabilité du couloir sur les gens du secrétariat en utilisant une pièce de papier ou un prototype VB.

 

Stratégie No 2 Favoriser la contagion

 

Plusieurs des stratégies du Test de Joël peuvent être mises en oeuvre par un simple individu au sein d'une équipe peu encline à coopérer. Quelques unes d'entre-elles, lorsque menées à bien, se répandront dans le reste de l'équipe.

 

Par exemple, supposons que personne dans votre équipe n'adhère pas à l'idée de se servir d'une base de données de bogues. Ne vous en faites pas. Contentez-vous de continuer à vous servir de la vôtre. Inscrivez-y les bogues que vous trouvez dans votre propre code. Si vous trouvez un bogue que quelqu'un d'autre devrait vraiment corriger, assignez-le lui à l'aide de la base de données de bogues. Si vous avez un bon logiciel de suivi de bogues, il leur enverra un courriel. À présent, vous pouvez continuer de leur envoyer du courrier électronique s'ils ne résolvent pas leurs bogues. Éventuellement, ils constateront l'utilité du suivi de bogues et commencerons à se servir du système convenablement. Si l'équipe du contrôle de la qualité refuse d'inscrire des bogues dans le système de suivi de bogues, refusez simplement de considérer les rapports de bogues qui vous parviennent par tout autre moyen. Lorsque ce sera la trois millième fois que vous direz aux gens «Écoutez. J'aimerais bien résoudre cela, mais je vais oublier. Pouvez-vous inscrire le bogue dans le système?», ils commenceront à se servir de la base de donnée.

 

Personne dans votre équipe ne veut recourir à la gestion du code source? Créez votre propre référentiel CVS, quitte à le faire sur votre disque dur. Même en l'absence de coopération, vous pouvez archiver votre code indépendamment de tout le monde. Ensuite, lorsqu'ils auront des problèmes que la gestion du code source peut résoudre (quelqu'un peut taper accidentellement rm * ~ au lieu de rm *~), ils vont venir à vous pour de l'aide. Éventuellement, les gens vont se rendre compte qu'eux aussi peuvent faire leurs propres extractions.

 

Stratégie No 3 Former une élite

 

L'équipe ne dressera pas de programmes de travail ou de cahiers des charges? Écrivez ceux qui vous concernent. Personne ne va commencer à se plaindre si vous passez une journée ou deux à écrire un cahier des charges et un programme minimaux pour le travail que vous abordez.

 

Admettez de meilleurs éléments dans l'équipe. Impliquez vous dans l'embauche et les entrevues, et recrutez de bons candidats.

 

Trouvez les gens qui cherchent à s'améliorer et qui sont capables de le faire, et mettez-les de votre côté. Même au sein d'équipes peu performantes, vous avez probablement des gens brillants à qui ne manque que l'expérience nécessaire pour produire du code exemplaire. Aidez-les. Favorisez leur apprentissage. Lisez le code source qu'ils archivent. S'ils font quelque chose de stupide, ne leur envoyez pas un courriel dédaigneux qui leur explique ce que leur code contient de stupide. Cela ne fera que les mettre en colère et sur la défensive. Au lieu de cela, rapportez innocemment le bogue qui, vous le savez, découle du code source archivé. Laissez-les découvrir ce qui le cause. Lorsqu'ils trouvent le bogue par leurs propres moyens, ils oublieront la leçon beaucoup plus difficilement.

 

Stratégie No 4 Mettre les imbéciles hors d'état de nuire

 

Même les meilleures équipes peuvent avoir un ou deux imbéciles. Ce qui est frustrant avec le fait d'avoir de mauvais programmeurs, c'est que leur mauvais code corrompt votre bon code, ou encore que les bons programmeurs ont besoin de réparer les dégâts causés par les mauvais programmeurs.

 

En tant que tâcheron, votre but est de limiter les désastres. Un jour ou l'autre, l'un de ces génies va passer deux semaines à écrire un bout de code qui est invraisemblablement si mauvais qu'il ne parviendra jamais à faire ce qu'il faut. Vous êtes tenté de vous taper les quinze minutes nécessaires pour réécrire la chose correctement à partir de zéro. Résistez à la tentation. Vous avez une parfaite opportunité de mettre ce crétin hors d'état de nuire pour plusieurs mois. Limitez-vous à lui rapporter les bogues que son code comporte. Il n'aura pas d'autre choix que d'y travailler sans relâche pendant des mois, jusqu'à ce que vous ne trouviez plus d'autres bogues. Ce sont des mois pendant lesquels il ne pourra pas causer de dégâts ailleurs.

 

Stratégie 5 Se protéger des interruptions

 

Tous les milieux de travail épanouissants se ressemblent : bureaux privés, faible niveau de bruit, excellents outils, peu d'interruptions, et encore moins de grandes réunions. Tous les milieux de travail abrutissants le sont à leur manière.

 

La mauvaise nouvelle, c'est que pour virtuellement n'importe quelle compagnie, il est presque impossible de changer l'environnement de travail. Un bail à long terme peut signifier que même le PDG n'y peut rien. Voilà pourquoi si peu de développeurs de logiciel obtiennent des bureaux privés. Ceci défavorise leurs compagnies d'au moins deux façons. Premièrement, cela complique le recrutement de développeurs de premier ordre, lesquels préfèrent la firme qui leur offre des conditions plus accommodantes (abstraction faite des autres détails). Deuxièmement, la fréquence des interruptions peut dramatiquement réduire la productivité des développeurs, pour lesquels il est difficile d'enter dans un état productif et d'y rester pour une durée quelconque.

 

Cherchez des manières de vous sortir d'un tel environnement. Amenez un ordinateur portable à la cafétéria, où beaucoup de tables sont libres la majeure partie de la journée (et où personne ne peut vous trouver). Réservez une salle de réunion pour toute la journée et écrivez-y du code, et démontrez par la prépondérance des archivages de code source à quel point vous abattez plus de travail lorsque vous êtes seul dans un local. La prochaine fois qu'une situation critique se manifeste et que votre superviseur vous demande «que ce soit fait pour demain», vous savez quoi répondre. Ils vont vous trouver un bureau pour la journée. Et en peu de temps ils vont se demander ce qu'ils peuvent faire pour étendre ce phénomène de productivité à toute l'année.

 

Arrivez tard et partez tard. Ces heures qui suivent le départ à la maison du reste de la compagnie peuvent être les plus productives. Ou si vous faites partie d'une équipe de développeurs qui arrivent tard régulièrement, arrivez au travail à 9h00. Vous abattrez plus de travail au cours des deux heures qui précèdent l'arrivée des autres gens et des distractions qu'ils vous occasionnent que pendant le reste de la journée.

 

Ne gardez pas vos logiciels de courrier électronique et de messagerie instantanée actifs. Vérifiez votre courrier électronique toutes les heures si vous voulez, mais ne gardez pas ce logiciel actif tout le temps.

 

Stratégie No 6 Se rendre inestimable

 

Aucune de ces stratégies ne fonctionne si vous n'apportez pas une excellente contribution. Si vous n'écrivez pas du code exemplaire, et en grandes quantités, vous n'arriverez qu'à vous faire détester pour avoir dérangé les gens à propos des bases de données de bogues alors que vous «deviez» écrire du code. Rien n'est plus ruinant pour votre carrière que d'avoir une réputation de se soucier du procédé au point de ne plus rien accomplir.

 

Une fois, lorsque j'ai commencé un nouvel emploi comme programmeur tâcheron dans une nouvelle compagnie, j'ai découvert que cette dernière ne marquait qu'environ deux points au Test de Joël, et j'étais déterminé à rectifier la situation. Mais je savais également qu'il était capital de produire une bonne première impression. J'ai donc consacré les sept premières heures de chaque jour à écrire du code, comme stipulé dans mon contrat. Il n'y a rien de pareil à une rafale d'archivages pour rehausser votre image au sein de l'équipe de développement. Mais j'ai consacré une autre heure chaque après-midi, avant de rentrer à la maison, à améliorer le procédé. Je me servais de cette période pour corriger des choses qui rendaient difficile le déboguage de notre produit. J'ai mis en fonction un générateur de builds quotidiens et une base de données de bogues. J'ai résolu toutes les sources d'ennuis qui rendaient depuis longtemps le développement difficile. J'ai écrit des cahiers des charges pour le travail que j'effectuais durant la journée. J'ai écrit un document qui explique point par point comment construire une machine pour développeur à partir de zéro. J'ai documenté à fond un important langage interne qui ne l'était pas encore. Petit à petit, le procédé s'améliorait. Personne d'autre que moi (et mon équipe, lorsqu'on m'en confia une) n'a jamais écrit de programme de travail ou de cahier des charges, mais pour le reste, nous marquions environs 10 au Test de Joël.

 

Vous pouvez améliorer les choses, même lorsque vous ne dirigez pas, mais vous devez être comme la femme de César : au-dessus de tout soupçon. Autrement, vous accumulerez les ennemis sur votre chemin.



Cet article est paru en version originale anglaise sous le titre Getting Things Done When You're Only A Grunt  

Joël Spolsky est le fondateur de Fog Creek Software, une petite société éditrice de logiciel située à New York. Il est diplômé de l'Université de Yale et a travaillé comme programmeur et manager chez Microsoft, Viacom et Juno.


Le contenu de ces pages représentent l'opinion d'une personne.
Contenu protégé par le copyright ©1999-2005 par Joël Spolsky. Tous droits réservés.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky