Kumpulan persyaratan untuk proyek perangkat lunak - tanpa pemotongan

Pengembangan ... itu seperti narkoba - mereka menulis sebuah sistem, mereka menulisnya, karena ia terburu-buru. Dan kemudian, tiba-tiba ternyata - "tunjangan" perlu dibayar. Dan setiap perubahan dalam sistem mengarah ke segunung kesalahan. Tetapi bahkan pada awal abad terakhir, Kurt Gödel yang agung meramalkan ini dan benar - benar membuktikan bahwa bahkan dalam aritmatika kita tidak memiliki kecerdasan yang cukup untuk mengekspresikan semua hukumnya tanpa kontradiksi. Dan dalam pemrograman dan bahkan lebih lagi - kita akan mulai menginjak kaki kita dan menjadi bingung. Yang, secara umum, adalah yang terjadi: laptop dihidupkan dan dinyalakan kembali pada malam hari, kemudian aplikasi seluler membuat kesalahan sehingga mereka mulai keluar dari saku dan tersebar, dimarahi dan dicicit di lantai.

Dan bagaimana Anda menyukai versi beta modis dari segalanya dan segalanya sekarang? Tampaknya pesawat segera akan mulai muncul dalam versi alpha-beta.

Tetapi Anda dapat memprogram tanpa kesalahan sehingga jiwa bersukacita dan tidak hanya menyenangkan untuk minum bir dengan klien, tetapi juga aman!


Dalam seri publikasi tentang berbagai aspek pengembangan perangkat lunak ini, saya akan mencoba membuat serangkaian nilai dan aturan yang minimalis, yang pertama ditempatkan di kepala orang kebanyakan, dan, kedua, biasanya memungkinkan ... untuk menang dengan biaya dan waktu paling sedikit. Hari ini, mari kita bicara terus terang tentang mengumpulkan persyaratan untuk sistem perangkat lunak.

Teater, teater di mana-mana. Tetapi industri pengembangan perangkat lunak pasti akan mendapat manfaat jika semua peserta dalam proses berbicara kebenaran, pertama, untuk diri mereka sendiri, dan kedua, tidak ada yang akan mendukung emosi dan pelayanan yang tidak sistematis kepada Cthulhu.

Anda tidak perlu melangkah jauh untuk contoh - model pengembangan terbuka dan keberhasilan mereka (tidak selalu nirlaba) menunjukkan dengan meyakinkan:

• kejelasan, keterbukaan, keberanian
• diskusi dengan komunitas dan klien
• identifikasi dan penyelesaian masalah yang cepat

serta komunikasi yang paling adil berdasarkan kepercayaan dan saling menghormati - pimpin solusi perangkat lunak, misalnya situs web, menuju kesuksesan.

Dunia sedang aktif berubah. Komunikasi horisontal terjadi dengan kecepatan cahaya, dan jika kita tidak belajar bagaimana menggunakan senjata baru ini, kita pasti akan kalah. Tapi pertama-tama, lihatlah sekeliling.

Dari mana "perang suci" berasal dari pemrograman?

Semuanya sederhana. Cukup untuk mengingat pelajaran geometri sekolah. Pemahaman ilmiah tentang dunia tempat kita hidup didasarkan pada ... kepercayaan pada "kebenaran abadi" = aksioma, misalnya, bahwa "garis paralel tidak berpotongan" atau dalam jumlah bilangan prima dalam suatu rentang (meskipun ini adalah teorema, tetapi itu anjingnya bekerja, tetapi tidak ada yang mengerti mengapa).

Mustahil untuk membuktikan aksioma, tetap saja percaya bahwa itu selalu berhasil. Tapi kami tidak bisa terbang ke cakrawala acara Lubang Hitam dan memeriksa. Dan jelaskan mengapa interaksi antara foton ditransmisikan lebih cepat daripada kecepatan cahaya juga .

Banyak teori ilmiah menggunakan aksioma untuk kesimpulan logis dari teorema, dan seterusnya dan buku tebal dengan masa garansi tertentu lahir. Akibatnya, dan ini tidak lagi lucu, Teorema Besar Fermat dibuktikan pada tahun sembilan puluhan sedemikian rupa sehingga hanya segelintir dari mereka yang memiliki tingkat pendidikan khusus yang luar biasa yang dapat memahami buktinya, dapat menyekop puluhan halaman teks halus dengan formula di bawah mikroskop :-) Itulah sebabnya mereka melanjutkan mencari bukti "nyata", sederhana dan indah.

