Le test de Joel

⚠️ AVERTISSEMENT - Le texte ci-dessous a été publié il y a vingt ans le 9 août 2000 par Joel Spolsky, développeur de logiciels à New York (The Joel Test: 12 Steps to Better Code) sur la problématique du développement informatique. Traduit par Serge Wautier, il a été publié le 22 décembre 2008. Les opinions exprimées ci-dessous ne reflètent en aucun cas l'opinion de Michel Campillo, ni ne reflète nécessairement la réalité du développement de logiciels vingt ans plus tard. Ce texte propose une série de points à vérifier quand on fait de la programmation, avant de mettre un dev en prod et éviter de devoir corriger un bug critique en production. 😄

Builds quotidiens? Bases de données de bugs? Allô je parle français?

Donnons la parole à Joel Spolsky:

Avez-vous déjà entendu parler du SEMA ? Il s'agit d'un système assez ésotérique permettant de mesurer la qualité d'une équipe de développeurs. Non, attendez ! Ne cliquez pas sur ce lien ! Cela vous prendra au moins sept ans rien que pour comprendre ce truc. J'ai donc créé mon propre test de mesure de qualité d'équipe de développement. Evidemment, ce test vaut ce qu'il vaut ! Son côté le plus intéressant est qu'il ne prend pas plus de 3 minutes. Et avec tout le temps que vous y gagnez, vous pouvez faire plein d'autres choses. Médecine, par exemple.

Ce qui est sympa avec le test de Joël, c'est qu'il ne faut ni estimer un nombre-de-lignes-de-code-par-jour ni calculer une moyenne-de-bugs-par-point-d'inflexion. Il suffit de répondre par oui ou par non à chaque question. Et pour chaque "oui", comptez un point de plus en faveur de votre équipe. Evidemment, le truc à ne pas faire avec le test de Joël, c'est d'évaluer la validité de votre logiciel de contrôle de centrales nucléaires.

Un score de 12 est parfait. 11 est tolérable. Mais avec 10 ou moins, vous avez de sérieux problèmes. Le fait est que la plupart des firmes qui font des logiciels ont un score de 2 ou 3. Et ils ont sérieusement besoin d'aide, parce que des sociétés telles que Microsoft tournent à 12 en permanence.

Un article de Joel Spolsky écrit il y a 20 ans mais n'a pas pris une ride, toujours autant pertinent.

Bien sûr, ce ne sont pas les seuls facteurs déterminants du succès ou de l'échec : En particulier, si vous avez une super équipe qui travaille sur un produit dont personne ne veut, eh bien, les gens n'en voudront pas. Et il est possible d'imaginer une équipe de "cow-boys" qui ne fait rien de tout ceci et qui réussit malgré tout à sortir un truc qui changera le monde. Mais, toutes autres choses étant égales, si vous suivez ces 12 règles, vous aurez une équipe disciplinée capable d'un niveau de qualité consistant.

Utilisez-vous un système de gestion de code source ?

J'ai utilisé des logiciels commerciaux de gestion de code source, et j'ai utilisé CVS, qui est gratuit. Et je vais vous dire ceci : CVS est suffisant . Mais si vous n'avez pas de gestion de code source, vous allez vous arracher les cheveux pour faire collaborer efficacement vos programmeurs. Les programmeurs n'ont aucun moyen de savoir ce que les autres font. Les erreurs ne peuvent pas être rattrapées facilement. L'autre avantage des systèmes de gestion de code source est que le code source lui-même est extrait sur le disque dur de chaque programmeur. Je n'ai jamais entendu parler d'un projet utilisant un gestionnaire de code source où une partie importante du code aurait été perdue.

Pouvez-vous faire un build en une seule étape ?

Je veux dire par là : Combien d'étapes vous faut-il pour créer une version livrable de votre produit à partir de l'état courant du code source ? Dans les bonnes équipes, il y a un script unique que vous pouvez lancer et qui extrait les sources complètes sur une base vierge, recompile chaque ligne de code, crée les EXEs sous toutes leurs formes, langues, et combinaisons d'#ifdef, et crée le programme d'installation et le média final -- layout CDROM, site web de téléchargement, ou quoi que ce soit d'autre.

Si le processus prend plus d'une étape, il est source d'erreurs. Et quand vous approchez de la date de livraison, vous voulez disposer d'un cycle aussi rapide que possible pour pouvoir réparer le "dernier" bug, créer l'EXE final,etc... Si cela vous prend 20 étapes pour compiler le code, lancer le créateur du programme d'installation,etc..., vous allez devenir dingue et vous commencerez à faire des erreurs stupides.

