Cosa ne pensi del test Joel? [chiuso]


51

Il Joel Test è un test ben noto per determinare quanto è brava la tua squadra. Cosa ne pensi dei punti? Non sei d'accordo con nessuno di loro? C'è qualcosa che vorresti aggiungere?

Risposte:


41

Jeff Atwood ha The Programmer's Bill of Rights .

Dal post:

  1. Ogni programmatore deve avere due monitor
  2. Ogni programmatore deve avere un PC veloce
  3. Ogni programmatore deve scegliere il mouse e la tastiera
  4. Ogni programmatore deve avere una sedia comoda
  5. Ogni programmatore deve disporre di una connessione Internet veloce
  6. Ogni programmatore deve avere condizioni di lavoro tranquille

Questo sembra avere alcuni elementi che mi piacerebbe vedere nell'elenco di Joel. In particolare nell'area dell'hardware (doppio monitor, PC veloce, mouse / tastiera, sedia comoda, connessione veloce).

L'unica cosa non menzionata è avere una scrivania comoda e regolabile .

Tutto ciò potrebbe essere aggiunto modificando:

Current # 9: Usi i migliori strumenti che il denaro può comprare?

per

Migliorato n. 9: usi gli strumenti e le attrezzature migliori che il denaro possa comprare?


Il tuo numero 6 non è identico al numero 8 nel test Joel:
HerbN,

È il numero 6 di Jeff Atwood, e sì, lo è.
spong

Sembra che il test Joel sia più specifico per aiutare i programmatori a sviluppare software pulito e privo di bug rispetto alle condizioni di lavoro, tranne # 8
Archmede,

13

È interessante che il punto 8 ora reciti:

8. Do programmers have quiet working conditions?

quando era solito leggere (qualcosa del genere)

8. Do programmers have their own office?

e l'ultimo paragrafo inizia ancora:

Ora spostiamoli in uffici separati con pareti e porte.

Sono sempre stato sospettoso di questo test in quanto in tutti i posti in cui ho lavorato - sia come dipendente che come visitatore - le uniche persone con i loro uffici sono i direttori e i senior manager.

Scrivere software nel mondo reale è di solito un'attività di gruppo, devi parlare con i tuoi compagni di squadra per far rimbalzare idee ecc. E questo è più difficile da fare con le persone in uffici separati anche con i sistemi di messaggistica istantanea. Essere in grado di disegnare e mostrare codice e diagrammi alle persone aiuta molto. Questo non vuol dire che i team distribuiti non possano funzionare - ovviamente possono e lo fanno, è solo una serie diversa di problemi.

