Author: 
Fabrice Moll

Malgré ce titre accrocheur, le but de cet article n'est pas de juger de l'efficacité des équipes de développement :)

Il y a plusieurs années, Joel Spolsky (co-fondateur de StackOverflow) a écrit un article contenant un test afin de mesurer la qualité d'une équipe de développement.

Le test consiste à répondre par "oui" ou "non" aux 12 questions suivantes :

The Joel Test

  1. Utilisez-vous une gestionnaire de sources?
  2. Pouvez-vous créer un exécutable utilisable par un client en une action?
  3. Est-ce que vous réalisez une compilation chaque jour?
  4. Avez-vous une base de données répertoriant les bugs?
  5. Est-ce que vous corrigez les bugs avant de créer une nouvelle fonctionnalité?
  6. Avez-vous un planning des développements à réaliser?
  7. Avez-vous une description technique/fonctionnelle du travail à réaliser?
  8. Est-ce que les développeurs travaillent dans un environnement calme?
  9. Est-ce que vous utilisez les meilleurs outils que vous pouvez acheter?
  10. Avez-vous des testeurs?
  11. Est-ce que les nouveaux candidats écrivent du code lors de l'entretien d'embauche?
  12. Faites-vous des tests de couloir?

Lorsque vous répondez "oui" à l'un de ces points, vous ajoutez 1 point de plus à votre équipe.

La perfection est un résultat de 12, 11 est acceptable mais pour une note en dessous de 10 vous rencontrerez certainement un jour des problèmes.

Utilisez-vous une gestionnaire de sources

Un gestionnaire de sources va vous permettre de centraliser les différentes modifications réalisées par votre équipe de développement.
Vous pourrez consulter facilement les modifications réalisées et vous pourrez également (et rapidement) annuler une modification.

Pouvez-vous créer un exécutable utilisable par un client en une action

En combien d'étapes pouvez-vous générer un exécutable (ou setup) que vous pouvez installer chez un client ?
Si cela nécessite plus d'une étape, vous risquez de commettre des erreurs.  Surtout si les opérations se font dans l'empressement.

Est-ce que vous réalisez une compilation chaque jour

Le but de cette opération est de détecter les erreurs de compilation rapidement.
Imaginez Alfred qui ajoute le nouveau logo de l'application.  Alfred est heureux et montre sont chef-d'oeuvre à ses collègues.  
Génial, cela fonctionne parfaitement sur sa machine ! Cependant, Alfred n'a pas vu qu'il était 19 heures et qu'il était temps de rentrer.
Afred ajoute sa modification dans le gestionnaire de source mais n'ajoute pas le nouveau logo tant attendu !

Le lendemain matin, Alfred est en congé et ses collègues récupèrent les dernières modifications d'Alfred.  Et là c'est le drame... l'application ne peut pas être exécutée car l'image est inexistante.

Ceci est un simple exemple et je vous laisse imaginer ce que cela peut provoquer lorsque les modifications sont plus conséquentes.

Donc une compilation chaque jour ou à chaque modification (de façon automatique bien sûr) peut vous éviter cette perte de temps.

Avez-vous une base de données répertoriant les bugs

Ne pas avoir une base de données des problèmes rencontrés et/ou signalés par les utilisateurs n'a pas de sens.

Cela peut rester simple :

  • Etapes pour reproduire le bug
  • Comportement attendu
  • Comportement observé
  • Qui est en charge de la résolution de ce point
  • Est résolu ou non

Si vous avez une petite équipe, vous n'êtes même pas obligé d'acheter un produit pour réaliser ce suivi : un simple fichier Excel suffit.

Est-ce que vous corrigez les bugs avant de créer une nouvelle fonctionnalité

Créer une nouvelle fonctionnalité dans une partie de l'application contenant des bugs peut engendrer d'autres problèmes.  De plus, plus vous attendez pour corriger un problème plus il vous sera difficile de le solutionner.

Avez-vous un planning des développements à réaliser

Coder c'est bien ! Avoir un planning des développements à réaliser c'est mieux !

Vous aurez une vue passée et futur des développement réalisés/à réaliser.  Et il vous sera également plus facile de définir les priorités en fonction des délais demandés/accordés.

Avez-vous une description technique/fonctionnelle du travail à réaliser

Souvent, lorsqu'on un problème est soumis à un programmeur, ce dernier aura la fâcheuse tendance à foncer tête baissée dans le code (nous le faisons tous).

Cependant, j'ai constaté qu'il est bien plus clair et simple de d'abord écrire une documentation technique et/ou fonctionnelle du besoin.

Cela peut se faire en utilisant des cas d'utilisation, des diagrammes de classes,...

Est-ce que les développeurs travaillent dans un environnement calme

Nous avons tous besoin de calme dans notre travail.  La moindre interruption peut vous faire perdre le fils de vos idées et cela nécessitera un certains temps avant de retrouver votre état de concentration maximum.

Est-ce que vous utilisez les meilleurs outils que vous pouvez acheter

En voilà une bonne question ! Pourquoi acheter une licence Photoshop pour votre designer alors que Paint est gratuit sous Windows ?

Si votre développeur, designer,... a besoin d'un outil spécifique pour travailler, ne cherchez pas un équivalent gratuit ou meilleur marché.  
C'est une perte de temps avant de commencer à travailler et la courbe d'apprentissage du produit gratuit sera également importante.

Avez-vous des testeurs

Pour ce point je vous recommande cet article très intéressant à ce sujet (en anglais) Top Five (Wrong) Reasons You Don't Have Testers.

Est-ce que les nouveaux candidats écrivent du code lors de l'entretien d'embauche

Il est important de permettre au candidat d'écrire du code lors de l'entretien cela vous permettra de voir ce que la personne est capable de faire lorsque vous lui soumettez un cas à réaliser.

Il faut quand même prendre ce point avec des pincettes car l'entretien est un moment stressant et pourrait ne pas refléter la réalité.

Peut être que le candidat pourrait également vous parler/montrer des projets sur lequel il a travaillé (et pourquoi pas des projets Open source?)

Faites-vous des tests de couloir

Si vous voulez savoir ce qui peut clocher dans votre nouvelle interface, nouvelle fonctionnalité,.... Il vous suffit d'attraper une personne dans le couloir et vous lui faite tester votre nouvelle interface, fonctionnalité,...

Vous serez parfois (agréablement) surpris des remarques que ces personnes peuvent vous faire.
Le nouvelle écran d'encodage des factures sera certainement une révolution aux yeux du programmeur mais il sera peut être très compliqué à utiliser.

______________________________________________________________________________________________________________________________________________________________

Les exemples donnés pour chaque point ne sont pas absolu et je suis sûr qu'il y a matière à discuter.  N'hésitez donc pas à me faire part de vos remarques/questions :)

Alors bien sûr, il ne suffit pas d'appliquer ce test à la lettre pour avoir une équipe de choque.  Il a bien d'autres critères à prendre en compte et s'arrêter à ce test serait une grossière erreur !

Cependant, je pense que ce test peut servir de base de travail.

Alors... Prêt à faire le test ?

 

Newsletter