PMDEX FIELD GUIDE
뜻을 찾았다면,
실무에 적용해 보세요.
지금 준비하는 회의를 고르세요. 먼저 알아둘 용어와 읽을 가이드를 연결했습니다.
백로그의 순서를 정할 때
이번 배포에 무엇을 넣고, 무엇을 미룰까요?
제품의 개선 목록과 계약 범위를 구분한 뒤, 변경의 일정 영향을 확인합니다.
회의 전에 확인하세요
- 이번 배포의 목적을 적었나요?
- 선행 작업과 담당자의 여유를 확인했나요?
- 보류 이유와 다시 판단할 조건을 공유했나요?
용어부터 확인
실무에 적용
- RICE 우선순위RICE 점수와 착수 순서를 구분하고 의존성과 추정 근거를 확인합니다.
- Jira 백로그 이월Jira 백로그 이월. 완료 열과 남은 일을 먼저 확인해요
- 제품 백로그오픈 범위와 제품 백로그를 한 목록에 두면 운영 개선이 기성 칸을 민다. 두 목록, 우선순위 손, 발주 개입, 기성, 운영 이관을 가르는 이유를 현장 기준으로 정리한다.
- 요구 우선순위 MoSCoW 읽기 - Should를 계약 범위로 오해하는 지점MoSCoW의 Should는 우선순위 라벨이지 계약 문장이 아니다. 제안서 기능 목록에 들어간 라벨이 검수에서 범위로 읽히는 지점과, 포함 여부 칸을 어디에 두는지 정리한다.
- 변경 우선순위 정하기 - 현업 표결과 임계경로가 다를 때 볼 칸스티커 표가 많은 변경이 이번 오픈의 1순위가 되는 경우가 있다. 불편의 크기와 여유일 영향을 다른 열에 두고 수용 순서를 정하는 기준을 정리한다.
요구사항을 합의할 때
개발 요청을 어떤 증거로 검수까지 연결할까요?
요구 ID부터 시안 합의, 인수 테스트까지 같은 기능을 추적합니다.
회의 전에 확인하세요
- 요청자와 요구 ID가 연결돼 있나요?
- 정상 동작과 예외 동작을 합의했나요?
- 검수 시나리오에서 요구 ID를 찾을 수 있나요?
용어부터 확인
실무에 적용
- 완료 정의와 인수 조건기능의 인수 조건과 공통 완료 정의를 구분해 합의하고 각각의 증거를 확인합니다.
- GitHub Projects 임시 항목GitHub Projects 임시 항목. 저장소 이슈로 넘길 때 확인해요
- 요구 ID 추적요구 ID가 설계와 시험 케이스에서 한 칸이라도 빠지면 검수 조서 사인이 흔들린다. ID 규칙, 설계 연결, 케이스 연결, 변경 시 재연결, 도구 최소 칸을 현장 기준으로 정리한다.
- 화면 시안 사인, 요구 확정 - 와이어를 범위로 쓰면 어디서 깨지나피그마 시안 사인을 요구 확정으로 읽으면 검수에서 그거 요청한 적 없다는 말이 나온다. 시안이 담는 칸과 확정 문서가 담아야 하는 칸을 나눠 적는다.
- 인수 테스트 설계인수 시나리오 초안은 요구 주에 씁니다. 초안 시점, 데모 대본, 버전, 현업 시간, 조서 연결을 오픈 2주 전이 아니라 앞에서 박는 법을 적습니다.
변경과 위험을 판단할 때
요청을 수용하기 전에 무엇을 확인할까요?
이미 생긴 문제와 앞으로의 위험을 구분하고, 범위와 공수 영향을 함께 검토합니다.
회의 전에 확인하세요
- 발생한 문제인지 예상 위험인지 구분했나요?
- 범위와 공수의 영향을 확인했나요?
- 결정자와 재검토 조건을 기록했나요?
용어부터 확인
실무에 적용
- 스프린트 리뷰와 회고스프린트 리뷰의 제품 결정과 회고의 개선 행동을 서로 연결하되 구분해 기록합니다.
- 이슈와 리스크 목록 나누기 - 발생 건과 예견 건을 한 표에 넣지 않는 기준이슈는 이미 벌어진 일이고 리스크는 아직 오지 않은 불확실입니다. 한 표에 섞으면 주간회의가 조치와 예견을 뒤섞습니다. 확률 칸, 이관, 주간 첫 장, 변경 창구, 담당을 현장 기준으로 나눕니다.
- 변경요청 공수 산정서 작성, 영향 시간변경요청서의 공수 칸이 비면 CCB는 다음 주로 밀린다. 영향 범위, 시간, 일정 이동, 비용 처리를 한 장에 두고 초안과 확인을 나누는 방법을 적는다.
- 요구사항 변경관리, 범위 증가합의 뒤 요구가 느는 것은 예외가 아니라 기본값이다. 어느 선까지 흡수하고, 어디부터 운영 이관하는지, CCB와 기준선으로 나누는 법을 정리한다.