Keuntungan:
- Keupayaan untuk mengubah permintaan perniagaan yang tidak jelas kepada keperluan perisian yang jelas dan boleh diuji dan cerita pengguna dengan sokongan AI
- Keupayaan untuk membandingkan kebaikan dan keburukan reka bentuk sistem, model data dan keputusan seni bina secara berstruktur dengan AI
- Keupayaan untuk mengesahkan secara kritis reka bentuk yang dicadangkan AI terhadap keperluan, kebolehskalaan dan kekangan
Majoriti projek perisian gagal bukan kerana kod buruk, tetapi kerana keperluan yang salah faham. Permintaan satu ayat seperti "Biarkan pengguna memuat turun laporan" meninggalkan berpuluh-puluh soalan yang tidak dijawab: Dalam format apa? Siapa yang bertanggungjawab? Berapa banyak rekod? Bagaimana jika ia lambat? Analisis keperluan (menerjemahkan permintaan perniagaan kepada keperluan teknikal yang jelas dan boleh diuji) dan reka bentuk perisian (membina struktur di atas kertas untuk memenuhi keperluan ini) ialah peringkat di mana kesilapan yang paling mahal dihalang sebelum menulis kod. Dalam unit ini, kita akan belajar menggunakan AI sebagai "rakan kongsi pemikiran" pada peringkat ini: rakan kongsi yang merungkai ketidakpastian, menyelesaikan pilihan, tetapi menyerahkan keputusan muktamad kepada anda.
AI menghasilkan dua nilai besar di sini. Pertama, ia bertanya soalan yang anda langkau; Ia membawa ke permukaan andaian tersembunyi dan kes kelebihan dalam permintaan. Kedua, ia dengan cepat menjadualkan kebaikan dan keburukan keputusan reka bentuk. Tetapi itulah bahayanya: AI akan memberikan cadangan generik sebagai "amalan terbaik" tanpa mengetahui konteks anda sepenuhnya (belanjawan, pasukan, sistem sedia ada, kekangan undang-undang). Tugas anda untuk menapis nasihat ini terhadap kebenaran anda sendiri.
Konsep: Cerita pengguna: Ayat pendek yang menyatakan keperluan dalam bentuk "... sebagai, saya mahu dapat... kerana...". Kriteria penerimaan: Syarat boleh diuji yang mesti dipenuhi untuk sesuatu kerja dianggap "selesai". Keperluan tidak berfungsi: Keperluan yang berkaitan dengan "bagaimana ia akan berkelakuan" dan bukannya "apa yang akan dilakukannya", seperti kelajuan, keselamatan, kebolehskalaan.
Daripada Permintaan Samar-samar kepada Keperluan Boleh Diuji
Keperluan yang baik boleh diukur dan boleh disahkan. Bukan "biar sistem menjadi pantas", tetapi "biarkan hasil carian kembali dalam masa 500 ms". Berikut ialah cara langkah demi langkah untuk menggunakan AI untuk mengecilkan ketidakpastian:
- Berikan permintaan sebagaimana adanya dan minta soalan dijana. Tanya AI bukan untuk penyelesaiannya, tetapi mula-mula "senarai apa-apa yang tidak jelas dalam permintaan ini sebagai soalan."
- Anda memberi jawapan. Hanya anda yang tahu konteksnya; Jawab soalan AI dengan kekangan perniagaan sebenar anda.
- Minta ia diterjemahkan ke dalam cerita pengguna dan kriteria penerimaan. Terjemahkan keperluan yang dijelaskan kepada item yang boleh diuji.
- Tambah kes tepi dan senario negatif. "Hasil kosong", "pengguna yang tidak dibenarkan", "fail terlalu besar" dsb.
Gesaan pengekstrakan kesamaran: "Kami akan menterjemah permintaan perniagaan berikut kepada keperluan perisian. Jangan cadangkan penyelesaian lagi. Pertama, keluarkan SEMUA kesamaran dan andaian tersembunyi yang tidak dijawab dalam permintaan ini sebagai senarai soalan. Kumpulan soalan di bawah tajuk berikut: skop, pengguna/pihak berkuasa, volum data, prestasi, keadaan ralat, keselamatan. Permintaan: 'Biar pengguna memuat turun sejarah pesanan'"
Cerita pengguna + gesaan kriteria penerimaan: "Bahagikan keperluan yang dijelaskan berikut kepada cerita pengguna yang mematuhi prinsip INVEST. Tulis 3-5 kriteria penerimaan yang boleh diuji untuk setiap cerita (dalam format Diberi-Apabila-Kemudian). Tambahkan sekurang-kurangnya 2 senario negatif (akses tanpa kebenaran, data kosong). Perlu: [tulis keperluan yang dijelaskan di sini]"
Membandingkan Keputusan Reka Bentuk dengan AI
Reka bentuk adalah pertukaran berterusan: kelajuan berbanding fleksibiliti, kesederhanaan berbanding skalabiliti? AI meletakkan pertukaran ini ke dalam hamparan pantas. Contohnya, untuk ciri "hantar pemberitahuan", anda boleh berdebat sama ada hendak menggunakan pendekatan segerak (hantar atas permintaan) atau tak segerak (baris gilir, hantar di latar belakang).
Gesaan perbandingan reka bentuk: "Saya sedang mereka bentuk ciri 'hantar pemberitahuan e-mel kepada pengguna'. Bandingkan dua pendekatan: (A) penghantaran segerak semasa permintaan HTTP, (B) penghantaran tak segerak di latar belakang dengan meletakkannya dalam baris gilir mesej. Buat jadual pada paksi berikut: masa menunggu pengguna, toleransi kesalahan, kerumitan, kos infrastruktur, yang mana saya akan memilih untuk menyahpepijat akhir. Jangan buat keputusan untuk saya."
paksi
penghantaran segerak
Asynchronous (baris gilir)
Masa menunggu pengguna
Lama (menunggu penghantaran)
Pendek (kembali segera)
Toleransi kesalahan
Rendah (permintaan meletup jika hantaran meletup)
Tinggi (cuba semula mungkin)
kerumitan
rendah
Sederhana tinggi (infrastruktur baris gilir)
Kos infrastruktur
rendah
Komponen tambahan diperlukan
Di mana ia sesuai
Kelantangan rendah, aplikasi mudah
Kelantangan tinggi, penghantaran kritikal
Petua: Memberitahu AI "jangan buat keputusan untuk saya, tunjukkan saya pilihan dan syarat" memaksa anda berfikir dan mengurangkan risiko menerima cadangan secara membuta tuli. Keputusan reka bentuk terbaik ialah keputusan yang dibuat oleh orang yang mengetahui konteks anda (anda).
Gesaan Lemah / Gesaan Kuat
LEMAH: "Reka bentuk pangkalan data untuk sistem pesanan." (Hasil: skala mana, perhubungan mana, kekangan mana yang tidak jelas; skema umum, tidak realistik.) KUAT: "Cadangkan model data draf untuk e-dagang kecil. Entiti: Pelanggan, Pesanan, Produk, Item Pesanan. Kekangan: terdapat banyak produk dalam pesanan; harga produk mungkin berubah dari semasa ke semasa, tetapi harga semasa perlu dikekalkan; ~500 adalah harga yang dijangkakan dalam pesanan yang lalu. "Jelaskan bahawa anda membuat keputusan. Nyatakan cara anda menyelesaikan masalah sejarah harga. Berikannya sebagai senarai entiti dan medan, bukan kod."
Perbezaan gesaan yang kuat; skala (500 pesanan sehari), peraturan perniagaan (harga lepas mesti dikekalkan) dan format output yang diingini. Satu ayat seperti "Harga lalu mesti dikekalkan" mengubah reka bentuk sepenuhnya; Jika anda tidak menyatakan ini, AI akan menghasilkan gambar rajah yang tidak tepat tetapi kelihatan munasabah.
Kes Mini
Kes 1 — Andaian tersembunyi. Pasukan mengekod secara langsung permintaan "pengguna boleh memuat naik foto profil". Pasukan lain bertanya kepada AI tentang ketidakpastian: "saiz maksimum? format yang dibenarkan? kawalan kandungan yang tidak sesuai? padam foto lama?" Ia menghasilkan 8 soalan seperti. Pasukan pertama mengetahui masalah dalam pengeluaran apabila fail 20 MB mengisi pelayan; Pasukan kedua menyelesaikannya dalam reka bentuk.
Kes 2 — Andaian skala yang salah. AI mencadangkan lapisan caching yang kompleks untuk ciri pelaporan. Apabila jurutera menunjukkan bahawa data sebenar hanya 30 laporan setiap hari, AI memudahkan cadangan itu. Tidak menyatakan skala menimbulkan kos kerumitan yang tidak perlu; menyatakan menjimatkan 2 minggu kerja yang tidak perlu.
Kes 3 — Jurang kriteria penerimaan. "Apa yang berlaku jika pembayaran gagal?" Memandangkan soalan itu tidak pernah ditanya, sistem pesanan masih akan menandakan pesanan sebagai "disahkan" sekiranya pembayaran tidak berjaya. Senarai senario negatif yang dijana oleh AI menangkap jurang ini; Kriteria penerimaan 1 baris menghalang kerugian wang sebenar.
Kesilapan biasa
- Menghantar permintaan terus kepada kod. Kod yang ditulis sebelum kekaburan diselesaikan dengan cepat menyelesaikan masalah yang salah.
- Mengambil "amalan terbaik" umum AI secara membuta tuli. Jika anda tidak menyatakan konteks anda (skala, belanjawan, pasukan) pengesyoran itu tidak akan berfungsi untuk anda.
- Melangkau keperluan tidak berfungsi. Jika kelajuan, keselamatan dan skala tidak dinyatakan, reka bentuk akan menjadi tidak lengkap.
- Hanya memikirkan senario gembira. Senario negatif seperti data kosong, pengguna yang tidak dibenarkan, status ralat harus disertakan dalam reka bentuk.
- Mewakilkan keputusan kepada AI. AI menjana pilihan; Anda tentukan trade-off yang sesuai dengan perniagaan anda.
Secara ringkasnya
Analisis dan reka bentuk keperluan adalah peringkat di mana ralat termurah ditangkap. Di sini, AI menjana soalan yang mendedahkan ketidakpastian, mendraf cerita pengguna dan kriteria penerimaan, dan reka bentuk carta tukar ganti. Tetapi hanya anda yang tahu konteksnya; Tugas anda untuk menapis syor AI berdasarkan skala, belanjawan, pasukan dan kekangan undang-undang anda dan membuat keputusan muktamad. Disiplin "jangan buat keputusan untuk saya, tunjukkan saya pilihan" membawa kepada reka bentuk yang lebih baik dan pembelajaran yang lebih mendalam.
Tugasan permohonan
Pilih permintaan kerja satu ayat daripada konteks anda. Pertama, gunakan gesaan kekaburan pada AI dan jawab soalan dengan kekangan sebenar anda. Kemudian terjemahkan keperluan yang dijelaskan kepada sekurang-kurangnya 2 cerita pengguna dan 3 kriteria penerimaan untuk setiap satu; Sertakan sekurang-kurangnya 1 senario negatif. Akhir sekali, buat jadual perbandingan untuk keputusan reka bentuk (segerak/tak segerak, struktur jadual, dll.) dan tulis keputusan anda sendiri dalam 2 ayat.
senarai semak
- [ ] Saya mengalih keluar kekaburan sebagai soalan sebelum menghantar permintaan ke dalam kod.
- [ ] Saya memberikan konteks (skala, kuasa, prestasi, kekangan undang-undang) kepada AI.
- [ ] Saya memecahkan cerita pengguna kepada kriteria penerimaan yang boleh diuji.
- [ ] Saya menambah sekurang-kurangnya satu senario kelemahan/tepi.
- [ ] Saya menilai keputusan reka bentuk dengan jadual tukar ganti.
- [ ] Saya membuat keputusan muktamad berdasarkan konteks saya, saya tidak menyerahkannya kepada AI.