C'est pour cette raison précise que la dernière société pour laquelle j'ai travaillé est passée de Wise à InstallShield : Nous avons exigé que la création du programme d'installation puisse se faire automatiquement pendant la nuit, à partir d'un script, en utilisant le séquenceur de tâches de NT. Mais comme Wise ne pouvait pas tourner de nuit à partir du séquenceur, nous l'avons jeté (Les gars de chez Wise m'ont assuré que leur dernière version permet maintenant de faire des builds nocturnes.)

Faites-vous des builds quotidiens ?

Quand vous utilisez un gestionnaire de code source, il arrive qu'un programmeur fasse accidentellement un check-in qui corrompt le build. Par exemple, il ajoute un nouveau fichier source. Le tout se compile bien sur sa machine mais il oublie d'ajouter ce fichier dans le gestionnaire de code source. Il éteint sa bécane et rentre chez lui, le coeur léger. Mais plus personne d'autre ne peut travailler et tous les développeurs doivent donc également rentrer chez eux, en râlant.

Corrompre le build est si problématique (et si courant) qu'il est très utile d'en faire quotidiennement pour s'assurer qu'aucune erreur ne se soit dissimulée. Dans les grosses équipes, un bon moyen pour être sûr que de telles erreurs sont corrigées immédiatement consiste à effectuer un build chaque jour, par exemple pendant le déjeuner. Chacun fait autant de check-ins que possible avant de partir manger. Quand ils reviennent, le build est fait. Si tout a bien marché, tant mieux ! Chacun récupère la dernière version des sources et se remet au boulot. Si le build a échoué, vous le corrigez, mais chacun peut continuer à travailler avec la version du matin (qui se compile correctement).

Dans l'équipe Excel, nous avions comme règle que quiconque corrompait le build en devenait le baby-sitter à titre de "punition", et ce jusqu'à ce que quelqu'un d'autre le corrompe à son tour. C'était une bonne motivation pour faire gaffe et un bon moyen pour effectuer une rotation du personnel au travers de la procédure de construction du build pour que chacun en apprenne le fonctionnement.

Vous trouverez plus d'infos sur les builds quotidiens dans mon article Les builds quotidiens sont tes amis (article du 27 janvier 2001).

Avez-vous une base de données de bugs ?

Je me fous de ce que vous pensez. Si vous développez du code, même en équipe d'une seule personne, sans une base de données organisée reprenant tous les bugs connus dans votre code, vous livrerez du code de mauvaise qualité. Beaucoup de programmeurs s'imaginent qu'ils peuvent garder la liste des bugs en mémoire. Quelle idiotie ! Je suis incapable de me rappeler de plus de deux ou trois bugs à la fois et le lendemain matin, ou dans la hâte d'une livraison, je les oublie. Vous devez à tout prix garder rationnellement trace des bugs.

Les bases de données de bugs peuvent être simples ou compliquées. Le minimum vital doit comprendre les données suivantes pour chaque bug :

• La liste complète des étapes pour reproduire le bug
• Le comportement attendu
• Le comportement observé (erroné)
• La personne à qui il est assigné
• Son état : S'il a été corrigé ou pas

Si la complexité des logiciels de suivi de bugs est la seule chose qui vous empêche de garder trace de vos bugs, faites simplement un tableau à 5 colonnes avec ces champs cruciaux et utilisez-le dès maintenant.

Pour plus d'infos à propos du suivi de bugs, lisez Suivi de bugs sans peine (article publié le 8 novembre 2000).

Corrigez-vous vos bugs avant d'écrire du nouveau code ?

La toute première version de Microsoft Word pour Windows était considérée comme un projet "morituri te salutant". Cela a pris une éternité. Ca n'arrêtait pas de déraper. Toute l'équipe faisait une quantité effrayante d'heures sup's, le projet était reporté, et reporté, et reporté encore et toujours et la tension était incroyable. Quand la bête fut finalement prête, avec des années de retard, Microsoft envoya tout le monde en vacances à Cancun ( NdT: une super plage mexicaine), puis s'attela à une sérieuse autocritique.