Bahkan dalam apa yang kelihatannya lebih sederhana, aritmatika, upaya telah berulang kali dilakukan untuk menertibkan aksioma - tetapi semuanya masih ada ...



Demikian pula, bahasa dan teknologi pemrograman tempat kami membuat situs web, aplikasi seluler, dan sistem informasi, pada kenyataannya, juga mewakili sekumpulan aksioma atau titik referensi, yang pertama-tama Anda perlu "percayai" dan di mana fondasi teknologi dibangun, tetapi tidak mungkin untuk membuktikan bahwa itu benar (walaupun kadang-kadang masih mungkin: coba tulis situs web dalam C ++ dan lihat berapa banyak waktu dan uang yang Anda hilangkan).

Misalnya, di dunia Jawa / C # dan bahasa lain yang otoritatif dan bereputasi, modern, diketik ketat dengan pengetikan statis, Anda hanya perlu mengambil dan "percaya" bahwa dunia terdiri dari psikopat, rentan terhadap kekerasan dan kehilangan identifikasi diri, dan karenanya "serangkaian aksioma" melakukan segalanya untuk melindungi pengembang tidak hanya dari kolega, tetapi juga dari dirinya sendiri (tentu saja, saya bercanda).

Hasilnya adalah sistem perangkat lunak yang dibuat untuk waktu yang lama, dari besi dan beton, yang kemudian ditutupi oleh ratusan autotest, dan sebagai hasilnya mungkin pada saat konstruksi selesai, persyaratan bisnis sudah ketinggalan zaman, senjata nuklir dilarang dan bungker dengan dinding 100 meter akan ditutup. segera ke museum. Tetapi seringkali persepsi seperti itu tentang dunia - bekerja dengan baik, misalnya, dalam pengembangan sistem khusus yang sempit atau di mana biaya kesalahan sangat tinggi (bank, dll.).



Dalam dunia bahasa dinamis dengan pengetikan ketat / tidak ketat (PHP, JavaScript, Python, Ruby), rangkaian aksioma sempurna, dari kata "sepenuhnya", yang lain:

• kami dikelilingi oleh orang-orang pintar yang menulis dengan benar dan rapi segera
• mania penganiayaan (mengubah jenis variabel di bawah daftar, akses ke anggota kelas tersembunyi oleh pengembang lain dengan niat "jahat", refactoring kode yang mendalam diperlukan di depan, dll.) - penyakit yang harus Anda coba pulihkan dengan cepat
• perangkat keras semakin murah, jadi Anda perlu mengkompilasi program hanya dalam beberapa bagian dan kemudian, jika perlu
• semakin banyak kode, semakin banyak kesalahan, sehingga kode harus segera dibaca dengan baik, jelas, singkat dan seksi

Dalam dunia bahasa fungsional, seperti Haskell / OCaml, Anda perlu percaya bahwa:

• tugas apa pun dapat diekspresikan oleh fungsi
• variabel, siklus dan mutabilitas - mengarah ke kesalahan (ini sebenarnya begitu)
• pemrograman - untuk memilih dan cenderung berpikir analitis

Akibatnya, alih-alih skrip kruk sederhana “dibuat, diperiksa, diputuskan, dan dilupakan”, karya ilmiah sungguhan dimulai di tempat kerja dan pencarian "fungsi Tuhan" sangat menarik untuk mengekspresikan situs web ... dengan serangkaian fungsi tanpa variabel, wow!

Tentu saja, saya melebih-lebihkan, tetapi tidak ada asap tanpa api. Meskipun dalam beberapa tugas pendekatan ini berfungsi dengan baik, dan tidak ada yang datang dengan pendekatan yang lebih baik.

"Perang Salib" dalam pengelolaan proyek perangkat lunak

Di bidang manajemen proyek, situasinya bahkan lebih ditutupi dengan kesuraman pseudo-ilmiah. Dan alasannya sudah diketahui: solusi yang jelas, terletak di permukaan, solusi sederhana dan ringkas untuk dahi:

