Dans quelle mesure le test Joel est-il à jour? [fermé]


17

Je veux convaincre mes partenaires que nous devrions avoir une spécification et que les bugs devraient être corrigés avant d'écrire un nouveau code. Dois-je me référer au test Joel ? Pensez-vous que le test Joel est à jour? Je pense que ne pas avoir de spécification est une mauvaise gestion de projet. Êtes-vous d'accord avec le test Joel? Pourriez-vous ajouter quelque chose? Il ne mentionne pas par exemple l'Open Source.


2
Le test Joel est axé sur les processus de développement de logiciels et d'embauche de développeurs. Comment la manière dont vous concédez votre licence de logiciel ou si vous publiez ou non votre source est-elle liée à cela?
Marjan Venema

Merci Marjan pour la question. Je pensais que depuis que le test Joel a été conçu, l'open source a été une tendance et si quelqu'un est très négatif à propos de l'open source, je voudrais probablement savoir comment une équipe s'oppose à l'open source, si c'est le cas. Je suis d'accord que les problèmes de droits d'auteur pourraient être au-delà de la portée, mais le programmeur ne peut pas travailler avec une équipe qui pense que l'open source est une question de pouvoir voir la source et la question 13 pourrait être "Avez-vous un système de sauvegarde?" et 14 "Avez-vous une sécurité plus forte que MD5?" où les réponses devraient être oui.
Niklas

1
Ok, ça a du sens. Les efforts open source devraient non seulement être «consommés», mais également y contribuer, mais pas nécessairement avec du code (pensez au soutien monétaire). Les systèmes de sauvegarde sont importants, mais ne se limitent pas au développement et en tant que tels, je ne les ajouterais pas au test Joel. Mais si j'interviewais avec une entreprise qui ne faisait rien sur les sauvegardes, je courrais pour la porte. Sécurité que je n'ajouterais pas non plus. Pour la sécurité développée par le logiciel, cela peut ne pas être un problème (applications internes), et donc il ne se prête pas à une réponse oui / non, plus la sécurité ne doit pas être spécifique au développement.
Marjan Venema

Merci d'avoir partagé les connaissances avec moi. Il est vrai que la sauvegarde est importante mais pas spécifique au développement.
Niklas

De nombreuses bonnes questions génèrent un certain degré d'opinion basé sur une expérience d'expert, mais les réponses à cette question auront tendance à être presque entièrement basées sur des opinions, plutôt que sur des faits, des références ou une expertise spécifique.
moucher

Réponses:


23

Je pense que le test Joel est à jour - il est aussi à jour que la plupart des autres logiciels d'écriture qui sont "intemporels".

Faire du développement de produits (qui comprend le développement de logiciels) sans spécification n'est que de la folie.

Comment savez-vous où vous voulez aller?

Il n'y a qu'un seul point que je ferai sur l'écriture d'une spécification (je ne pense pas que les spécifications de Joel soient très bonnes ... mieux que rien, mais pas aussi bonnes que possible). Ce point est:

Lors de la rédaction d'une spécification, dites uniquement ce que le produit doit faire, pas comment il doit être fait.

Cela signifie que vous ne dictez pas les détails d'implémentation dans une spécification. C'est une activité de design et vous laissez cela à l'expérience et à la créativité des designers.

[Il n'y a qu'une seule exception à cette règle: Parfois, un détail ou une méthode d'implémentation particulier est obligatoire ou requis, auquel cas mettez-le dedans. Par exemple, si le logiciel doit être écrit en PHP et que ce n'est pas négociable, alors il va dans la spécification. Il devrait y avoir très peu d'exemples de cela.]

Je pourrais ajouter: ne pas avoir de suivi des bogues est un acte de folie égale. C'est tout simplement la façon la moins professionnelle et la plus insensée de fonctionner et cela entraînera de grandes douleurs et de grandes souffrances.


Merci pour la réponse très rapide et précieuse. Un autre exemple de folie qui m'est arrivé est la déclaration selon laquelle tout devrait avoir la même priorité. C'est comme faire le contraire de ces règles folles qui mènera au succès.
Niklas

4
"tout a la même priorité" - aussi connu comme "tout est n ° 1". C'est franchement des conneries. Tout doit être priorisé, brutalement, en termes de DOMMAGES AUX ENTREPRISES. Ensuite, vous travaillez sur le # 1. Si vous êtes arrêté sur le # 1 pour une raison quelconque, vous travaillez sur le # 2. Etc. Si vous avez des gens qui ne peuvent pas travailler sur le n ° 1 pour une raison quelconque et qui finissent par travailler sur le n ° 9 - c'est OK à condition qu'il y ait une bonne raison. ("J'en avais envie et son cooooooool" n'est pas une bonne raison). Il est également OK de redéfinir les priorités. Le faire plus fréquemment qu'une fois par semaine est aussi de la folie.
quick_now

Merci pour la sagesse. Je suis tout à fait d'accord pour que tout soit prioritaire. Mon partenaire a également déclaré que nous ne devrions pas avoir de problèmes et pas de suivi des problèmes. Mais je pense que la documentation des problèmes est juste et même le leader du marché conserve un tracker de problèmes. Encore une fois, faire le contraire de la règle fonctionnera ...
Niklas

@ 909Niklas Vous devriez probablement chercher à trouver un autre partenaire, pour garder votre vie future plus confortable ...
Marcel

+1 juste pour: Lorsque vous rédigez une spécification, dites seulement ce que le produit doit faire, pas comment il doit être fait.
Marcel

5

Je vais jouer l'avocat du diable ici et suggérer que le test Joel n'est pas à jour. C'est trop général. À mesure que la technologie a mûri, les questions devraient être plus précises que lorsqu'il a écrit le test.

Les documents de spécifications, au moins les gros documents de spécifications initiaux ne sont plus nécessaires maintenant que nous avons des user stories et des processus de développement Agile. Cette question doit être remplacée par "Le niveau de documentation est-il approprié aux solutions en cours de conception?" Les user stories plus petites et plus étroites, livrées toutes les deux semaines, sont beaucoup plus utiles dans la plupart des cas qu'un document de grande taille décrivant le produit en détail. Cependant, si vous construisez le prochain Mars Rover, vous voudrez peut-être un document de conception détaillé à l'avance. Si vous demandez si une entreprise a des spécifications de conception, je ne serais pas surpris d'entendre une réponse de «pas vraiment, nous utilisons plutôt des processus agiles et des histoires d'utilisateurs».

Deuxièmement, la question des «constructions quotidiennes» devrait devenir une question d'intégration continue. À moins que vous ne construisiez un logiciel qui prend des heures à construire (ce que 99,99% des lieux ne feront pas), la question devrait se demander si l'entreprise utilise l'intégration continue.

La plupart du test de Joel n'est vraiment pas daté du tout. C'est toujours un bon moyen d'avoir une idée de l'environnement de travail.

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.