Seberapa up-to-date tes Joel? [Tutup]

Ditutup . Pertanyaan ini didasarkan pada pendapat . Saat ini tidak menerima jawaban.

Ingin meningkatkan pertanyaan ini? Perbarui pertanyaan sehingga dapat dijawab dengan fakta dan kutipan dengan mengedit posting ini .

Ditutup 6 tahun yang lalu .

Saya ingin meyakinkan mitra saya bahwa kita harus memiliki spesifikasi dan bahwa bug harus diperbaiki sebelum menulis kode baru. Haruskah saya merujuk pada tes Joel ? Apakah menurut Anda tes Joel terkini? Saya pikir tidak memiliki spec adalah manajemen proyek yang buruk. Apakah Anda setuju dengan tes Joel? Bisakah Anda menambahkan sesuatu? Itu tidak menyebutkan misalnya Open Source.

issue-tracking specifications joel-test

— Niklas
sumber

Tes Joel diarahkan pada pengembangan perangkat lunak dan proses perekrutan pengembang. Bagaimana cara Anda melisensikan perangkat lunak atau apakah Anda menerbitkan atau tidak terkait dengan sumber Anda?

— Marjan Venema

Terima kasih Marjan untuk pertanyaannya. Saya berpikir bahwa sejak tes Joel dikandung Open Source telah menjadi tren dan jika seseorang sangat negatif tentang Open Source maka mungkin saya ingin tahu bagaimana sebuah tim menentang open source, jika mereka. Saya setuju masalah hak cipta bisa di luar ruang lingkup tetapi programmer tidak dapat bekerja dengan tim yang berpikir bahwa open source adalah masalah untuk dapat melihat sumber dan juga pertanyaan 13 bisa jadi "Apakah Anda memiliki sistem cadangan?" dan 14 "Apakah Anda memiliki keamanan yang lebih kuat dari MD5?" di mana jawabannya harus ya.

— Niklas

Oke, itu masuk akal. Upaya open source tidak hanya harus "dikonsumsi", tetapi juga berkontribusi, meskipun tidak harus dengan kode (pikirkan dukungan moneter). Sistem cadangan penting, tetapi tidak terbatas pada pengembangan dan karena itu saya tidak akan menambahkannya ke tes Joel. Tetapi jika saya wawancarai dengan bisnis yang tidak melakukan apa-apa tentang backup, saya akan berlari menuju pintu. Keamanan saya tidak akan menambahkan. Untuk keamanan yang dikembangkan perangkat lunak, ini mungkin bukan masalah (aplikasi in-house), sehingga tidak memberikan jawaban ya / tidak, plus keamanan tidak harus spesifik untuk pengembangan.

— Marjan Venema

Terima kasih telah berbagi pengetahuan dengan saya. Memang benar bahwa cadangan itu penting tetapi tidak spesifik untuk pengembangan.

— Niklas

Banyak pertanyaan bagus menghasilkan beberapa tingkat pendapat berdasarkan pengalaman ahli, tetapi jawaban atas pertanyaan ini cenderung hampir seluruhnya didasarkan pada pendapat, bukan fakta, referensi, atau keahlian khusus.

— nyamuk

Jawaban:

Saya pikir tes Joel up to date - itu sebagai up to date karena banyak dari penulisan perangkat lunak lain yang "abadi".

Melakukan pengembangan produk (yang meliputi pengembangan perangkat lunak) tanpa spek hanyalah kegilaan.

Bagaimana Anda tahu ke mana Anda ingin pergi?

Hanya ada satu poin yang akan saya sampaikan tentang menulis spec (saya sebenarnya tidak berpikir bahwa spec Joel sangat bagus ... lebih baik daripada tidak sama sekali, tetapi tidak sebagus yang seharusnya). Poin itu adalah:

Saat menulis spec, ucapkan hanya apa yang harus dilakukan produk, bukan bagaimana melakukannya.

Ini berarti Anda tidak menentukan detail implementasi dalam spesifikasi. Itu aktivitas desain dan Anda membiarkan pengalaman dan kreativitas para desainer.

