Il Joel Test è un test ben noto per determinare quanto è buona la tua squadra. Cosa ne pensi dei punti? Sei in disaccordo con qualcuno di loro? C'è qualcosa che vorresti aggiungere?
Jeff Atwood ha la Dichiarazione dei diritti del programmatore .
Dal post:
- Every programmer shall have two monitors
- Every programmer shall have a fast PC
- Every programmer shall have their choice of mouse and keyboard
- Every programmer shall have a comfortable chair
- Every programmer shall have a fast internet connection
- Every programmer shall have quiet working conditions
Sembra che ci siano alcuni elementi che mi piacerebbe vedere sulla lista di Joel. In particolare nel settore dell'hardware (doppio monitor, PC veloce, mouse / tastiera, sedia comoda, connessione veloce).
L'unica cosa non menzionata è avere una scrivania comoda e regolabile
Questo può essere aggiunto cambiando:
Current # 9: usi gli strumenti migliori che il denaro può comprare?
a
Migliorato # 9: usi i migliori strumenti e attrezzature che i soldi possono comprare?
È interessante notare che il punto 8 ora recita:
8. Do programmers have quiet working conditions?
quando leggeva (qualcosa di simile)
8. Do programmers have their own office?
e l'ultimo paragrafo inizia ancora:
Now let's move them into separate offices with walls and doors.
Sono sempre stato diffidente nei confronti di questo test, come in tutti i luoghi in cui ho lavorato, sia come dipendente che come visitatore: le uniche persone con i loro uffici sono i direttori e i dirigenti.
Scrivere software nel mondo reale è di solito un'attività di gruppo, devi parlare con i tuoi compagni di squadra per far rimbalzare idee in giro 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 cose e mostrare codice e diagrammi di persone aiuta moltissimo. Questo non vuol dire che i team distribuiti non possano funzionare - ovviamente possono farlo e basta, è solo una serie di problemi diversi.
Quello che direi è che ogni squadra ha bisogno di essere nel proprio ufficio di 6-8 persone (supponendo che sia la dimensione della squadra). In questo modo possono interagire senza disturbare le altre squadre (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 passato dalla porta principale direttamente all'area di sviluppo).
Se stai lavorando con altri sviluppatori, ma ognuno sta lavorando su progetti separati, allora un can ufficio condiviso può essere utile - ma solo se sei severo nel prendere riunioni nella sala riunioni e nel rispetto degli altri le scadenze delle persone ecc.
La maggior parte degli altri sono verità evidenti.
L'unico contrattempo per me è:
8. Do programmers have quiet working conditions?
Interessante è la domanda più probabile che non venga soddisfatta dalle inserzioni di lavoro Stack Overflow.
Alcune domande sono difficili da fallire, in particolare se c'è più di un programmatore in 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 bugiardi:
5. Do you fix bugs before writing new code?
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 possa acquistare.
Devo dire che è una buona "linea di base", ma con qualsiasi strumento di misurazione ci sono altri fattori. Ad esempio, non una singola azienda per cui ho lavorato ha fatto build giornaliere (lo so, lo so), ma alcune sono state molto buone.
Personalmente ho alcuni altri elementi che vorrei aggiungere a un elenco.
Più di tutto questo sono elementi che mi hanno "incazzato" dai precedenti datori di lavoro, e ora sono domande veloci che chiedo su ogni singola opportunità.
Sono d'accordo con la maggior parte dei punti di Joel. Non sono così sicuro riguardo al "test di usabilità del corridoio". Test di usabilità, certo, ma in realtà catturare qualcuno dal corridoio e farli testare il tuo programma, anche se non è il loro lavoro? Sembra un ottimo modo per fare il ticchettio alle persone.
Anche se penso che abbia senso in senso generale, ho trovato la lista abbastanza centrata sul tipo specifico di software che Fog Creek Il software fa ( shrinkwrap ). Questo non è davvero sorprendente, come ne parla anche su un altro post, Five Worlds . E ci sono molti sviluppi al di fuori di quel mondo.
Ci sono alcune condizioni che in realtà non hanno molto senso se si sviluppa ad esempio software incorporato per un satellite o un distributore automatico, come build giornalieri (3) o test di usabilità (12).
Il test di Joel non mette alla prova quanto sia buona una squadra. Verifica quanto bene il tuo team aderisce al test di Joel.
Ecco un test migliore di quanto è buona la tua squadra. Lo chiamo test del GrandmasterB. Ha una domanda.
1) Il software che scrivi è buono?
Per me è irrilevante che tu collaudi o meno, o quale controllo della sorgente tu abbia, o quale sia il tuo processo di creazione (se ce n'è uno - non tutti i linguaggi li hanno). La vera misura di un team è la qualità del software che creano.
Fondamentalmente, è possibile seguire ogni singola fase del test di Joel, e ancora finire con il codice crap e i prodotti che non vengono mai spediti. Ad esempio, il controllo del codice sorgente non crea magicamente un codificatore migliore; rende il codice più facile da gestire. E avere l'ultima versione di Visual Studio non significa che la tua applicazione funzionerà meglio che se fosse scritta con Visual Studio 2005 .
Leggi altre domande sui tag joel-test