Mengapa repot dengan spesifikasi terperinci?

Saat menulis perangkat lunak, apa gunanya menulis spesifikasi pohon mati yang formal dan terperinci? Untuk memperjelas, spesifikasi agak tinggi, tingkat tinggi untuk orang-orang yang tidak ingin membaca kode masuk akal bagi saya. Implementasi referensi dalam kode sumber yang dapat dikomentari dengan baik dan dapat dibaca adalah tentang spesifikasi paling jelas dari apa pun yang akan Anda dapatkan, karena komputer harus dapat menjalankannya. Spesifikasi formal seringkali sama sulitnya untuk dibaca, dan hampir sama sulit untuk ditulis, seperti kode.

Apa manfaat yang ditawarkan spesifikasi formal atas implementasi referensi ditambah sedikit dokumentasi tentang perilaku apa yang tidak terdefinisi / didefinisikan-implementasi terlepas dari bagaimana kerjanya dalam implementasi referensi.

Sunting: Atau, apa yang salah dengan tes yang menjadi spesifikasi formal?

Bagaimana Anda bisa tahu Anda sudah selesai, jika Anda tidak tahu seperti apa bentuknya saat selesai?

Creep fitur akan menangkap Anda. Anda akan mencoba memberikan untuk klien, dan, seiring waktu berlalu, mereka akan menemukan 10.000 hal kecil yang benar - benar harus mereka miliki .

Untuk mendapatkan bayaran, untuk membuat atasan Anda mundur ketika tenggat waktu berlalu, Anda harus dapat mengeluarkan spek dan berkata, "Semua perkiraan waktu dan biaya saya untuk hal ini , bukan yang baru ini hal yang semua orang telah memutuskan mereka inginkan. "

Spesifikasi memungkinkan Anda untuk merenungkan hal-hal tanpa harus menulis banyak kode di muka yang harus diubah, jika spesifikasi berubah. Anggap saja antara papan tulis dan coding aktual

Ini juga merupakan ide yang sangat baik untuk dilakukan ketika memiliki beberapa pihak yang independen menulis komponen yang perlu disatukan.

Selain beberapa alasan bagus lainnya yang telah disebutkan, memiliki spesifikasi formal memungkinkan Anda untuk CYA - Tutupi Ass Anda! Jika manajer / analis / penguji mengatakan Anda tidak membangun sesuatu dengan benar, Anda dapat menunjuk ke spec dan mengatakan "Saya membangunnya seperti yang Anda inginkan!". Ini termasuk hal-hal tingkat rendah seperti "Semua data yang bertahan pada tabel AXX_RGV harus dalam UPPERCASE", "Formulir web dengan kurang dari 3 bidang input harus memiliki tombol Kirim di sebelah kiri bawah", dll ...

Juga ketika orang melupakan hal-hal pada proyek yang sangat panjang dan besar, memiliki spesifikasi rinci untuk merujuk bisa sangat berguna. Ingat saja bahwa spesifikasi harus berupa Dokumen Hidup, dan jika persyaratannya berubah (melalui apa yang diharapkan merupakan proses formal dan terdokumentasi), maka spesifikasi tersebut juga harus. Ya, ini bisa memakan waktu lebih lama. Dalam pengalaman saya, itu sepadan (jika dilakukan dengan benar).

Spesifikasi formal persyaratan program yang diperlukan karena insinyur perangkat lunak perlu tahu apa yang harus diterapkan; insinyur QA perlu tahu apa yang harus diuji, dan pelanggan perlu tahu apa yang diharapkan.

Memiliki spec memungkinkan Anda untuk mengetahui kapan Anda selesai pemrograman.

Salah satu manfaat utama mungkin keselamatan. Saya tidak ingin terbang dengan pesawat terbang di mana spesifikasi sistem kontrol adalah implementasi referensi. Saya benar-benar ingin seseorang untuk menentukan apa yang perlu dilakukan sistem dalam bentuk yang bisa dipahami oleh seseorang yang tidak akrab dengan perangkat lunak. Saya berharap setiap persyaratan telah sepenuhnya diverifikasi oleh pengujian.

Untuk sistem kritis yang kurang aman, spesifikasi adalah alat komunikasi. Mereka harus merinci apa yang perlu dilakukan sistem dengan detail yang cukup untuk membangun dan menguji sistem. Bagaimana sistem melakukan ini adalah tanggung jawab kode. Detail yang diperlukan akan bervariasi tergantung pada keahlian domain dari tim pengembangan dan akses ke pakar domain.

