1검수할 수 있는 업무의 조건
이 과정의 업무 본문은 다섯 부분으로 구성한다.
| 부분 | 쓰는 내용 | 빠지면 생기는 일 |
|---|---|---|
| 제목 | 끝났을 때의 결과 | 같은 이름의 작업이 여러 번 열린다 |
| 배경 | 이 업무가 필요한 이유 | 범위 판단 기준이 없다 |
| 완료 조건 | 예·아니오로 확인할 수 있는 체크리스트 | “거의 다 됐다”가 반복된다 |
| 검증 근거 | 완료를 확인할 자료와 그 위치 | 검수자가 다시 물어본다 |
| 범위 제외 | 이번에 하지 않는 것 | 작업 중에 범위가 늘어난다 |
제목과 완료 조건은 아래처럼 바꾼다.
| 구분 | 확인하기 어려운 예 | 확인할 수 있는 예 |
|---|---|---|
| 제목 | 신청 페이지 작업 | [LP-03] 방문자가 이메일로 사전신청을 완료한다 |
| 완료 조건 | 신청 기능이 잘 동작한다 | 이메일과 동의를 입력하면 신청이 저장된다 |
| 예외 상황 | 오류 처리 | 빈 값, 이메일 형식 오류, 동의 누락 시 저장하지 않고 이유를 보여 준다 |
| 중복 | (없음) | 같은 이메일로 다시 신청하면 정책에서 정한 방식으로 처리한다 |
제목 앞의 [LP-01]은 업무 키(key)다. 키는 이슈 번호와 별개로 기획 문서와 회의에서 업무를 부르는 이름이다. 이슈 번호는 PR도 함께 쓰는 번호여서 업무 순서와 맞지 않는다. 키는 한 번 정하면 바꾸지 않는다.
2본문을 파일로 작성하기
본문을 파일로 두면 다음 프로젝트에서 내용만 고쳐 다시 쓸 수 있다. 아래 블록은 첫 줄부터 마지막 EOF까지 한 번에 붙여넣는다. <<'EOF'에 따옴표가 있으므로 본문의 글자는 바뀌지 않고 그대로 저장된다.
mkdir -p pm-lab cat > pm-lab/01-policy.md <<'EOF' ## 배경 신청 화면과 저장 방식을 만들기 전에 사전신청 정책을 확정한다. ## 완료 조건 - [ ] 필수 입력 항목과 개인정보 동의 문구를 확정했다. - [ ] 같은 이메일의 재신청 처리 방식을 정했다. - [ ] 신청 성공과 실패 시 사용자에게 보여 줄 안내를 정했다. - [ ] 기획자와 개발 담당자가 같은 정책 문서를 확인했다. ## 검증 근거 정책 문서 링크와 검토 결과를 댓글로 남긴다. ## 범위 제외 결제와 회원 로그인은 이번 베타에 포함하지 않는다. EOF cat pm-lab/01-policy.md
- [ ]는 GitHub에서 체크박스로 표시된다. 이슈 목록에는 “0 of 4 tasks”처럼 진행 개수가 보인다.
3이슈 등록하기
PM_POLICY_URL=$(gh issue create -R "$PM_REPO" \ --title "[LP-01] 사전신청 정책을 확정한다" \ --body-file pm-lab/01-policy.md \ --label "kind:task,area:product" \ --assignee "@me" \ --milestone "$PM_MILESTONE") echo "$PM_POLICY_URL"
https://github.com/gildong/launchpad-pm-lab/issues/1
| 옵션 | 뜻 |
|---|---|
PM_POLICY_URL=$( ... ) | 명령이 출력한 이슈 주소를 변수에 저장한다. 이후 실습에서 이 업무를 가리킬 때 쓴다. |
--title | 제목. 업무 키와 결과 문장을 함께 쓴다. |
--body-file | 본문을 파일에서 읽는다. |
--label "a,b" | 라벨 여러 개를 쉼표로 이어 쓴다. 저장소에 이미 있는 라벨이어야 한다. |
--assignee "@me" | 로그인한 본인을 담당자로 지정한다. |
--milestone | 마일스톤을 제목으로 지정한다. 공백까지 정확히 같아야 한다. |
주소를 변수 파일에도 저장한다. >>는 파일 끝에 한 줄을 덧붙인다. > 하나를 쓰면 파일 내용이 지워지므로 주의한다.
echo "PM_POLICY_URL=\"$PM_POLICY_URL\"" >> pm-lab/env.sh tail -n 1 pm-lab/env.sh gh issue view "$PM_POLICY_URL" --web
팀에서는 @me 대신 실제 실행 담당자의 로그인 이름을 넣는다. 예: --assignee dev-lee. 담당자는 저장소에 접근 권한이 있는 사람이어야 한다. 검수자는 본문이나 댓글에 이름을 적어 둔다.
4직접 고쳐 쓰기
아래 이슈는 회의에서 자주 보는 형태다. 제목을 결과 문장으로 바꾸고, 완료 조건 세 개를 예·아니오로 확인할 수 있게 쓴다. 터미널 입력은 필요 없다.
제목: 알림 기능 개발 본문: 운영자 알림 기능을 개발한다. 잘 동작해야 한다.
작성 예시 보기
제목: [LP-04] 운영자가 새 신청을 알림으로 확인한다 ## 완료 조건 - [ ] 새 신청이 저장되면 운영 채널(메일 또는 메신저)로 알림이 간다. - [ ] 알림에는 신청 시각과 가린 이메일(예: ab***@example.com)만 표시한다. - [ ] 알림 전송이 실패해도 신청 저장은 유지되고 실패 기록이 남는다.
세 번째 조건처럼 실패했을 때의 동작을 적어 두면, 검수자가 정상 경우만 확인하고 닫는 일을 막는다.
- 웹 화면의 LP-01에 본문, 담당자, 라벨 2개, 마일스톤이 모두 보인다.
- 이슈 목록에서 LP-01 옆에 “0 of 4 tasks”가 보인다.
tail -n 1 pm-lab/env.sh가PM_POLICY_URL=...줄을 보여 준다.- 고쳐 쓰기 연습에서 완료 조건 세 개를 작성했다.
막히면
| 증상 | 확인과 해결 |
|---|---|
could not add to milestone 'M1 비공개 베타': 'M1 비공개 베타' not found | 마일스톤 제목이 다르다. 실습 2의 조회 명령으로 제목을 확인하고 PM_MILESTONE 값을 맞춘다. |
could not add label: 'area:product' not found | 라벨이 없다. gh label list -R "$PM_REPO"로 확인한다. |
| 같은 업무가 두 번 생김 | 등록 명령을 두 번 실행했다. 나중 것을 gh issue close 번호 -R "$PM_REPO" --reason "not planned"로 닫고, PM_POLICY_URL이 남길 이슈를 가리키는지 확인한다. |
본문에 EOF 글자가 들어감 | 마지막 EOF 앞뒤에 공백이 있었다. EOF는 줄 맨 앞에 단독으로 있어야 한다. 파일을 다시 만들고 gh issue edit "$PM_POLICY_URL" --body-file pm-lab/01-policy.md로 본문을 바꾼다. |
마치며...
저장소에 완료 조건이 있는 첫 업무 LP-01이 생겼고, 그 주소가 PM_POLICY_URL에 저장되었다. 실습 4에서는 이 업무를 우선순위와 상태로 관리할 Project를 만든다.