Bagaimana cara menghentikan spek pengembangan agar tidak berubah di pertengahan pengembangan?

Masalah : Tampaknya dengan hampir setiap upaya pengembangan yang saya lakukan, tidak peduli berapa banyak waktu yang dihabiskan untuk perencanaan sebelum memulai pengembangan, selalu ada sejumlah besar perubahan yang diperlukan baik di tengah atau menjelang akhir proyek. Ini kadang-kadang perubahan besar yang membutuhkan banyak pengembangan kembali.

Saya tidak bekerja untuk klien yang membayar uang, ini adalah tim pengembangan in-house di situs web pengembangan in-house. Jadi, bukan berarti saya bisa meminta bayaran untuk itu atau apa pun. Dan pada akhirnya, kita harus mencoba mencapai tenggat waktu.

Pertanyaan : Apa saja cara terbaik yang kalian temukan untuk meminimalkan dan mencegah perubahan spesifikasi agar tidak muncul di tengah atau setelah pengembangan?

Ada pepatah militer terkenal, dikaitkan dengan Helmut von Moltke: "Tidak ada rencana pertempuran bertahan kontak dengan musuh". Dalam nada yang sama, saya tidak berpikir itu mungkin untuk membuat spek yang tidak harus diubah - tidak kecuali Anda dapat memprediksi masa depan dan membaca pikiran para pemangku kepentingan (bahkan kemudian mereka mungkin belum membuat keputusan, bahkan jika mereka mengklaim mereka melakukannya). Saya akan menyarankan sebagai gantinya mendekatinya dalam beberapa cara:

1. Buat perbedaan yang jelas apa yang bisa diubah dan apa yang tidak bisa. Komunikasikan dengan jelas kepada para pemangku kepentingan, buat mereka secara eksplisit menandatangani hal-hal yang tidak dapat diubah sesegera mungkin.
2. Bersiaplah untuk perubahan di muka. Gunakan metodologi kode yang memungkinkan untuk mengubah bagian yang dapat diubah dengan lebih mudah, berinvestasi dalam konfigurasi, enkapsulasi, dan protokol yang jelas yang memungkinkan bagian diubah dan diganti secara independen.
3. Sering berbicara dengan pemangku kepentingan, meminta umpan balik dan persetujuan. Ini akan membuat Anda tetap sinkron dan menghindari mereka mengklaim "oh, bukan itu yang kami inginkan" ketika sudah terlambat. Seperti disebutkan dalam jawaban lain, metodologi lincah dan mini-rilis yang sering akan membantu Anda dengan itu.
4. Masukkan jadwal untuk mengakomodasi perubahan yang tak terhindarkan. Jangan takut untuk mengatakan "kita akan membutuhkan lebih banyak waktu" lebih awal jika Anda pikir Anda akan - jika jadwal yang Anda berikan tidak realistis lebih baik untuk mengetahuinya (dan membuat Anda pada catatan mengatakan itu) pada awalnya daripada pada tamat.
5. Jika perubahan terlalu luas dan mengancam batas waktu - dorong kembali dan ucapkan sesuatu seperti "perubahan ini mungkin, tetapi akan mendorong batas waktu pada waktu X, tentukan pilihan Anda".
6. Buat proses formal untuk meminta perubahan, memprioritaskan perubahan, dan menetapkan perubahan pada versi atau rilis. Jika Anda dapat memberi tahu orang-orang "Saya tidak bisa melakukannya dalam rilis ini, tetapi dengan senang hati akan mengaturnya untuk yang berikutnya", itu jauh lebih baik daripada mengatakan kepada mereka "Anda terlambat, perubahan Anda tidak bisa masuk , selamat tinggal "dan akan menjadikan mereka teman Anda - mereka akan senang bagi Anda untuk merilis tepat waktu sehingga Anda bisa bebas lebih cepat untuk sampai ke rilis berikutnya yang akan memiliki perubahan mereka - dan bukan musuh Anda.

Kirim sesuatu (saya ragu menggunakan kata apa pun) lebih awal dan mengirimkannya sesering mungkin. Yaitu - gunakan semacam metodologi pengembangan berulang.

Ini adalah dasar pengembangan Agile, tetapi dapat digunakan dengan (hampir) metodologi apa pun.

Dengan memecah proyek menjadi serangkaian proyek mini Anda mendapatkan kontrol lebih besar karena Anda dapat menempatkan sesuatu di depan klien lebih awal, Anda tidak terkunci dalam jadwal pengembangan panjang yang menjadi ketinggalan zaman ketika klien berubah pikiran (seperti mereka akan).

