Apakah menulis perangkat lunak tanpa persyaratan merupakan keterampilan yang harus dimiliki atau situasi yang harus saya hindari?


44

Saya menemukan bahwa beberapa pengembang perangkat lunak sangat mahir dalam hal ini, dan sering kali dipuji karena kemampuan mereka untuk memberikan konsep kerja dengan persyaratan abstrak. Terus terang, ini membuatku gila, dan aku tidak suka "mengada-ada" saat aku pergi. Dulu saya pikir ini bermasalah, tapi saya mulai merasakan perubahan, dan saya bertanya-tanya apakah saya perlu menyesuaikan proses pemikiran (dan pemrograman) saya ketika diberikan arahan yang sangat sedikit. Haruskah saya mulai mendapatkan kemampuan ini sebagai keterampilan, atau berpegang pada gagasan bahwa pengumpulan persyaratan dan aturan bisnis adalah prioritas utama?


2
Situasi yang harus dihindari. Hanya masalahnya, Anda tidak bisa. Dan saya sudah berteriak-teriak tentang hal itu beberapa minggu yang lalu ...
yannis

64
Keduanya, seperti mengoperasikan alat pemadam kebakaran.
Ben Brocka

3
Jika Anda gagal merencanakan, Anda berencana untuk gagal. Proyek-proyek ini dibangun tanpa persyaratan mungkin atau tidak sesuai harapan pelanggan ketika mereka meninggalkan toko tetapi mereka hampir pasti menyembunyikan banyak dosa yang berarti bahwa ketika persyaratan berubah (dan mereka selalu melakukannya) dunia yang terluka menunggu orang yang harus lakukan perubahan yang diperlukan. Programmer yang menulis tanpa persyaratan formal tidak boleh dipuji, mereka harus ditegur karena gagal dipersiapkan untuk pemeliharaan jangka panjang di masa depan proyek
GordonM


5
Terkadang, pelanggan tidak tahu apa yang mereka inginkan. Mereka ingin Anda menjalankan "percobaan" untuk menentukan apa yang mereka inginkan. Saya pernah menulis sistem komisi di mana satu-satunya syarat adalah membayar komisi. Persentase dan item yang akan dibayar komisi ditentukan berdasarkan pengalaman dengan sistem komisi eksperimental.
Gilbert Le Blanc

Jawaban:


80

Keahliannya bukan menulis perangkat lunak tanpa persyaratan. Alih-alih untuk mendapatkan persyaratan dari pemilik proyek terlepas dari apakah ada dokumentasi persyaratan formal atau tidak.

Mengumpulkan persyaratan jelas merupakan prioritas utama Anda, tetapi Anda tidak perlu selalu mencatat semua kebutuhan pelanggan. Risikonya tentu saja adalah bahwa Anda mungkin kehilangan beberapa informasi penting yang membuat arsitektur sistem Anda tidak berguna jika Anda belum berhasil memiliki jenis percakapan yang tepat dengan pelanggan Anda, namun itu tidak biasa untuk mendefinisikan suatu produk dan bahkan mendapatkan banyak pengembangan keluar dari jalan, sambil menunda keputusan arsitektur sistem utama sampai saat-saat terakhir yang mungkin. Ini adalah pendekatan pengembangan lean yang dimaksudkan untuk memastikan bahwa Anda tidak berkomitmen pada arsitektur yang berpotensi tidak kompatibel terlalu dini dalam pengembangan produk Anda sampai Anda memiliki informasi yang lebih solid. Dalam situasi OP telah dijelaskan dalam pertanyaannya,

Ya, kadang-kadang Anda perlu sedikit menatap bola-bola untuk mendapatkan inti dari apa yang sebenarnya diminta oleh pelanggan, yang merupakan tempat prototipe lonjakan dan yang lambat - dan ya kadang menyakitkan - tambahan gambar dari persyaratan membutuhkan Anda benar-benar mengembangkan keterampilan hubungan pelanggan yang baik, dan juga kesabaran untuk menyadari bahwa dengan gagasan perangkat lunak yang rumit, bahwa pada awalnya pelanggan tidak sering tahu lebih banyak daripada Anda tentang apa yang sebenarnya perlu dilakukan oleh perangkat lunak. Paling sering, pelanggan menelepon Anda lebih awal untuk bergantung pada keahlian Anda untuk menentukan persyaratan mereka karena pelanggan tidak selalu memiliki keahlian atau pengetahuan yang diperlukan dari proses pengembangan perangkat lunak.


