Que pensez-vous du test Joël? [fermé]


51

Le test Joel est un test bien connu pour déterminer la qualité de votre équipe. Que penses-tu des points? Êtes-vous en désaccord avec l'un d'entre eux? Y at-il quelque chose que vous voudriez ajouter?

Réponses:


41

Jeff Atwood a la Charte des droits du programmeur .

De la poste:

  1. Chaque programmeur doit avoir deux moniteurs
  2. Chaque programmeur aura un PC rapide
  3. Chaque programmeur aura son choix de souris et de 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 certains éléments que j'aimerais voir sur la liste de Joel. Spécifiquement dans le domaine du matériel (double moniteur, PC rapide, souris / clavier, fauteuil confortable, connexion rapide).

La seule chose qui n’a pas été mentionnée est d’avoir un bureau confortable et réglable .

Tout cela pourrait être ajouté en changeant:

Actuel # 9: Utilisez-vous les meilleurs outils que l’argent peut acheter?

à

Amélioré # 9: Utilisez-vous les meilleurs outils et équipements que l’ argent peut acheter?


Votre n ° 6 n'est-il pas identique au n ° 8 du test Joel:
HerbN le

C'est le numéro 6 de Jeff Atwood, et oui, c'est le cas.
Spong

Il semble que le test Joel soit plus spécifique pour aider les programmeurs à développer un logiciel propre et sans bug, par opposition aux conditions de travail, à l'exception du point 8
Archmede

13

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.

Je me suis toujours méfié de ce test car, dans tous les endroits où j'ai travaillé - en tant qu'employé et visiteur - les seules personnes ayant leur propre bureau sont les directeurs et les cadres supérieurs.

Écrire un logiciel dans le monde réel est généralement une activité d'équipe. Vous devez parler à vos coéquipiers pour échanger des idées, etc., ce qui est plus difficile à faire avec des personnes se trouvant dans des bureaux distincts, même avec des systèmes de messagerie instantanée. Être capable de dessiner des choses et de montrer aux gens des codes et des diagrammes aide beaucoup. Cela ne veut pas dire que les équipes distribuées ne peuvent pas fonctionner - elles le peuvent et le font, c’est 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 ce soit la taille de l'équipe). De cette façon, ils peuvent interagir sans déranger les autres équipes (le cas échéant) 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 par la porte d'entrée).

Si vous travaillez avec d'autres développeurs, mais que chacun travaille sur des projets distincts, un bureau partagé peut s'avérer utile, mais uniquement si vous êtes strict sur le fait de prendre des réunions dans la salle de réunion et de respecter les délais impartis par d'autres personnes, etc.

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


9
Le problème avec les idées qui rebondissent chez les coéquipiers est que leur demander verbalement est une énorme distraction. Si vous avez besoin d'une collaboration sérieuse, travaillez dans un espace de collaboration. Mais pour les questions "hé comment feriez-vous cela", vous êtes beaucoup mieux avec IM.
Matt Olenik

@Matt - Pour les petites choses que vous avez raison, mais les espaces de bureau sont toujours rares - aucune entreprise ne veut dépenser de l'argent sur des bureaux vides - c'est pourquoi il est utile de disposer d'équipes dans leur propre espace. Vous pouvez transformer le bureau en "espace de collaboration".
ChrisF

2
Vous ne pouvez jamais dire huit personnes dans la même pièce, n'est-ce pas? Je suis déjà ennuyé de partager une salle avec trois autres programmeurs (chacun travaillant sur son propre matériel, l'un travaillant sur un projet complètement indépendant et l'autre sur le type serveur / base de données). Je sais avec certitude que si je partageais la pièce avec sept autres gars, je me contenterais de la poste.
Baelnorn le

1
@ChrisF: c'est peut-être le problème. Nous quatre, assis dans la même pièce, n’avons pratiquement rien à faire entre eux en matière de programmation. Cela ressemble plus à 4 personnes travaillant sur 2 projets 1/2 assis dans la même pièce. Et maintenant, ajoutez un patron qui n’a absolument pas d’importance à tenir des discussions d’une demi-heure avec un autre programmateur juste à côté de votre bureau, bien que la salle de réunion se trouve de l’autre côté du couloir . >. <
Baelnorn

1
@ChrisF - "Écrire un logiciel dans le monde réel est une activité d'équipe, vous devez parler à vos coéquipiers pour échanger des idées, etc., ce qui est beaucoup plus difficile avec des personnes occupant des bureaux distincts." - Alors, comment fonctionnent les équipes de développement réparties sur différents sites? J'ai travaillé en étroite collaboration avec des personnes aux États-Unis, au Brésil et en Inde (messagerie instantanée et Adobe Connect), ainsi que dans des locaux partagés, allant de petites à très grandes équipes distribuées. Le vôtre est un environnement très perturbateur. Travailler en équipe peut être fait efficacement, mais ce que vous prescrivez est tout sauf (votre idée vient de la chute des années 70)
luis.espinal

10

J'aime ça, mais si je l'utilisais pour évaluer une entreprise, je ne pèserais pas également tous les éléments. Ne pas avoir le contrôle de la source est un problème beaucoup plus important que de ne pas acheter les meilleurs outils que l’argent peut acheter.


9

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 un échec par l’affichage des offres de débordement de pile.

Certaines des 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 ne m'intéressent 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?

20
Je pense que vous seriez surpris de voir combien d'entreprises ne peuvent pas construire en une seule étape et n'ont pas de base de données de bogues. Vous avez probablement raison sur le contrôle de source, mais je dirais que de nombreuses entreprises l'utilisent simplement pour sauvegarder leur code et ne font même pas disparaître les avantages du contrôle de source.
Rob Sobers

