Bisakah toko gesit benar-benar mencetak skor 12 pada Tes Joel? [Tutup]

Saya sangat menyukai tes Joel, menggunakannya sendiri, dan mendorong staf dan orang yang saya wawancarai untuk mempertimbangkannya dengan cermat. Namun saya tidak berpikir saya bisa mencetak lebih dari 9 karena beberapa poin tampaknya bertentangan dengan Agile Manifesto, XP dan TDD, yang merupakan landasan dunia saya.

Khususnya: pertanyaan tentang jadwal, spesifikasi, penguji, dan kondisi kerja yang tenang bertentangan dengan apa yang kami coba ciptakan dan nilai-nilai yang kami adopsi untuk menjadi benar-benar gesit.

Jadi pertanyaan saya adalah apakah mungkin untuk toko Agile sejati mencetak 12?

Edit:

Atas rekomendasi dari seorang penjawab di bawah ini saya menambahkan tautan ke blog saya di mana saya awalnya menulis tentang ini dan yang menyebabkan saya ingin memposting pertanyaan di sini.

http://simonpalmer.com/2011/03/16/why-i-will-never-score-more-than-9-on-the-joel-test/

Saya memasukkan ini karena saya setuju dengan banyak dari apa yang telah dikatakan di bawah ini dan saya ingin menyatakan posisi penuh saya.

Pandangan saya sebagai agonis:

Apakah Anda menggunakan kontrol sumber?

Ya, tentu saja, integrasi berkelanjutan, bagian dari XP membutuhkan sistem kontrol sumber untuk dapat mengkomit kode untuk itu.

Bisakah Anda membuat build dalam satu langkah?

Ya, server integrasi berkelanjutan ada untuk itu.

Apakah Anda membuat build harian?

Jika kita dapat membuatnya dalam satu langkah, kita dapat menjadwalkannya.

Apakah Anda memiliki basis data bug?

Ya, alat manajemen "Agile project" apa pun dapat melacak bug dan ditambahkan dalam jaminan produk scrum

Apakah Anda memperbaiki bug sebelum menulis kode baru?

Ya mereka diprioritaskan dalam jaminan produk

Apakah Anda memiliki jadwal terkini?

Ya selalu, terima kasih pada backlog produk, backlog iterasi, rencana rilis & estimasi akurat yang menyertainya berkat Perencanaan Poker.

Anda punya spec?

Ya, setiap Kisah Pengguna disertai dengan perincian lebih lanjut jika diperlukan. Kami juga mendorong komunikasi antara pemilik produk dan tim.

Apakah programmer memiliki kondisi kerja yang tenang?

Ya, kamar dengan 8 pengembang biasanya sangat sunyi. Kami mencoba untuk tidak menempatkan orang-orang penjualan di ruangan yang sama.

Apakah Anda menggunakan alat terbaik yang bisa dibeli dengan uang?

Ya, sementara kami menghargai individu di atas alat, jangan khawatir Joel, kami membeli lisensi semua produk Anda;)

Apakah Anda memiliki penguji?

Ya dan mereka adalah bagian integral dari tim.

Apakah kandidat baru menulis kode selama wawancara mereka?

Ya, dan tim terlibat dalam proses tersebut.

Apakah Anda melakukan pengujian kegunaan lorong?

Ya penguji kami membantu kami dengan itu.

Apakah Anda memiliki jadwal terkini?

Ini Agile. Scrum mengharuskan kami berkomitmen untuk merilis. Memiliki jadwal terbaru berarti mengetahui apa yang akan dilakukan (dan tidak akan dilakukan) dalam rilis, dan seperti apa tumpukannya.

Anda punya spec?

Ini Agile. Arsitektur (dan deskripsi yang terkait) sangat penting. Ini menentukan formulir. Kasus penggunaan (atau kisah pengguna) sangat penting dan tentukan fungsinya.

Apakah programmer memiliki kondisi kerja yang tenang?

Saya tidak dapat melihat bagaimana Agile membutuhkan lingkungan yang bising, mengganggu, dan menjengkelkan.

Apakah Anda memiliki penguji?

Um Ketika kami melakukan TDD, kami adalah penguji. Ketika kami menyerahkan kode tersebut kepada pemilik produk, penguji tambahan mungkin terlibat sebelum pelanggan terlibat.

Bagaimana ini bertentangan dengan metode Agile atau manifesto Agile?

Saya pikir jawabannya adalah ya, sebuah toko Agile harus dapat melakukan ini. Khusus untuk poin Anda.

• Penjadwalan adalah tentang memiliki definisi yang jelas tentang fitur apa yang Anda rencanakan untuk ditangani. Ini pasti dapat dicapai.
• "Kondisi kerja yang tenang" bukan tentang suara di tempat kerja, itu menghilangkan kebisingan non-proyek / pemrograman. Ini adalah tentang menjaga programmer Anda dari harus menggunakan upaya untuk memblokir gangguan
• Toko tangkas harus menguji sejak dini dan memiliki orang lain selain pengembang yang menguji kodenya benar-benar maksud Joel.

Menurut Anda mengapa memiliki jadwal (untuk mengambil satu contoh) tidak sesuai dengan pengembangan Agile?

Sangat tidak mungkin bahwa Anda akan bekerja dari sprint ke sprint dengan sama sekali tidak tahu ke mana Anda ingin pergi dengan produk Anda. Ya, Anda perlu meninjau kembali dan merevisi jadwal setelah setiap sprint, tetapi Anda masih memiliki satu.

Memiliki pernyataan seperti "di Q1 kami berencana untuk merilis fitur A, B, C dan di Q2 kami saat ini melihat fitur X, Y, Z" masih jadwal. Ada setiap kesempatan bahwa X akan menjadi W tetapi itulah yang menjadi Agile memungkinkan Anda melakukannya.

Mengambil hal lain dari daftar Anda - Spesifikasi. Apa itu Cerita Pengguna jika bukan spesifikasi?

Saya kira saya akan melihat ini dari perspektif yang berbeda dari kebanyakan di sini. Jika Anda mencetak angka 9 pada tes Joel, Anda berada di depan kurva. Banyak tempat akan berjuang untuk mencapai 5 atau 6, apalagi 9 hingga 12.

Apakah Anda kesulitan mempekerjakan orang baik? Jika tidak, maka 12 pada Tes Joel, sementara tujuan yang mulia, mungkin tidak benar-benar menjadi masalah. Jika karyawan Anda dapat berfungsi di lingkungan yang Anda miliki, saya akan mengatakan pekerjaan yang baik untuk mencetak skor setinggi yang Anda miliki.