Ils réalisèrent que les chefs de projet avaient tant insisté sur le respect du "planning" que les programmeurs se contentaient de se dépêcher en écrivant du très mauvais code, parce que la phase de correction ne faisait pas partie intégrante du planning. Il n'y avait aucune volonté de garder le compteur de bugs au plus bas. Au contraire. On raconte même qu'un programmeur qui devait écrire une fonction calculant la hauteur d'une ligne de texte écrivit tout simplement "return 12;" et attendit le rapport de bug lui indiquant que sa fonction ne marchait pas dans tous les cas. Le planning était en gros une liste de fonctionnalités attendant d'être transformées en bugs. Cette histoire passa à la postérité sous le nom de "méthodologie bugs à l'infini".

Pour rectifier le tir, Microsoft adopta de manière universelle un binz appelé la "méthodologie zéro fautes". Beaucoup de programmeurs ricanèrent car cela semblait vouloir dire que la direction croyait pouvoir diminuer la quantité de bugs par décret. En réalité, "zéro fautes" voulait dire qu'à tout instant, la priorité la plus haute était d'éliminer les bugs avant d'écrire du nouveau code.

En général, plus vous attendez pour corriger un bug, plus ça coûtera pour le corriger (en temps et en argent).

Par exemple, quand vous faites une faute de frappe ou de syntaxe que le compilateur détecte, la correction est tout à fait triviale.

Quand vous découvrez un bug dans votre code la première fois que vous le lancez, vous pouvez le corriger immédiatement puisque le code est encore frais dans votre esprit.

Si vous découvrez un bug dans du code que vous avez écrit quelques jours auparavant, ça vous prend un peu de temps pour traquer le problème . Mais quand vous relisez le code, vous vous souvenez de tout et vous pouvez le corriger dans un délai raisonnable.

Mais si vous êtes face à un bug dans du code écrit il y a quelques mois, vous aurez probablement oublié un tas de choses à propos de ce bout de programme et cela devient beaucoup plus difficile à corriger. Le pire se produit quand vous êtes en train de corriger le code d'un autre type et que le gaillard est en vacances à Djerba. Auquel cas, effectuer cette correction s'apparentera plus à de la recherche scientifique : Il faut être lent, méthodique et méticuleux, et vous n'êtes jamais sûr du temps que ça prendra pour trouver le remède.

Et si vous trouvez un bug dans du code qui est déjà livré, la correction va vous coûter des sommes folles.

Cela donne une raison pour corriger les bugs immédiatement : Parce que cela prend moins de temps. Il y en a une autre, relative au fait qu'il est plus facile de prévoir combien temps cela va prendre pour écrire du nouveau code que pour corriger un bug existant. Par exemple, si je vous demande de prévoir combien de temps il vous faut pour écrire une fonction de tri d'une liste, vous pourrez me donner une assez bonne estimation. Mais si je vous demande de prévoir combien de temps il faut pour corriger ce bug qui fait que votre programme ne marche pas si Internet Explorer 5.5 est installé, vous ne pouvez même pas deviner, parce que vous ne savez pas (par définition) ce qui cause le bug. Cela peut prendre 3 jours comme ça peut prendre 2 minutes.

Ce que ceci signifie, c'est que si votre planning contient un tas de bugs à corriger, ce planning n'est pas fiable. Mais si vous avez corrigé tous les bugs connus, et que tout ce qui reste au planning est du nouveau code à écrire, alors ce planning sera infiniment plus précis.

Un autre truc sympa à propos du compteur de bugs à zéro est que vous pouvez répondre beaucoup plus vite à la concurrence. Certains programmeurs considèrent ceci comme garder le produit prêt à la livraison à tout instant. Alors si votre concurrent présente une nouveauté qui est le nec plus ultra et qu'il vous pique vos clients, vous pouvez juste implémenter cette fonction et diffuser immédiatement votre logiciel sans devoir corriger un grand nombre de bugs accumulés.

Avez-vous un planning à jour ?

Ce qui nous amène aux plannings. Si votre code est un tant soit peu important pour le marché, il y a un tas de raisons pour lesquelles il est important que le marché sache quand ce code va être prêt. Les programmeurs sont notoirement évasifs quand il s'agit de faire des planning. "Ce sera prêt quand ce sera prêt!" crient-ils aux commerciaux.

Malheureusement, ça ne marche pas comme ça. Le commercial a beaucoup trop de choses à planifier bien à l'avance par rapport à la livraison du code : démos, salons, publicité, etc... Et le seul moyen d'y arriver est d'avoir un planning et de le tenir à jour.

L'autre aspect crucial des plannings est que ça vous force à décider quelles fonctionnalités vous allez réaliser et cela vous incite à laisser tomber les moins importantes plutôt que de glisser vers la fonctionnalitite (NdT : traduction de featuritis ou creeping featurism).

