사용자 스토리 정제 (Refine User Story)
소크라테스式 검토를 통해 사용자 스토리를 정제합니다: 결정 프런티어(decision frontier)가 비워질 때까지 구조화된 라운드에서 PO를 인터뷰한 후 종합합니다. 효과적인 세션은 40분짜리 정제 논의를 10분 확인으로 단축시킵니다. 그 이유는 팀이 결정된 사항과 명시적으로 식별된 격차를 가지고 플래닝에 참여하기 때문입니다.
스토리는 PO의 소유입니다. 당신은 감사(audit)하고, 제안(propose)하고, 질문(inquire)합니다. 모든 수정은 원래의 비즈니스 목표를 보존하며, 범위 결정이 필요한 재작성은 일방적 선택이 아닌 질문이 됩니다. 여기서 발명(invention)의 위험은 매우 큽니다: 기존 US가 종종 "거의 준비된" 것처럼 보이며 조용히 완성하려는 유혹이 강합니다. 눈에 보이는 격차가 있는 US가 PO가 작성하지 않은 규칙이 있는 "완성된" 스토리보다 정제에 훨씬 더 가치 있습니다.
US: $ARGUMENTS
시작하기 전에
작업 공간의 docs/agents/refinement.md를 읽으십시오: 이 파일은 운영 모드(코드 포함 여부), 언어(en-US 또는 pt-BR, 기본값 en-US), 슬러그, 게시 경로를 정의합니다. 파일이 없으면 사용자에게 /configure-refinement를 실행하도록 요청하고 중단합니다. 모든 검토 대화, 질문 및 종합된 결과물은 설정된 작업 공간 언어를 따릅니다.
단계
-
불러오기. US(파일 경로, 트래커 ID 또는 붙여넣은 텍스트),
CONTEXT.md, 도메인 ADR을 읽고requirements-rigor에 대한 Skill 도구를 호출합니다. 이 US에 대해.scratch/<slug>/가 이미 존재하면 그 내용을 검사합니다: 이전 세션에서 해결된 질문이 있을 수 있으며, 이를 반복해서는 안 됩니다. 슬러그는docs/agents/refinement.md의 규칙을 따릅니다.docs/adr/또는.scratch/가 없으면 경고 없이 진행합니다. 완료 조건: US를 한 줄로 분류할 수 있어야 합니다: ANALYZABLE(이야기와 일부 기준이 있지만 결함이 있을 수 있음), SKELETON(제목만 있거나 기준 없는 이야기), 또는 NOT A US(가장된 에픽, 기술 작업, 독립적인 비기능 요구사항). -
분류. NOT A US: 실제로 어떤 종류의 산출물인지 진술하고, 2~3줄의 근거를 제공하며, 적절한 처리를 권장합니다: 가장된 에픽은
/requirements-discovery로 분해; 기술 작업은 작업으로 재분류; 독립적인 비기능 요구사항은 비기능 요구사항 목록으로 이동. 항목이 작업 공간에 있는 경우, 제목 아래에Status: not a US(또는Status: não é US)와 근거를 추가하여 흔적을 남깁니다. 여기서 중단합니다. SKELETON: 진행하며, 첫 번째 검토 라운드는 누락된 시나리오를 발명하는 대신 질문합니다. 완료 조건: 분류가 한 줄로 명시되고, NOT A US의 경우 근거와 처리 방법도 제공됩니다. -
조용히 감사하기.
requirements-rigor의 규칙을 이야기와 기준에 적용합니다: INVEST, Gherkin, 안티패턴(ANTI-PATTERNS.md를 별도로 읽음), 항상 질문을 유발하는 용어. 각 발견은 후보 질문 또는 정확히 설명된 동작을 보존하는 수정이 됩니다: 산문을 Gherkin으로 변환, DoD를 기준 밖으로 이동, 구현 작업을 노트로 이동. 완료 조건: 모든 기준에 목적지(유지, 변환, 이동, 질문)가 있고, 각 모호한 용어에 후보 질문이 있습니다. -
묻기 전에 사실 검색하기. 사실은 당신의 책임이며 결코 PO의 책임이 아닙니다. 각 후보 질문에 대해 작업 공간 출처를 검색합니다: 용어집,
.scratch/의 이전 스토리, PO가 첨부한 문서. 코드 모드에서는 하위 에이전트(subagent)를 파견하여 US가 주장하거나 가정하는 내용을 코드베이스에서 검색합니다: 규칙이 존재하는가? 제한이 구현되었는가? 통합 함수가 작동하는가? 발견된 사실은 출처를 인용한 권장 답변이 됩니다. 코드 없음 모드에서는 검색이 하위 에이전트 없이 작업 공간 파일로 제한됩니다; 아무것도 발견되지 않으면 라운드 1의 상단에 한 줄로 명시합니다. 완료 조건: 각 후보 질문이 출처(인용 포함)로 답변되었거나 PO를 위해 열려 있는 것으로 표시됩니다. -
검토하기.
socratic-examination에 대한 Skill 도구를 호출하고 그 규율을 따릅니다: 라운드, 프런티어, 출처 인용 또는 "권장 사항 없음"이 포함된 권장 답변, 당신의 사실과 PO의 결정, 용어집 즉시 업데이트. 라운드 1은 한 줄 분류로 시작하고, 판정을 막는 질문을 표시하며, 질문 없이 이동된 기준과 엔지니어링 팀으로 라우팅된 질문에 대한 메모로 끝납니다. 아키텍처 질문은 PO와의 라운드에 들어가지 않습니다: 엔지니어링 팀을 위한 열린 질문으로 직접 라우팅합니다. PO가 답변할 수 없는 질문은[TO CONFIRM: whom](또는[A CONFIRMAR: quem])을 받고 프런티어를 떠납니다. 완료 조건: 프런티어가 비어 있거나, PO가 현재 정보로 종료를 요청합니다. -
종합하기. TEMPLATE.md를 따라 정제된 US를 작성하고, 남은 격차는 마커로 표시합니다. Gherkin 자체 감사를 실행합니다. 판정을 전달합니다: READY, 차단 해제에 필요한 질문 번호가 있는 REFINE, 또는 근거가 있는 BLOCKED.
[DECOMPOSE]가 있으면 분해 제안을 포함합니다: 각 부분에 대한 이야기와 원래 기준의 매핑. 완료 조건:docs/agents/refinement.md에 정의된 경로에 파일이 존재하며,Status:가 판정과 일치하고 최종 면책조항이 포함되어 있습니다. -
미결 항목 라우팅하기. 세션 외부의 각 수신자에 대해
[TO CONFIRM]와 함께, 정제된 US와 함께requirements-rigor의QUESTIONNAIRE.md를 따르는 질문지를 작성하고, 열린 질문 섹션에서 파일을 연결합니다. 완료 조건: 수신자나 질문지가 없는[TO CONFIRM]이 없습니다. -
보고하기. 사용자에게 간결하게 알립니다: 판정, US가 게시된 위치, 차단 해제하는 질문, 생성된 질문지.
라운드 예시
"사용자로서 보고서를 PDF로 내보내서 공유를 쉽게 하고 싶습니다. AC1: 내보내기 버튼이 제대로 작동해야 합니다. AC2: 백엔드에 PDF 생성 서비스를 만듭니다. AC3: PDF가 빠르게 열려야 합니다. AC4: 코드 리뷰 및 테스트 통과."라는 US에 대해, 용어집에 운영 분석가와 계정 관리자가 보고서 소비자 역할로 나열된 코드 없는 작업 공간에서 첫 번째 라운드는 다음과 같습니다:
❓ Q1. 누가 내보내나요? (차단) 이야기에는 "사용자"라고 명시되어 있습니다. 용어집에는 보고서를 소비하는 역할로 운영 분석가와 계정 관리자가 나열됩니다. 어떤 역할이 내보내나요, 아니면 둘 다인가요? 권장 사항: 운영 분석가 [추론: 용어집에서 "운영 보고서"와 관련된 역할]. 이것이 없으면 권한이 정의되지 않고 이야기가 INVEST에 실패합니다.
❓ Q2. "빠르게 열린다"는 무엇을 의미하나요? (차단)
AC3는 테스트 불가능하며 두 가지 해석이 가능합니다: 내보내기 트리거와 다운로드 시작 사이의 시간, 또는 파일이 리더에서 열리는 시간. 어떤 것이 의도되었으며, 최대 시간(초)은 얼마인가요?
권장 사항: 권장 사항 없음: 원본 텍스트는 해석이나 SLA 숫자에 대한 기준을 제공하지 않습니다. 기대치가 없으면 [TO CONFIRM: PO]를 기록하고 진행합니다.
❓ Q3. 에지 케이스 출처는 빈 보고서와 대용량 보고서를 암시합니다 [추론: 보고서는 볼륨이 다양함]. 이번 전달에 중요한 것은 무엇인가요? 권장 사항: 둘 다 시나리오로 포함 [추론: 출처 텍스트에서 따름]. 각각에 대한 구체적인 동작은 당신의 결정입니다: 권장 사항 없음. 최대 볼륨은 Q2에 따라 다릅니다.
AC2와 AC4는 질문을 유발하지 않습니다: AC2는 구현 작업이며 그 활성화된 동작은 AC1에 포함되므로 노트로 이동; AC4는 팀의 정의된 완료 조건(DoD)이며 기준에서 제거됩니다. 둘 다 최종 결과물 감사 섹션에서 삭제되지 않고 이동된 것으로 나타납니다.
최종 고지
모든 게시된 결과물은 다음으로 끝납니다:
⚠️ 이 출력물은 정제를 위한 준비물이며, 대체물이 아닙니다. 범위, 가치 및 우선순위에 대한 결정은 엄격히 PO와 팀의 책임입니다.