Ketika mereka melihat sistem berevolusi, beberapa persyaratan akan berubah, beberapa akan menjadi berlebihan dan yang lain akan meningkat dalam prioritas. Namun, dengan memiliki siklus hidup proyek pendek Anda akan dapat mengatasi perubahan ini.

Teori bahwa adalah mungkin untuk sepenuhnya menentukan proyek perangkat lunak dari berbagai ukuran yang signifikan adalah fantasi yang lengkap. Teori ini telah ditemukan tidak berfungsi dalam organisasi dari besar ke kecil untuk hampir sepanjang sejarah pengembangan perangkat lunak.

Anda HARUS menemukan beberapa cara untuk mengakomodasi perubahan saat berjalan! Mereka akan terjadi, karena sebagian besar pemangku kepentingan, bahkan jika mereka mengatakan 'ya, itu yang saya inginkan' sebenarnya tidak tahu apa yang mereka inginkan sampai itu di depan mereka. Itu sebabnya kami memiliki begitu banyak orang yang mengadopsi metode berulang.

Apakah Anda melakukan iterasi produk atau apa pun, Anda HARUS menemukan beberapa cara untuk mengakomodasi perubahan ini, karena mencoba menemukan cara untuk tidak melakukan perubahan hanyalah meminta gravitasi untuk mematikan diri selama beberapa menit sehingga Anda dapat terbang.

Jangan mencoba untuk mencegah perubahan, merangkulnya . Semakin Anda merencanakan ke depan, semakin besar kemungkinan rencana Anda akan berubah. Jadi, rencanakan lebih sedikit , bukan lebih. Adopsi metodologi pengembangan yang gesit di mana Anda sering mengirimkan potongan kecil kode kerja, memberi pelanggan kesempatan untuk mengubah spesifikasi setiap beberapa minggu.

Anda mengajukan pertanyaan yang salah. Perubahan spesifikasi akan selalu terjadi dalam proyek pengembangan perangkat lunak dalam berbagai ukuran.

Seringkali karena persyaratan bisnis berubah tetapi saya juga telah melihatnya terjadi karena pelanggan (internal atau eksternal) dapat kesulitan untuk memvisualisasikan apa yang mungkin terjadi tanpa melihat sesuatu untuk diulangi, sehingga mereka memiliki visi yang perlahan berubah saat mereka terlibat dengan mengembangkan solusi.

Pertanyaan yang harus Anda ajukan bukanlah "bagaimana saya bisa mengunci spesifikasi", melainkan "bagaimana saya bisa menyusun kode dan proses saya untuk menanggapi lingkungan yang berubah tanpa membuang semua yang sudah saya tulis?"

Ini kemudian membawa Anda ke arena bingo kata kunci: metodologi lincah, pengembangan berulang dan solusi teknis seperti pengkodean berbasis modul / modular, integrasi terus menerus ... daftarnya terus berlanjut.

Saya tidak mengatakan ini adalah peluru perak untuk semua masalah Anda, tetapi mereka semua terjadi karena keinginan untuk mengelola situasi yang Anda gambarkan sehingga setidaknya mereka layak diselidiki.

Maaf jika itu tidak menawarkan solusi konkret tapi saya cenderung berpikir perubahan pola pikir untuk menerima dan mengelola perubahan akan membayar dividen yang lebih besar daripada mencoba menghindarinya.

Perubahan hanyalah kejutan ... jika itu kejutan!

Saya sarankan memikirkan:

• dari mana sih perubahan-perubahan ini berasal?
• kenapa kamu tidak menyadarinya lebih awal?
• mengapa Anda tidak berkontribusi pada perubahan ini (dan berpotensi membuat lebih banyak dari mereka)?

Perubahan adalah sifat dari apa yang kita lakukan. Sejak kapan Anda membuat kode algoritma persis seperti yang dibayangkan pada hari 1?

Tetapi jika Anda ingin menghindari terus-menerus menjadi pengembang yang frustrasi "terkejut" oleh perubahan, saya pikir Anda perlu menemukan Anda lebih dekat dengan tindakan di mana keputusan dibuat. Lagi pula, saya yakin Anda memiliki banyak ide tentang bagaimana Anda bisa membuat produk lebih baik. Duduklah di meja, atau terimalah selamanya bahwa Anda hanya harus berurusan dengan "perubahan kejutan" itu.

Yah itu panggilan, klien selalu ingin lebih tetapi di sini ada beberapa hal yang harus Anda pertimbangkan:

HTML Mock-up: Selalu buat mock up HTML untuk menentukan bagian UI suatu aplikasi, perlihatkan kepada mereka bagaimana tampilannya dan tanyakan pendapat mereka. Jika Anda menemukan sesuatu yang masuk akal untuk diubah, wujudkanlah dalam prototipe HTML. Dengan menggunakan ini Anda akan memilah banyak hal seperti masalah UI, aliran dasar dan beberapa add-on (seperti Sortasi, Pagination, no. Catatan yang akan ditampilkan dll.)

Partisipasi aktif dari ujung lain: Ini sangat penting jika Anda mengembangkan untuk organisasi bisnis, masuk ke bisnis mereka minta mereka untuk menjelaskan keraguan Anda dan tanpa gagal bertanya kepada mereka perubahan apa yang mereka inginkan dalam aliran mereka (jika diperlukan).

Rilis modular: Lepaskan kode Anda dengan cara modular, lepaskan, uji, terima umpan balik, dan lepaskan lagi.

Inilah sebabnya mengapa hampir tidak mungkin untuk merencanakan terlalu jauh sebelumnya, tetapi bukan alasan untuk tidak merencanakan sama sekali. Jangan jatuh cinta terlalu jauh dengan rencana Anda dan Anda tidak perlu khawatir mereka menghancurkan hati Anda.

Di dalam perusahaan Anda ada biaya untuk menggunakan sumber daya TI apakah ada yang mengakuinya, melacaknya, atau harus menganggarkannya atau tidak. Kenyataannya adalah, tim Anda hanya dapat membuat begitu banyak kode dalam waktu tertentu. Semua departemen dan proyek berbagi dalam anggaran ini.

Anda tidak dapat mencegah siapa pun dari keinginan untuk mengubah persyaratan, tetapi mereka tidak dapat lepas dari konsekuensinya. Perubahan secara signifikan dapat meningkatkan waktu pengembangan. Itu adalah fakta yang harus mereka hadapi atau putuskan untuk tidak melakukan perubahan. Apakah permintaan dari satu departemen memengaruhi departemen lain? Anda mungkin harus memindahkan proyek mereka sepenuhnya di belakang departemen lain karena permintaan perubahan akan melanggar jadwal waktu kelompok lain.

Keterlibatan pengguna aktif sepanjang siklus pengembangan, dan penggunaan metodologi Agile sebanyak mungkin sangat membantu kami dengan produk kami.

Perubahan spesifikasi tidak dapat dihindari, tetapi dengan bersikap transparan dengan pengguna dan yang terpenting, sering berkonsultasi dengan mereka berarti sebagian besar perubahan ditangkap sedini mungkin.

Bagi saya itu cukup mudah.
Katakan pada orang itu, "Pemilik produk" , yang telah memesan fitur bahwa ini OK, tetapi ia harus memilih beberapa fitur yang direncanakan, yang mungkin tanpa batas waktu ini.
Anggap saja sebagai rapat setengah sprint dengan PO tempat Anda memberi tahu dia bahwa sprint tidak akan hangus hingga 0.

Ps. Jika bukan "PO", saya akan mengatakan jangan bicara dengan saya, pergi melalui "PO"

Apa saja cara terbaik yang Anda temukan untuk meminimalkan dan mencegah perubahan spesifikasi agar tidak muncul di tengah atau setelah pengembangan?

Tidak ada cara terbaik. Terserah manajemen untuk membatasi perubahan pada spesifikasi dalam fase pengembangan tertentu.

Namun, Anda harus merancang perangkat lunak Anda sedemikian rupa untuk mengharapkan perubahan. Maka dampak perubahan akan jauh lebih sedikit. Pengembangan berulang dan bertahap adalah awal yang baik.

Saya telah menemukan bahwa, secara langsung atau tidak langsung, pelanggan adalah penyebab sebagian besar perubahan (dan juga bug paling kritis, BTW). Jadi solusi yang jelas adalah menghilangkan pelanggan. (Apa gunanya mereka?)

Karena Anda tidak dapat mencegah perubahan, Anda harus menerimanya. Saya pikir hal terpenting yang dapat Anda lakukan adalah: Anda perlu mencoba mendapatkan permintaan perubahan dari pelanggan sedini mungkin , karena lebih murah untuk mengubah hal-hal ketika hanya ada sedikit kode. Jadi, Anda perlu mempresentasikan desain Anda sedini mungkin kepada pelanggan dengan menggunakan prototipe (mungkin bahkan prototipe kertas), menggunakan metode gesit dan sebagainya.

Anda dapat mempertimbangkan untuk memperkenalkan beberapa disiplin dalam proses pengembangan menggunakan metodologi seperti SCRUM. Di SCRUM, sebuah tim membuat rencana awal dengan memecah implementasi fitur menjadi cerita , dan menugaskan masing-masing cerita sebuah perkiraan upaya (jumlah jam kerja atau hari yang dibutuhkan untuk mengimplementasikan cerita itu).