22
"Keahliannya bukan untuk menulis perangkat lunak tanpa persyaratan. Alih-alih untuk mendapatkan persyaratan dari pemilik proyek terlepas dari apakah ada dokumentasi persyaratan formal atau tidak." Ini juga sesuatu yang sudah banyak saya pikirkan. Ini hampir seperti menjadi detektif yang baik, atau mengetahui cara mewawancarai seseorang dan mengajukan pertanyaan yang tepat. Dalam situasi ini saya menemukan pertanyaan, "Bisakah Anda memberi tahu saya apa yang ingin Anda lakukan?" bekerja jauh lebih baik daripada "Bisakah Anda memberi tahu saya cara kerjanya?"

5
@BrianReindel Saya terkadang mulai dengan kombinasi Mind-Map / Binary-Tree dari pemikiran pelanggan. Saya bertanya "Apa idenya?", Lalu gunakan asosiasi kata untuk melihat apa yang dibawa oleh setiap ide ke benak pelanggan. Dari sana saya membangun gambaran tentang apa yang dipikirkan pelanggan, dan saya mulai mendefinisikan persyaratan dari sana. Setiap persyaratan menimbulkan pertanyaan yang perlu ditanyakan. Biasanya pertanyaan "Mengapa" memberi saya respons yang lebih baik daripada pertanyaan "Apa / Bagaimana", karena mereka memberi pelanggan kesempatan untuk berpikir di luar dasar-dasar. Ini pada dasarnya adalah seni dalam menggunakan psikologi untuk mendapatkan pelanggan mengungkapkan kebutuhan.
S.Robins

3
Bagian dari keterampilan adalah mengetahui urutan untuk melakukan sesuatu dan untuk menghindari "menyempurnakan" hal-hal yang akan rusak. Dengan begitu, Anda dapat bertemu dengan pelanggan / manajer / apa pun, menunjukkan kepada mereka apa yang Anda miliki sejauh ini, dan menyesuaikannya seiring berjalannya waktu. Anda harus tahu cara mengambil langkah besar dalam arah umum yang benar terlebih dahulu.
David Schwartz

4
Salah satu cara memunculkan persyaratan adalah memberi mereka sesuatu yang mendasar, dan melihat bagian mana yang mereka keluhkan. Misalnya, buat prototipe kertas ( amazon.co.uk/... ) dan jalankan melalui interaksi dengan mereka.
deworde

35

Ini sangat ambigu ...

Dua hal yang bisa saya katakan:

  1. Ada banyak orang teknis yang sangat berbakat yang kariernya terhenti karena mereka menunggu persyaratan yang sempurna. Atau mereka memainkan, "Maaf, tidak bisa melakukannya, tidak ada dalam persyaratan." Kenyataannya adalah persyaratan menulis sangat sulit. Ketepatan yang diperlukan untuk persyaratan yang baik tidak seperti apa pun yang sebagian besar pelaku bisnis pernah ciptakan. Ada jembatan antara teknologi dan bisnis, dan orang-orang yang membuat yang lain datang 100% dari cara untuk bertemu dengan mereka biasanya kalah.

  2. Ada orang-orang perangkat lunak yang mempelajari domain sebagai baik atau lebih baik daripada pelanggan mereka. Orang-orang ini sepadan dengan bobot mereka dalam emas, bahkan jika mereka bukan 100% pengembang terbaik. Saya telah melihat orang-orang perangkat lunak mengantisipasi kebutuhan pemasaran kuantitatif manajer merek terbaik di negara ini. Mereka bukan yang terbaik dalam mengkodekan semua solusi, tetapi mereka adalah pahlawan karena mereka dapat menyeberangi jembatan.

Hidup bukan tentang hitam dan putih. Jika Anda menggambar kotak sempit di sekitar diri Anda, Anda akan membatasi diri. Di sisi lain, organisasi yang menolak apa yang diperlukan untuk menciptakan teknologi juga terbatas. Anda harus melihat di mana di abu-abu yang Anda inginkan.


12

Persyaratan adalah langkah-langkah dalam perjalanan, visi adalah arah

Untuk banyak aplikasi, spesifikasi teknis yang sangat terperinci terlalu jauh di muka karena diskusi singkat dapat membuat dokumen penyetelan mereka dengan hati-hati tidak berguna. Sebaliknya, mulailah dengan sebuah visi. Jika semua orang memahami gambaran keseluruhan maka persyaratan dapat diisi sepanjang jalan melalui diskusi.

Sebagai pengembang, Anda harus belajar menggunakan diskusi ini untuk mencari persyaratan . Ini berarti mengajukan pertanyaan-pertanyaan utama kepada pelanggan yang membuat mereka berpikir tentang bagaimana keputusan mereka hari ini cocok dengan visi keseluruhan. Semakin awal diskusi yang lebih rinci ini terjadi, semakin cepat visi keseluruhan akan memantapkan menjadi desain yang koheren.