1
Lorsque j'ai commencé à occuper mon poste actuel, nous avions un système de contrôle de source, mais des constructions ont été réalisées sur la machine d'un type et lui seul connaissait toutes les étapes et les bugs étaient suivis sur papier. Celles-ci sont toutes "réparées" maintenant, mais je ne prendrais jamais ces choses pour acquises.
HappyCat

6

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

J'ai personnellement quelques autres éléments à ajouter à une liste.

  1. Soutenez-vous la formation des développeurs en assistant à des conférences, en achetant des livres ou quelque chose du genre?
  2. Avez-vous un processus simple et documenté pour adopter de nouveaux outils si nécessaire pour effectuer des tâches
  3. Fournissez-vous aux développeurs du matériel et un environnement leur permettant d’être productifs?

Plus que tout, ce sont des articles qui m'ont "énervé" des employeurs précédents et, bien, ce sont maintenant des questions rapides que je pose à propos de chaque opportunité.


1
Est-ce que 3 n'est pas déjà dans la liste?
Casebash

Oui, sous une forme ou une autre c'est. Mais j'énumère le mien un peu différemment, alors je l'ai laissé là.
Mitchel Sellers

5

Je suis d'accord avec la plupart des points de Joel. Je ne suis pas si sûr de "tests d'utilisabilité de couloir". Des tests d’utilisabilité, bien sûr, mais en fait, attrapez une personne dans le couloir pour qu’elle teste votre programme, même si ce n’est pas leur travail? Cela semble être un excellent moyen de cocher les gens.


1
C’est sûrement une affaire culturelle - si elle n’est pas trop perturbante et si elle fait partie du fonctionnement de l’entreprise, elle ne devrait pas "décourager les gens" - surtout si le but de l’entreprise est le développement d’applications.
Murph

1
Peut-être que le fait est que cela devrait faire partie du travail des autres?
JeffO

7
le point essentiel des tests de convivialité des couloirs est qu'il doit s'agir d'une personne qui n'utilise pas le programme régulièrement. Une fois que vous l'avez construite et / ou avez passé des heures à l'utiliser (comme un testeur dédié), votre point de vue sur l'application va être faussé
GSto

5

Le test de Joël ne teste pas la qualité d'une équipe. Il teste à quel point 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?

Peu importe si vous testez un couloir ou non, ou quel contrôle de source vous avez, ou quel est votre processus de construction (s'il en existe un - tous les langues ne les ont pas). La véritable mesure d’une équipe est la qualité du logiciel qu’elle crée.

Fondamentalement, vous pouvez suivre chaque étape du test Joel tout en vous retrouvant avec un code de merde et des produits qui ne sont jamais expédiés. Par exemple, le contrôle de source ne fait pas d'un magicien un meilleur codeur; cela rend le code plus facile à gérer. Et disposer de la dernière version de Visual Studio ne signifie pas que votre application fonctionnera mieux que si elle avait été écrite avec Visual Studio 2005 .


14
Vous manquez le point. Le test Joel ne concerne pas la qualité du logiciel, mais l’ efficacité du processus de production. Une équipe qui échoue au test Joel peut tout de même produire de bons produits, mais il est probable que cela prendra beaucoup plus de temps et que les ouvriers seront misérables. En outre, les outils ne font pas uniquement référence aux logiciels. Cela signifie également le matériel, de votre ordinateur à votre bureau et votre clavier.
Matt Olenik

Je pense que vous manquez le point. Si une équipe termine ses projets à temps et produit un logiciel de bonne qualité, ils sont, par définition, efficaces. Et ils ont, par définition, un processus efficace.
GrandmasterB

2
Vous n'avez jamais mentionné l'expédition à l'heure. De plus, je serais extrêmement surpris de voir une équipe efficace qui a complètement échoué au test de Joël. Des éléments tels que le contrôle de version, les tests et la convivialité sont essentiels. Les autres éléments peuvent également constituer de gros obstacles.
Matt Olenik

C'est un bon point, mais la principale faiblesse est sa subjectivité. Tout le monde peut avoir une opinion différente de la qualité du logiciel, en fonction de son expérience, de son niveau de compétence et de sa perspective d'utilisation. Mais j'aime le point.
Bernard Dy

Si leur processus efficace n’est efficace que pour les membres de l’équipe, en particulier si l’équipe est petite, dans quelle mesure résistera-t-il à la croissance ou en cas de catastrophe ou de retraite prématurée? Etre capable de produire du code qui fonctionne bien et qui est livré à temps via un processus qui n'existe que dans la tête des personnes qui le développent est une recette pour un désastre, une équipe qui tôt ou tard (probablement plus tôt) sera confrontée à un problème dont la plupart des gens ne peut pas, ou ne veut simplement pas, récupérer.
Finni McFinger

5

Bien que je pense que cela ait du sens au sens général, j'ai trouvé la liste assez centrée sur le type de logiciel spécifique que Fog Creek Software ( shrinkwrap ) fait. 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.

Certaines conditions n’ont pas vraiment de sens si vous développez, par exemple, un logiciel embarqué pour satellite ou un distributeur automatique, comme des versions quotidiennes (3) ou des tests d’utilisabilité (12).


D'accord. Une fois que vous vous éloignez des applications "top of the stack", de nombreuses idées contemporaines semblent devenir un peu ... peu pertinentes.
Paul Nathan le

Je suis d'accord. Il y a beaucoup de postes de développeur dans les magasins informatiques d'entreprise ... certainement pas aussi glamour que de faire des films rétractables. Comme la plupart de ces entreprises ne font pas partie du secteur des logiciels, la plupart d’entre elles obtiennent un score de 4 au test de Joël.
Bernard Dy

6
Pourquoi ne pas créer des tests unitaires pour les logiciels embarqués (et les faire exécuter automatiquement par un système de génération)?
Peter Mortensen
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.