Apa pendapat Anda tentang Tes Joel? [Tutup]

51

The Joel Test adalah tes terkenal untuk menentukan seberapa baik tim Anda adalah. Apa pendapat Anda tentang poinnya? Apakah Anda tidak setuju dengan mereka? Apakah ada sesuatu yang ingin Anda tambahkan?

joel-test

— Casebash
sumber

41

Jeff Atwood memiliki Bill of Rights Programmer .

Dari pos:

Setiap programmer harus memiliki dua monitor

Setiap programmer harus memiliki PC yang cepat

Setiap programmer akan memiliki pilihan mouse dan keyboard mereka

Setiap programmer harus memiliki kursi yang nyaman

Setiap programmer harus memiliki koneksi internet yang cepat

Setiap programmer harus memiliki kondisi kerja yang tenang

Ini sepertinya memiliki beberapa item yang ingin saya lihat di daftar Joel. Khususnya di bidang perangkat keras (monitor ganda, PC cepat, mouse / keyboard, kursi nyaman, koneksi cepat).

Satu-satunya hal yang tidak disebutkan adalah memiliki nyaman dan disesuaikan meja .

Ini semua dapat ditambahkan dengan mengubah:

Saat ini # 9: Apakah Anda menggunakan alat terbaik yang dapat dibeli dengan uang?

untuk

Peningkatan # 9: Apakah Anda menggunakan alat dan peralatan terbaik yang dapat dibeli dengan uang?

— sepon
sumber

Bukankah # 6 Anda identik dengan # 8 pada tes Joel:

— HerbN

Itu Jeff Atwood # 6, dan ya, benar.

— spong

Sepertinya Tes Joel lebih spesifik untuk membantu programmer mengembangkan perangkat lunak bebas bug yang bertentangan dengan kondisi kerja, kecuali # 8

— Archmede

13

Sangat menarik bahwa poin 8 sekarang berbunyi:

8. Do programmers have quiet working conditions?

ketika digunakan untuk membaca (sesuatu seperti)

8. Do programmers have their own office?

dan paragraf terakhir masih dimulai:

Sekarang mari kita pindahkan mereka ke kantor terpisah dengan dinding dan pintu.

Saya selalu curiga dengan tes ini karena di semua tempat saya bekerja - baik sebagai karyawan dan pengunjung - satu-satunya orang dengan kantor mereka sendiri adalah direktur dan manajer senior.

Menulis perangkat lunak di dunia nyata biasanya merupakan kegiatan tim, Anda perlu berbicara dengan rekan satu tim Anda untuk memantulkan ide, dll. Dan itu lebih sulit dilakukan dengan orang-orang di kantor yang terpisah bahkan dengan sistem pesan instan. Mampu menggambar sesuatu dan menunjukkan kode dan diagram kepada orang-orang sangat membantu. Ini bukan untuk mengatakan bahwa tim yang didistribusikan tidak dapat bekerja - mereka jelas dapat dan melakukannya, itu hanya serangkaian masalah yang berbeda.

Apa yang akan saya katakan adalah bahwa masing-masing tim perlu berada di kantornya sendiri yang terdiri dari 6-8 orang (dengan asumsi itu ukuran tim). Dengan begitu mereka dapat berinteraksi tanpa mengganggu tim lain (jika ada) dan melanjutkan pekerjaan mereka tanpa diganggu oleh tim penjualan atau pengunjung (di satu tempat saya bekerja Anda datang melalui pintu depan langsung ke area pengembangan).

Jika Anda bekerja dengan pengembang lain, tetapi masing-masing bekerja pada proyek yang terpisah, maka kantor bersama dapat bermanfaat - tetapi hanya jika Anda ketat tentang membawa rapat ke ruang rapat dan menghormati tenggat waktu orang lain, dll.

Sebagian besar yang lain adalah kebenaran yang terbukti dengan sendirinya.