Quello che vorrei dire è che ogni squadra deve essere nel proprio ufficio di 6-8 persone (supponendo che sia la dimensione della squadra). In questo modo possono interagire senza disturbare gli altri team (se ce ne sono) e andare avanti con il loro lavoro senza essere disturbati dal team di vendita o dai visitatori (in un posto in cui ho lavorato sei arrivato direttamente dall'area di sviluppo).

Se stai lavorando con altri sviluppatori, ma ognuno sta lavorando a progetti separati, allora un ufficio condiviso può essere utile - ma solo se sei severo nel prendere riunioni nella sala riunioni e rispettare le scadenze di altre persone ecc.

La maggior parte degli altri sono verità evidenti.


9
Il problema di far rimbalzare le idee dai compagni di squadra è che CHIEDERLO verbalmente è una grande distrazione. Se devi collaborare seriamente, lavora in uno spazio di collaborazione. Ma per "hey come faresti questo" domande stai molto meglio con IM.
Matt Olenik,

@Matt - Per le piccole cose che hai ragione, ma lo spazio per gli uffici è sempre scarso - nessuna azienda vuole spendere soldi in uffici vuoti - ecco perché avere squadre nel proprio spazio aiuta. Puoi trasformare l'ufficio in uno "spazio di collaborazione".
ChrisF

2
Non puoi mai significare otto persone nella stessa stanza, vero? Sono già infastidito dalla condivisione di una stanza con altri tre programmatori (ognuno dei quali lavora sulla propria roba, con uno che lavora su un progetto completamente non correlato e un altro è il ragazzo backend / database). So per certo che se avessi condiviso la stanza con altri sette ragazzi sarei andato solo in posta.
Baelnorn,

1
@ChrisF: forse questo è il problema. Tutti e quattro seduti nella stessa stanza non abbiamo quasi nulla a che fare l'uno con l'altro, per quanto riguarda la programmazione. È più come 4 persone che lavorano su 2 1/2 progetti seduti nella stessa stanza. E ora aggiungi un capo a cui non dispiace assolutamente tenere discussioni di mezz'ora con un altro programmatore proprio accanto alla tua scrivania nonostante la sala riunioni sia proprio dall'altra parte del corridoio . >. <
Baelnorn,

1
@ChrisF - "Scrivere software nel mondo reale è un'attività di gruppo, devi parlare con i tuoi compagni di squadra per far rimbalzare idee ecc. E questo è molto più difficile con le persone in uffici separati." - Quindi, come funzionano i team di sviluppo sparsi in diverse località? Ho lavorato a stretto contatto con persone negli Stati Uniti, in Brasile o in India (IM e Adobe Connect) e co-localizzato, da team distribuiti di piccole a molto grandi. Il tuo è un ambiente molto dirompente. Lavorare in gruppo può essere fatto in modo efficiente, ma quello che stai prescrivendo è tutt'altro che (la tua idea è proprio quella di
precipitare

10

Mi piace ma se lo usassi per valutare un'azienda non peserei ugualmente tutti gli articoli. Non avere il controllo del codice sorgente è un problema molto più grande quindi non acquistare i migliori strumenti che il denaro può comprare.


9

L'unico affare per me è:

 8. Do programmers have quiet working conditions?

Interessante è la domanda che molto probabilmente fallirà con le offerte di lavoro di Stack Overflow.

Alcune delle domande sono difficili da fallire, in particolare se c'è più di un programmatore nell'azienda:

 1. Do you use source control?
 2. Can you make a build in one step?
 4. Do you have a bug database?

La maggior parte degli altri non mi interessa davvero. Voglio dire, onestamente:

12. Do you do hallway usability testing?

Ce n'è uno per rilevare i bugiardi:

 5. Do you fix bugs before writing new code?

20
Penso che rimarrai sorpreso da quante aziende non possono creare una build in un solo passaggio e non hanno un database di bug. Probabilmente hai ragione sul controllo del codice sorgente, ma direi che molte aziende lo usano semplicemente per eseguire il backup del loro codice e non graffiano nemmeno la superficie dei vantaggi del controllo del codice sorgente.
Rob Sobers,

1
Quando ho iniziato il mio attuale lavoro, avevamo un sistema di controllo del codice sorgente, ma le build venivano eseguite sulla macchina di un ragazzo e solo lui conosceva tutti i passaggi, e i bug venivano rintracciati su carta. Questi sono tutti "riparati" ora, ma non darei mai queste cose per scontate.
HappyCat,

6

Devo dire che è una buona "base", ma con qualsiasi strumento di misurazione ci sono altri fattori. Ad esempio, non una singola azienda per cui ho lavorato ha realizzato build giornaliere (lo so, lo so), ma alcune sono state molto buone.

Personalmente ho alcuni altri elementi che aggiungerei a un elenco.

  1. Sostieni l'educazione degli sviluppatori partecipando a conferenze, acquistando libri o qualcosa del genere?
  2. Avete un processo semplice e documentato per adottare nuovi strumenti se necessario per completare le funzioni lavorative
  3. Fornite agli sviluppatori attrezzature e un ambiente che consentano loro di essere produttivi.

Più di ogni altra cosa si tratta di elementi che mi hanno "fatto incazzare" dai precedenti datori di lavoro e che ora sono domande rapide che faccio su ogni singola opportunità.


1
3 non sono già nella lista?
Casebash,

Sì, in un modo o nell'altro lo è. Ma elenco il mio in modo leggermente diverso, quindi l'ho lasciato lì.
Mitchel Sellers,

5

Sono d'accordo con la maggior parte dei punti di Joel. Non sono così sicuro del "test di usabilità in corridoio". Test di usabilità, certo, ma in realtà afferrare qualcuno dal corridoio e farli testare il tuo programma, anche se non è il loro lavoro? Sembra un ottimo modo per stuzzicare le persone.


1
Sicuramente è una cosa culturale - se non è eccessivamente dirompente e se fa parte del modo in cui funziona l'azienda, allora non dovrebbe "spaccare la gente" - specialmente se lo scopo del business è lo sviluppo di applicazioni.
Murph,

1
Forse il punto è che dovrebbe far parte del lavoro degli altri?
JeffO,

7
il punto fondamentale del test di usabilità in corridoio è che deve essere qualcuno che non utilizza regolarmente il programma. Dopo averlo costruito e / o trascorso ore ad usarlo (come un tester dedicato), la tua prospettiva sull'app sarà distorta
GSto

5

Il Joel Test non verifica quanto è brava una squadra. Verifica quanto bene la tua squadra aderisce al Joel Test.

Ecco un test migliore di quanto è brava la tua squadra. Lo chiamo test GrandmasterB. Ha una domanda

1) Il software che scrivi è buono?

