Cereri duplicate: combinare fără a pierde vocea originală
6 min de citit
Trei clienți cer aceeași capacitate în trei săptămâni diferite, formulată în trei moduri diferite, și un proces de triaj construit să prindă duplicatele își face treaba: le grupează, le numără ca o singură cerere cu trei voturi, iar backlog-ul rămâne curat. Asta e partea ușoară. Ce etichete merită folosite acoperă gruparea după capacitatea de bază înainte de a tria după formulare ca soluție mecanică pentru duplicate; ce nu acoperă e ce se întâmplă cu cuvintele în sine odată ce trei cereri devin o singură linie, iar acea pierdere e de obicei mai mare decât problema numărării duplicatelor pe care a rezolvat-o.
Ce se pierde de fapt când duplicatele sunt combinate?
Formularea specifică folosită de fiecare solicitantă, care e adesea mai informativă decât numărul de voturi în care se prăbușește. O clientă ar putea cere “un mod de a exporta rezultate filtrate”, alta “export CSV care respectă filtrele mele salvate”, și o a treia “export care nu include coloane ascunse”. Toate trei sunt aceeași cerere de bază, grupată corect, dar fiecare formulare poartă un accent ușor diferit pe ce contează pentru acea persoană, iar o combinare care păstrează doar formularea primei trimiteri le aruncă complet pe celelalte două. Numărătoarea supraviețuiește; textura care ar ajuta pe cineva să construiască versiunea corectă a funcționalității, nu.
De ce contează textura dacă numărul de voturi spune deja că cererea există?
Pentru că cererea și designul sunt întrebări diferite, și doar formularea specifică răspunde la a doua. Zece voturi pe “export” spune unei echipe că merită construită funcționalitatea; nu spune nimic despre dacă “export” înseamnă CSV, PDF, un email programat sau un endpoint API, iar o combinare care aruncă nouă din zece trimiteri originale în favoarea formulării primei poate îngusta în tăcere specificația la orice a cerut întâmplător prima solicitantă, chiar dacă celelalte nouă voiau ceva subtil diferit. Ce ar trebui să înregistreze de fapt o cerere de funcționalitate acoperă exact acest gol de pe partea de primire; combinarea duplicatelor e locul unde reapare după primire, exact în punctul în care o echipă are cel mai mult nevoie de gama a ceea ce s-a cerut cu adevărat.
Cum arată un proces de combinare care păstrează formularea în loc s-o arunce?
Adăugare în loc de înlocuire. Elementul canonic păstrează un singur titlu pentru vizualizarea backlog-ului, dar formularea originală a fiecărei trimiteri combinate rămâne atașată de el, fie ca o listă de citate, fie ca tichete sursă legate, astfel încât oricine revizuiește elementul mai târziu poate vedea gama reală a ceea ce au cerut oamenii în loc de rezumatul unui membru al echipei. Costă aproape nimic de construit, un câmp pe tichet în loc de un sistem nou, și e diferența între o combinare care comprimă informația și una care comprimă doar afișarea ei.
Funcționalitate: Export CSV filtrat
Voturi: 12
Cereri combinate:
- "un mod de a exporta rezultate filtrate" (acct_4421)
- "export CSV care respectă filtrele mele salvate" (acct_8832)
- "export care nu include coloane ascunse" (acct_1097)
...Merită fiecare duplicat să fie combinat, sau există potriviri false?
Unele sunt potriviri false, iar tratarea “sună similar” ca “e aceeași cerere” e propriul ei mod de eșec. “Lăsați-mă să-mi exportez datele” și “lăsați-mă să exportez doar vizualizarea filtrată” pot fi grupate printr-o potrivire de cuvânt cheie pe “export” în timp ce descriu de fapt două domenii diferite ale aceleiași capacități generale; combinarea lor fie umflă numărul de voturi pentru lucrul greșit, fie, mai rău, livrează versiunea mai îngustă pentru că a ajuns întâmplător prima. O trecere umană peste grupare, chiar și una rapidă, prinde asta înainte să se acumuleze; o potrivire automată de similaritate singură va combina excesiv după vocabular și insuficient după intenție.
Când ar trebui să ruleze de fapt verificarea duplicatelor, la primire sau mai târziu?
Amândouă, din motive diferite. Verificarea la primire prinde cazul evident, o cerere nouă care reformulează ceva deja deschis, înainte să devină propria ei linie netrackuită; o căutare de similaritate față de cererile deschise, la momentul trimiterii, rezolvă majoritatea acestor cazuri fără nicio persoană implicată. O a doua trecere, mai târziu, într-un ritm mai lent, prinde cazul pe care primirea îl ratează: două cereri care au folosit un limbaj suficient de diferit ca să scape de o potrivire pe cuvinte cheie sau embeddings la momentul respectiv, dar care se dovedesc, odată ce o echipă a văzut o duzină de variații, că descriu aceeași capacitate de bază. Sărirea peste a doua trecere lasă cvasi-duplicate împrăștiate sub titluri separate la nesfârșit, fiecare cu propriul număr mic de voturi care nu se adună niciodată la numărul care i-ar fi adus construirea.
Ar trebui solicitanta să știe că trimiterea ei a fost combinată într-un element existent?
Da, și asta e aceeași disciplină ca închiderea buclei de feedback a clientului aplicată cu un pas mai devreme decât de obicei: o solicitantă care a trimis ceva și nu mai aude niciodată nimic concluzionează că cererea ei nu a dus nicăieri, chiar dacă a fost combinată corect într-un element cu alte unsprezece voturi care în cele din urmă a fost lansat. O confirmare scurtă, “am combinat asta cu o cerere existentă pe care au făcut-o și alții”, costă un mesaj și previne o clientă să retrimită aceeași cerere la câteva luni pentru că nu are nicio vizibilitate asupra dacă a fost vreodată urmărită cu adevărat.
Combinarea schimbă cui i se acordă credit când funcționalitatea e lansată?
Ar trebui să-i includă pe toți, nu doar pe cine a trimis primul. Închiderea buclei de
feedback acoperă anunțarea solicitantelor când cererea lor e
lansată; pentru un element combinat asta înseamnă fiecare cont atașat combinării, nu doar cel a
cărui formulare a devenit titlul canonic, pentru că din perspectiva fiecărei solicitante ea a cerut
asta și a fost lansat, indiferent de formularea pe care un proces de triaj a ales-o întâmplător să
o păstreze. Cu Changeloop, asta înseamnă că pull request-ul numește fiecare issue legat
(Fixes #142, fixes #187); un issue pe care nu-l numește nu primește niciun comentariu.
FAQ
Câtă formulare merită păstrată per cerere combinată, un citat sau un link complet către tichet? Un citat scurt e de obicei suficient pentru cazul comun, din moment ce scopul lui e să lase o recenzentă să vadă gama de formulări dintr-o privire; păstrați și link-ul complet către tichet când originalul avea context suplimentar semnificativ, cum ar fi o captură de ecran sau o descriere detaliată a fluxului de lucru pe care un citat de o linie l-ar aplatiza.
Păstrarea formulării fiecărui duplicat face backlog-ul mai greu de scanat? Nu, dacă e restrâns implicit. Titlul canonic e ce vede o recenzentă care scanează rapid; formularea combinată e la un clic sau o expandare distanță, prezentă pentru cine face cercetare mai profundă dar fără să aglomereze vizualizarea pentru cineva care doar numără voturi.
Ce se întâmplă dacă două cereri par identice dar se dovedesc a vrea lucruri diferite odată construite? Separați-le din nou de îndată ce devine clar, și tratați combinarea originală ca o decizie rezonabilă luată cu informația disponibilă la acel moment, nu ca o greșeală de evitat repetarea. Un sistem de grupare care nu desparte niciodată nimic va ajunge în final să aibă câteva combinări greșite coapte permanent.
Există un prag de voturi de la care o cerere combinată ar trebui să primească o revizuire umană a formulării de bază? Nu un număr fix, dar orice cerere care se apropie de o decizie de construire merită asta indiferent de numărul de voturi, pentru că ăsta e punctul unde diferența dintre “export” și “export ca CSV cu filtre salvate” încetează să fie o nuanță și începe să fie specificația.
Afirmațiile tehnice din acest articol nu au fost verificate independent. Dacă ceva nu e corect, spune-ne și vom corecta.