작업 분해 (Task Breakdown)
설계를 팀의 모든 엔지니어가 독립적으로 선택하여 완료하고 병합할 수 있는 1스토리포인트 티켓의 백로그로 전환합니다.
입력
$ARGUMENTS
- 경로가 주어지면 해당 문서를 읽습니다.
- 그렇지 않으면, 이 대화나 디스크에 있는 생산적 사고 세션의 가장 최근 RFC 또는
*.notes.md파일을 사용합니다. (보통.rfcs/,docs/rfcs/,docs/adr/,rfcs/와 같은 git에서 무시된 폴더에 있는 로컬, 추적되지 않은 파일입니다.) 찾지 못하면 어떤 문서나 설계를 분해할지 질문합니다. - 소스에 분할을 막는 공백(선택된 설계 없음, 롤아웃 접근법 없음)이 있으면, 그것들을 나열하고 답변을 지어내기 전에 질문하세요. 작은 공백은 대신 스파이크 티켓이 될 수 있습니다.
"1스토리포인트"의 의미
티켓이 1포인트가 되려면 다음 모든 조건이 충족되어야 합니다. 하나라도 실패하면 분할하세요:
- 한 사람이 하루 이내 (테스트 및 리뷰 수정 포함).
- 하나의 검토 가능한 PR로 단일 목적을 가질 것. 리뷰어가 다른 열린 PR을 읽지 않고도 이해할 수 있어야 함.
- 자체적으로 병합 가능. 메인 브랜치가 병합 후에도 녹색이고 출시 가능한 상태를 유지해야 하며, 이는 일반적으로 새로운 동작이 플래그 뒤에 있거나 아직 연결되지 않았음을 의미함.
- 테스트 가능. 작성자가 아닌 다른 사람이 확인할 수 있는 1~5개의 승인 기준이 있어야 함.
- 숨겨진 불확실성이 없음. 구현자가 무엇을 해야 할지 알기 위해 조사가 필요하다면, 그것은 스토리가 아닌 스파이크임.
팀이 자체적인 포인트 정의를 가지고 있다면, 그 정의를 따르고 출력 상단에 명시하세요.
분할 방법
분할하기 전에 코드를 읽으십시오: 각 티켓이 실제로 건드리는 파일, 모듈, 스키마, 테스트가 존재하는지 확인하고, 티켓에 이름을 명시하십시오. 실제 경로를 언급하는 티켓은 선택되고, 모호한 티켓은 백로그에 남습니다.
**걷는 해골(walking skeleton)**부터 시작하십시오: 설계가 프로덕션에서 작동함을 증명하는 가장 얇은 종단 간 조각(종종 플래그 뒤에 있음)을 만들고, 그 다음 두껍게 만듭니다. 이렇게 하면 마지막 티켓에서 통합 문제를 발견하는 대신 위험을 조기에 노출시킵니다.
티켓이 너무 클 때, 다음 분할이 일반적으로 작동합니다:
- 준비, 그 다음 변경. 순수 리팩터링을 먼저 추출하십시오("변경을 쉽게 만든 다음, 쉬운 변경을 하라"), 리팩터링 전에 테스트로 현재 동작을 고정합니다.
- 확장 / 마이그레이션 / 축소 스키마 및 API 변경의 경우: 새 열이나 엔드포인트 추가, 백필 또는 이중 쓰기, 읽기 전환, 그 다음 이전 경로 제거. 각 단계가 자체 티켓입니다.
- 플래그 뒤의 계층별: 데이터 모델 → 서비스 로직 → API → UI, 각각 플래그가 꺼져 있으므로 병합 가능.
- 읽기 경로를 쓰기 경로보다 먼저, 그리고 해피 패스를 엣지 케이스 및 오류 처리보다 먼저.
- 변형별: 첫 번째가 패턴을 확립한 후, 제공자, 파일 유형 또는 클라이언트당 하나의 티켓.
- 불확실성에 대한 스파이크: 시간 제한(≤ 1일), 출력은 결정 및 후속 티켓이며 프로덕션 코드가 아님. 각 스파이크에 답변이 있는
Question:과 시간 상자를 지정하십시오. 결정에 의존하는 티켓은 안전한 수준까지만 분할하고, 스파이크가 결정되면 정제될 것임을 명시합니다. 스파이크를 일찍 배치하십시오: 그 뒤에 있는 모든 것을 차단합니다.
기능 코드가 아닌 작업도 잊지 마십시오: 기능 플래그 설정 및 제거, 메트릭/알림/대시보드, 런북 또는 문서 업데이트, 데이터 백필, 단계적 롤아웃 단계, 이전 경로 정리. 프로젝트가 "거의 완료"된 상태에서 멈추는 곳이 바로 여기입니다.
분할 자체를 위해 분할하지 마십시오: 다른 티켓과 함께 병합해야만 의미가 있는 티켓은 하나의 티켓이어야 하거나, 쌍을 다른 분할선을 따라 다시 자르십시오.
출력
- templates/tasks.md 템플릿을 사용하여 백로그를 소스 RFC 옆에
<rfc-name>.tasks.md로 작성하십시오. RFC와 마찬가지로 로컬 작업 파일이며, 기본적으로 추적되지 않습니다. 폴더가 git에서 무시되지 않았다면.git/info/exclude에 추가하십시오. 티켓 번호를T-01,T-02, …로 매겨 의존성이 참조할 수 있도록 하고, 모든 상태를open으로 설정하며, 브랜치 이름에 사용될 프로젝트 슬러그를 입력하십시오./implement-task와/deliver-project가 읽기 때문에 필드 이름을 템플릿과 정확히 일치시키십시오. - 티켓을 RFC의 단계와 일치하는 마일스톤으로 그룹화하고, 각각은 시연 가능하거나 출시 가능한 것으로 끝나야 합니다.
- 의존성 그림을 포함하십시오: 어떤 티켓이 병렬로 실행될 수 있는지, 그리고 임계 경로. 약 8개 이상의 티켓이 있을 때는 작은 Mermaid 그래프가 잘 작동합니다.
- 채팅에서 짧은 요약을 제공하십시오: 마일스톤별 티켓 수, 즉시 시작할 수 있는 티켓 수, 임계 경로, 스파이크, 그리고 1포인트가 아닐 수 있는 티켓. 사용자에게 너무 크거나, 너무 작거나, 순서가 잘못된 티켓을 표시하고 수정하도록 요청하십시오.
- 팀 트래커에 게시하십시오. 팀이 하나(Linear, Jira, GitHub Issues 등)를 사용한다고 가정합니다. 사용자가 분해에 만족하면, 연결된 트래커 도구를 통해 게시하도록 제안하십시오. 연결된 것이 없으면 어떤 커넥터가 도움이 될지 말하고, 대체 방안으로
ID, Title, Description, Acceptance Criteria, Story Points, Milestone, Depends On, Labels컬럼이 있는 CSV를 제공하십시오. 전체 팀에 표시되므로 사용자가 확인한 후에만 게시하십시오. 각 티켓에 대해 제목, 독립적인 설명(컨텍스트, 범위, 파일, 범위 밖, 승인 기준), 추정치 1, 마일스톤, 그리고 트래커가 지원하는 경우 의존성에 대한 차단 관계를 포함한 이슈를 만드십시오. 그런 다음 각 이슈의 키와 링크를 로컬 파일의 티켓Tracker:필드에 쓰십시오. - 다음 단계를 가리키십시오: 단일 티켓의 경우
/implement-task <ticket-id>, 스파이크의 경우/spike-task <ticket-id>, 또는 에이전트 팀으로 전체 백로그를 실행하려면/deliver-project <tasks-file>을 사용하십시오.
소스 RFC에 실행 계획 섹션이 있다면, 목록을 중복하지 않고 작업 파일을 링크하도록 업데이트하십시오.
스파이크 후 정제
결정된 스파이크의 결정 기록(상태 decided)이 주어지면, 처음부터 다시 시작하지 않고 백로그를 업데이트하십시오:
- 기록의 승인된 백로그 변경 사항을 적용하십시오: 티켓 추가(
T-NN번호를 계속 사용하고 ID를 재사용하지 마십시오), 영향을 받는 티켓의 범위, 기준 또는 의존성 변경, 삭제된 티켓은 삭제하지 말고 이유와 함께canceled로 표시하십시오. - 변경되거나 새로운 모든 티켓을 1포인트 테스트에 대해 다시 확인하고, 요약, 의존성 그래프 및 임계 경로를 업데이트하십시오.
- 기록이 나열하는 RFC 섹션을 업데이트하십시오.
- 트래커를 동기화하십시오: 새 이슈를 만들고, 변경된 이슈를 업데이트하고, 제거된 이슈를 취소하며, 작업 파일에 새 키를 쓰십시오. 사용자가 결정과 백로그 변경을 함께 승인했다면, 그 승인이 이 동기화를 포함합니다. 그렇지 않으면 먼저 확인하십시오.
- 스파이크를
done으로 설정하고 변경된 사항을 몇 줄로 요약하십시오.