[Hanya ada satu pengecualian untuk aturan ini: Kadang-kadang detail atau metode implementasi tertentu diamanatkan atau diperlukan, dalam hal ini memasukkannya. Misalnya, jika perangkat lunak harus ditulis dalam PHP dan ini tidak dapat dinegosiasikan, maka masuk spec. Seharusnya ada sangat sedikit contoh dari ini.]

Saya dapat menambahkan: tidak memiliki pelacakan bug adalah tindakan kegilaan yang sama. Ini hanyalah cara yang paling tidak profesional dan bodoh untuk beroperasi dan akan menyebabkan rasa sakit dan penderitaan yang hebat.

— dengan cepat_now
sumber

Terima kasih atas jawaban yang sangat cepat dan berharga. Contoh kegilaan lain yang sampai kepada saya adalah pernyataan bahwa segala sesuatu harus memiliki prioritas yang sama. Rasanya seperti melakukan kebalikan dari aturan gila ini yang akan mengarah pada kesuksesan.

— Niklas

"semuanya memiliki prioritas yang sama" - juga dikenal sebagai "semuanya adalah # 1". Ini, terus terang, benar-benar omong kosong. Semuanya harus diprioritaskan, secara brutal, dalam hal HARM TO THE BUSINESS. Kemudian Anda bekerja di # 1. Jika Anda berhenti di # 1 karena alasan tertentu, Anda bekerja pada # 2. Dan seterusnya. Jika Anda memiliki beberapa orang yang tidak dapat mengerjakan # 1 karena alasan tertentu dan mereka akhirnya bekerja pada # 9 - itu tidak masalah asalkan ada alasan yang bagus. ("Aku merasa seperti itu dan itu cooooooool" BUKAN alasan yang baik). Ini juga OK untuk memprioritaskan kembali. Melakukannya lebih sering daripada mingguan juga merupakan kegilaan.

— cepat_now

Terima kasih atas kebijaksanaannya. Saya setuju sepenuhnya bahwa semuanya harus diprioritaskan. Mitra saya juga menyatakan bahwa kita seharusnya tidak memiliki masalah dan tidak ada pelacak masalah. Tetapi saya merasa bahwa mendokumentasikan masalah adalah benar dan bahkan pemimpin pasar menyimpan pelacak masalah. Sekali lagi, melakukan kebalikan dari aturan akan berhasil ...

— Niklas

@ 909 Niklas Anda mungkin harus mencari pasangan lain, untuk membuat kehidupan masa depan Anda lebih nyaman ...

— Marcel

+1 hanya untuk: Saat menulis spec, ucapkan hanya apa yang harus dilakukan produk, bukan bagaimana melakukannya.

— Marcel

Saya akan berperan sebagai penasihat iblis di sini dan menyarankan agar Tes Joel tidak mutakhir. Itu terlalu umum. Ketika teknologi telah matang, pertanyaan-pertanyaan harus lebih spesifik daripada ketika ia menulis tes.

Spesifikasi dokumen, setidaknya dokumen spesifikasi besar di muka tidak diperlukan sekarang karena kami memiliki kisah pengguna dan proses pengembangan Agile. Pertanyaan ini harus diubah menjadi "Apakah tingkat dokumentasi sesuai dengan solusi yang direkayasa?" Kisah pengguna yang lebih kecil dan lebih ketat yang disampaikan setiap dua minggu jauh lebih bermanfaat dalam banyak kasus daripada dokumen besar di muka yang menjelaskan produk secara terperinci. Namun, jika Anda sedang membangun Mars Rover berikutnya, Anda mungkin menginginkan dokumen desain depan yang terperinci. Jika Anda bertanya apakah perusahaan memiliki spesifikasi desain, saya tidak akan terkejut mendengar jawaban "tidak benar-benar, kami menggunakan proses yang gesit dan cerita pengguna sebagai gantinya".

Kedua, pertanyaan "pembuatan harian" harus berubah menjadi pertanyaan tentang integrasi berkelanjutan. Kecuali jika Anda membangun perangkat lunak yang membutuhkan waktu berjam-jam untuk membangun (yang 99,99% tempat tidak akan melakukan), pertanyaan harus bertanya apakah perusahaan menggunakan integrasi berkelanjutan.

Sebagian besar tes Joel benar-benar belum berkencan sama sekali. Ini masih merupakan cara yang baik untuk mendapatkan indikasi lingkungan kerja.

— Stephen
sumber