Aujourd’hui nous allons voir ensemble comment évaluer son équipe de développement avec le test de joël , c’est un petit test rapide et informel permettant, selon son auteur, d’évaluer la qualité d’une équipe de développement en informatique.
Le nom test de Joël provient directement de son auteur Joel Spolsky qui a publié ce test en 2000 sur son blog, donc oui ça date mais vous allez voir que les principes de base sont toujours d’actualité.
L’avantage de ce test informel c’est qu’il se veut très simplement applicable en 1 ou 2 minutes. Contrairement à des systèmes plus poussés comme SEMA par exemple, qui peut nécessiter plusieurs mois pour être déroulé.
En revanche le test de Joël est uniquement à prendre à titre indicatif et ne peut donc pas être utilisé pour évaluer de manière précise des équipes travaillant sur des projets critiques comme dans l’aéronautique par exemple.
Le principe du Test de Joel
Ok c’est intéressant tout ça, mais le test il consiste en quoi?
Il y a 12 questions, si vous répondez par oui c’est 1 point alors que si vous répondez par non c’est 0 point. Nous allons voir les questions ensemble une à une pour détailler un peu plus leur signification.
Je vous propose de faire en même temps le compte des points pour votre équipe de développement. Si vous êtes encore étudiant, répondez par oui aux questions si cette notion est au programme de votre formation.
| Q | VO | FR |
| 1 | Do you use source control? | Utilisez-vous un système de gestion de version ? |
| 2 | Can you make a build in one step? | Pouvez-vous effectuer une compilation en une seule étape ? |
| 3 | Do you make daily builds? | Faites-vous des compilations journalières ? |
| 4 | Do you have a bug database? | Avez-vous un logiciel de suivi de problèmes ? |
| 5 | Do you fix bugs before writing new code? | Corrigez-vous les bugs avant d’écrire de nouvelles fonctionnalités ? |
| 6 | Do you have an up-to-date schedule? | Avez-vous un planning de développement à jour ? |
| 7 | Do you have a spec? | Avez-vous des spécifications fonctionnelles ? |
| 8 | Do programmers have quiet working conditions? | Les programmeurs ont-ils un environnement de travail calme ? |
| 9 | Do you use the best tools money can buy? | Utilisez-vous les meilleurs outils que vous puissiez vous payer ? |
| 10 | Do you have testers? | Avez-vous des testeurs ? |
| 11 | Do new candidates write code during their interview? | Les candidats doivent-ils écrire du code pendant leur entretien d’embauche ? |
| 12 | Do you do hallway usability testing? | Faites-vous des tests utilisateur complet ? |
Les questions du test de Joël
1- Utilisez-vous un système de gestion de code source ?
Pour ceux qui ne savent pas de quoi il est question ici, un système de gestion de code source est un outil. Il permet en outre d’enregistrer l’historique des modifications du code source et de le versionner. Cela permet alors de partager plus facilement du code source avec d’autres développeurs et de suivre les modifications apportées par ces derniers.
Parmi ces outils on peut citer SVN, CVS ou encore le plus populaire d’entre eux: Git
Pour moi, cette question est surement l’une des plus importante. A titre personnel, je considère qu’une équipe de développement qui répond non ici, peut laisser tomber les autres questions et très vite faire le nécessaire pour remédier à ce problème avant de revenir sur le test de Joël.
2- Pouvez-vous faire un build en une seule étape ?
Ici, cela signifie, êtes vous capable de générer une version livrable de votre programme à partir des sources en une seule et unique étape.
Par exemple via un script à lancer pour cloner les sources et effectuer les étapes de compilation et de livraison. Ou encore via des outils d’intégration continue tel que Jenkins.
Plus vous avez d’étapes nécessitant une action Humaine, plus vous avez de risques d’erreurs. On dit souvent que le problème se trouve entre la chaise et le clavier, si vous voyez ce que je veux dire.
En plus de diminuer les risques d’erreurs, cela fait gagner énormément de temps aux équipes de développement, qui se débarrassent d’une tâche longue, répétitive et ennuyeuse…
3- Faites-vous des builds quotidiens ?
J’apporterai une petite nuance à ce que nous dit l’auteur ici. plutôt que “faites-vous des builds quotidiens ?” Je dirais “Avez vous un système d’intégration continue?” car l’intérêt n’est clairement pas de faire des compilations tous les jours juste pour le fun.
Le principe c’est d’avoir un système qui détecte que des modifications ont été apportées au code source puis de compiler celui-ci de manière automatique ( cloner les sources, compiler, générer le binaire, lancer les tests auto). Cela permet alors de voir si un développeur a entraîné des régressions dans ses dernières modifications qui peuvent, par exemple, empêcher la compilation du programme. Si cela arrive, alors tout le reste de l’équipe peut se retrouver bloqué. Avec un build automatique on peut détecter très vite le problème et envoyer un mail au coupable qui corrigera immédiatement son erreur et apportera les croissants le lendemain pour se faire pardonner.
Vous avez par exemple sous Jenkins un plugin chuck norris qui permet d’ajouter un peu de sérieux au statut des builds. Croyez moi, les développeurs y réfléchissent à deux fois avant de pousser leurs modifications.
4- Avez-vous une base de données de bugs ?
Un système de gestion d’anomalie, est un outil qui vous permet d’avoir une base de donnée des bugs détectés sur votre programme. Malheureusement encore beaucoup de développeurs ne comprennent pas son utilité et c’est une grave erreur. Je les mets au défit de retenir tous les bugs présents dans leur code ainsi que les informations qui en découlent:
- Quel est le problème rencontré?
- Quel est le comportement attendu?
- Depuis quelle version est-il apparue?
- Comment le reproduire? liste des étapes
- Quel est sa fréquence de reproduction? tout le temps? aléatoirement?
- Qui a remonté le problème et quand?
- Qui se charge de sa correction?
- Quel est son état? en cours de correction? déjà corrigé?
- Et plus encore
En plus d’apporter toutes ces informations un tel outil peut également utiliser des filtres, tries ou autres requêtes de base de donnée pour gérer plus facilement le projet et la liste des bugs.
Selons moi, même si vous travaillez seul sur un projet, un gestionnaire d’anomalie est clairement un incontournable. On peut citer par exemple Redmine ou encore Mantis.
5- Corrigez-vous vos bugs avant d’écrire du nouveau code ?
Cela signifie de corriger les bugs remontés sur la version actuelle de votre programme avant d’ajouter de nouvelles fonctionnalités. Ici par exemple on peut voir l’utilité d’avoir une base de gestion de bug.
Si vous développez 100% des fonctionnalités de votre programme avant de commencer à corriger les bugs vous allez vous retrouvez avec les problèmes suivants:
- Vous allez avoir ÉNORMÉMENT de bugs à corriger!
- L’historique du code aura tellement changé depuis la détection du bug que vous ne pourrez pas facilement isoler la partie des sources incriminées.
- La personne qui a développée la fonctionnalité qui pose problème ne fait peut être plus partie de l’équipe. Même si elle est toujours là, si cela fait plusieurs semaines ou plusieurs mois qu’elle a réalisé le développement, il y a de grandes chances qu’elle ne se souvient plus très bien de ce qu’elle a fait. Il y aura alors un temps plus ou moins important de reprises en main des sources.
- Et j’en passe
Alors que si vous corrigez les bugs avant l’ajout de nouvelles fonctionnalités:
- Le nombre de bug sera très limité
- L’historique du code étant réduit, vous pourrez isoler beaucoup plus facilement la partie qui pose problème.
- Les développements seront encore frais dans la tête des développeurs, qui pourront alors facilement apporter les corrections adéquates.
- Et j’en passe, comme par exemple le fait d’avoir un soft qui soit toujours présentable pour des démos client par exemple.
Si vous répondez par oui à cette question, vous gagnerez en temps de développement et en qualité de code. Tout en ayant en permanence un logiciel présentable.
6- Avez-vous un planning à jour ?
On appelle aussi cela la RoadMap d’un logiciel. C’est à dire le calendrier des sorties des différentes versionS de celui-ci avec pour chacune d’entre elle la liste des fonctionnalités qu’elle embarquera.
Cela permet alors de synchroniser les différentes équipes sur des livrables comme par exemple le commercial qui prépare un salon et les développeurs qui développent les fonctionnalités qui seront présentes dans la version de démo.
L’autre intérêt des plannings est qu’il vous force à prioriser les fonctionnalités à implémenter. Il n’y a pas de secret si vous souhaitez ajouter 4 fonctionnalités qui demandent chacune 1 semaine de développement mais que le salon est dans 2 semaines, vous n’avez pas le choix, il faut prioriser. Sans planning vous ne verrez pas que le jalon n’est pas tenable et risqueriez alors d’arriver sur le salon avec les deux fonctionnalités gadgets sans avoir les bases de votre programme. En gros rien de présentable…
7- Avez-vous une spec ?
Cela correspond au document d’entré qui décrit ce que doit faire le logiciel sous forme d’une liste d’exigences. Cette spec peut être très complète dans les cas de projets utilisants le cycle en V comme très simple pour des projets dit agiles, on parle alors de MVP (minimum viable product) ou en français produit minimum viable. En gros la liste minimale des fonctionnalités que doit avoir le logiciel.
Cette spec permet de mettre sur écrit ce que doit faire le logiciel et se poser ainsi certaines questions avant de commencer à coder. De plus ce listing est alors utilisable pour faire le planning du projet et donc comme on l’a vu dans le point précédent de prioriser les tâches.
Pour finir cette spec va également servir de base pour la rédaction des fiches de test pour la validation. En face de chaque exigence, on trouvera alors au moins un test. Lors de la rédaction des bugs dans le gestionnaire d’anomalie, on peut indiquer la fiche de test correspondant si il y en a une et donc ainsi remonter à l’exigence qui en découle. C’est ce que l’on appelle la traçabilité.
Les specs vous permettent alors de lister, préciser et prioriser les tâches à effectuer. De plus cela permet d’avoir une traçabilité et ainsi livrer un logiciel qui correspond aux attentes initiales.
8- Les programmeurs bénéficient-ils d’un environnement de travail calme ?
Ici rien de bien compliqué à comprendre. Une personne sera toujours plus productif dans un environnement propice à la concentration.
A noter qu’il faut environ 15min à une personne pour atteindre la concentration maximale et donc le rendement maximum. 15min ça peut paraître faible au regard d’une journée de travail. Mais le problème c’est que cet échauffement de 15min, vous n’en faite pas qu’une dans la journée. Nous somme régulièrement interrompus dans notre travail par de très nombreux perturbateurs, Téléphone, Réunion, Votre collègue qui vous propose une pause café ou déjeuné et j’en passe. A chaque interruption, vous allez devoir vous replonger dans ce que vous faisiez. ça vous demandera du temps et de l’énergie pour arriver à vous concentrer. Le double effet kiscool arrive alors, plus vous serez déconcentrés plus vous allez fatiguer et donc plus vous aurez de mal à vous remettre au travail à nouveau, jusqu’à arriver à un moment ou vous finirez par procrastiner ou glander sur le Net.
J’ai personnellement bénéficier d’une journée de télétravail pendant près de 2ans et je peux vous dire que j’étais clairement plus productif chez moi qu’à mon bureau car moins en prise avec des perturbations.
Je rajouterai également par rapport à l’auteur, la notion de confort au travail ou plutôt de poste de travail adapté à la personne. Encore une fois si vous avez une chaise qui n’est pas confortable et donc qui vous déconcentre, vous fatigue et vous crée des douleurs, vous allez moins bien travailler.
L’environnement de travail influe directement sur la productivité de votre équipe, il ne faut donc pas le négliger.
9- Utilisez-vous les meilleurs outils que vous puissiez vous payer ?
Pour préciser cette question, il faut se demander si votre équipe se paye les meilleurs outils (logiciel et matériel) dont elle a besoin et qu’elle peut s’offrir. l’idée ici n’est pas d’acheter le plus cher. Mais plutôt de faire un point sur les outils et se demander lesquels répondent le mieux à mes besoins et puis-je me les offrir. On voit bien trop souvent des entreprises ou des groupes faire de petites économies en achetant du matériel bas de gamme ou en utilisant que des logiciels gratuits. Attention, je ne dit pas que parfois les logiciels libres ne font pas l’affaire. Malheureusement ces petites économies à court terme entraînent des pertes parfois importantes à moyen ou long terme. Par exemple vous achetez un PC pas cher à 400€. celui-ci vous permet de faire une compilation en 10min alors qu’un autre PC à 600€ permettait quand à lui de faire la compilation de ce même logiciel en 8min. Ok ce n’est que 2min pour une compilation, mais il y a de grandes chances que vous réalisiez bien plus d’une compilation par jour, et ce, tous les jours de votre semaine de travail. Quand on vois le coup d’un développeur pour une entreprise soit environs 100€/h, vous imaginez bien que ces 200€ de PC seront très vite rentabilisés. De plus ici on ne prend pas en compte le fait que le développeur va attendre 10min sa compilation et donc potentiellement sortir de son temps de concentration (voir point 8).
Utiliser les meilleurs outils possibles pour votre équipe est la garantie d’un gain en efficacité et correspond certe a un investissement de base mais qui sera très vite rentabilisé. Si il y a bien une dépense dans laquelle il ne faut pas être radin c’est bien les outils.
Comme le dit le proverbe français: LES BONS OUTILS FONT LES BONS OUVRIERS
10- Avez-vous des testeurs ?
Ici on ne parle pas des développeurs qui font un ou deux test rapides de leur nouveaux développements mais bien de personnes dans votre équipe qui s’occupent de dérouler les tests rédigés à partir des exigences de la spec sur votre produit.
Faire faire la validation par les développeurs est une grosse erreur pour plusieurs raisons. la première, c’est que les développeurs connaissent le code ce qui les poussent, parfois, à biaiser leurs tests. Ils connaissent mieux que quiconque les faiblesses du programme et évite, bien souvent inconscient, les actions sensibles.
De plus, un bon testeur indique de manière factuel ce qu’il observe car il a un recul sur le code source alors que le développeur ne pourra pas s’empêcher d’interpréter ce qu’il voit et alors potentiellement mal orienter la personne qui fera le correctif.
Autre point qui me fait dire que c’est une vrai bêtise d’utiliser les développeurs pour la validation, c’est que c’est deux métiers différents avec des savoirs faire et des compétences propres.
Pour finir c’est une très mauvaise “économie” car un développeur coûtera plus cher d’un valideur et comme le dit l’auteur “Lésiner sur les testeurs est une économie si atrocement fausse que je suis tout simplement soufflé qu’il n’y ait pas plus de monde qui le reconnaisse.”
11- Les nouveaux candidats écrivent-ils du code pendant leur entretien d’embauche ?
Malheureusement, la majorité des entretiens pour des candidatures de développeur se réduisent à entrevue en face à face avec une personne des RH et normalement (je l’espère en tout cas) avec un représentant technique. Après plus de 50 entretiens passé dans ma carrière, je n’est eu le droit qu’à une seule écriture de code!
Vous achèteriez une maison uniquement sur description et photos de l’annonce? Ou utiliseriez vous les services d’un traiteur pour votre mariage sans avoir goûter avant ce qu’il fait? Je ne pense pas, alors pourquoi prendre des développeurs sans voir comment ils codent?
il est facile de faire un jolie CV dans lequel vous avez changé la face du monde. De même pour ,certaines personnes, il est très facile de faire bonne impression lors d’un entretien en face à face. Certains me diront “oui mais on peut poser des questions au candidat et voir si il mitonne ou pas” mouai…
Même si la personne a vraiment travaillé sur les projets en question, rien ne permet de savoir quel était la qualité de son code ou encore sa manière de résoudre les problèmes. Alors que si vous demandez au candidat de développer lors de l’entretien d’embauche, vous verrez par vous même, ce dont il est capable de faire.
Alors oui, il y a la période d’essai, mais ça restera une perte de temps pour tout le monde…
12 – Faites-vous des tests d’utilisabilité de couloir?
Cette question peut paraitre bizarre je vous l’accorde. Elle signifie tout simplement, prenez vous de temps en temps des personnes, au hasard et qui ne font pas partie des membre de l’équipe, pour leur faire tester votre logiciel.
Souvent avec simplement 5 ou 6 personnes, vous pourrez remonter presque 95% des problèmes (ergonomie ou bug) de votre produit. Il est important que ce soit des personnes externes (prises dans le couloir) au projet pour avoir un recule suffisant sur le produit.
C’est gratuit et ça apporte énormément d’informations sur la qualité et le ressenti de votre produit. Même si vous n’avez pas d’ergonome, si vous réalisez régulièrement des campagnes de test comme celle-ci, vous avez de très grandes chances d’arriver à un produit agréable à utiliser.
Calculer son score au test de Joël
Bien nous avons vu l’ensemble des questions. Pour Calculer votre score il faut faire la somme des points (oui=1 et non=0). Quel est votre score? plus de la moyenne?
Selon l’auteur un score de 10 ou moins, implique qu’une entreprise spécialisée dans le logiciel doit se remettre en question. Il faut savoir que les grandes entreprises de dev comme google ou Microsoft on un score de 12 mais que d’après l’auteur, la majorités des entreprises de développement ont un score autour de 3.
Vous allez me dire “mais un score de 10/12 c’est bien plus que la moyenne”. oui mais en même temps c’est compréhensible, en vu des points abordés, très peu peuvent être considérés comme optionnels pour une équipe de développement. je pense par exemple au logiciel de gestion de version. c’est clairement un indispensable pour tout projet de développement. Il faut voir ça comme une chaîne, si un maillon est fragile, c’est toute votre mécanique qui l’est également.
Encore une fois ce test est simplement à titre indicatif, il ne faut pas dramatiser si vous avez moins de 11. Il faut simplement regarder quel point est à améliorer et mettre en place des actions.
Selon moi un de ces gros point faible c’est de donner le même poids pour toutes les questions. Encore une fois, je considère que la gestion de version est incontournable et de ce fait, répondre non à la question un devrait être beaucoup plus pénalisant qu’un point.
Dans quels cas utiliser le test de Joël?
Voici quelques exemples de cas ou l’on peut utiliser le test de Joël:
- Si vous faite partie d’une entreprise, calculez le score de son équipe de développement pour faire un check up rapide. ça vous permet de voir les points faibles et alors de mettre des actions en place pour améliorer votre score.
- Si vous passez des entretiens d’embauche, cela permet d’avoir un petit aperçu de la qualité des équipes de développement de l’entreprise. Si le score est bas, tout n’est pas perdu, assurez-vous d’avoir assez d’autorité pour pouvoir arranger les choses . Sinon, vous allez être frustré et non productif. Bien entendu, ne demandez pas directement à la personne qui vous fait passer l’entretien “quel est votre score au test de joel?”. Posez simplement les questions et si jamais votre interlocuteur découvre votre petit jeu, pas de problèmes. il sait maintenant que vous connaissez le test et c’est un très bon point pour vous.
- Si vous êtes un investisseur essayant d’estimer la qualité d’une équipe de développement, ou si votre société envisage de fusionner avec une autre, ce test peut faire office de rapide estimation empirique.
- Si vous ête encore étudiant, cela permet de voir si ces notions indispensables pour tout développeurs sont bien enseignées dans votre école. Si ce n’est pas le cas il ne vous reste plus qu’a en parler à vos professeurs ou vous former par vous même.