Anda harus melacak hasil diskusi ini di semacam pelacak masalah sehingga orang lain dapat mengomentari mereka jika mereka melewatkan diskusi asli. Dan agar Anda memiliki catatan, Anda, atau anggota lain dari tim Anda, dapat merujuk kembali jika Anda memerlukan klarifikasi.

Jadi, belajarlah untuk menentang visi, tetapi bersiaplah untuk memenuhi persyaratan tersebut ketika saatnya tiba.


+1 untuk "Persyaratan adalah langkah-langkah dalam perjalanan, sebuah visi adalah arah"
pengguna

10

Steve Jobs percaya bahwa pelanggan tidak dapat menggambarkan dengan tepat seperti apa produk yang mereka inginkan di masa depan, jadi itu tugas Anda untuk mengirimkannya. Jadi, kecuali Anda selalu memberikan perangkat lunak khusus, lupakan spesifikasi formal dan mulai dengan membuat prototipe dan membiarkan pelanggan bermain dengannya dan memberi tahu Anda apa yang mereka pikirkan. Anda harus membuat orang yang tepat melakukan prototyping, dan mereka perlu bantuan. Saya mengatakan ini dari pengalaman - Saya monyet prototipe yang suka membuat antarmuka intuitif dan saya bekerja sama dengan seseorang dalam produk yang mengerti apa yang diinginkan klien dan dapat menjelaskan hal-hal di atas kertas atau menggunakan Excel.

Tak satu pun dari kami yang jenius, tapi kami berpikir sama - Anda hampir bisa mengatakan kami telah memiliki chemistry dan telah memiliki dampak besar pada hal-hal yang sedang dibangun dan bagaimana. Sekarang, hanya tim menengah hingga besar yang mampu memiliki prototipe dan bukan pembuat kode yang mengembangkan produk secara eksklusif, tetapi itu sangat berharga. Prototyping adalah tahap termurah dalam pengembangan perangkat lunak, sehingga hanya masuk akal untuk mendapatkan UI dan perilaku yang tampak benar. Saya belum membaca Kode Lengkap tetapi saya pikir ada sesuatu seperti itu yang tertulis dalam buku itu.

Spesifikasi bagus untuk dimiliki, tetapi tidak pernah sempurna. Ada teorema tentang itu. Anda tidak dapat membuktikan bahwa spesifikasi telah selesai dan Anda tidak dapat membuktikan bahwa alat tersebut tidak memiliki bug atau akan berhenti :)

Namun, perusahaan perangkat lunak melakukan pengiriman perangkat lunak sepanjang waktu meskipun ada ketidaksempurnaan dalam proses ini. Speknya tidak akan pernah sempurna. Spek ini juga UNNATURAL dan ketinggalan zaman. Spek untuk prototipe seperti tabel logaritma untuk satu grafik - spek pada dasarnya adalah brosur yang membosankan yang ingin dicetak sedangkan Anda bisa berinteraksi dengan alat / grafik sebagai gantinya. Lihatlah http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.html untuk mendapatkan inspirasi.

Sekarang, spek itu bagus jika Anda harus memiliki kontrak untuk menutupi pantat Anda. Tetapi spec masih harus datang setelah prototipe, bukan sebelumnya. Adalah tugas Anda untuk mencari tahu cara membuat prototipe murah.


+1 untuk spec tidak pernah sempurna, tetapi -1 untuk spec tidak alami dan ketinggalan zaman. Pikirkan persyaratan sebagai daftar fitur yang diinginkan klien, dan Spec menjadi daftar perilaku yang menentukan apa yang dibutuhkan pelanggan. Pada dasarnya kontrak semacam mendefinisikan bagaimana fungsi sistem, bukan apa sistem itu. Desain dan spesifikasi besar di depan bermasalah, namun seperti semua masalah besar lebih mudah dilakukan ketika dipecah untuk dilakukan sedikit demi sedikit. Prototipe juga jarang efektif biaya jika Anda tidak tahu APA yang akan prototipe. Di sinilah spesifikasi menawarkan titik awal ...
S.Robins

