Permintaan fitur duplikat: menggabung tanpa kehilangan suara
5 menit baca
Tiga pelanggan meminta kapabilitas yang sama dalam tiga minggu berbeda, diungkapkan dengan tiga cara berbeda, dan proses triase yang dibangun untuk menangkap duplikat melakukan tugasnya: ia mengelompokkan mereka, menghitungnya sebagai satu permintaan dengan tiga suara, dan backlog tetap bersih. Itu bagian mudahnya. Label mana yang layak dipakai membahas mengelompokkan berdasarkan kapabilitas mendasar sebelum triase berdasarkan kata-kata sebagai perbaikan mekanis untuk duplikat; yang tidak dibahas adalah apa yang terjadi pada kata-kata itu sendiri begitu tiga permintaan menjadi satu baris, dan kerugian itu biasanya lebih besar daripada masalah penghitungan duplikat yang diselesaikannya.
Apa yang sebenarnya hilang saat duplikat digabung?
Kata-kata spesifik yang digunakan setiap pemohon, yang sering lebih informatif daripada hitungan suara tempat ia menyusut. Satu pelanggan mungkin meminta “cara mengekspor hasil yang difilter”, yang lain “ekspor CSV yang menghormati filter tersimpan saya”, dan yang ketiga “ekspor yang tidak menyertakan kolom tersembunyi”. Ketiganya adalah permintaan mendasar yang sama, dikelompokkan dengan benar, tapi setiap kata-kata membawa penekanan sedikit berbeda tentang apa yang penting bagi orang itu, dan penggabungan yang hanya menyimpan kata-kata dari pengiriman pertama membuang sepenuhnya dua lainnya. Hitungan bertahan; tekstur yang akan membantu seseorang membangun versi fitur yang tepat, tidak.
Mengapa tekstur penting jika hitungan suara sudah mengatakan permintaan itu ada?
Karena permintaan dan desain adalah pertanyaan berbeda, dan hanya kata-kata spesifik yang menjawab yang kedua. Sepuluh suara pada “ekspor” memberi tahu tim bahwa fitur itu layak dibangun; tidak mengatakan apa pun tentang apakah “ekspor” berarti CSV, PDF, email terjadwal, atau endpoint API, dan penggabungan yang membuang sembilan dari sepuluh pengiriman asli demi kata-kata yang pertama bisa diam-diam mempersempit spesifikasi ke apa pun yang kebetulan diminta pemohon pertama itu, meskipun sembilan lainnya menginginkan sesuatu yang sedikit berbeda. Apa yang sebenarnya harus dicatat permintaan fitur membahas celah yang sama persis dari sisi asupan; menggabung duplikat adalah tempat itu muncul kembali setelah asupan, tepat pada titik di mana tim paling membutuhkan rentang dari apa yang sebenarnya diminta.
Seperti apa proses penggabungan yang menyimpan kata-kata alih-alih membuangnya?
Menambahkan alih-alih mengganti. Item kanonik menyimpan satu judul untuk tampilan backlog, tapi kata-kata asli dari setiap pengiriman yang digabung tetap melekat padanya, entah sebagai daftar kutipan atau sebagai tiket sumber yang ditautkan, sehingga siapa pun yang meninjau item itu kemudian bisa melihat rentang nyata dari apa yang diminta orang alih-alih ringkasan satu anggota tim. Ini hampir tidak berbiaya untuk dibangun, satu field pada tiket alih-alih sistem baru, dan ini perbedaan antara penggabungan yang memampatkan informasi dan yang hanya memampatkan tampilannya.
Fitur: Ekspor CSV yang difilter
Suara: 12
Permintaan yang digabung:
- "cara mengekspor hasil yang difilter" (acct_4421)
- "ekspor CSV yang menghormati filter tersimpan saya" (acct_8832)
- "ekspor yang tidak menyertakan kolom tersembunyi" (acct_1097)
...Apakah setiap duplikat layak digabung, atau ada kecocokan yang salah?
Beberapa adalah kecocokan yang salah, dan memperlakukan “terdengar mirip” sebagai “adalah permintaan yang sama” adalah mode kegagalannya sendiri. “Biarkan saya mengekspor data saya” dan “biarkan saya mengekspor hanya tampilan yang difilter” bisa dikelompokkan oleh kecocokan kata kunci pada “ekspor” padahal sebenarnya menggambarkan dua cakupan berbeda dari kapabilitas umum yang sama; menggabungnya entah menggembungkan hitungan suara untuk hal yang salah atau, lebih buruk, merilis versi yang lebih sempit karena kebetulan tiba lebih dulu. Tinjauan manusia atas pengelompokan, bahkan yang cepat, menangkap ini sebelum menumpuk; kecocokan kemiripan otomatis saja akan menggabung berlebihan berdasarkan kosakata dan menggabung kurang berdasarkan niat.
Kapan sebenarnya pengecekan duplikat harus berjalan, saat asupan atau belakangan?
Keduanya, untuk alasan berbeda. Pengecekan saat asupan menangkap kasus yang jelas, permintaan baru yang menyatakan ulang sesuatu yang sudah terbuka, sebelum itu sempat menjadi baris item terlacak tersendiri; pencarian kemiripan terhadap permintaan terbuka saat pengiriman menangani kebanyakan kasus ini tanpa melibatkan manusia. Tinjauan kedua belakangan, pada kadensi yang lebih lambat, menangkap kasus yang terlewat asupan: dua permintaan yang memakai bahasa cukup berbeda untuk lolos dari kecocokan kata kunci atau embedding saat itu, tapi ternyata, begitu tim sudah melihat selusin variasi, menggambarkan kapabilitas mendasar yang sama. Melewatkan tinjauan kedua membiarkan hampir-duplikat tersebar di bawah judul terpisah tanpa batas waktu, masing-masing dengan hitungan suara kecilnya sendiri yang tidak pernah bertambah ke angka yang seharusnya membuatnya dibangun.
Haruskah pemohon tahu pengirimannya digabung ke item yang sudah ada?
Ya, dan ini disiplin yang sama dengan menutup lingkaran umpan balik pelanggan diterapkan satu langkah lebih awal dari biasanya: pemohon yang mengirim sesuatu dan tidak pernah mendengar kabar lagi menyimpulkan permintaannya tidak ke mana-mana, meskipun digabung dengan benar ke item dengan sebelas suara lain yang akhirnya dirilis. Konfirmasi singkat, “kami telah menggabungkan ini dengan permintaan yang sudah ada yang juga dibuat orang lain”, berbiaya satu pesan dan mencegah pelanggan mengirim ulang permintaan yang sama setiap beberapa bulan karena tidak punya visibilitas apakah itu pernah benar-benar dilacak.
Apakah menggabung mengubah siapa yang mendapat kredit saat fitur dirilis?
Seharusnya menyertakan semua orang, bukan hanya yang mengirim pertama. Menutup lingkaran umpan
balik membahas memberi tahu pemohon saat permintaan mereka
dirilis; untuk item yang digabung itu berarti setiap akun yang melekat pada penggabungan, bukan
hanya yang kata-katanya menjadi judul kanonik, karena dari sudut pandang setiap pemohon dia
meminta ini dan itu dirilis, tanpa peduli kata-kata siapa yang kebetulan disimpan proses triase. Dengan Changeloop itu
berarti pull request menyebut setiap issue yang tertaut (Fixes #142, fixes #187); issue yang tidak
disebutnya tidak mendapat komentar.
FAQ
Berapa banyak kata-kata yang layak disimpan per permintaan yang digabung, kutipan atau tautan tiket lengkap? Kutipan singkat biasanya cukup untuk kasus umum, karena tujuannya membiarkan peninjau melihat rentang kata-kata sekilas; simpan juga tautan tiket lengkap ketika yang asli punya konteks tambahan signifikan, seperti tangkapan layar atau deskripsi alur kerja rinci yang akan diratakan kutipan satu baris.
Apakah menyimpan kata-kata setiap duplikat membuat backlog lebih sulit dipindai? Tidak, jika dilipat secara default. Judul kanonik adalah yang dilihat peninjau yang memindai cepat; kata-kata yang digabung berjarak satu klik atau satu perluasan, hadir bagi yang melakukan riset lebih dalam tapi tanpa memenuhi tampilan bagi yang hanya menghitung suara.
Bagaimana jika dua permintaan terlihat identik tapi ternyata menginginkan hal berbeda setelah dibangun? Pisahkan lagi begitu itu menjadi jelas, dan perlakukan penggabungan asli sebagai keputusan masuk akal yang dibuat dengan informasi yang tersedia saat itu, bukan sebagai kesalahan yang harus dihindari diulangi. Sistem pengelompokan yang tidak pernah membatalkan penggabungan apa pun akhirnya akan punya beberapa penggabungan salah yang tertanam permanen.
Apakah ada ambang suara di mana permintaan yang digabung harus mendapat tinjauan manusia atas kata-kata mendasarnya? Bukan angka tetap, tapi permintaan apa pun yang mendekati keputusan pembangunan layak mendapatkan itu tanpa peduli hitungan suara, karena itu titik di mana perbedaan antara “ekspor” dan “ekspor sebagai CSV dengan filter tersimpan” berhenti menjadi nuansa dan mulai menjadi spesifikasi.
Klaim teknis dalam artikel ini belum ditinjau secara independen. Jika ada yang keliru, beri tahu kami dan kami akan memperbaikinya.