— ChrisF
sumber

9

Masalah dengan memunculkan ide dari rekan satu tim adalah bahwa MEMINTA mereka secara lisan adalah gangguan besar. Jika Anda perlu melakukan kolaborasi serius, maka bekerjalah di ruang kolaborasi. Tetapi untuk pertanyaan "hei, bagaimana Anda akan melakukan ini", Anda jauh lebih baik dengan IM.

— Matt Olenik

@Matt - Untuk hal-hal kecil yang Anda benar, tetapi ruang kantor selalu langka - tidak ada perusahaan yang ingin menghabiskan uang untuk kantor kosong - itulah sebabnya mengapa tim di ruang mereka sendiri membantu. Anda dapat mengubah kantor menjadi "ruang kolaborasi".

— ChrisF

2

Anda tidak bisa berarti delapan orang di ruangan yang sama, bukan? Saya sudah kesal dengan berbagi kamar dengan tiga programmer lain (masing-masing bekerja pada barang-barangnya sendiri, dengan satu bekerja pada proyek yang sama sekali tidak terkait dan satu lagi menjadi orang backend / basis data). Saya tahu pasti bahwa jika saya berbagi kamar dengan tujuh orang lain saya hanya akan mengirim pos.

— Baelnorn

1

@ ChrisF: mungkin itu masalahnya. Kami berempat duduk di ruangan yang sama nyaris tidak ada hubungannya, pemrograman bijaksana. Ini lebih seperti 4 orang yang mengerjakan 2 1/2 proyek yang duduk di ruangan yang sama. Dan sekarang tambahkan bos yang sama sekali tidak keberatan mengadakan diskusi setengah jam dengan programmer lain tepat di sebelah meja Anda meskipun ruang rapat berada tepat di seberang lorong . >. <

— Baelnorn

1

