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

Il mio punto di vista come un agilista:

Do you use source control?

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

Can you make a build in one step?

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

Do you make daily builds?

Se riusciamo a farlo in un solo passaggio, possiamo programmarlo.

Do you have a bug database?

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

Do you fix bugs before writing new code?

Sì, hanno la priorità nel backlog del prodotto

Do you have an up-to-date schedule?

Sì sempre, grazie al backlog del prodotto, al backlog di iterazione, al piano di rilascio e all'ampliamento stime accurate che vengono con esso grazie a Planning Poker.

Do you have a spec?

Sì, ogni User Story ha più dettagli se necessario. Incoraggiamo anche la comunicazione tra il proprietario del prodotto e il team.

Do programmers have quiet working conditions?

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

Do you use the best tools money can buy?

Sì, mentre valutiamo le persone sugli strumenti, non preoccuparti Joel, acquistiamo una licenza per tutti i tuoi prodotti;)

Do you have testers?

Sì e sono parte integrante del team.

Do new candidates write code during their interview?

Sì, e il team è coinvolto nel processo.

Do you do hallway usability testing?

Sì, i nostri tester ci aiutano con quello.

Hai una pianificazione aggiornata?

Questo è Agile. Scrum ci impone di impegnarci per un rilascio. Avere un programma aggiornato significa sapere cosa verrà fatto (e non verrà fatto) nel rilascio e come appare il backlog.

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, dirompente e fastidioso.

Hai dei tester?

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

In che modo questo 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.

• Pianificazione significa avere una chiara definizione di quali funzionalità si prevede di affrontare. Questo sicuramente raggiungibile.
• "Le condizioni di lavoro silenziose" non riguardano il suono sul posto di lavoro, ma rimuovono il rumore non di progetto e di programmazione. Si tratta di impedire ai programmatori di utilizzare lo sforzo per bloccare le distrazioni
• I negozi agili dovrebbero essere testati in anticipo e avere qualcuno che non sia lo sviluppatore a testare il codice è davvero ciò di cui parla Joel.

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

È altamente improbabile che lavorerai da sprint a sprint con assolutamente nessuna idea di dove vuoi andare con il tuo prodotto. Sì, dovrai rivedere e rivedere il programma dopo ogni sprint, ma ne avrai ancora uno.

Avendo una dichiarazione del tipo "nel primo trimestre prevediamo di rilasciare le funzionalità A, B, C e nel secondo trimestre stiamo considerando le caratteristiche X, Y, Z" è ancora un programma. Ci sono tutte le possibilità che X diventi W, ma è quello che ti permette di fare Agile.

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

Credo che lo vedrò da una prospettiva diversa da quella della maggior parte qui. Se stai segnando un 9 sul test di Joel, sei davanti alla curva. Un sacco di posti farebbe fatica a colpire un 5 o 6, figuriamoci da 9 a 12.

Stai facendo fatica ad assumere brave persone? Se no, allora un 12 sul test di Joel, mentre 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.