Saya ingin menjelaskan mengapa spesifikasi tidak boleh diubah selama periode pengembangan

Saya ingin menjelaskan mengapa spesifikasi tidak boleh diubah selama periode pengembangan kepada karyawan departemen perencanaan baru.

Spesifikasi hampir selalu berubah selama pengembangan untuk proyek apa pun kecuali yang paling sederhana.

Alasannya adalah:

• Pengembangan atau pengujian integrasi proyek yang lebih mungkin mengungkap hal-hal yang tidak diperhatikan ketika spec asli dilakukan - dari kasus tepi ke sisi utama. Misalnya, pemberitahuan pengembang bahwa konfirmasi pesan yang tidak sesuai pesanan mungkin tiba.

• Kondisi dunia nyata yang menentukan spec tidak beku. Misalnya, produk keuangan baru dibuat yang perlu ditambahkan ke spesifikasi pemrosesan langsung.

• Tekanan tenggat waktu menghasilkan pemangkasan fitur.

• Para pemangku kepentingan tambahan untuk proyek ini ditemukan (mis. Di tengah proyek, proyek serupa ditemukan di area yang berbeda, dan subsistem umum perlu dipusatkan / dibagikan - ini terjadi pada saya di tengah jalan melalui proyek 2 tahun yang menghasilkan pemulihan besar. architeching).

• Sponsor tambahan dari proyek memiliki persyaratan spesifikasi baru (salah satu contoh paling terkenal adalah sejarah pengembangan Bradley Fighting Vehicle).

Mengenai mengapa perubahan spesifikasi memiliki efek yang merugikan (Anda tidak bisa mengatakan "tidak boleh terjadi" karena seperti yang Anda lihat ada banyak alasan, hampir semua di luar kendali Anda dan banyak alasan lainnya) -

• Perubahan spesifikasi menghasilkan perubahan kode, mengalihkan Anda dari menyelesaikan bagian proyek yang belum ditulis (seperti yang kita semua tahu, dan diinjili oleh Joel Spolsky, perubahan fokus sangat buruk bagi pengembang)

• Beberapa perubahan spesifikasi (kadang-kadang tampak SANGAT minor) dapat mengakibatkan kebutuhan untuk merekayasa ulang sepenuhnya / merancang ulang sistem karena pilihan antara 2 arsitektur dibuat berdasarkan asumsi yang diambil dari spesifikasi .

• Dalam hal TDD, sebagian besar pekerjaan dimasukkan ke dalam tes mungkin batal.

• Jika perubahan spesifikasi berasal dari pemangku kepentingan tambahan seperti yang disebutkan di atas, mereka mungkin bertentangan dengan spesifikasi yang ada, yang mengakibatkan penurunan kualitas produk yang signifikan (lihat Fighting Vehicle, Bradley).

• Perubahan spesifikasi mungkin melanggar beberapa persyaratan bisnis yang ada yang tidak diketahui atau dipedulikan oleh changer / pemohon (ini benar-benar sama dengan poin-poin terakhir).

Jumlah semua ini tentu saja diperpanjang (kadang-kadang secara signifikan) tanggal pengiriman proyek dan berpotensi meningkatkan kemungkinan cacat.

Untuk contoh terbaik tentang bagaimana perubahan kecil dalam spesifikasi dapat membuat masalah ekstrem, saya punya 3 huruf untuk Anda:

Y2K .

Yang mereka lakukan hanyalah mengubah spesifikasi untuk mengatakan " harus bekerja setelah tahun 2000 ".

Selain itu, dalam beberapa situasi memang benar bahwa spesifikasi HARUS tidak berubah (sebagai lawan dari "tidak boleh berubah tanpa alasan yang baik"):

• Bagian dari spesifikasi adalah (atau tergantung pada) spesifikasi sistem eksternal yang harus dihubungkan dengan.

• Bagian dari spesifikasi adalah (atau tergantung pada) perangkat keras yang diimplementasikan oleh sistem.

• Persyaratan kontrak dengan klien (meskipun batasannya secara tegas berbicara tentang mengubah spesifikasi tanpa bekerja melalui perubahan dengan klien terlebih dahulu dan mengubah kontrak, yang bertentangan dengan fakta perubahan saja)

• Suatu sistem mungkin perlu memenuhi persyaratan hukum atau peraturan khusus terlepas dari preferensi pelanggan. Contoh: enkripsi kartu kredit, perlindungan data pajak.

