Tulis ringkasan tugas untuk agen

Jelaskan perubahan yang dapat dinilai peninjau

“Tambahkan ekspor pelanggan” menyisakan beberapa keputusan. Siapa yang dapat mengekspor data? Data dan field mana yang disertakan? Apa yang terjadi ketika permintaan gagal? Agen dapat mengisi kekosongan ini dengan pilihan yang masuk akal. Pilihan tersebut tetap dapat keliru bagi bisnis.

Mulai dari pengguna dan masalahnya. Lalu jelaskan perilaku yang diperlukan. Sertakan bukti yang akan menunjukkan apakah hasil dapat diterima.

Ringkasan tugas seharusnya mengurangi ketidakpastian tanpa menetapkan setiap pilihan desain internal. Tentukan batas data yang diperlukan. Biarkan implementasi menggunakan pola repositori yang sudah ada kecuali terdapat alasan untuk mengubahnya.

Gunakan contoh konkret

Ringkasan berikut digunakan untuk aplikasi dukungan fiktif. Ini contoh pembelajaran, bukan spesifikasi produksi lengkap.

Hasil: Manajer dukungan dapat mengunduh daftar pelanggan.
Pelaku: Manajer dalam organisasi saat ini.
Data: Hanya pelanggan aktif dalam organisasi tersebut.
Field: ID pelanggan, nama perusahaan, dan status akun.
Format: CSV UTF-8 dengan baris header.
Permintaan ditolak: Kembalikan error otorisasi yang sudah ada.
Hasil kosong: Kembalikan CSV valid yang hanya berisi header.
Cakupan: Gunakan route ekspor dan pola audit yang sudah ada.
Pengecualian: Tidak ada peran baru, dependensi baru, atau deployment.
Bukti: Pengujian permintaan yang diizinkan, ditolak, kosong, dan lintas organisasi.

Ringkasan ini mengidentifikasi perilaku dan batas yang berguna. Ringkasan juga memperlihatkan pertanyaan lanjutan. Perlukah sistem membatasi ukuran ekspor? Dapatkah field memuat formula spreadsheet? Siapa yang dapat mengakses catatan audit? Selesaikan pertanyaan berdampak penting sebelum implementasi. Jangan perlakukan contoh sebagai daftar pemeriksaan universal.

Pisahkan persyaratan dari asumsi

Persyaratan menyatakan perilaku yang harus dipenuhi perubahan. Asumsi merupakan fakta yang belum diverifikasi. Pisahkan keduanya.

Misalnya, “Gunakan pola audit yang sudah ada” mengasumsikan adanya pola yang sesuai. Minta agen menemukannya. Jika repositori tidak memilikinya, agen harus melaporkan dependensi yang belum tersedia sebelum menciptakan sistem audit baru.

Batasan juga dapat bertentangan dengan hasil. Route yang sudah ada mungkin memang dirancang untuk mengembalikan data setiap organisasi. Agen harus menunjukkan pertentangan dan mengusulkan perbaikan terbatas. Agen tidak boleh diam-diam menghapus batas data atau memperluas tugas menjadi penulisan ulang arsitektur.

Sertakan bukti dalam syarat penyelesaian

Minta ringkasan hasil yang menjelaskan perilaku akhir, perubahan cakupan, dan pemeriksaan yang dilakukan. Wajibkan perintah dan hasil yang tepat ketika diperlukan. Bedakan pemeriksaan yang lulus dari pemeriksaan yang tidak dapat dijalankan.

Pull request harus mempertahankan alasan perubahan. Pemelihara berikutnya mungkin melihat kode tanpa percakapan awal. Sertakan konteks yang cukup untuk menjelaskan alasan ekspor mengecualikan field tertentu dan cara akses ditegakkan.

Panduan deskripsi perubahan Google merupakan referensi yang berguna untuk catatan ini. Deskripsi harus menjelaskan perubahan dan tujuannya. Jaga catatan tetap sesuai dengan implementasi akhir setelah perubahan hasil peninjauan.

Sesuaikan detail ringkasan dengan tugas

Perbaikan teks kecil dapat menggunakan ringkasan singkat. Ekspor data memerlukan detail lebih banyak karena kegagalannya dapat mengungkap informasi. Alur pembayaran baru memerlukan lebih banyak analisis dan peninjauan.

Jangan mengukur kualitas ringkasan dari panjangnya. Tanyakan apakah peninjau yang kompeten dapat membedakan hasil benar dari hasil keliru. Jika dua implementasi yang masuk akal akan berbeda dalam perilaku berdampak penting, perjelas perilaku tersebut terlebih dahulu.