The Joel Test ou comment évaluer votre environnement de travail
En tant que consultants nous avons l’occasion de participer à de nombreux projets chez différents clients. Ces expériences sont généralement enrichissantes sur le plan technique comme sur le plan humain. Il est toujours difficile de quitter une mission on l’on se sent bien car comme dit le proverbe « On sait ce que l’on quitte, on ne sait pas ce que l’on prend »
Je vais tenter ici de vous expliquer une méthode qui vous permettra d’évaluer très rapidement votre mission actuelle ainsi que vos futures missions.
Il s’agit du « Joel Test ». Une méthodologie imaginée par Joel Spolsky ( https://www.joelonsoftware.com) qui est notamment co-fondateur de https://stackoverflow.com/. Si vous voulez lire l’article original c’est ici : https://www.joelonsoftware.com/articles/fog0000000043.html
Ce test est basé sur 12 simples questions. Chaque question donnant un point si la réponse est « oui ». Si vous obtenez un score de 12 c’est que vous avez tout bon. Un score de 11 est tolérable mais d’après lui un score de 10 ou moins dénote de gros problèmes.
|
The Joel Test
|
Évidemment ce n’est pas la seule métrique à prendre en compte, ni un indicateur de réussite. Vous pouvez avoir un score de 12 et une super équipe, mais un produit dont personne ne veut avec des technologies qui ne vous intéressent pas. Et inversement, un score inférieur à 10 avec une équipe qui n’a pas trop de rigueur, mais faire des choses fantastiques où vous vous sentirez super bien.
Je vais maintenant décrire ces 12 questions.
1. Do you use source control?
Autrement dit : utilisez-vous un outil de gestion de version des sources (cvs, svn, git..)? Il me parait essentiel d’avoir un outil de versionning, pour pouvoir travailler de manière collaborative et également garder un historique du travail effectué. Je pense qu’il s’agit d’un minimum à avoir. Ceci peut nous éviter bien des problèmes (notamment la perte de code) et nous aider à réparer des erreurs en récupérant facilement une ancienne version. Et si je peux me permettre : s’il-vous plait, ajoutez un commentaire lors de votre commit ! Ça ne vous prendra que 30 secondes au moment où vous commitez et permettra à votre équipe de gagner de longues minutes (et parfois de sauver quelques cheveux).
2.Can you make a build in one step?
Considérant le build comme un livrable issu des dernières versions snapshot, Joel part du principe que si votre application nécessite plus d’une étape pour construire votre livrable, les risques d’oublier l’une de ces étapes lorsque vous livrez ne sont pas négligeables. Par ailleurs lorsque la deadline de livraison approche vous n’avez pas envie d’avoir 15 étapes à faire. Vous voulez livrer rapidement et ne pas perdre de temps sur cette tâche.
3.Do you make daily builds?
L’idée est surtout d’avoir un outil d’intégration continue effectuant un build quotidien. On a tous un jour ou l’autre eut cette conversation avec un collègue :
Vous : « Je pense que tu as oublié de commiter un fichier, je n’arrive pas à builder sur mon environnement. »
Votre collègue : « Non, j’ai tout commité, tu n’es peut-être pas à jour ou alors c’est toi qui a cassé le build »
S’en suit une discussion stérile ou chacun reste persuadé que l’autre a oublié quelque chose et ne veut pas l’admettre.
L’avantage majeur d’un tel outil est de travailler uniquement sur ce qui a été commité. Vous pouvez donc à tout moment connaître les sources que vous pouvez ou non récupérer. Joel suggère un build pendant le déjeuner pour que chacun commit son travail avant de déjeuner et récupère toutes les modifications au retour de la pause. C’est une solution envisageable mais je préfère l’idée de réparer un build cassé le plus rapidement possible. Ce qui implique de le détecter le plus rapidement possible. La plupart des outils d’intégration continue permettent de programmer les builds tous les X temps ou sur évènement (par exemple à chaque commit). Après, à chaque équipe d’adopter la solution qui lui convienne le mieux.
4. Do you have a bug database?
Effectivement pour ce point je rejoins l’opinion de Joel qui explique que les cerveaux des développeurs ne peuvent pas constituer une base fiable de toutes les anomalies connues et/ou corrigées. Il existe beaucoup d’outils sur le marché, et si l’idée d’installer un nouvel outil, former les gens etc. vous rebute, un simple fichier Excel contenant à minima ces informations peut suffire :
- quelles sont les étapes de reproduction de l’anomalie
-
quel est le comportement attendu
-
quel est le comportement observé
-
qui corrige l’anomalie
-
quel est l’état de l’anomalie (corrigé/ en attente …)
-
quelle est la version où l’anomalie est corrigée
5. Do you fix bugs before writing new code?
Joel nous explique avec une anecdote enrichissante sur le développement de Microsoft Word l’intérêt de cette méthodologie. En résumé leurs équipes étaient tellement en retard dans le planning qu’ils ont développé chaque fonctionnalité rapidement pour passer à la suivante et respecter le planning. Toutes les anomalies seront détectées et reportées, mais feraient l’objet de corrections prévues une fois la deadline passée. Cette façon de reporter à plus tard été baptisée « infinite defects methodology » ou comment fabriquer une roue couverte de rustines.
Suite à cela, Microsoft a appliqué la « zero defects methodology » la priorité étant de corriger chaque anomalie connue avant de développer de nouvelles fonctionnalités.
Ce concept permet sur le long terme de gagner beaucoup de temps pour différentes raisons :
- plus rapidement vous corrigez le problème, plus le code est frais dans votre mémoire, ce qui vous permettra de le corriger plus vite que si vous devez d’abord vous rappeler du code écrit.
-
si l’anomalie à corriger a déjà été livrée il vous faudra plus de temps pour la corriger (vous devrez potentiellement relivrer, créer une branche, reporter sur le tronc …)
-
le temps de correction n’est pas toujours prévisible : on a parfois des bugs dont le temps de correction variera selon le temps de détection de la cause. Par contre, le temps de développement des nouvelles fonctionnalités est estimable. Si l’on développe toutes les fonctionnalités et que l’on s’occupe de corriger les anomalies à la fin, on aura respecté le planning initial mais la date de bouclage sera très difficilement prévisible. Corriger les bugs avant de faire de nouveaux développements permet d’avoir un planning plus proche de la réalité.
-
cela permet également d’avoir une application de qualité dans un état quasiment toujours livrable, ce qui permet d’être réactif au marché.
6. Do you have an up-to-date schedule?
Avoir un planning à jour apporte une aide précieuse. Grâce à lui nous pouvons organiser les évènements et les décaler si besoin. L’autre atout s’affilie à l’un des avantages de scrum : si l’on a du retard mais que la date finale ne peut être déplacée, nous devons réévaluer la nécessité des fonctionnalités et ainsi travailler par ordre de priorité en fonction de l’importance des celles-ci, quitte à supprimer celles qui sont triviales.
7. Do you have a spec?
Tout le monde est d’accord pour dire que l’on a besoin de traces écrites sur le fonctionnel d’une application. Que ce soit une spécification fonctionnelle détaillée en bonne et due forme, ou bien une liste d’US (https://scrumcrazy.wordpress.com/2012/05/03/user-story-basics-what-is-a-user-story/) rédigées de manière concise et claire. En tant que développeur, on pense tout d’abord à la façon dont on implémentera le code. Si l’on n’a pas, en amont, rédigé la description de la fonctionnalité, même de façon sommaire, on risque de découvrir les éventuels problèmes fonctionnels une fois le code écrit. Ce qui implique que l’on devra repasser sur ce code, voir également sur la spécification de la fonctionnalité.
Si l’on définit par écrit le besoin et le fonctionnement d’une nouvelle fonctionnalité, on aura plus de facilité à corriger les éventuels problèmes fonctionnels lors de la rédaction. Ainsi le code pourra être implémenté pour répondre au besoin dès le départ. Corriger des anomalies sur une application non documentée peut devenir tellement complexe que certains décident de tout jeter pour recommencer de zéro. Joel préconise d’appliquer la règle “no code without spec” pour éviter ce genre de problème.
8. Do programmers have quiet working conditions?
Lorsqu’un programmeur est au meilleur de ses capacités, on dit qu’il est dans la « zone ». Cette zone est atteinte au moment où il est complètement concentré sur son travail et ne prête aucune attention à l’environnement qui l’entoure. Il faut en moyenne 15 minutes pour atteindre la zone de travail optimale. Mais le fait est que l’on peut en sortir très rapidement. Que ce soit à cause du bruit, d’un coup de téléphone, d’une pause, d’une interruption par un collègue etc. Dans les open space et autres bureaux partagés, la principale raison est l’interruption intempestive de nos collègues. Du coup lorsque l’un de vos collègues pense gagner du temps en vous posant une question qui vous prendra 1 minute à chacun, au lieu de prendre 5 minutes à chercher seul, il fait en réalité perdre 15 minutes de votre temps pour gagner 4 minutes du sien. La meilleure solution est de considérer que vos collègues sont dans un bureau fermé avant de les déranger et également de se demander si cela ne nous prendrait pas moins d’un quart d’heure pour trouver une solution seul.
9. Do you use the best tools money can buy?
On ne parle pas d’avoir toutes les licences des dernières applications à la mode mais uniquement d’avoir des outils adaptés au travail demandé. En réalité un développeur perd parfois beaucoup de temps car sa machine n’est pas assez performante. Si sa machine prend par exemple 15 secondes à la compilation, ce temps est perceptible et fera perdre patience au développeur. Il pourrait s’en lasser, être démotivé et décider régulièrement d’aller sur internet pendant ce temps. Mais puisqu’il y passera certainement plus de 15 secondes c’est au final de nombreuses heures de productivité qui seront perdues.
Si l’on doit travailler sur des IHM, avoir deux écrans peut rendre la tâche beaucoup plus facile. Idem pour les retouches d’images, utiliser Paint au lieu d’un outil spécialisé pour cela rend la tâche plus fastidieuse.
Fournir à ses équipes le matériel et les outils les plus adaptés peut représenter un coût important à première vue. Mais un meilleur environnement de travail, rendra vos équipes plus heureuses sur le long terme. En répercussion, cet investissement pourra vous faire gagner une meilleure productivité.
10. Do you have testers?
Ici, Joel explique que si l’on n’a pas un ratio d’un testeur pour deux à trois développeurs on s’expose à une forte probabilité que, soit nos produits ne sont pas de qualité, soit nos produits coûtent extrêmement cher pour être de qualité. Cette déduction est moins évidente en France car la différence de coût entre un développeur et un testeur n’est pas aussi flagrante qu’aux Etats-Unis (il parle d’un coût de 100$/heure contre 30$/heure pour un testeur). À mon avis, il est effectivement important d’avoir des personnes qui font des tests. Que ce soit les développeurs eux-mêmes en changeant de rôle temporairement ou bien qu’il y ait une équipe de QA spécifique. Le principal problème est qu’il est très difficile de recruter de bons testeurs. Il faut donc parfois se construire une équipe avec des profils mixtes pour pouvoir faire des tests croisés entre développeurs. Ce qui est important ici n’est pas que chacun ait un rôle définit et ne puisse pas en sortir mais que le rôle de testeur existe dans chaque équipe même de manière temporaire. Il vaut mieux, par exemple, avoir des développeurs qui testent un jour par semaine qu’aucun testeur ou même un mauvais testeur.
J’ajouterais également que l’existence d’une équipe d’intégration est un vrai plus. On a tendance à livrer son produit et oublier qu’il doit potentiellement interagir avec d’autres applications. Lorsqu’un échange est en échec, souvent chaque équipe accuse l’autre. Une équipe d’intégration permettra de tester ces interactions et vérifier que chaque partie a bien fait les choses.
11. Do new candidates write code during their interview?
Il est vrai que souvent lors des entretiens, nous avons droit à une batterie de questions techniques. Nous préparons donc nos entretiens pour pouvoir répondre correctement à toutes ces éventuelles questions. Il est également très rare d’avoir un test écrit. Que ce soit sur ordinateur ou sur un tableau, on nous demande rarement de coder ou d’écrire un algorithme.
Ce qui est en théorie absurde car nous sommes alors recruté sur l’hypothèse de correspondre au profil recherché. C’est pourtant l’un des rares métiers où cela est très fréquent. Joel prend l’exemple d’un magicien. En effet, on n’embaucherait pas un magicien sans avoir vu quelques tours. Alors pourquoi continue-t-on à embaucher des développeurs sans les avoir vu coder ? Cela permettrait d’éviter parfois de grosses surprises et donc la perte de temps à vos équipes.
12. Do you do hallway usability testing?
Ce point est très enrichissant. “Hallway usability testing” est le fait d’arrêter des personnes que vous croisez dans le couloir et leur demandez d’utiliser le code que vous venez de développer. En faisant cela avec cinq personnes, on devrait découvrir 95% des problèmes de conception de son code.
On peut également utiliser cette méthode pour les IHM. En prenant cinq ou six personnes et en leur demandant d’utiliser notre IHM, on découvrirait les plus gros problèmes ergonomiques. Cela nous permettra d’avoir une application plus facile d’utilisation et plus rapide à prendre en main pour les nouveaux utilisateurs.
Ce point est à mon sens le plus difficile à mettre en œuvre car comme le pair-programming, il est souvent ardu de faire comprendre sa valeur ajoutée à notre hiérarchie qui d’un œil extérieur ne verra que du temps gaspillé par cinq personnes alors qu’une seule aurait pu faire ce travail. Mais s’il est compris, vous arriverez certainement à sortir un meilleur produit.
D’une manière plus poussée, certaines équipes font ça sous forme de réunion informelle. En réunissant un panel d’un certain nombre de personnes issues de différents services de l’entreprise, on leur fait utiliser l’application et on récolte leurs avis et suggestions. Vous pourrez ainsi avoir une application qui sera utilisable par tout type de personnes qu’elles soient techniques ou non.
Conclusion
En conclusion, je dirais que ces 12 points sont effectivement importants. Mais d’autres points sont également à considérer. Certaines équipes atteignent un score très bas mais auront la volonté de l’améliorer. D’autres pourraient avoir un score moyen et seraient tentées de se reposer sur leurs acquis. Il faut donc également essayer de déceler cette part de volonté. Il sera plus facile pour une nouvelle équipe et une entreprise récente d’atteindre plus de 10 points, comparée à une société ayant de nombreuses applications à maintenir depuis des années. Mais ce qui compte également est votre implication. Si travailler dans un environnement qui applique un certain nombre de ces points est important pour vous. Si vous pensez que cela pourrait vous enrichir professionnellement. C’est à vous de faire en sorte que cette métrique augmente et d’en convaincre vos collègues. En quelques mots : soyez acteur de votre carrière.