Spesifikasi harus selalu sesuai dengan sistem yang diterapkan. Jika ditemukan kesalahan dalam spesifikasi, spesifikasi harus diperbarui.

Kesalahan menyebabkan perkiraan yang saya lihat menunjukkan kegagalan pengujian terbagi secara merata antara kesalahan dalam spesifikasi, kode, dan pengujian.

Saya pikir pertanyaan ini adalah inti dari pertanyaan siklus hidup lincah vs air terjun.

Jika Anda tangkas, premis dasarnya adalah bahwa kode yang digabungkan dengan interaksi pengembang dekat lebih baik dan lebih cepat daripada spesifikasi terperinci. Tim memprioritaskan merilis fitur-fitur baru dan berkualitas tinggi di atas hal-hal lain - seperti mekanisme komunikasi formal seperti spesifikasi desain terperinci. Tapi ada perdagangan di sini - Anda harus memiliki saluran komunikasi antara anggota tim yang memungkinkan mereka bertanya tentang nuansa dan maksud desain rinci ketika mereka membutuhkannya.

Jika Anda melakukan air terjun, Anda bekerja dengan asumsi bahwa pekerjaan mengisi kode di bawah desain terperinci dan kemudian mengujinya adalah signifikan. Dan Anda ingin memberi para pemangku kepentingan wawasan awal tentang bagaimana pekerjaan ini akan dilanjutkan dan akan seperti apa saat itu dilakukan. Itu mungkin memeriksa desain dengan pelanggan untuk memastikan Anda telah menemukan fitur yang masuk akal. Mungkin juga untuk memeriksanya dengan para ahli di arena lain - seperti ulasan keselamatan, ulasan keamanan, dan ulasan oleh anggota tim yang harus berintegrasi dengan kode Anda. Asumsinya adalah bahwa ulasan ini akan menghemat waktu dalam jangka panjang karena mereka akan menyelamatkan Anda dari menyelidiki sejumlah besar waktu dalam mengembangkan hal yang salah.

Akhir-akhir ini, saya telah melihat beberapa perpaduan yang sangat bagus antara desain rinci dan alat kode komentar - JavaDoc misalnya. Karena sebagian besar desain terperinci adalah cetakan kaki kode dan penjelasan singkat tentang apa yang akan dilakukan - ini kurang lebih sama dengan yang Anda harapkan sebagai komentar kode. Jadi memiliki alat yang akan mengubah komentar kode menjadi spesifikasi desain terperinci sangat bagus - cara yang jauh lebih baik untuk tetap up to date daripada melakukannya dengan tangan.

Saya percaya bahwa penilaian yang tidak akurat tentang bagaimana desain rinci harus untuk proyek , merupakan faktor utama dalam pertumbuhan biaya. Bagian terburuknya adalah Anda dikutuk jika Anda melakukannya dan terkutuk jika Anda tidak:

• Jika desain Anda terlalu rinci untuk ukuran tim, kompleksitas pekerjaan, dan persyaratan gerbang yang harus Anda lalui (ulasan keamanan, ulasan keselamatan, dll.), Maka Anda telah membuang-buang waktu dan uang yang berharga untuk artefak yang tidak akan pernah Anda gunakan.
• Jika desain Anda tidak cukup detail, Anda akan membuang-buang uang karena anggota tim membuat asumsi yang tidak benar yang mengarah ke masalah integrasi, dan Anda berisiko pengerjaan ulang yang berat ketika audit keamanan atau keselamatan final mengungkap masalah yang bisa diperbaiki lebih awal dan murah jika mereka telah melakukannya. aspek desain yang jelas sebelum implementasi.

Saya tidak merasa ini kasus hitam dan putih - mungkin ada banyak waktu di mana beberapa komponen "cukup baik" jika dirancang pada tingkat tinggi, sementara yang lain membutuhkan pekerjaan rinci yang ketat. Dan lingkungan tim atau proyek yang berubah dapat menentukan kebutuhan desain baru ketika sebuah proyek berkembang.

