Que pensez-vous sur le Test de Joël? [fermé]

Question

Le Joel test est un test bien connu pour déterminer la qualité de votre équipe. Que pensez-vous des points? Avez-vous n'êtes pas d'accord avec l'un d'eux? Y at-il que vous ajouteriez?

Answer 1

Jeff Atwood a Charte des droits du programmeur.

Du message:

  

  
1. Chaque programmeur doit avoir deux moniteurs
  
2. Chaque programmeur doit avoir un PC rapide
  
3. Chaque programmeur doit avoir le choix de leur 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 calme
  

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

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

Cela pourrait tout être ajouté en changeant:

# 9 actuel: Utilisez-vous les meilleurs outils de l'argent peut acheter

à

Amélioration # 9: Utilisez-vous les meilleurs Outils et de l'équipement l'argent peut acheter

Answer 2

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

8. Do programmers have quiet working conditions?

quand il utilisé pour lire (quelque chose comme)

8. Do programmers have their own office?

et le dernier paragraphe commence encore:

  

Maintenant, nous allons les déplacer dans des bureaux séparés avec des murs et des portes.

Je suis toujours méfiant de ce test comme dans tous les endroits où j'ai travaillé - à la fois comme employé et visiteur - les seules personnes avec leurs propres bureaux sont les administrateurs et les cadres supérieurs

.

logiciel d'écriture dans le monde réel est généralement une activité d'équipe, vous devez parler à vos coéquipiers aux idées de rebond autour, etc., et qui est plus difficile à faire avec des gens dans des bureaux séparés, même avec les systèmes de messagerie instantanée. Être en mesure de tirer les choses et montrer le code et les diagrammes des gens aide beaucoup. Cela ne veut pas dire que les équipes distribuées ne peuvent pas travailler -. Ils peuvent évidemment faire et, qui est juste un ensemble différent de problèmes

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

Si vous travaillez avec d'autres développeurs, mais chacun travaille sur des projets séparés, puis un bureau partagé peut être utile - mais seulement si vous êtes strict de prendre des réunions à la salle de réunion et le respect des autres etc délais des gens.

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

Answer 3

Je l'aime, mais si je l'utilise pour évaluer une entreprise que je ne serais pas aussi peser tous les éléments. Ne pas avoir le contrôle de la source est un problème beaucoup plus alors ne pas acheter les meilleurs outils de l'argent peut acheter.

Answer 4

Le seul deal-breaker pour moi est:

 8. Do programmers have quiet working conditions?

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

Certaines des questions sont difficiles à l'échec, surtout 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 que je ne se soucient pas vraiment. Je veux dire, honnêtement:

12. Do you do hallway usability testing?

Il y a un pour détecter les menteurs:

 5. Do you fix bugs before writing new code?

Answer 5

Je dois dire que c'est une bonne « base », mais avec un outil de mesure il y a d'autres facteurs. Par exemple pas une seule entreprise que je travaille pour a fait Daily Builds (je sais, je sais), mais certains d'entre eux ont été très bons.

J'ai personnellement quelques autres articles que je voudrais ajouter à une liste.

1. Est-ce que vous soutenez l'éducation des développeurs en assistant à des conférences, l'achat de livres, ou quelque chose de cette nature?
2. Avez-vous un processus simple et documenté pour adopter de nouveaux outils si nécessaire pour les fonctions d'emploi complet
3. Avez-vous fournir des équipements pour les développeurs et un environnement qui leur permettra d'être productifs.

Plus que tout ce sont des articles ont ont « me marre » des employeurs précédents, et bien ils sont maintenant Accélérez questions que je pose au sujet de chaque occasion.

Answer 6

Je suis d'accord avec la plupart des points de Joel. Je ne suis pas sûr de « tests d'utilisabilité de couloir ». Test d'utilisation, bien sûr, mais saisissant effectivement quelqu'un dans le couloir et les faire tester votre programme, même si ce n'est pas leur travail? Cela semble être une excellente façon de cocher les gens.

Answer 7

Bien que je pense qu'il est bon sens dans le sens général, je trouve la liste tout à fait centrée sur le genre spécifique du logiciel Fog Creek Software fait ( shrinkwrap ). Ce n'est pas vraiment surprenant, car il parle aussi que sur un autre poste, Cinq Mondes . Et il y a beaucoup de développements en dehors de ce monde.

Il y a des conditions qui ne font pas vraiment beaucoup de sens si vous développez par exemple logiciel embarqué pour un satellite ou d'un distributeur automatique, comme construit journalier (3) ou épreuves de facilité d'utilisation (12).

Answer 8

Le test Joel ne teste pas la qualité d'une équipe. Il teste comment votre équipe adhère au Test de Joël.

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

1) Est-ce le logiciel que vous écrivez bien?

Il est hors de propos pour moi si vous « test de couloir » ou non, ou quel contrôle de source que vous avez, ou ce que votre processus de construction est (s'il y en a un - pas tous les Lanugage a). La vraie mesure d'une équipe est la qualité du logiciel qu'ils créent.

En fait, vous pouvez suivre chaque étape du test Joel, et encore jusqu'à la fin avec le code de la merde et des produits qui ne navire. Par exemple, le contrôle de la source ne fait pas comme par magie un meilleur codeur; il est plus facile de gérer le code. Et ayant 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 .