it-swarm.dev

Que pensez-vous du test Joel?

Le Joel Test est un test bien connu pour déterminer la qualité de votre équipe. Que pensez-vous des points? Êtes-vous en désaccord avec l'un d'eux? Y a-t-il quelque chose à ajouter?

52
Casebash

Jeff Atwood a La Déclaration des droits du programmeur .

De la poste:

  1. Chaque programmeur doit avoir deux moniteurs
  2. Chaque programmeur doit avoir un PC rapide
  3. Chaque programmeur doit avoir le choix entre la souris et le clavier
  4. Chaque programmeur doit avoir une chaise confortable
  5. Chaque programmeur doit avoir une connexion Internet rapide
  6. Chaque programmeur doit avoir des conditions de travail silencieuses

Cela semble avoir quelques éléments que j'aimerais voir sur la liste de Joel. Plus précisément dans le domaine du matériel (double moniteur, PC rapide, souris/clavier, chaise confortable, connexion rapide).

La seule chose non mentionnée est d'avoir un bureau confortable et réglable .

Tout cela pourrait être ajouté en modifiant:

Actuel # 9: Utilisez-vous les meilleurs outils que l'argent puisse acheter?

à

Amélioration # 9: Utilisez-vous les meilleurs outils et l'équipement l'argent que vous pouvez acheter?

41
spong

Il est intéressant de noter que le point 8 se lit maintenant:

8. Do programmers have quiet working conditions?

quand il lisait (quelque chose comme)

8. Do programmers have their own office?

et le dernier paragraphe commence toujours:

Maintenant, déplaçons-les dans des bureaux séparés avec des murs et des portes.

J'ai toujours été méfiant de ce test car dans tous les endroits où j'ai travaillé - en tant qu'employé et visiteur - les seules personnes ayant leurs propres bureaux sont les directeurs et les cadres supérieurs.

L'écriture de logiciels dans le monde réel est généralement une activité d'équipe, vous devez parler à vos coéquipiers pour faire rebondir des idées, etc., ce qui est plus difficile à faire avec des personnes dans des bureaux séparés, même avec des systèmes de messagerie instantanée. Être capable de dessiner des choses et de montrer du code et des diagrammes aux gens aide beaucoup. Cela ne veut pas dire que les équipes réparties ne peuvent pas travailler - elles le peuvent et le font évidemment, c'est juste un ensemble de problèmes différent.

Ce que je dirais, c'est que chaque équipe doit être dans son propre bureau de 6-8 personnes (en supposant que c'est la taille de l'équipe). De cette façon, ils peuvent interagir sans déranger les autres équipes (s'il y en a) et poursuivre leur travail sans être dérangés par l'équipe des ventes ou les visiteurs (à un endroit où j'ai travaillé, vous êtes entré directement dans la zone de développement).

Si vous travaillez avec d'autres développeurs, mais que chacun travaille sur des projets distincts, un bureau partagé peut être utile - mais uniquement si vous êtes strict quant à la prise de réunions dans la salle de réunion et au respect des délais des autres, etc. .

La plupart des autres sont des vérités évidentes.

13
ChrisF

Je l'aime bien, mais si je l'utilisais pour évaluer une entreprise, je ne peserais pas tous les articles également. Ne pas avoir le contrôle des sources est un problème beaucoup plus important que de ne pas acheter les meilleurs outils que l'argent puisse acheter.

10
JeffO

Le seul casse-tête pour moi est:

 8. Do programmers have quiet working conditions?

Intéressant, c'est la question la plus susceptible d'être échouée par les offres d'emploi de Stack Overflow.

Certaines questions sont difficiles à échouer, en particulier s'il y a plus d'un programmeur dans l'entreprise:

 1. Do you use source control?
 2. Can you make a build in one step?
 4. Do you have a bug database?

La plupart des autres dont je ne me soucie pas vraiment. Je veux dire, honnêtement:

12. Do you do hallway usability testing?

Il y en a un pour détecter les menteurs:

 5. Do you fix bugs before writing new code?
9

Je dois dire que c'est une bonne "ligne de base", mais avec tout outil de mesure, il y a d'autres facteurs. Par exemple, pas une seule entreprise pour laquelle j'ai travaillé n'a réalisé Daily Builds (je sais, je sais), mais certaines d'entre elles ont été très bonnes.

J'ai personnellement quelques autres éléments que j'ajouterais à une liste.

  1. Soutenez-vous l'éducation des développeurs en assistant à des conférences, en achetant des livres ou quelque chose de ce genre?
  2. Avez-vous un processus simple et documenté pour adopter de nouveaux outils si nécessaire pour compléter les fonctions du poste
  3. Fournissez-vous aux développeurs de l'équipement et un environnement qui leur permettront d'être productifs.

Plus que tout ce sont des articles qui m'ont "énervé" par les employeurs précédents, et bien ce sont maintenant des questions accélérées que je pose sur chaque opportunité.

6
Mitchel Sellers

Le test Joel ne teste pas la qualité d'une équipe. Il teste la façon dont votre équipe adhère au test Joel.

Voici un meilleur test de la qualité de votre équipe. Je l'appelle le test GrandmasterB. Il a une question.

1) Le logiciel que vous écrivez est-il bon?

Cela ne m'importe pas que vous testiez le couloir ou non, quel contrôle de source vous avez ou quel est votre processus de construction (s'il y en a un - toutes les langues ne les ont pas). La vraie mesure d'une équipe est la qualité du logiciel qu'elle crée.

Fondamentalement, vous pouvez suivre chaque étape du test Joel et vous retrouver avec du code de merde et des produits qui ne sont jamais expédiés. Par exemple, le contrôle des sources ne fait pas comme par magie un meilleur codeur; il facilite la gestion du code. Et avoir la dernière version de Visual Studio ne signifie pas que votre application fonctionnera mieux que si elle a été écrite avec Visual Studio 2005 .

5
GrandmasterB

Bien que je pense que cela a du bon sens dans le sens général, j'ai trouvé la liste assez centrée sur le type spécifique de logiciel que Fog Creek Software fait ( shrinkwrap ). Ce n'est pas vraiment surprenant, car il en parle également dans un autre article, Five Worlds. Et il y a beaucoup de développements en dehors de ce monde.

Il y a des conditions qui n'ont vraiment pas beaucoup de sens si vous développez par exemple logiciel embarqué pour un satellite ou un distributeur automatique, comme les versions quotidiennes (3) ou les tests d'utilisabilité (12).

5
Khelben

Je suis d'accord avec la plupart des points de Joel. Je ne suis pas sûr des "tests d'utilisabilité du couloir". Des tests d'utilisabilité, bien sûr, mais en fait, saisir quelqu'un du couloir et le faire tester votre programme, même si ce n'est pas son travail? Cela semble être un excellent moyen de cocher les gens.

5
Tim Goodman