Quanto è aggiornato il test Joel? [chiuso]

Chiuso . Questa domanda è basata sull'opinione . Al momento non accetta risposte.

Vuoi migliorare questa domanda? Aggiorna la domanda in modo che possa essere risolta con fatti e citazioni modificando questo post .

Chiuso 6 anni fa .

Voglio convincere i miei partner che dovremmo avere una specifica e che i bug dovrebbero essere corretti prima di scrivere un nuovo codice. Devo fare riferimento al test Joel ? Pensi che il test Joel sia aggiornato? Penso che non avere una specifica sia una cattiva gestione del progetto. Sei d'accordo con il test Joel? Potresti aggiungere qualcosa? Non menziona ad esempio Open Source.

issue-tracking specifications joel-test

— Niklas
fonte

Il test Joel è diretto allo sviluppo del software e ai processi di assunzione degli sviluppatori. In che modo il modo in cui licenzi il tuo software o se pubblichi o non pubblichi la tua fonte è collegato a questo?

— Marjan Venema,

Grazie Marjan per la domanda. Stavo pensando che da quando è stato concepito il test Joel Open Source è stata una tendenza e, se qualcuno fosse molto negativo sull'Open Source, probabilmente avrei voluto sapere come una squadra si oppone all'open source, se lo sono. Sono d'accordo che i problemi di copyright potrebbero andare oltre lo scopo ma il programmatore non può lavorare con un team che pensa che l'open source sia una questione di essere in grado di visualizzare l'origine e anche la domanda 13 potrebbe essere "Hai un sistema di backup?" e 14 "Hai una sicurezza più forte di MD5?" dove le risposte dovrebbero essere sì.

— Niklas

Ok, ha senso. Gli sforzi dell'open source non dovrebbero solo essere "consumati", ma dovrebbero anche contribuire, sebbene non necessariamente con il codice (si pensi al sostegno monetario). I sistemi di backup sono importanti, ma non limitati allo sviluppo e come tali non li aggiungerei al test Joel. Ma se avessi intervistato un'azienda che non faceva nulla per i backup, sarei corsa alla porta. Sicurezza Non aggiungerei neanche. Per la sicurezza sviluppata dal software potrebbe non essere un problema (app in-house), quindi non si presta a una risposta sì / no, inoltre la sicurezza non deve essere specifica per lo sviluppo.

— Marjan Venema,

Grazie per aver condiviso la conoscenza con me. È vero che il backup è importante ma non specifico per lo sviluppo.

— Niklas,

Molte buone domande generano un certo grado di opinione basato sull'esperienza degli esperti, ma le risposte a questa domanda tenderanno ad essere quasi interamente basate su opinioni, piuttosto che su fatti, riferimenti o competenze specifiche.

— moscerino il

Risposte:

Penso che il test Joel sia aggiornato: è aggiornato tanto quanto gli altri software che scrivono è "senza tempo".

Fare lo sviluppo del prodotto (che include lo sviluppo del software) senza una specifica è solo una follia.

Come fai a sapere dove vuoi andare?

C'è solo un punto che farò sullo scrivere una specifica (in realtà non penso che le specifiche di Joel siano molto buone ... meglio di niente, ma non così buone come potrebbero). Quel punto è:

Quando scrivi una specifica, dì solo cosa deve fare il prodotto, non come deve essere fatto.

Ciò significa che non devi dettare i dettagli dell'implementazione in una specifica. Questa è un'attività di design e la lasci all'esperienza e alla creatività dei designer.

[C'è solo un'eccezione a questa regola: a volte un particolare o metodo di implementazione particolare è obbligatorio o obbligatorio, nel qual caso inseriscilo. Ad esempio, se il software deve essere scritto in PHP e questo non è negoziabile, va in la specifica Dovrebbero esserci pochissimi casi di questo.]

Potrei aggiungere: non avere il tracciamento dei bug è un atto di uguale follia. È semplicemente il modo più poco professionale e sciocco di operare e porterà a grandi dolori e sofferenze.

— quickly_now
fonte

Grazie per la pronta e preziosa risposta. Un altro esempio di follia che mi ha raggiunto è stata l'affermazione che tutto dovrebbe avere la stessa priorità. Sembra che fare il contrario di queste regole folli porterà al successo.

— Niklas,

"tutto ha la stessa priorità", noto anche come "tutto è il numero 1". Questa è, francamente, una stronzata totale. Tutto dovrebbe essere prioritario, brutalmente, in termini di HARM TO THE BUSINESS. Quindi lavori sul numero 1. Se ti fermi sul numero 1 per qualche motivo, lavori sul numero 2. E così via. Se hai alcune persone che non riescono a lavorare sul n. 1 per qualche motivo e finiscono per lavorare sul n. 9, va bene, a condizione che ci sia una buona ragione. ("Mi sono sentito come se fosse suo cooooooool" NON è un buon motivo). È anche OK riordinare le priorità. Fare altrettanto più frequentemente del settimanale è anche una follia.

— quick_now

Grazie per la saggezza. Sono completamente d'accordo sul fatto che tutto dovrebbe essere prioritario. Il mio partner ha anche dichiarato che non dovremmo avere problemi e nessun tracker di problemi. Ma sento che documentare i problemi è giusto e persino il leader di mercato mantiene un tracker dei problemi. Ancora una volta, fare il contrario della regola funzionerà ...

— Niklas,

@ 909Niklas Probabilmente dovresti cercare un altro partner, per rendere più confortevole la tua vita futura ...

— Marcel

+1 solo per: quando scrivi una specifica, dì solo cosa deve fare il prodotto, non come deve essere fatto.

— Marcel,

Qui interpreterò l'avvocato del diavolo e suggerirò che il Joel Test non è aggiornato. È troppo generale. Poiché la tecnologia è maturata, le domande dovrebbero essere più specifiche rispetto a quando ha scritto il test.

Non sono necessari documenti di specifica, almeno grandi documenti di specifiche anticipati ora che abbiamo storie utente e processi di sviluppo Agile. Questa domanda dovrebbe essere cambiata in "Il livello di documentazione è appropriato per le soluzioni che vengono progettate?" Storie di utenti più piccole e più strette che vengono consegnate ogni due settimane sono molto più utili nella maggior parte dei casi rispetto a un documento di grandi dimensioni che descriva dettagliatamente il prodotto. Tuttavia, se stai costruendo la prossima Mars Rover, potresti desiderare un documento di progettazione anteriore dettagliato. Se mi chiedessi se un'azienda ha specifiche di progettazione, non sarei sorpreso di sentire una risposta di "non proprio, usiamo invece processi agili e storie utente".

In secondo luogo, la domanda "build giornaliere" dovrebbe cambiare in una domanda sull'integrazione continua. A meno che tu non stia costruendo un software che richiede ore per essere costruito (cosa che il 99,99% dei posti non farà), la domanda dovrebbe porre se la società utilizza l'integrazione continua.

La maggior parte del test di Joel non è ancora per niente datato. È ancora un buon modo per ottenere un'indicazione dell'ambiente di lavoro.

— Stefano
fonte