Maintenir un planning ne doit pas être compliqué. Lisez mon article Plannings sans peine (article publié le 29 mars 2000) qui décrit un moyen simple de faire de superbes plannings.

Avez-vous une spec ?

Ecrire des specs, c'est comme utiliser du fil dentaire: Tout le monde s'accorde à dire que c'est une bonne chose mais personne ne le fait.

Je ne suis pas sûr de savoir à quoi ça tient, mais c'est probablement parce que la plupart des programmeurs détestent écrire des documents. Quand des équipes constituées uniquement de programmeurs s'attaquent à un problème, ils préfèrent exprimer leur solution sous forme de code plutôt que sous forme de documents. Ils préfèrent beaucoup plus plonger dans l'écriture du code que produire d'abord une spec.

Lors de la phase de conception et d'analyse, quand vous découvrez un problème, vous pouvez le corriger facilement en modifiant quelques lignes de texte. Mais une fois que le code est écrit, le coût de la correction est considérablement plus élevé, aussi bien émotionnellement (les gens détestent jeter du code) qu'en terme de temps, d'où une certaine résistance à réellement corriger les problèmes. Un logiciel qui ne naît pas d'une spec se retrouve souvent mal conçu et le planning devient incontrôlable. Cela semble avoir été le problème chez Netscape, où les quatre premières versions furent développées dans un tel désordre que la direction décida stupidement (article écrit le 6 avril 2000 il y a 20 ans) de jeter le code et de recommencer à zéro. Et puis ils refirent la même erreur avec Mozilla, créant ainsi un monstre qui échappa à tout contrôle et prit plusieurs années avant d'atteindre la phase alpha.

Ma théorie favorite est que ce problème peut être corrigé en apprenant aux programmeurs à devenir moins réfractaires à l'écriture en les envoyant suivre un cours intensif d'écriture (NdT: Lien vers un cours alternatif de littérature dans une prestigieuse université américaine). Une autre solution consiste à engager des chefs de projets intelligents qui écrivent la spec eux-mêmes. Dans tous les cas, vous devriez insister sur cette règle simple : "Pas de code sans spec".

Apprenez tout ce qu'il y a à savoir sur l'écriture des specs en lisant ma série en 4 parties (article publié le 2 octobre 2000).

Les programmeurs bénéficient-ils d'un environnement de travail calme ?

Il est largement reconnu qu'on obtient un gain de productivité en fournissant aux emplois intellectuels de l'espace, du calme et de l'isolement. Peopleware, le grand classique de la gestion de personnel informatique décrit cette augmentation de productivité dans le détail.

Voilà le topo. Nous savons tous que les intellos travaillent mieux quand ils peuvent se percher sur leur nuage, quand leur concentration est totale et qu'ils oublient complètement leur environnement. Ils perdent la notion du temps et vous sortent alors le meilleur d'eux-mêmes. C'est comme cela qu'ils sont le plus productifs. Ecrivains, programmeurs, scientifiques et même sportifs vous le confirmeront.

Le problème est que ce n'est pas évident d'arriver sur ce nuage. Si on essaie de mesurer, on se rend compte qu'il faut en moyenne un quart d'heure pour atteindre son rendement maximum. Certains jours, si vous êtes fatigué, ou si vous avez déjà donné le meilleur de vous-même pour ce jour-là, vous ne parvenez tout simplement pas à vous replonger et vous passez le reste de la journée à glander, à naviguer sur le Web ou à jouer à Tetris.

L'autre problème, c'est qu'il est si facile de se faire sortir de son nuage. Le bruit, les coups de fil, sortir déjeuner, devoir marcher 5 minutes jusqu'au bistrot du coin pour boire un café, et les interruptions par les collègues -- surtout les interruptions par les collègues -- tout cela vous fait retomber de votre nuage. Si un collègue vous pose une question, vous interrompant pour 1 minute, cela peut vous déranger tellement qu'il vous faudra jusqu'à une demi-heure pour retrouver votre productivité. Et c'est votre rendement global qui s'en trouve méchamment affecté. Si vous êtes en plein vacarme, du genre qui était à la mode dans certaines dotcoms, avec les types du marketing qui beuglent au téléphone juste à côté des programmeurs, votre rendement plongera d'autant plus que les développeurs sont constamment interrompus et ne parviennent pas à retrouver leur concentration.