• memahami apa yang diinginkan klien
• menarik spesialis dan mengevaluasi jumlah pekerjaan
• tulis kode

pada kenyataannya, untuk beberapa alasan, itu tidak berfungsi :-)

Peserta berpengalaman dalam tim proyek sangat menyadari bahwa pelanggan sering, klise, tidak tahu apa yang dia inginkan, karena dia kewalahan dengan emosi, dan menyalin masalah matematika di sekolah, yang akhirnya mengarah pada "atrofi otak bagian" parsial yang bertanggung jawab atas ekspresi logis konsisten dari bukunya. pikiran. Memiliki opus puitis, gambar lipstik dan catatan akord gitar, alih-alih persyaratan teknis untuk situs web, spesialis, menangis agar tidak tertawa karena impotensi, menambah taksiran jumlah pekerjaan dengan urutan besarnya, memperkenalkan pajak untuk ketidakcukupan, dan sebagainya.

Di bawah kondisi kurangnya logika dan hasrat yang ketat ini, saya minta maaf untuk menggunakan kepala saya untuk tujuan yang dimaksudkan, seolah-olah dengan cepat, pelanggaran tidak ilmiah yang mengerikan muncul dalam gaya astrologi / numerologi / pranyozhenie dan peramal nasib dengan alasan kopi.

Pelanggaran biasanya dieksploitasi secara aktif oleh orang-orang yang sangat percaya diri yang mampu meyakinkan dengan baik, yang tidak pernah memegang "kode" (ya, saya berbicara tentang Agile yang salah).

Mereka mengatakan bahwa di beberapa tim sebelum sprint bahkan penggemar yang paling bersemangat memaksa kami insinyur, permisi, terapi urin :-) Namun, "praktik" ini sendiri sering dibuat oleh pengembang yang sangat berpengalaman yang, seperti yang lain, dapat menggunakannya dengan benar.

Di sini saya sangat menyukai analogi dengan nunchucks - sepertinya senjata sederhana, tetapi hanya sedikit yang dapat menggunakannya dengan benar, dan sebagian besar terluka, maaf, Anda tahu apa yang Anda sendiri.

Mitos lain adalah interchangeability

Kadang-kadang mereka mencoba meyakinkan kita tentang pertukaran insinyur . Sudah terkenal bahwa untuk mendapatkan pemahaman yang baik dan mendalam tentang teknologi perangkat lunak, Anda perlu membaca banyak buku, mendengarkan belasan kursus , menyelesaikan beberapa ratus masalah dan mengambil bagian dalam lima proyek perangkat lunak, di mana setidaknya satu telah mencapai garis finish. Selanjutnya - percobaan dimulai, yang setelah 5 tahun, setidaknya, membuat encoder - Spesialis.

Biasanya, terus-menerus mengerjakan proyek, pengembang fasih dalam satu atau dua bahasa pemrograman dan teknologi terkait. Keberhasilan dan pertumbuhan profesional seorang insinyur justru terletak pada spesialisasi sempitnya, karena selain bahasa itu sendiri, perlu untuk menyelidiki secara mendalam ke perpustakaan sistem, yang sering sangat banyak dan dokumentasi untuk mereka sangat luas.

Masalahnya adalah bahwa sekarang, untuk beberapa alasan, sangat modis untuk tidak membaca buku - tetapi untuk google dan menghapusnya, tidak termasuk otak, sementara secara mental melakukan masturbasi mental di jejaring sosial dan pemberitahuan ponsel cerdas.

Menemukan spesialis nyata yang secara sistematis belajar dari bawah ke atas, perlahan tapi pasti, menutup celah dalam pengetahuannya sendiri - menjadi semakin sulit. Pasar, sayangnya, dipenuhi dengan "otodidak" dengan ... "tangan manja."

Apa yang harus dilakukan Nilai Kelangsungan Hidup yang Disarankan

Pertama, tidak perlu putus asa dan sangat penting untuk tidak menikmati emosi. Penting untuk memahami dengan jelas bahwa pengembangan adalah, pertama-tama, matematika yang ketat (biasanya di tingkat sekolah) dan logika dengan metrik, di mana, menggunakan terver dan intuisi, perlu untuk menghadapi risiko prioritas dan bos "basah" saat masih bayi.

