개발팀 진행 업무 프로세스
Sprint Life Cycle
SLC
Requirement Life Cycle
RLC
상태 | 설명 | 상태 전이 가능자 | 정보 추가 |
---|---|---|---|
요청됨 | 개발 요청서 작성 | 누구나 | 오류내용, 기대결과 |
보류 | 개발안함, 다른방식으로 기능 제공 됨 | PMO, 개발자 | 사유 |
요구사항분석 | 백로그, 구체적 내용 확인 (필요 시 인터뷰) | PMO, 개발자 | 담당자 지정 |
개발 중 | 담당자가 업무를 시작함 | 담당 개발자 | 작업일정 |
개발완료 | 요구사항 개발 완료 | 담당 개발자 | (검증 환경 및 조건) |
검증 중 | QA담당자가 확인하는 중 | QA 담당자 | |
수정 중 | 개발된 결과에 오류가 발견됨 | QA 담당자 | 재현 조건 |
검증완료 | 기능동작 확인. 배포대기 | QA 담당자 | 배포 버전/일, 릴리즈 노트 |
배포됨 | 수정내용이 포함된 바이너리가 배포됨 | PMO, 개발자 | 배포버전, 배포일 |
PMO 는 요구사항 관계자로 대체 가능합니다.
이러한 프로세스 표는 프로젝트 관리와 협업을 효과적으로 조직하고 추적하는 데 도움이 되며, 무조건적인 진리는 아닌,
프로젝트의 크기, 복잡성 및 요구 사항에 따라 조정이 가능한 영역입니다.
다만, 이표를 근거로, 프로젝트의 상태 및 진행을 시각적으로 추적하고, 팀 간의 의사 소통을 강화하기 위해 도입되었습니다.
Semantic Versioning
참고: https://semver.org/lang/ko/
Semantic Versioning (SemVer)를 커스터마이즈하여 프로젝트에 맞게 조정하는 것은 흔한 일입니다.
- 기존 버전과 호환되지 않는 대규모 업데이트는
“MAJOR”
(주) 버전을 올린다. - 기존 버전과 호환되면서 새로운 기능을 추가할 때는
“MINOR”
(부) 버전을 올린다. - 기존 버전과 호환되면서 버그를 수정한 것이라면
“PATCH”
(수) 버전을 올린다. - QA 를 할 수 없거나, 필요가 없는 업데이트 (ex : sre 작업, info, error 등 백엔드 단순작업, query 수행 등)라면
“NOQA”
(무시주석) 버전을 올린다.
현재 배포 예정중인(비정기 배포) 사항에 긴급하게 Hotfix 처리를 통해서 배포 되어야할 경우
부득이 하게 miner(N.N.N) 버젼명을 변경하여 예정중인 버젼명을 일괄 변경 처리해야되는 부분을 고도화 하여
miner 버젼 숫자를 두자리(NN)으로 적용해서 차기 버젼명을 바꾸지 않고 처리하는것으로 정리.