Et le problème des développeurs est particulièrement compliqué. Leur rendement dépend de leur capacité à jongler avec un tas de petits détails en même temps. Toute interruption, aussi minime soit elle, risque de faire s'écrouler ces petits détails. Quand vous vous remettez au travail, vous ne vous en souvenez plus (quels sont les noms des variables locales que vous étiez en trains d'utiliser , où en étiez-vous dans l'implémentation de cet algorithme de recherche, etc...) et vous devez vous remémorer ces choses, ce qui vous ralentit un grand coup avant que vous ne puissiez retrouver votre vitesse de croisière.

Voici la preuve par 9 : Supposons (comme le bon sens peut le suggérer) que si nous interrompons un programmeur, même pour une seule minute, on gaspille en réalité 15 minutes de rendement. Pour cet exemple, mettons en présence deux programmeurs, Pierre et Paul, assis dans des box voisins comme dans la bonne vieille batterie de poulets. Paul ne se rappelle plus du nom de la version Unicode de la fonction strcpy. Il peut regarder dans la doc, ce qui lui prendrait 30 secondes. Il peut aussi demander à Pierre, ce qui lui prendrait 15 secondes. Puisqu'il est assis à proximité de Pierre, il lui demande donc. Pierre se fait distraire et perd donc 15 minutes de productivité (pour faire gagner 15 secondes à Paul).

A présent, mettons-les dans des pièces séparées avec des murs et des portes. Maintenant, quand Paul ne se rappelle plus du nom d'une fonction, il peut regarder dans la doc, ce qui lui prendrait toujours 30 secondes. Ou il peut demander à Pierre, ce qui lui prendrait 45 secondes et impliquerait qu'il se lève (pas évident quand on connaît la condition physique du programmeur moyen !). Alors, il regarde dans la doc. Donc maintenant, Paul perd 30 secondes, mais Pierre gagne un quart d'heure. Ahhh!

Utilisez-vous les meilleurs outils que vous puissiez vous payer ?

Ecrire du code dans un langage compilé sur un ordinateur familial d'entrée de gamme ne sera jamais quelque chose de réaliste. Si la compilation dure plus de quelques secondes, acheter le dernier modèle vous fera gagner du temps. Même si cette compilation ne prend que 15 secondes, les programmeurs en auront vite marre et, pendant ce temps-là, ils iront lire Le Gorafi (NdT: Joël cite en réalité The Onion) où ils resteront scotchés, perdant ainsi des heures et des heures.

De même, déboguer du code gérant une interface utilisateur graphique (IUG; NdT: GUI en anglais) avec un seul écran n'est vraiment pas évident. C'est même impossible. Si vous écrivez des IUGs, un système à deux écrans vous facilitera énormément la vie.

La plupart des programmeurs manipulent un jour ou l'autre des images pour leurs icônes ou barres d'outils. Et la plupart des programmeurs ne disposent pas d'un éditeur d'images valable. Utiliser Microsoft Paint pour manipuler des images est une douce illusion, mais c'est ce que font la plupart des programmeurs.

A mon dernier boulot (article publié le 19 mars 2000), l'administrateur réseau n'arrêtait pas de m'inonder d'e-mails automatiques pour se plaindre du fait que je consommais plus de... tenez-vous bien...220 mégaoctets sur le disque dur du serveur. Je lui ai fait remarquer que vu les prix des disques durs de nos jours, cet espace disque était nettement moins cher que le papier toilette que j'utilisais. Consacrer même ne fut-ce que 10 minutes à nettoyer mon répertoire serait une monstrueuse perte de temps.

Dans les supers équipes de développement, on ne torture pas les programmeurs. Même les frustrations mineures causées par des outils non adaptés s'additionnent, rendant les programmeurs grincheux et de mauvaise humeur. Et un programmeur grincheux est un programmeur non productif.

Et en plus de tout cela... les programmeurs sont facilement attirés par le matos dernier cri. C'est un moyen bien meilleur marché de les faire bosser pour vous que de leur payer un salaire compétitif!

Avez-vous des testeurs ?

Si votre équipe ne dispose pas de testeurs attitrés, au moins un pour deux ou trois programmeurs, soit vous livrez des produits bogués, soit vous gaspillez de l'argent en faisant faire aux programmeurs un boulot qui pourrait être fait par des testeurs et qui vous coûteraient trois fois moins cher. 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.

Lisez Les cinq principales (mauvaises) raisons pour lesquelles vous n'avez pas de testeurs (article écrit le 30 avril 2000 il y a 20 ans), un article que j'ai écrit à ce sujet.

Les nouveaux candidats écrivent-ils du code pendant leur entretien d'embauche ?