Jika perubahan yang terlambat diminta (untuk cerita yang sudah diterapkan), Anda perlu membuat cerita baru dan memperkirakan upaya penerapannya. Kemudian Anda dapat pergi ke manajer Anda ( pemilik produk ) dan hanya menjelaskan bahwa fitur baru akan dikenakan biaya waktu tambahan itu. Manajer proyek kemudian memiliki tanggung jawab untuk menerima upaya ekstra dan menyesuaikan jadwal (mungkin membatalkan cerita lain yang belum diimplementasikan).

Bahkan jika tim Anda tidak akan sepenuhnya mengimplementasikan SCRUM atau proses pengembangan lainnya, Anda setidaknya bisa memperkenalkan perencanaan berdasarkan cerita , memperkirakan upaya pengembangan untuk setiap cerita, dan menyesuaikan jadwal ketika cerita baru diminta.

http://teddziuba.com/2010/05/why-engineers-hop-jobs.html

Saya menghabiskan terlalu banyak malam setelah bekerja menekankan dan tidak bahagia karena orang lain belum mengerti atau peduli bagaimana bisnis perangkat lunak bekerja. Saya tidak punya masalah menghadapi siapa pun yang lebih tinggi, tetapi saya tidak memiliki dukungan dari sesama kutu buku saya. Memiliki anak itu menyebalkan, eh? Saya kemungkinan akan segera berhenti.

Terus terang, saya berharap programmer pada umumnya punya lebih banyak bola. Mari kita lihat ini:

"" "Saya tidak bekerja untuk klien yang membayar uang, ini adalah tim pengembangan in-house di situs web pengembangan in-house. Jadi, sepertinya saya tidak bisa mengenakan biaya untuk itu atau apa pun. Dan pada akhirnya, kita harus mencoba mencapai tenggat waktu. "" "

Jika Anda berurusan dengan klien yang membayar $ dan jika Anda menutupi pantat Anda dengan memiliki kontrak (http://vimeo.com/22053820?utm_source=swissmiss), maka perubahan dalam spesifikasi akan membebani klien ini lebih banyak waktu DAN lebih banyak uang ( atau berpotensi sama atau kurang waktu tetapi secara eksponensial lebih banyak uang). Perusahaan Anda sedang berusaha melepaskan spec tanpa menimbulkan biaya lebih banyak waktu dan lebih banyak uang.

Sementara itu, mencoba mencapai tenggat waktu menyebabkan Anda dan rekan kerja Anda TIDAK PERLU stres; Anda tidak dapat menghabiskan akhir pekan yang berkualitas dengan teman / keluarga. Ini benar-benar tidak perlu, karena siapa pun yang melempar pekerjaan pada Anda mungkin bahkan tidak mengetahuinya, yang menyedihkan.

Solusi yang saya usulkan: bersama-sama punya nyali untuk menghadapi mereka dan menjelaskan bahwa tidak ada makan siang gratis dan semuanya ada biayanya, bahwa montir otomatis akan membutuhkan waktu lebih lama dan biaya lebih banyak jika spesifikasi diubah di tengah kerja, bahwa agen kontrak akan membutuhkan waktu lebih lama dan menagih lebih banyak jika spesifikasi diubah di tengah kerja, dan ada alasan bagus untuk itu. Jika mereka tidak mau bekerja dengan Anda dengan cara yang masuk akal, maka Anda sebagai kelompok akan bangun dan pergi, dan mereka harus mempekerjakan pengembang yang dapat mengambil proyek di mana proyek itu ditinggalkan dan tepat waktu.

Lalu ada juga janji pengembangan tangkas, yang tidak menyiratkan tenggat waktu yang sulit.

Saya belum melihat pemrogram mogok, tapi ini akan menjadi sesuatu. Manajer yang tidak kompeten terlalu banyak di perusahaan perangkat lunak. Terlalu banyak orang yang ingin mendapatkan sesuatu tanpa bayaran, di Craigslist atau dalam perusahaan yang sebenarnya. http://teddziuba.com/2011/07/the-craigslist-reverse-programmer-troll.html

Programmer perlu memiliki lebih banyak bola.

Sebuah pendekatan yang saya temukan yang bekerja agak OK (tidak dengan semua manajer jelas) adalah "Saya pikir saya bisa melakukan itu, ya. Itu tergantung - berapa banyak waktu tambahan yang Anda tetapkan untuk proyek ini? Ini perubahan yang cukup besar bagi Anda meminta. "