Yinelenen özellik talepleri: sesi kaybetmeden birleştirmek
5 dk okuma
Üç müşteri aynı yeteneği üç farklı haftada, üç farklı şekilde ifade ederek talep eder, ve yinelenenleri yakalamak için kurulmuş bir triyaj süreci işini yapar: onları gruplar, üç oylu tek bir talep olarak sayar, ve backlog temiz kalır. Kolay olan kısım budur. Hangi etiketler işe yarar, yinelenenler için mekanik çözüm olarak ifadeye göre triyaj etmeden önce temel yeteneğe göre gruplamayı ele alır; ele almadığı şey, üç talep tek bir satır kalemine dönüştüğünde kelimelerin kendisine ne olduğudur, ve bu kayıp genellikle çözdüğü yinelenen sayma sorunundan daha büyüktür.
Yinelenenler birleştirildiğinde gerçekte ne kaybedilir?
Her talep edenin kullandığı, sıkça çöktüğü oy sayısından daha bilgilendirici olan spesifik ifade. Bir müşteri “filtrelenmiş sonuçları dışa aktarmanın bir yolu” isteyebilir, bir diğeri “kaydedilmiş filtrelerime saygı gösteren CSV dışa aktarma”, ve üçüncüsü “gizli sütunları içermeyen dışa aktarma”. Üçü de aynı temel talep, doğru şekilde gruplanmış, ama her ifade o kişi için neyin önemli olduğuna dair hafifçe farklı bir vurgu taşır, ve sadece ilk gönderimin ifadesini koruyan bir birleştirme diğer ikisini tamamen atar. Sayım hayatta kalır; birinin özelliğin doğru versiyonunu inşa etmesine yardımcı olacak doku hayatta kalmaz.
Oy sayısı zaten talebin var olduğunu söylüyorsa doku neden önemli?
Çünkü talep ve tasarım farklı sorulardır, ve sadece spesifik ifade ikincisini cevaplar. “Dışa aktarma” üzerinde on oy, bir ekibe özelliği inşa etmeye değdiğini söyler; “dışa aktarma”nın CSV, PDF, planlanmış bir e-posta, yoksa bir API endpoint’i mi anlamına geldiği hakkında hiçbir şey söylemez, ve ilk gönderimin ifadesi lehine on orijinal gönderimden dokuzunu atan bir birleştirme, diğer dokuzu ince bir şekilde farklı bir şey istese bile spesifikasyonu sessizce ilk talep edenin tesadüfen istediği şeye daraltabilir. Bir özellik talebinin gerçekte neyi kaydetmesi gerektiği, bu aynı boşluğu alım tarafından ele alır; yinelenenleri birleştirmek, bunun alımdan sonra yeniden ortaya çıktığı yerdir, tam olarak bir ekibin gerçekte ne istendiğinin aralığına en çok ihtiyaç duyduğu noktada.
İfadeyi atmak yerine koruyan bir birleştirme süreci nasıl görünür?
Değiştirmek yerine eklemek. Kanonik öğe backlog görünümü için tek bir başlık korur, ama birleştirilen her gönderimin orijinal ifadesi ona bağlı kalır, alıntılar listesi olarak veya bağlantılı kaynak biletler olarak, böylece öğeyi daha sonra inceleyen herkes bir ekip üyesinin özetinin yerine insanların gerçekten istediği şeyin gerçek aralığını görebilir. Bunu inşa etmek neredeyse hiçbir şeye mal olmaz, yeni bir sistem yerine bilette bir alan, ve bu bilgiyi sıkıştıran bir birleştirme ile sadece görüntüsünü sıkıştıran bir birleştirme arasındaki farktır.
Özellik: Filtrelenmiş CSV dışa aktarma
Oylar: 12
Birleştirilen talepler:
- "filtrelenmiş sonuçları dışa aktarmanın bir yolu" (acct_4421)
- "kaydedilmiş filtrelerime saygı gösteren CSV dışa aktarma" (acct_8832)
- "gizli sütunları içermeyen dışa aktarma" (acct_1097)
...Her yinelenen birleştirilmeyi hak eder mi, yoksa yanlış eşleşmeler var mı?
Bazıları yanlış eşleşmelerdir, ve “benzer geliyor”u “aynı talep”miş gibi ele almak kendi başına bir başarısızlık modudur. “Verilerimi dışa aktarmama izin ver” ve “sadece filtrelenmiş görünümü dışa aktarmama izin ver”, aslında aynı genel yeteneğin iki farklı kapsamını tanımlarken “dışa aktarma” üzerinde bir anahtar kelime eşleşmesiyle gruplanabilir; onları birleştirmek ya yanlış şey için oy sayısını şişirir ya da, daha kötüsü, tesadüfen önce geldiği için daha dar versiyonu gönderir. Gruplama üzerinde bir insan geçişi, hızlı bile olsa, bu birikmeden önce bunu yakalar; otomatik bir benzerlik eşleştirmesi tek başına kelime dağarcığında aşırı birleştirir ve niyette yetersiz birleştirir.
Yinelenen kontrolü gerçekte ne zaman çalışmalı, alımda mı yoksa daha sonra mı?
İkisi de, farklı nedenlerle. Alımda kontrol etmek, açık olanı, zaten açık olan bir şeyi tekrar eden yeni bir talebi, kendi izlenmeyen satırına dönüşmeden önce yakalar; gönderim anında açık taleplere karşı bir benzerlik araması bunların çoğunu insan müdahalesi olmadan halleder. Daha yavaş bir ritimde yapılan sonraki bir geçiş, alımın kaçırdığı durumu yakalar: o sırada bir anahtar kelime veya embedding eşleşmesinden kaçacak kadar farklı bir dil kullanan, ama bir ekip düzinelerce varyasyon gördükten sonra aynı temel yeteneği tanımladığı ortaya çıkan iki talep. İkinci geçişi atlamak, yakın yinelenenleri süresiz olarak ayrı başlıklar altında dağınık bırakır, her biri kendi başına asla inşa edilecek sayıya ulaşmayan küçük bir oy sayısıyla.
Talep eden, gönderiminin mevcut bir öğeye birleştirildiğini bilmeli mi?
Evet, ve bu müşteri geri bildirim döngüsünü kapatmak ile aynı disiplindir, sadece alışılmıştan bir adım daha erken uygulanır: bir şey gönderip hiç haber almayan bir talep eden, sonunda gönderilen on bir başka oyla bir öğeye doğru şekilde birleştirilmiş olsa bile, talebinin hiçbir yere gitmediği sonucuna varır. Kısa bir onay, “bunu başkalarının da yaptığı mevcut bir talep ile birleştirdik”, bir mesaja mal olur ve bir müşterinin onu gerçekten takip edip etmediğine dair hiçbir görünürlüğü olmadığı için aynı talebi birkaç ayda bir yeniden göndermesini önler.
Birleştirme, özellik gönderildiğinde kime kredi verildiğini değiştirir mi?
İlk gönderen kişiye değil, herkese kredi vermelidir. Geri bildirim döngüsünü kapatmak,
talep edenlere talepleri gönderildiğinde bildirmeyi ele alır; birleştirilmiş bir öğe için bu,
ifadesi kanonik başlık haline gelen hesap değil, birleştirmeye bağlı her hesap anlamına gelir,
çünkü her talep edenin bakış açısından o bunu istedi ve gönderildi, bir triyaj sürecinin tesadüfen
hangi ifadeyi koruduğuna bakılmaksızın. Changeloop’ta bu, pull request’in bağlantılı her issue’yu
adlandırması demektir (Fixes #142, fixes #187); adlandırmadığı bir issue yorum almaz.
FAQ
Birleştirilen her talep için bir alıntı mı yoksa tam bir bilet bağlantısı mı, ne kadar ifade korunmaya değer? Kısa bir alıntı genellikle yaygın durum için yeterlidir, çünkü amacı bir incelemecinin ifade aralığını bir bakışta görmesini sağlamaktır; orijinalin bir ekran görüntüsü veya tek satırlık bir alıntının düzleştireceği ayrıntılı bir iş akışı açıklaması gibi önemli ek bağlamı olduğunda tam bilet bağlantısını da koruyun.
Her yinelenenin ifadesini korumak backlog’u taramayı zorlaştırır mı? Varsayılan olarak daraltılmışsa hayır. Kanonik başlık, tarayan bir incelemecinin gördüğü şeydir; birleştirilmiş ifade bir tık veya bir genişletme uzaklıktadır, daha derin araştırma yapan kişi için mevcuttur ama sadece oy sayan biri için görünümü karmaşıklaştırmaz.
İki talep aynı görünüyor ama inşa edildiğinde farklı şeyler istediği ortaya çıkarsa ne olur? Bu netleştiği anda onları tekrar ayırın, ve orijinal birleştirmeyi tekrarlamaktan kaçınılması gereken bir hata olarak değil, o zaman mevcut bilgiyle yapılmış makul bir karar olarak ele alın. Hiçbir şeyi asla ayırmayan bir gruplama sistemi, sonunda kalıcı olarak pişmiş birkaç yanlış birleştirmeye sahip olacaktır.
Birleştirilen bir talebin altında yatan ifadenin insan incelemesini alması gereken bir oy eşiği var mı? Sabit bir sayı yok, ama bir inşa kararına yaklaşan herhangi bir talep oy sayısından bağımsız olarak bunu hak eder, çünkü bu, “dışa aktarma” ile “kaydedilmiş filtrelerle CSV olarak dışa aktarma” arasındaki farkın bir nüans olmaktan çıkıp spesifikasyon olmaya başladığı noktadır.
Bu yazıdaki teknik iddialar bağımsız olarak kontrol edilmedi. Yanlış bir şey varsa bize söyle, düzeltelim.