Sedang mengerjakan proyek besar sekarang. Sejauh ini spek telah membantu QA mengidentifikasi apa yang harus diuji, telah memungkinkan kami untuk menagih pelanggan lebih banyak (secara signifikan dalam jutaan) ketika dalam pengujian Pengguna, mereka memutuskan bahwa apa yang telah mereka setujui bukan apa yang sebenarnya mereka inginkan, memungkinkan orang-orang melakukan review kode untuk melihat apakah kode memenuhi persyaratan, memungkinkan devs memiliki dasar untuk memeriksa untuk melihat apakah mereka selesai dan menunjuk ke spesifikasi untuk menyelesaikan perselisihan tentang apa yang harus mengandung modul. Hal ini juga memungkinkan kami untuk mengidentifikasi pengembang yang tidak menghasilkan apa yang diperlukan klien sebelum klien melihat produk dan yang berakhir sebagai dasar untuk menyingkirkan beberapa orang yang secara cosy tidak dapat mengikuti spesifikasi. Kompleksitas spesifikasi kami membantu klien menyadari bahwa kami tidak keterlaluan dalam perkiraan biaya dan waktu kami.

Saya ingin menambahkan, saya telah mengerjakan proyek dengan spesifikasi baik, dengan spesifikasi buruk dan tanpa spesifikasi. Yang akhirnya menjadi yang terburuk adalah yang tidak spesifik karena tim pengembangan dan klien selalu memiliki visi internal yang berbeda dari hasil akhirnya. Ini adalah proyek di mana Anda berkeliling bergumam, "di mana saya bisa mendapatkan modul membaca pikiran?" Menebak apa yang diinginkan pelanggan adalah pengalaman yang mengerikan. Spek buruk tidak jauh lebih baik, tetapi setidaknya Anda dapat memperbaiki saat Anda pergi dan berkata, "Saya tidak yakin apa yang Anda maksud di sini." untuk mendapatkan informasi lebih lanjut sebelum membuang-buang waktu Anda membangun hal yang salah. Proyek besar yang saya jalani sekarang memiliki spesifikasi yang luar biasa, membuat hidup lebih mudah dan tidak terlalu membuat stres.

Secara pribadi, saya pikir spesifikasi rinci berlebihan.

Dalam pengalaman saya, apa yang pelanggan butuhkan dan apa yang pelanggan pikir mereka butuhkan seringkali merupakan dua hal yang berbeda. Jika Anda membekukan persyaratan sejak dini, Anda sedang membangun apa yang menurut mereka dibutuhkan, bukan apa yang sebenarnya mereka butuhkan. Secara hukum, Anda berada di sisi yang aman dan Anda akan dibayar, tetapi Anda tidak akan memiliki pelanggan yang bahagia.

Di sisi lain, jika Anda menerima bahwa pengembangan perangkat lunak sampai batas tertentu merupakan kegiatan eksplorasi, Anda akan mencoba untuk menjaga persyaratan terbuka selama mungkin. Diskusikan dengan pengguna apa yang perlu Anda ketahui untuk iterasi saat ini , tidak lebih, tidak kurang. Dan ketahuilah bahwa kadang-kadang, Anda harus meninjau kembali keputusan ini dalam iterasi selanjutnya. Yang paling penting: Ingatlah bahwa jika itu terjadi, itu bukan kesalahan klien. Kecuali jika pengguna Anda adalah pengembang perangkat lunak juga, pengumpulan persyaratan bukan bagian dari deskripsi pekerjaan mereka. Itu bagian dari deskripsi pekerjaan Anda.

Jadi bagaimana Anda mencegah fitur creep? Idealnya, dengan memiliki manajer produk yang waras yang bertugas menerima atau menolak permintaan fitur, dan yang tidak dapat ditolak oleh orang lain.

Agile berumur 10+ tahun, jadi ini bukan fenomena baru.

Saya berharap spesifikasi akan jauh lebih pendek daripada kode, jadi saya tidak tahu berapa banyak detail yang Anda butuhkan. Harus ada cukup untuk menjaga anggota tim tetap dalam lingkaran. Apakah membaca semua kode masing-masing praktis / perlu?

Setuju, tidak perlu dokumen mati. Saya lebih suka mendekati basis kode yang tidak dikenal tanpa dokumentasi daripada dokumentasi yang salah.

Dan jika komputer sangat bagus dalam mengeksekusi kode Anda, mengapa Anda tidak membiarkannya melakukan perubahan sendiri? Mengikuti resep di bagian belakang kotak tidak membuat Anda seorang koki.