중복된 기능 요청, 목소리를 잃지 않고 병합하기
4분 분량
세 명의 고객이 서로 다른 세 주에, 서로 다른 세 가지 표현으로 같은 기능을 요청한다. 중복을 잡기 위해 만들어진 분류 프로세스는 제 일을 한다: 그것들을 묶고, 세 표를 가진 하나의 요청으로 세고, 백로그는 깨끗하게 유지된다. 그것이 쉬운 부분이다. 어떤 라벨이 가치 있는가는 표현으로 분류하기 전에 근본 기능으로 묶는 것을 중복에 대한 기계적 해결책으로 다룬다. 다루지 않는 것은 세 요청이 한 줄이 되는 순간 말 자체에 무슨 일이 일어나는가이며, 그 손실은 보통 그것이 해결한 중복 계산 문제보다 크다.
중복이 병합될 때 실제로 무엇이 사라지는가
각 요청자가 사용한 구체적인 표현으로, 그것이 무너져 들어가는 표 수보다 정보가 많은 경우가 많다. 한 고객은 “필터링된 결과를 내보낼 방법”을 요청할 수 있고, 다른 고객은 “저장된 필터를 존중하는 CSV 내보내기”를, 세 번째 고객은 “숨겨진 열을 포함하지 않는 내보내기”를 요청할 수 있다. 셋 다 같은 근본 요청이고 올바르게 묶였지만, 각 표현은 그 사람에게 무엇이 중요한지에 대해 약간 다른 강조를 담고 있으며, 첫 제출의 표현만 유지하는 병합은 다른 두 개를 완전히 버린다. 개수는 살아남는다; 누군가 기능의 올바른 버전을 만드는 데 도움이 될 질감은 그렇지 않다.
표 수가 이미 수요가 존재한다고 말하는데 왜 질감이 중요한가
수요와 설계는 다른 질문이고, 오직 구체적인 표현만이 두 번째 질문에 답하기 때문이다. “내보내기”에 대한 열 표는 팀에게 그 기능을 만들 가치가 있다고 말한다; “내보내기”가 CSV를 의미하는지, PDF를 의미하는지, 예약된 이메일을 의미하는지, API 엔드포인트를 의미하는지에 대해서는 아무것도 말하지 않는다. 첫 제출의 표현을 위해 열 개 중 아홉 개의 원래 제출을 버리는 병합은, 나머지 아홉이 미묘하게 다른 것을 원했더라도 첫 요청자가 우연히 요청한 것으로 사양을 조용히 좁힐 수 있다. 기능 요청이 실제로 무엇을 기록해야 하는가는 정확히 이 격차를 접수 쪽에서 다룬다; 중복 병합은 그것이 접수 후에 다시 나타나는 지점이며, 팀이 실제로 요청된 것의 범위를 가장 필요로 하는 바로 그 지점이다.
표현을 버리는 대신 지키는 병합 과정은 어떤 모습인가
교체 대신 추가. 정본 항목은 백로그 뷰를 위해 하나의 제목을 유지하지만, 병합된 각 제출의 원래 표현은 인용 목록으로든 연결된 소스 티켓으로든 거기에 계속 붙어 있어서, 나중에 항목을 검토하는 누구든 팀원 한 명의 요약 대신 사람들이 실제로 요청한 것의 진짜 범위를 볼 수 있다. 이것은 만드는 데 거의 아무 비용도 들지 않는다, 새 시스템 대신 티켓의 필드 하나이며, 정보를 압축하는 병합과 그저 그것의 표시만 압축하는 병합의 차이다.
기능: 필터링된 CSV 내보내기
표: 12
병합된 요청:
- "필터링된 결과를 내보낼 방법" (acct_4421)
- "저장된 필터를 존중하는 CSV 내보내기" (acct_8832)
- "숨겨진 열을 포함하지 않는 내보내기" (acct_1097)
...모든 중복이 병합될 가치가 있는가, 아니면 잘못된 일치가 있는가
일부는 잘못된 일치이며, “비슷하게 들린다”를 “같은 요청이다”로 취급하는 것은 그 자체로 하나의 실패 모드다. “내 데이터를 내보내게 해달라”와 “필터링된 뷰만 내보내게 해달라”는 실제로는 같은 일반적 기능의 두 다른 범위를 설명하면서도 “내보내기”에 대한 키워드 일치로 묶일 수 있다; 그것들을 병합하면 잘못된 것에 대한 표 수를 부풀리거나, 더 나쁘게는, 우연히 먼저 도착했다는 이유로 더 좁은 버전을 내놓게 된다. 묶음에 대한 사람의 검토는, 빠른 검토라도, 그것이 쌓이기 전에 이것을 잡아낸다; 자동 유사성 일치만으로는 어휘 기준으로 과도하게 병합하고 의도 기준으로 부족하게 병합할 것이다.
중복 확인은 실제로 언제 실행해야 하는가, 접수 시점인가 나중인가
둘 다, 이유는 다르다. 접수 시점에 확인하면 뻔한 경우, 즉 이미 열려 있는 것을 그대로 되풀이하는 새 요청이 그 자체로 추적되지 않는 독립 항목이 되기 전에 잡아낸다. 제출 시점에 열린 요청들에 대해 유사성 검색을 돌리면 사람 없이도 이런 경우 대부분을 처리한다. 나중에 더 느린 주기로 돌리는 두 번째 확인은 접수 단계가 놓치는 경우를 잡아낸다. 당시에는 키워드나 임베딩 일치를 피해 갈 만큼 표현이 달랐던 두 요청이, 팀이 십여 개의 변형을 본 뒤에야 사실은 같은 기저 기능을 설명하고 있었다는 것이 드러나는 경우다. 두 번째 확인을 건너뛰면 거의 중복인 항목들이 서로 다른 제목 아래 무기한 흩어진 채로 남고, 각각의 표 수는 그것을 만들게 했을 숫자로 결코 합쳐지지 않는다.
요청자는 자신의 제출이 기존 항목에 병합되었다는 것을 알아야 하는가
그렇다, 그리고 이것은 고객 피드백 루프 닫기와 같은 규율을, 평소보다 한 단계 일찍 적용한 것이다: 무언가를 제출하고 두 번 다시 아무것도 듣지 못하는 요청자는, 그것이 결국 출시된 다른 열한 표를 가진 항목에 올바르게 병합되었더라도, 자신의 요청이 아무 데도 가지 못했다고 결론짓는다. “이것을 다른 사람들도 한 기존 요청과 결합했습니다”라는 짧은 확인은 메시지 하나의 비용이 들며, 고객이 그것이 실제로 추적된 적이 있는지 알 수 없어서 몇 달마다 같은 요청을 다시 제출하는 것을 막는다.
병합은 기능이 출시될 때 누구에게 공이 돌아가는지를 바꾸는가
먼저 제출한 사람뿐 아니라 모두를 포함해야 한다. 피드백 루프 닫기는 요청이 출시될 때 요청자에게 알리는 것을 다룬다; 병합된 항목의 경우 그것은 정본 제목이 된 표현을 가진 계정뿐 아니라 병합에 붙은 모든 계정을 의미한다, 각 요청자의 관점에서는 그녀가 이것을 요청했고 그것이 출시되었기 때문이며, 분류 프로세스가 우연히 어느 표현을 유지했는지와는 무관하다. Changeloop에서는 pull request가 연결된 모든 이슈를 지정한다는 뜻이다(Fixes #142, fixes #187). 지정되지 않은 이슈에는 코멘트가 달리지 않는다.
FAQ
병합된 요청당 얼마나 많은 표현을 지킬 가치가 있는가, 인용인가 완전한 티켓 링크인가? 짧은 인용이 보통 흔한 경우에는 충분하다, 그 목적이 검토자가 표현의 범위를 한눈에 볼 수 있게 하는 것이기 때문이다; 원본에 스크린샷이나 한 줄 인용이 평평하게 만들어버릴 상세한 워크플로 설명 같은 상당한 추가 맥락이 있었다면 완전한 티켓 링크도 지켜라.
각 중복의 표현을 지키는 것이 백로그를 스캔하기 더 어렵게 만드는가? 기본적으로 접혀 있다면 아니다. 정본 제목은 빠르게 훑어보는 검토자가 보는 것이다; 병합된 표현은 클릭 한 번이나 펼침 한 번 떨어져 있어서, 더 깊은 조사를 하는 사람에게는 존재하지만 그저 표를 세는 사람의 뷰를 어지럽히지는 않는다.
두 요청이 동일해 보이지만 만들고 보니 다른 것을 원했던 것으로 밝혀지면 어떻게 하는가? 그것이 명확해지는 순간 다시 분리하고, 원래 병합을 반복을 피해야 할 실수로서가 아니라 당시 가용했던 정보로 내려진 합리적인 결정으로 취급하라. 아무것도 다시 나누지 않는 묶음 시스템은 결국 몇 개의 잘못된 병합을 영구히 굳혀버리게 될 것이다.
병합된 요청이 근본 표현에 대한 사람의 검토를 받아야 하는 표 임계값이 있는가? 고정된 숫자는 없지만, 제작 결정에 다가가는 어떤 요청이든 표 수와 무관하게 그것을 받을 자격이 있다, 그것이 “내보내기”와 “저장된 필터가 있는 CSV로서의 내보내기” 사이의 차이가 뉘앙스이기를 멈추고 사양이 되기 시작하는 지점이기 때문이다.
이 글의 기술적 내용은 독립적으로 검토되지 않았습니다. 잘못된 부분이 있으면 알려 주세요. 바로잡겠습니다.