Une boutique agile peut-elle vraiment obtenir 12 sur le test Joel? [fermé]

J'aime vraiment le test Joel, je l'utilise moi-même et j'encourage mon personnel et les personnes interrogées à y réfléchir attentivement. Cependant, je ne pense pas pouvoir jamais marquer plus de 9 parce que quelques points semblent contredire le Manifeste Agile, XP et TDD, qui sont les fondements de mon monde.

Plus précisément: les questions sur le calendrier, les spécifications, les testeurs et les conditions de travail silencieuses vont à l'encontre de ce que nous essayons de créer et des valeurs que nous avons adoptées pour être véritablement agiles.

Ma question est donc de savoir s'il est possible pour une véritable boutique Agile de marquer 12?

Éditer:

Sur recommandation d'un répondeur ci-dessous, j'ajoute un lien vers mon blog où j'ai écrit à ce sujet à l'origine et qui m'a poussé à publier la question ici.

http://simonpalmer.com/2011/03/16/why-i-will-never-score-more-than-9-on-the-joel-test/

Je mets cela parce que je suis d'accord avec une grande partie de ce qui a été dit ci-dessous et je voulais déclarer ma position complète.

Mon point de vue en tant qu'agiliste:

Utilisez-vous le contrôle de code source?

Oui, bien sûr, une intégration continue, une partie de XP a besoin d'un système de contrôle de source pour pouvoir y valider du code.

Pouvez-vous créer un build en une seule étape?

Oui, le serveur d'intégration continue est là pour ça.

Faites-vous des builds quotidiens?

Si nous pouvons le faire en une seule étape, nous pouvons le planifier.

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

Oui, tout outil de gestion de "projet Agile" peut suivre les bogues et être ajouté dans le backlog du produit Scrum

Corrigez-vous les bugs avant d'écrire un nouveau code?

Oui, ils sont priorisés dans le backlog produit

Avez-vous un calendrier à jour?

Oui toujours, grâce au backlog produit, au backlog d'itération, au plan de release et aux estimations précises qui l'accompagnent grâce à Planning Poker.

Avez-vous une spécification?

Oui, chaque User Story est fournie avec plus de détails si nécessaire. Nous encourageons également la communication entre le propriétaire du produit et l'équipe.

Les programmeurs ont-ils des conditions de travail tranquilles?

Oui, une salle avec 8 développeurs est généralement très calme. Nous essayons de ne pas mettre les vendeurs dans la même pièce.

Utilisez-vous les meilleurs outils que l'argent peut acheter?

Oui, alors que nous valorisons les individus par rapport aux outils, ne vous inquiétez pas Joel, nous achetons une licence de tous vos produits;)

Avez-vous des testeurs?

Oui et ils font partie intégrante de l'équipe.

Les nouveaux candidats écrivent-ils du code lors de leur entretien?

Oui, et l'équipe est impliquée dans le processus.

Faites-vous des tests d'utilisabilité des couloirs?

Oui, nos testeurs nous aident avec ça.

Avez-vous un calendrier à jour?

C'est Agile. Scrum nous oblige à nous engager sur une version. Avoir un calendrier à jour signifie savoir ce qui sera fait (et ne sera pas fait) dans la version, et à quoi ressemble l'arriéré.

Avez-vous une spécification?

C'est Agile. Une architecture (et la description associée) est essentielle. Cela spécifie le formulaire. Les cas d'utilisation (ou user stories) sont essentiels et précisent la fonctionnalité.

Les programmeurs ont-ils des conditions de travail tranquilles?

Je ne vois pas comment Agile nécessite un environnement bruyant, perturbateur et ennuyeux.

Avez-vous des testeurs?

Hum. Quand nous faisons TDD, nous sommes testeurs. Lorsque nous remettons le code au propriétaire du produit, des testeurs supplémentaires peuvent être impliqués avant que les clients ne soient impliqués.

Comment cela contredit-il les méthodes Agiles ou le manifeste Agile?

Je pense que la réponse est oui, une boutique Agile devrait pouvoir le faire. Plus précisément à vos points.

• La planification consiste à avoir une définition claire des fonctionnalités que vous prévoyez de traiter. C'est certainement réalisable.
• Les «conditions de travail silencieuses» ne concernent pas le son sur le lieu de travail, elles éliminent le bruit non lié aux projets / à la programmation. Il s'agit d'empêcher vos programmeurs d'avoir à faire des efforts pour bloquer les distractions
• Les boutiques agiles devraient tester tôt et avoir quelqu'un d'autre que le développeur testant le code est vraiment le but de Joel.

Pourquoi pensez-vous qu'avoir un planning (pour prendre un exemple) est incompatible avec le développement Agile?

Il est très peu probable que vous travailliez de sprint en sprint sans aucune idée de l'endroit où vous souhaitez aller avec votre produit. Oui, vous devrez revoir et réviser le calendrier après chaque sprint, mais vous en aurez toujours un.

Ayant une déclaration comme "au T1, nous prévoyons de publier les fonctionnalités A, B, C et au T2, nous examinons actuellement les fonctionnalités X, Y, Z" est toujours un calendrier. Il y a toutes les chances que X devienne W, mais c'est ce qu'être Agile vous permet de faire.

Prendre une autre chose de votre liste - Spécifications. Qu'est-ce qu'une User Story sinon une spécification?

Je suppose que je vais regarder cela sous un angle différent que la plupart ici. Si vous marquez un 9 au test Joel, vous êtes en avance sur la courbe. Beaucoup d'endroits auraient du mal à atteindre un 5 ou un 6, sans parler de 9 à 12.

Avez-vous de la difficulté à embaucher de bonnes personnes? Si ce n'est pas le cas, alors un 12 sur le test Joel, bien qu'un objectif noble, ne soit pas vraiment un problème. Si vos employés sont capables de fonctionner dans l'environnement que vous avez, je dirais un bon travail pour obtenir un score aussi élevé que vous.