Per me è irrilevante se si esegue il "test di corridoio" o meno, o quale controllo del codice sorgente si ha o quale sia il processo di compilazione (se presente, non tutti i linguaggi li hanno). La vera misura di una squadra è la qualità del software che creano.

Fondamentalmente, potresti seguire ogni singolo passaggio del test Joel e finire con codice merda e prodotti che non vengono mai spediti. Ad esempio, il controllo del codice sorgente non rende magicamente uno dei programmatori migliori; semplifica la gestione del codice. E avere l'ultima versione di Visual Studio non significa che la tua applicazione funzionerà meglio che se fosse stata scritta con Visual Studio 2005 .


14
Ti manca il punto. Il test Joel non riguarda quanto sia buono il software, ma quanto sia efficace il processo di produzione. Una squadra che non supera il test Joel può comunque produrre buoni prodotti, ma è probabile che ci vorrà molto più tempo e che i lavoratori saranno infelici. Inoltre, gli strumenti non si riferiscono solo al software. Significa anche hardware, dal tuo computer alla scrivania e alla tastiera.
Matt Olenik,

Penso che ti stia perdendo il punto. Se un team termina i progetti in tempo e produce software di buona qualità, sono, per definizione, efficaci. E hanno, per definizione, un processo efficace.
GrandmasterB,

2
Non hai mai menzionato la spedizione in tempo. Inoltre, sarei estremamente sorpreso di vedere un team efficace che ha fallito (completamente) il Joel Test. Cose come il controllo delle versioni, i test e l'usabilità sono tutti elementi fondamentali. Gli altri articoli possono essere anche impedimenti piuttosto grandi.
Matt Olenik,

Questo è un buon punto, ma il principale punto debole è la soggettività. Tutti potrebbero avere un'opinione diversa sulla qualità del software, a seconda della loro esperienza, livello di abilità e prospettiva di utilizzo. Ma mi piace il punto.
Bernard Dy,

Se il loro processo efficace è efficace solo per i membri del team, in particolare se il team è piccolo, quanto resisterà alla crescita o in caso di disastro prematuro o pensionamento? Essere in grado di produrre codice che funzioni bene e spedire in tempo tramite un processo che esiste solo nelle teste delle persone che lo sviluppano è una ricetta per il disastro, un team che prima o poi (probabilmente prima) dovrà affrontare un problema dal quale la maggior parte delle persone non può, o semplicemente non vorrebbe, recuperare.
Finni McFinger,

5

Anche se penso che abbia un senso in senso generale, ho trovato la lista piuttosto centrata sul tipo specifico di software che Fog Creek Software fa ( termoretraibile ). Non è davvero sorprendente, visto che ne parla anche in un altro post, Five Worlds . E ci sono molti sviluppi al di fuori di quel mondo.

Ci sono alcune condizioni che non hanno molto senso se si sviluppa, ad esempio, un software incorporato per un satellite o un distributore automatico, come build giornaliere (3) o test di usabilità (12).


Concordato. Una volta che ti allontani dalle app "top of the stack", molte idee contemporanee sembrano diventare un po '... irrilevanti.
Paul Nathan,

Sono d'accordo. Ci sono molti lavori degli sviluppatori nei negozi IT aziendali ... certamente non così glamour come fare un film termoretraibile. Poiché la maggior parte di queste aziende non è attiva nel settore del software, la maggior parte di esse in genere ottiene circa 4 punti nel test Joel.
Bernard Dy,

6
Perché non dovresti creare unit test per il software incorporato (e farli funzionare automaticamente da un sistema di generazione)?
Peter Mortensen,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.