@ChrisF - "Menulis perangkat lunak di dunia nyata adalah kegiatan tim, Anda perlu berbicara dengan rekan satu tim Anda untuk memantulkan ide di sekitar dll. Dan itu jauh lebih sulit dengan orang-orang di kantor yang terpisah." - Jadi, bagaimana tim pengembangan menyebar di berbagai lokasi bekerja? Saya telah bekerja erat dengan orang-orang di seluruh AS atau Brasil atau India - IM dan Adobe Connect - dan juga terletak bersama, dari tim kecil hingga tim yang sangat besar. Lingkungan Anda sangat mengganggu. Bekerja dalam tim dapat dilakukan secara efisien, tetapi apa yang Anda resepkan adalah apa-apa tetapi (ide Anda benar dari

— menyiram tahun

10

Saya suka tetapi jika saya menggunakannya untuk mengevaluasi perusahaan saya tidak akan sama-sama menimbang semua item. Tidak memiliki kendali sumber adalah masalah yang jauh lebih besar daripada tidak membeli alat terbaik yang dapat dibeli dengan uang.

— JeffO
sumber

9

Satu-satunya pemecah kesepakatan bagi saya adalah:

 8. Do programmers have quiet working conditions?

Yang menarik adalah pertanyaan yang paling mungkin gagal oleh postingan pekerjaan Stack Overflow.

Beberapa pertanyaan sulit untuk gagal, terutama jika ada lebih dari satu programmer di perusahaan:

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

Sebagian besar yang lain tidak begitu saya pedulikan. Maksud saya, jujur:

12. Do you do hallway usability testing?

Ada satu untuk mendeteksi pembohong:

 5. Do you fix bugs before writing new code?

— Tom Hawtin - tackline
sumber

20

Saya pikir Anda akan terkejut betapa banyak perusahaan tidak dapat membuat build dalam satu langkah dan tidak memiliki database bug. Anda mungkin benar tentang kontrol sumber, tetapi saya berpendapat bahwa banyak perusahaan menggunakannya hanya untuk membuat cadangan kode mereka dan bahkan tidak menggaruk permukaan manfaat dari kontrol sumber.

— Rob Sobers

1

Ketika saya mulai pada pekerjaan saya saat ini, kami memiliki sistem kontrol sumber, tetapi build dilakukan pada mesin satu orang dan hanya dia yang tahu semua langkah, dan bug dilacak di atas kertas. Ini semua sudah "diperbaiki" sekarang, tetapi saya tidak akan pernah menerima begitu saja.

— HappyCat

6

Saya harus mengatakan bahwa ini adalah "dasar" yang bagus, tetapi dengan alat ukur apa pun ada faktor-faktor lain. Misalnya, tidak ada satu pun perusahaan tempat saya bekerja telah melakukan Pembuatan Harian (saya tahu, saya tahu), tetapi beberapa di antaranya sangat bagus.

Saya pribadi memiliki beberapa item lain yang akan saya tambahkan ke daftar.

Apakah Anda mendukung pendidikan pengembang dengan menghadiri konferensi, membeli buku, atau semacamnya?
Apakah Anda memiliki proses yang sederhana dan terdokumentasi untuk mengadopsi alat-alat baru jika perlu untuk menyelesaikan fungsi pekerjaan
Apakah Anda menyediakan peralatan pengembang dan lingkungan yang memungkinkan mereka menjadi produktif.

Lebih dari segalanya, barang-barang ini telah "membuat saya kesal" dari para majikan sebelumnya, dan sekarang mereka adalah pertanyaan-pertanyaan cepat yang saya tanyakan tentang setiap peluang.

— Penjual Mitchel
sumber

1

Bukankah 3 sudah ada dalam daftar?

— Casebash

Ya, dalam satu atau lain bentuk. Tapi saya daftar milik saya sedikit berbeda jadi saya meninggalkannya di sana.

— Penjual Mitchel

5

Saya setuju dengan sebagian besar poin Joel. Saya tidak begitu yakin tentang "pengujian kegunaan lorong". Pengujian kegunaan, tentu, tetapi benar-benar menarik seseorang dari lorong dan membuat mereka menguji program Anda, meskipun itu bukan pekerjaan mereka? Itu sepertinya cara yang bagus untuk menandai orang.

— Tim Goodman
sumber

1

Tentunya itu adalah masalah budaya - jika tidak terlalu mengganggu dan jika itu merupakan bagian dari cara bisnis berfungsi maka tidak boleh "mengecilkan orang" - terutama jika tujuan bisnis adalah pengembangan aplikasi.

— Murph

1

Mungkin intinya adalah itu harus menjadi bagian dari pekerjaan orang lain?

— JeffO

7

inti dari pengujian kegunaan lorong adalah bahwa itu harus seseorang yang tidak menggunakan program secara teratur. Setelah Anda membuatnya dan / atau menghabiskan waktu berjam-jam menggunakannya (seperti penguji khusus) perspektif Anda pada aplikasi akan miring

— GSto

5

Tes Joel tidak menguji seberapa bagus tim. Ini menguji seberapa baik tim Anda mematuhi Tes Joel.

Inilah tes yang lebih baik tentang seberapa baik tim Anda. Saya menyebutnya tes GrandmasterB. Ada satu pertanyaan.

1) Apakah perangkat lunak yang Anda tulis baik?

Bagi saya tidak relevan apakah Anda 'lorong tes' atau tidak, atau apa kontrol sumber yang Anda miliki, atau apa proses pembangunan Anda (jika ada satu - tidak setiap lanugage memilikinya). Ukuran sebenarnya dari tim adalah kualitas perangkat lunak yang mereka buat.

Pada dasarnya, Anda dapat mengikuti setiap langkah Joel Test, dan tetap berakhir dengan kode sampah dan produk yang tidak pernah dikirimkan. Misalnya, kontrol sumber tidak secara ajaib menjadikannya sebagai pembuat kode yang lebih baik; itu membuat kode lebih mudah dikelola. Dan memiliki Visual Studio versi terbaru tidak berarti aplikasi Anda akan bekerja lebih baik daripada jika ditulis dengan Visual Studio 2005 .

