Un negozio agile può davvero segnare 12 nel Joel Test? [chiuso]

Mi piace molto il test Joel, lo uso da solo e incoraggio il mio staff e gli intervistati a considerarlo attentamente. Tuttavia, non credo di poter mai segnare più di 9 perché alcuni punti sembrano contraddire l'Agile Manifesto, XP e TDD, che sono i fondamenti del mio mondo.

In particolare: le domande su programma, specifiche, tester e condizioni di lavoro silenziose sono in contrasto con ciò che stiamo cercando di creare e i valori che abbiamo adottato per essere veramente agili.

Quindi la mia domanda è se per un vero negozio Agile è possibile ottenere un punteggio di 12?

Modificare:

Su consiglio di un risponditore di seguito sto aggiungendo un link al mio blog in cui ho scritto in origine su questo e che mi ha portato a voler pubblicare la domanda qui.

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

Lo inserisco perché sono d'accordo con gran parte di ciò che è stato detto di seguito e volevo dichiarare la mia posizione.

Il mio punto di vista come agilista:

Usi il controllo del codice sorgente?

Sì, ovviamente, integrazione continua, parte di XP ha bisogno di un sistema di controllo del codice sorgente per poter eseguire il commit del codice.

Puoi creare una build in un solo passaggio?

Sì, il server di integrazione continua è lì per quello.

Realizzi build giornaliere?

Se possiamo farcela in un solo passaggio, possiamo programmarla.

Hai un database di bug?

Sì, qualsiasi strumento di gestione del "progetto Agile" può tenere traccia dei bug e aggiunto nel backlog del prodotto Scrum

Correggi i bug prima di scrivere un nuovo codice?

Sì, hanno la priorità nel backlog del prodotto

Hai un programma aggiornato?

Sì sempre, grazie al backlog di prodotto, all'arretrato di iterazioni, al piano di rilascio e alle stime accurate che ne derivano grazie a Planning Poker.

Hai una specifica?

Sì, ogni User Story viene fornita con ulteriori dettagli, se necessario. Incoraggiamo anche la comunicazione tra il proprietario del prodotto e il team.

I programmatori hanno condizioni di lavoro silenziose?

Sì, una stanza con 8 sviluppatori è generalmente molto silenziosa. Cerchiamo di non mettere gli addetti alle vendite nella stessa stanza.

Usi i migliori strumenti che il denaro può comprare?

Sì, mentre diamo valore alle persone rispetto agli strumenti, non preoccuparti Joel, acquistiamo una licenza di tutti i tuoi prodotti;)

Hai tester?

Sì e sono parte integrante del team.

I nuovi candidati scrivono codice durante il loro colloquio?

Sì, e il team è coinvolto nel processo.

Fai test di usabilità in corridoio?

Sì, i nostri tester ci aiutano in questo.

Hai un programma aggiornato?

Questo è agile. Scrum ci richiede di impegnarci in una versione. Avere una pianificazione aggiornata significa sapere cosa sarà fatto (e non sarà fatto) nella versione e come appare l'arretrato.

Hai una specifica?

Questo è agile. Un'architettura (e la descrizione associata) è essenziale. Questo specifica il modulo. I casi d'uso (o le storie degli utenti) sono essenziali e specificano la funzionalità.

I programmatori hanno condizioni di lavoro silenziose?

Non riesco a vedere come Agile richieda un ambiente rumoroso, distruttivo e fastidioso.

Hai tester?

Um. Quando facciamo TDD, noi siamo i tester. Quando consegniamo il codice al proprietario del prodotto, possono essere coinvolti tester aggiuntivi prima che siano coinvolti i clienti.

In che modo ciò contraddice i metodi Agile o il manifesto Agile?

Penso che la risposta sia sì, un negozio Agile dovrebbe essere in grado di farlo. In particolare per i tuoi punti.

• Pianificare significa avere una chiara definizione di quali funzionalità si intende affrontare. Questo sicuramente raggiungibile.
• Le "condizioni di lavoro silenziose" non riguardano il suono sul posto di lavoro, ma la rimozione del rumore non di progetto / programmazione. Si tratta di impedire ai programmatori di fare sforzi per bloccare le distrazioni
• I negozi Agile dovrebbero testare in anticipo e avere qualcuno diverso dallo sviluppatore che sta testando il codice è davvero il punto su Joel.

Perché pensi che avere un programma (per fare un esempio) sia incompatibile con lo sviluppo Agile?

È altamente improbabile che tu stia lavorando dallo sprint allo sprint senza assolutamente idea di dove vuoi andare con il tuo prodotto. Sì, dovrai rivisitare e rivedere il programma dopo ogni sprint, ma ne avrai ancora uno.

Avere una dichiarazione come "in Q1 intendiamo rilasciare le funzionalità A, B, C e in Q2 stiamo attualmente esaminando le funzionalità X, Y, Z" è ancora un programma. Ci sono tutte le possibilità che X diventi W, ma questo è ciò che l'essere Agile ti consente di fare.

Prendendo un'altra cosa dalla tua lista - Specifiche. Che cos'è una User Story se non una specifica?

Immagino che lo guarderò da una prospettiva diversa rispetto alla maggior parte qui. Se stai segnando un 9 nel test Joel, sei in vantaggio sulla curva. Molti posti avrebbero difficoltà a colpire un 5 o un 6, figuriamoci un 9 a 12.

Stai avendo difficoltà ad assumere brave persone? Altrimenti, un 12 al Joel Test, pur essendo un obiettivo nobile, potrebbe non essere un problema. Se i tuoi dipendenti sono in grado di funzionare nell'ambiente che hai, direi un buon lavoro per il punteggio più alto che hai.