... Namun, spesifikasi tidak harus ditulis dengan batu. Prototyping (pada dasarnya masalah spiking) paling berharga ketika mereka memasukkan informasi baru kembali ke dalam spesifikasi dan di mana spesifikasi diizinkan untuk berubah untuk mengakomodasi hal-hal yang telah Anda pelajari dari prototipe. Tanpa spek, Anda berisiko hanya mengada-ada saat Anda pergi, yang tidak selalu dalam kepentingan terbaik klien. Klien mengharapkan Anda untuk memenuhi kebutuhan mereka, dan Anda berisiko lebih sedikit gesekan ketika Anda dapat memberikan bukti bahwa Anda telah menyetujui sesuatu, bahkan jika hanya sementara.
S.Robins

@ S. Robins, seorang dokter (klien) mungkin mengatakan sesuatu yang sederhana seperti "Saya ingin melihat pohon keluarga dengan perkiraan risiko kanker yang sesuai untuk setiap anggota keluarga." Karena ada banyak cara berbeda untuk menyajikan informasi ini dan khawatir tentang keluarga besar yang menjangkau beberapa halaman, saya pikir tidak masuk akal untuk segera mulai mendokumentasikan ini sebagai spek. Kami mengerti apa yang dikatakan dokter, tetapi kami ingin mendapatkan yang lebih tepat. Prototipe interaktif yang menampilkan angka dan nama acak yang dapat dikatakan oleh seorang dokter sebagai yay atau nay lebih alami daripada spesifikasi 30 halaman yang tidak lengkap yang mencoba menggambarkan hal yang sama.
Pekerjaan

1
Saya mengerti dari mana Anda berasal, namun apa yang Anda sarankan biasanya merupakan pendekatan yang mahal. Jelas saya tidak menyarankan prototipe adalah produk yang lengkap, tetapi apa pun yang Anda bangun di mana ada interaktivitas akan memerlukan waktu untuk berkembang. Pilihan yang lebih murah adalah berdiri di papan tulis, membuat beberapa ide, dan mengajukan pertanyaan yang ditargetkan untuk membantu Anda mempersempit kriteria Anda. Saya juga tidak menganjurkan untuk membuat spec besar. Garis besar dokumen, atau bahkan templat kode uji, diproduksi secara iteratif dan sesuai kebutuhan, biasanya lebih sederhana dan lebih murah daripada membuat prototipe terlebih dahulu.
S.Robins

3

Saya sering menemukan bahwa dalam beberapa situasi saya perlu bertindak sebagai analis bisnis, menemukan dengan tepat bagaimana bisnis saat ini bekerja, bagaimana orang berpikir itu bekerja (seringkali hal yang sangat berbeda), dan bagaimana mereka ingin itu bekerja.

Saya telah menemukan kesuksesan dengan selalu jelas tentang keputusan yang saya dipaksa untuk membuat perangkat lunak. Saya menjelaskan alasan saya, menulis dokumentasi tentang apa yang saya temukan, membuat grafik dan membagikannya kepada semua orang, dll.

Anda mungkin tidak akan membuat kesan yang sangat baik dengan menolak melakukan pekerjaan apa pun sampai persyaratan lengkap diserahkan. Tetapi dengan mengumpulkan sendiri persyaratan kualitas yang baik (tanpa harus menarik perhatian pada fakta), Anda akan mencapai tujuan yang sama dari perangkat lunak berkualitas.

Dan ya, seperti yang dikatakan komentator lain, selalu buat perangkat lunak dengan asumsi itu akan berubah. Perubahan adalah satu konstanta yang dapat Anda andalkan. Selalu bangun perangkat lunak Anda cukup fleksibel dan modular sehingga tidak akan menyakitkan untuk memperbaruinya ketika beberapa persyaratan baru tiba-tiba muncul.


3

Jika Anda ingin bekerja sebagai pengembang perangkat lunak di startup, itu adalah keterampilan yang harus dimiliki.

Jika Anda ingin bekerja di perusahaan konsultan maka itu adalah situasi yang harus dihindari. Ini karena perusahaan Anda dibayar sesuai dengan seberapa baik Anda mengimplementasikan spesifikasi / persyaratan dan bukan seberapa baik Anda menyelesaikan masalah pelanggan.

Jika Anda menyandi untuk bersenang-senang di waktu luang, maka itu panggilan Anda. Jika Anda merasa tidak memenuhi syarat untuk melakukan panggilan untuk proyek waktu luang Anda, maka cobalah beberapa cara dan lihat mana yang berhasil. Juga tidak perlu hal satu ukuran untuk semua, beberapa proyek memerlukan satu atau jenis pendekatan lainnya. Biasanya jika Anda memilih yang salah di salah satu proyek ini Anda akan mengetahuinya dengan cukup cepat.


2

Sedikit dari keduanya. Anda perlu memuaskan klien Anda, yang berarti Anda harus tahu apa yang mereka inginkan. Di sisi lain, klien terkenal buruk dalam mengkomunikasikan apa yang sebenarnya mereka inginkan.