— GrandmasterB
sumber

14

Anda tidak mengerti intinya. Tes Joel bukan tentang seberapa bagus perangkat lunaknya, ini tentang seberapa efektif proses produksinya. Sebuah tim yang gagal dalam tes Joel mungkin masih menghasilkan produk yang bagus, tetapi kemungkinan itu akan memakan waktu lebih lama dan para pekerja akan sengsara. Selain itu, alat tidak hanya merujuk ke perangkat lunak. Ini juga berarti perangkat keras, dari komputer Anda ke meja dan keyboard Anda.

— Matt Olenik

Saya pikir Anda tidak mengerti intinya. Jika sebuah tim menyelesaikan proyek tepat waktu dan menghasilkan perangkat lunak berkualitas baik, mereka, menurut definisi, efektif. Dan mereka memiliki, menurut definisi, proses yang efektif.

— GrandmasterB

2

Anda tidak pernah menyebut pengiriman tepat waktu. Juga, saya akan sangat terkejut melihat tim yang efektif yang gagal (sepenuhnya) Tes Joel. Hal-hal seperti kontrol versi, pengujian, dan kegunaan semuanya penting. Barang-barang lainnya bisa menjadi hambatan yang cukup besar juga.

— Matt Olenik

Ini adalah poin yang bagus, tetapi kelemahan utama adalah subjektivitasnya. Setiap orang mungkin memiliki pendapat berbeda tentang kualitas perangkat lunak, tergantung pada pengalaman, tingkat keterampilan, dan perspektif penggunaannya. Tapi saya suka intinya.

— Bernard Dy

Jika proses efektif mereka hanya efektif untuk anggota yang ada di tim, terutama jika tim itu kecil, seberapa baik hal itu dapat bertahan terhadap pertumbuhan atau jika terjadi bencana atau pensiun yang tidak tepat waktu? Mampu menghasilkan kode yang berfungsi dengan baik dan mengirimkan tepat waktu melalui proses yang baru saja ada di kepala orang-orang yang mengembangkannya adalah resep untuk bencana, sebuah tim yang cepat atau lambat (mungkin lebih cepat) akan menghadapi masalah dari mana kebanyakan orang tidak bisa, atau tidak mau, pulih.

— Finni McFinger

5

Meskipun saya pikir itu masuk akal baik dalam pengertian umum, saya menemukan daftar itu cukup terpusat pada jenis perangkat lunak tertentu yang dilakukan oleh Fog Creek Software ( shrinkwrap ). Itu tidak terlalu mengejutkan, karena ia juga membicarakan hal itu di postingan lain, Five Worlds . Dan ada banyak perkembangan di luar dunia itu.

Ada beberapa kondisi yang benar-benar tidak masuk akal jika Anda mengembangkan misalnya perangkat lunak tertanam untuk satelit atau mesin penjual otomatis, seperti build harian (3) atau pengujian kegunaan (12).

— Khelben
sumber

Sepakat. Setelah Anda menjauh dari aplikasi "atas tumpukan", banyak ide kontemporer tampaknya menjadi sedikit ... tidak relevan.

— Paul Nathan

Saya setuju. Ada banyak pekerjaan pengembang di toko-toko IT perusahaan ... tentu tidak semewah yang dilakukan dengan bungkus plastik. Karena sebagian besar perusahaan ini tidak berada dalam bisnis perangkat lunak, kebanyakan dari mereka biasanya mendapat skor 4 pada Tes Joel.

— Bernard Dy

6

Mengapa Anda tidak membuat tes unit untuk perangkat lunak tertanam (dan membuatnya secara otomatis dijalankan oleh sistem build)?

— Peter Mortensen