Tu engagerais un magicien sans lui demander de te montrer un tour de magie ? Bien sûr que non.

Tu oserais engager un traiteur pour ton mariage sans goûter ses plats ? J'en doute fort (Sauf s'il s'agit de Maïté, car elle te détestera à jamais si tu ne la laisses pas faire sa "célèbre" tourte à l'anguille).

Et pourtant, chaque jour, des programmeurs sont embauchés sur la base d'un CV impressionnant ou parce que l'interviewer a apprécié la conversation qu'ils ont eue ensemble. Ou bien on leur pose des questions ridicules (ex.: "Quelle est la différence entre CreateDialog() et DialogBox()?") dont les réponses peuvent être trouvées en regardant simplement dans la doc. On se fout qu'ils aient mémorisé des milliers de trivialités à propos de la programmation. Ce qui importe, c'est s'ils sont capables de produire du code. Pire encore, on leur pose souvent des questions à la "AHA!" : Le genre de questions qui semblent évidentes quand on connaît la réponse, mais qui sont insolubles quand on ne la connaît pas.

De grâce, arrêtez ça. Faites ce qui vous chante pendant l'entrevue, mais faites écrire du code au candidat. (Pour de plus amples conseils, lisez mon Manuel de survie à l'intention de l'interviewer, article écrit le 23 mars 2000 il y a 20 ans.)

Faites-vous des tests d'utilisabilité de couloir?

Un test d'utilisabilité de couloir consiste à attraper le premier venu dans le couloir et à le forcer à essayer le bout de code qu'on vient d'écrire. Si vous faites ça avec cinq personnes, vous découvrirez 95% de ce qu'il y a à savoir à propos des problèmes d'utilisabilité de votre programme.

Créer une bonne interface utilisateur n'est pas aussi difficile que vous pourriez le croire et c'est fondamental si vous voulez que vos clients aiment votre produit et l'achètent. A ce sujet, vous pouvez lire mon livre gratuit disponible en ligne (article écrit le 10 avril 2020) sur la conception des interface utilisateurs, une courte introduction pour les programmeurs.

Mais la chose la plus importante à retenir à propos des interfaces utilisateur est que si vous montrez votre programme à quelques personnes (en fait, cinq ou six suffisent), vous découvrirez rapidement les plus gros problèmes que les gens peuvent rencontrer avec. L'article de Jakob Nielsen explique pourquoi. Même si vous n'êtes pas doué pour les interfaces utilisateur, tant que vous vous forcez à faire des tests d'utilisabilité de couloir, ce qui ne coûte rien, votre IU sera meilleure. Bien meilleure.

Quatre manières d'utiliser le test de Joël :

• ➥ Calculez le score de votre boîte et envoyez-le moi, histoire qu'on en tchatche.
• ➥ Si vous dirigez une équipe de programmeurs, utilisez-le comme check-list pour vous assurer que votre équipe travaille dans les meilleures conditions. Si vous obtenez un 12, vous pouvez les laissez en paix et vous consacrer à plein temps à empêcher les commerciaux de venir les déranger.
• ➥ Si vous voulez vous décider pour un emploi, demandez à votre employeur potentiel quel score il obtient. Si ce score est trop faible, assurez-vous d'avoir assez d'autorité pour pouvoir arranger les choses . Sinon, vous allez être frustré et non productif.
• ➥ 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.

Attention! Texte initialement publié en anglais le 9 août 2000 et traduit puis re-publié le 22 décembre 2008. ⚠️ Le texte ci-dessus ne reflètent en aucun cas l'opinion de Michel Campillo. Je n'en suis pas l'auteur. Voir l'avertissement en début de page.

Aix en Provence, le 23 avril 2020

Michel Campillo, consultant d'entreprise
Logiciels de Gestion
☎ 06 89 56 58 18   
✉ contact par email

➽ Autres billets pour consultants ERP travaillant sur des bases de données Oracle: Comment changer la taille de police dans Oracle SQL Developer?, Configuration de SQL Developer pour MySQL, SkySQL : Oracle n'aura pas la peau de MySQL.

Ce post vous a aidé? Alors partagez-le avec d'autres utilisateurs en cliquant sur les boutons ci-dessous:

Merci de vos partages! Maintenant à vous de commenter. 😍



🎯 Autres options: un logiciel ERP travaux publics et un logiciel de gestion BTP.
✇ En télétravail depuis le 29 octobre (confinement Covid-19)

Copyright © 2004-2021 Michel Campillo, tous droits réservés