Jadi, Anda ingin menghindari skenario di mana Anda tidak tahu apa yang diinginkan klien, tetapi Anda pasti akan mengalami skenario di mana persyaratannya 'paling licin', dan menipu paling buruk. Seorang programmer dunia nyata yang baik membutuhkan kemampuan beradaptasi.


2

Tidak mungkin menulis program tanpa persyaratan. Bahkan 'Hello World' memiliki persyaratan: untuk menghasilkan output. Jadi, saya pikir Anda bertanya tentang persyaratan formal, dalam bentuk tumpukan besar sesuatu yang mirip UML. Dan mengenai itu, saya sudah bertemu 2 macam orang:

1) Orang yang membutuhkan persyaratan formal. Mereka perlu diberi tahu persis apa yang harus dilakukan, dan paling baik bagaimana melakukannya. Mereka menyukai kalimat-kalimat seperti Prosedur A yang mengambil argumen B akan menghasilkan C , dan mereka membenci kalimat-kalimat itu: Program harus membuat pekerjaan departemen kami lebih efektif . Mereka biasanya binatang perusahaan.

2) Orang-orang yang berseberangan dengan 1. Mereka benci diberi tahu apa yang harus dilakukan dan bagaimana melakukannya, mereka senang diberi tahu apa yang harus dicapai. Mereka suka berbicara dengan klien, menganalisis apa yang mereka katakan dan kemudian mengembangkan solusi mereka sendiri. Mereka biasanya pekerja lepas dan tidak cocok untuk korporasi.

Saya tidak akan mengatakan yang mana yang lebih baik. Keduanya memiliki pro dan kontra. Mereka cukup memadai untuk kondisi lainnya.


0

Anda TIDAK dapat mengembangkan perangkat lunak operasional tanpa mengetahui Persyaratan; tetapi, Anda dapat memiliki menusuk periang baik untuk mengembangkan apa pengalaman Anda memberitahu Anda Persyaratan yang mungkinmenjadi. Pengembangan tangkas menggunakan kombinasi teknik 'intuitif', termasuk Aturan 80:20 dan 'penemuan' Persyaratan dengan membuat prototipe. Dengan kata lain, tim pengembang yang berpengalaman membuat tebakan terbaik atas apa yang dibutuhkan dan menghasilkan prototipe perangkat lunak. Aturan 80:20 mengatakan mereka akan 80% benar. Stakeholder proyek kemudian meninjau prototipe nyata. Umpan balik mereka mulai mengisi celah 20% dalam pemahaman kami tentang Persyaratan. Jadi, pada dasarnya, Agile bukan tentang menulis perangkat lunak tanpa persyaratan, melainkan tentang menggunakan pengalaman Anda sebelumnya untuk mengatakan, "apakah Anda menginginkan sesuatu seperti ini?" Yang, dalam 80% kasus, akan memungkinkan Anda untuk melompat ke depan dan mengkonfirmasi apa yang benar-benar dibutuhkan lebih cepat daripada berlari melalui proses Persyaratan tradisional.


Agile bukan tentang intuisi, ini tentang komunikasi. Memberikan perangkat lunak yang berfungsi sering untuk menerima umpan balik sering mendorong komunikasi dan menilai pengiriman hal-hal yang dibutuhkan pelanggan. Ya, pengalaman ikut berperan, tetapi Anda lebih cenderung mengembangkan apa yang dibutuhkan pelanggan jika Anda pertama kali bertanya apa yang dibutuhkan pelanggan. Aturan 80:20 yang disebut tidak benar-benar berlaku kecuali jika Anda sangat akrab dengan domain bisnis pelanggan, dan bahkan kemudian saya akan mengambil 'statistik' dengan sendok besar garam.
S.Robins

-2

Siapa bilang Agile menulis kode tanpa persyaratan? Saya tahu Manifesto telah ditafsirkan seperti ini oleh beberapa ... tapi itu tidak benar.


1
Hai Trent, sementara saya setuju dengan komentar Anda pada prinsipnya (dan saya juga bosan melihat bagaimana orang menggunakan Agile sebagai alasan untuk mengacaukan proses pengembangan dan menyebutnya "menjadi gesit"), jawaban ini tidak benar-benar menjawab pertanyaan OP pertanyaan, yang bukan tentang Agile, tetapi bertanya tentang apakah menulis perangkat lunak tanpa persyaratan adalah keterampilan untuk dikembangkan. Mungkin Anda bermaksud menambahkan ini sebagai komentar untuk jawaban orang lain?
S.Robins
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.