Kami pernah bermain game online sebelumnya dan itu berhasil dengan baik - jadi silakan, hanya alih-alih bos Anda akan memiliki proyek perangkat lunak, dan bukannya bug - zerg!

Selalu mungkin dan perlu untuk mengelola risiko secara bijaksana dan, dari pengalaman, jika dilakukan "secara sistematis dan ilmiah", proyek perangkat lunak akan lepas landas tepat waktu, atau dengan cepat akan menjadi jelas mengapa rudal tidak dimulai dan apa / siapa, khususnya, masalahnya.

Mengingat hal tersebut di atas, disarankan agar Anda mulai mematuhi nilai-nilai berikut dari pendekatan ilmiah-empiris, yang bersinggungan erat dengan himne yang terkenal dengan akal sehat - " python zen " dan " manifesto lincah ":

1. Cari solusi paling sederhana dan paling jelas
2. Semakin jelas semakin benar
3. Itu menjadi sulit - itu berarti suatu tempat kusen dan Anda harus terus mencari lebih lanjut
4. Arogansi - dari rasa tidak aman atau masa kecil yang sulit
5. Kemampuan otak manusia terbatas, terutama di bawah pengaruh hormon, dan bahkan dalam beberapa periode pun
6. Dari alkohol dan merokok - kami sangat tumpul
7. Kita cenderung cepat melupakan bahkan apa yang kita ketahui dengan baik dan bahkan baru-baru ini
8. Berusaha keras untuk transparansi dan keterbukaan maksimum
9. Saling menghormati
10. Dorong pendakian tercepat dan diskusi masalah dalam lingkaran seluas mungkin - ideal untuk semua
11. Menarik kesimpulan dan jangan menginjak menyapu 3,14 kali berturut-turut :-)

Koleksi Persyaratan

Setelah mempelajari beberapa rahasia dan fitur tren dalam pengembangan perangkat lunak, kami akan dengan percaya diri melanjutkan - kami akan belajar bagaimana mengumpulkan dengan benar persyaratan untuk sistem.

Apakah pelanggan pada prinsipnya dapat berpikir?

Tidak ada yang lucu - ini masih situasi biasa. Dan pelanggan dalam konteks ini adalah konsep kolektif. Pertama-tama, cobalah untuk menilai tingkat pemikiran logis dan kemampuan untuk memusatkan perwakilan pelanggan. Dengan siapa Anda akan bekerja dan siapa yang akan membantu Anda? Opsi yang memungkinkan:

1. Partai politik. Perlu untuk membuat, misalnya, proyek web pada tanggal karena seseorang menginginkan / menjanjikan sesuatu ... Persyaratannya tidak jelas, tidak ada yang tahu detailnya, dan siapa tahu - akan berhenti sejak lama. Proyek itu digergaji oleh tim yang pergi dan hampir mustahil untuk memahami apa yang mereka lihat. Di dinding - otak kering dari, mungkin, bunuh diri seorang programmer terkemuka. Kode ini buruk dan rapuh, baunya sehingga menyakitkan mata Anda. Seringkali dalam situasi seperti itu, mereka mencoba mencari, permisi, "pengorbanan suci", yang dapat disalahkan selama enam bulan ke depan dan ... mulai mencari yang baru. Perasaan takut, menekan dan menekan keterbukaan proses dengan campuran darah di bibir. Kemungkinan membuat solusi perangkat lunak tepat waktu, meskipun kecil, masih ada - jika Anda melakukannya lagi pada kerangka kerja yang sudah jadi dengan dokumentasi yang sudah jadi. Biasanya satu-satunya cara dan tidak ada cara lain.
2. Anda berkomunikasi dengan perwakilan pelanggan dan memahami bahwa sungguh-sungguh sulit bagi orang untuk secara konsisten / formal mengungkapkan pikiran mereka sendiri, yang bingung setelah kalimat ketiga, diulangi dan berputar-putar. Setelah 15 menit dialog, keluhan sakit kepala mulai. Tawa terdengar, suasana pesta, selfie, hidup itu sukses ... Tetapi keinginan, secara umum, dapat dimengerti dan tulus - Anda hanya perlu membantu mereka sedikit untuk bisa keluar dengan ketat. Kemungkinan lepas landas di sini biasanya lebih tinggi dari pada paragraf 1, tetapi sekali lagi, penggunaan solusi kotak yang paling siap pakai dengan dokumentasi siap pakai dan skenario tipikal biasanya membantu.
3. Klien memahami dengan baik apa yang dia inginkan dan mencoba untuk secara logis dan konsisten mengekspresikan pikiran dan keinginannya sendiri. Dalam hal ini ia dibantu oleh seorang analis yang tidak bingung, menjabarkan pemikiran manajemen dan menyampaikannya sebagai miliknya. Tim klien juga memiliki setidaknya satu pakar dalam bidang subjeknya (lucu, tetapi ini masih merupakan situasi yang jarang terjadi). Dalam hal ini, probabilitas untuk membantu dan menyelesaikan masalah secara pemrograman sangat tinggi. Di sini Anda dapat terlibat dalam desain, diskusi bersama glosarium, model objek, model data, aliran data, skenario pengujian beban. Kemungkinan besar, Anda dapat mengumpulkan persyaratan dalam waktu yang wajar.