Melarang perubahan spesifikasi selama pengembangan sangat ideal untuk programmer, tetapi tidak realistis dalam pengaturan dunia nyata. Orang akan selalu ingin melakukan perubahan, bahkan ketika barang dikirim keluar. Tidak pernah berhenti. Dan beberapa dari orang-orang itu mungkin menandatangani gaji Anda. Semakin mereka peduli, semakin mereka memikirkannya, dan karena itu semakin sering mereka ingin merevisi desain. Anda harus bisa mentolerir perubahan desain sebelum selesai, bahkan jika itu berarti memulai dari awal.

Yang penting adalah untuk mengkomunikasikan dengan jelas konsekuensi dari perubahan sehingga setiap orang memiliki harapan yang realistis terhadap proses desain.

Perubahan harus didiskusikan dengan benar, dan orang yang bertanggung jawab atas hal tersebut harus memiliki pemahaman yang jelas tentang dampak perubahan yang akan terjadi pada tanggal pengiriman. Untuk mendapatkannya, dia harus berbicara dengan pengembang. Namun, karena diskusi perubahan yang sedang berlangsung akan membanjiri pengembang dan menjaga pekerjaan nyata tidak terjadi, perubahan harus antri dan dibahas pada interval yang direncanakan dan jarang. Itu yang Anda harapkan, tentu saja.

Idealnya, Anda menginstruksikan orang untuk membuat catatan tentang perubahan yang ingin mereka buat dan meminta mereka menyampaikannya dalam rapat koordinasi mingguan / dua mingguan / bulanan / apa pun. Selama pertemuan, setiap permintaan perubahan dibahas, termasuk diskusi tentang modifikasi mendasar yang perlu dilakukan untuk menerapkan fitur yang diminta, dan oleh karena itu pengaruhnya pada tanggal penyelesaian. Setelah "biaya" perubahan ditetapkan, maka mereka kemudian dapat menentukan apakah akan memasukkannya atau tidak.

Hal penting yang diperkenalkan oleh proses ini adalah gagasan bahwa setiap perubahan memiliki biaya yang terkait, dan biaya umumnya lebih tinggi seiring berjalannya proyek, karena lebih banyak pekerjaan yang harus diduplikasi. Orang-orang yang tidak bekerja dalam pembangunan biasanya tidak tahu berapa banyak biaya perubahan; satu-satunya cara bagi mereka untuk mengatakan adalah mengusulkan dan mengukur reaksi Anda. Membuat proses peninjauan perubahan yang terdefinisi dengan baik akan membantu mereka dan Anda.

Perhatikan bahwa programmer cenderung sangat optimis tentang betapa mudahnya membuat perubahan, atau sangat pesimis tentang betapa mustahilnya melakukan hal itu. Coba cari tahu apa Anda dengan membandingkan perkiraan awal Anda dengan hasil, dan sesuaikan sesuai.

Mungkin akan lebih baik untuk mengatakan bahwa spesifikasi tidak boleh berubah tanpa permintaan dan proses perubahan yang valid. Meminta perubahan spesifikasi berdampak pada jadwal dan biaya, jadi ini harus dimasukkan dalam persetujuan.

Mengingat bahwa ada proses manajemen perubahan yang tepat, tidak ada yang "salah" tentang mengubah spesifikasi, tetapi kemungkinan akan sangat mahal, sehingga pelanggan Anda mungkin tidak terlalu senang. Anda dapat melindungi mereka dari diri mereka sendiri dengan mencoba mendapatkan beberapa persyaratan dan spesifikasi yang baik di depan, sehingga diperlukan lebih sedikit perubahan.

Analogi terbaik yang saya miliki adalah membandingkannya dengan membangun rumah. Arsitek menyusun rencana, dan kemudian muncul dengan perkiraan, pelanggan kemudian setuju (atau tidak) dengan rencana tersebut. Jika pelanggan menginginkan kamar mandi tambahan dimasukkan maka pekerjaan berhenti, rencana harus berubah, perkiraan baru dilakukan dan pelanggan setuju (atau tidak).

Menulis perangkat lunak tidak berbeda. setelah perjanjian dibuat (setelah desain dan perkiraan) maka jika ada perubahan yang perlu dilakukan maka pekerjaan harus dihentikan untuk dapat membuat rencana baru, estimasi baru kemudian membuat mereka disetujui (atau tidak) dan kemudian pekerjaan dilanjutkan.

dimanapun saya katakan atau tidak berarti proyek berjalan tanpa perubahan baru. Tentu saja selalu ada waktu dan bahan untuk membuat rencana dan perkiraan baru.