Poin penting lainnya di sini adalah untuk membangun hubungan yang terpercaya dengan klien, menunjukkan keterbukaan dan keinginan Anda untuk membantu pelanggan mengekspresikan pikiran mereka dengan jelas. Seringkali beberapa jenis pelatihan membantu, di mana perwakilan pelanggan dijelaskan cara bekerja dengan alat pengumpulan persyaratan berikut:

• Glosarium Umum
• Model data logis di mana hubungan multiplisitas yang ketat diperkenalkan antara elemen glosarium (satu ke satu, satu ke banyak, banyak ke banyak)
• Peran dan gunakan rantai yang menunjukkan siapa yang menggunakan sistem dan caranya

Alarm yang akan menunjukkan masalah dalam mengumpulkan persyaratan:

• perwakilan pelanggan menerjemahkan "panah" satu sama lain dan tidak dapat menghubungkan dua kata, ada banyak emosi - disarankan untuk meningkatkan masalah secepat mungkin dan pergi ke tingkat yang lebih tinggi - jika Anda, sebagai "pengorbanan suci", akan disajikan sebagai hadiah kepada kultus dan cuti pensiun / bersalin. Bekerja dalam kondisi seperti itu pada Agile sangat berbahaya, lebih baik menulis persyaratan teknis yang ketat dan bergerak dalam langkah-langkah kecil
• perwakilan pelanggan merespons dengan gaya: oh, kepala Anda sakit, tetapi Anda pintar, seorang "programmer," jadi lakukanlah dengan benar. Di sini Anda perlu meminta untuk menemukan seorang ahli dalam bidang subjek, yang bertanggung jawab atas jawaban atas nama pelanggan dan sesegera mungkin. Atau lihat paragraf di atas.
• mereka lebih suka untuk tidak membicarakan masalah (kode tidak dapat dibaca, kurangnya dokumentasi untuk proses bisnis utama), karena uang dihabiskan, posisi diterima, bonus disuarakan dan berbicara risiko dapat mengarah pada pembersihan intensif staf (namun semua orang "mengerti", dan di sini para insinyur menggulingkan laras) - sulit untuk memberikan saran di sini, bertindak berdasarkan cuaca aktual

Dalam kasus klinis di atas, sekali lagi, pengembangan solusi kotak / cloud siap pakai dengan dokumentasi siap pakai sangat membantu. Pendekatan semacam itu akan mengurangi risiko perubahan mendadak dalam kursus sebesar 180 derajat atas perintah besarnya. Tetapi jaminan sudah kurang.

Dalam hal pendekatan yang memadai dari pihak klien, keinginan untuk mempelajari dan memahami Anda, keinginan tulus untuk meluncurkan proyek tepat waktu dan mengembangkan lebih lanjut, penggunaan simultan beberapa platform teknologi sangat membantu. Mendesain tidak lagi menakutkan - Anda merasa bahwa klien berbagi tanggung jawab untuk mengumpulkan persyaratan dengan Anda 100% dan Anda dapat mencoba melakukannya dengan baik. Anda - memastikan satu sama lain dan bersama-sama berjuang dengan kompleksitas:

• Situs web PHP dengan kerangka kerja, solusi kotak
• analitik prediktif dengan Python
• aplikasi seluler baik pada platform tunggal yang berfungsi di mana-mana, atau kami menulis untuk setiap perangkat

Jangan buang waktu!

Jika selama 2-3 minggu, dalam kasus-kasus ekstrem, satu setengah bulan, perasaan itu tidak lulus bahwa Anda berpartisipasi dalam permainan "mengobrol dengan tampilan yang cerdas dan luangkan waktu dan letakkan semuanya pada seseorang", tarik pemberhentian derek, nyalakan kereta api dan berteriak keras pada teriak: "pulanglah, anak-anak! kinerja sudah berakhir. "

Serius, mengatur pertemuan dengan manajemen klien dan bersikeras untuk menyertakan karyawan yang memadai dalam tim proyek, yang memahami secara rinci bagaimana bisnis ini bekerja dan mampu menjawab pertanyaan yang diajukan secara ketat oleh para insinyur. Atau berhenti - terkadang ini adalah langkah yang tepat: selamatkan wajah Anda dan tumbuh sebagai seorang spesialis.

Daftar periksa

Akibatnya, kami dapat mempertimbangkan proses pengumpulan persyaratan berhasil dan masuk akal untuk melanjutkan jika, bersama dengan pelanggan, Anda dapat menyiapkan artefak berikut dalam beberapa minggu:

1. Daftar istilah 50-150 istilah domain
2. Model data logis dengan hubungan istilah glosarium
3. Gunakan case dengan istilah glosarium
4. Untuk algoritme yang kompleks - diagram alur atau diagram aktivitas UML
5. Antarmuka sistem perangkat lunak yang tidak secara logis bertentangan dengan item di atas
6. Anda telah memutuskan serangkaian aksioma yang menggambarkan sikap Anda terhadap dunia = memilih teknologi perangkat lunak. Di sini, banyak orang, karena kecintaan terhadap kreativitas, tertarik pada sado-masokisme dan keinginan untuk menemukan kembali roda - melawan keinginan ini. Putuskan: apakah seluruh dunia penuh dengan trik kotor dan psikopat dan membuat bunker yang dapat menahan serangan UFO, atau pengembang dengan tulus ingin membantu Anda. Teknologi terbaik dan serangkaian aksioma: kerangka kerja yang dikembangkan atau solusi kotak yang sudah jadi - risiko tidak lepas landas akan berkurang dengan urutan besarnya (dalam pengalaman, 95% dan di atas proyek lepas landas)
7. Anda merindukan sistem perangkat lunak melalui pelanggan, diri Anda sendiri, melalui otak Anda, dan tidak ada tempat berlumpur atau lumpur emosional. Jika ada tempat-tempat yang berpotensi rusak (dan ini, sebagai suatu peraturan, selalu terjadi) - sertakan di dalam rencana manajemen risiko dan suara di setiap pertemuan proyek. Dan berharap Anda akan dijebak dan pastikan untuk menanyakan bagaimana Anda melewatkannya

Jika artefak di atas untuk periode yang ditentukan tidak dapat dikumpulkan, dan hanya ada makalah yang membahas poin kelima seperti "lipstik" TK yang tidak jelas, analis tidak akan bekerja sama satu sama lain, para ahli di bidang subjek tidak diharapkan di sisi klien, masalah-masalah diam dan suasana window dressing berkuasa dan "Hanya kabar baik" - kemasi barang-barang Anda: kemungkinan besar mereka tidak akan membiarkan Anda terbang, penjelajahan bulan ditunda untuk jangka waktu yang tidak terbatas dan Anda berada dalam pertunjukan teater tidak akan bubar. "

Untuk mencapai kesuksesan nyata, sangat, sangat penting untuk benar-benar mencintai sistem perangkat lunak, menyerah untuk mengumpulkan persyaratan dan desain sepenuhnya, berharap memulai roket lebih awal, minum bir dengan pelanggan, saling percaya dan terus mengulangi kata-kata Edsger Dijkstra : “kesederhanaan adalah kuncinya keandalan "!

Dengan Hadirnya semua dan dengan tulus berharap Anda beruntung dalam mengimplementasikan proyek perangkat lunak.