재사용률이 높으면 일정도 짧아지나

본체 수정이 없고 회귀 대상의 일수가 작을 때만 짧아집니다. 비율만 높고 래퍼 일수가 비어 있으면 통합 주가 늘어납니다.

래퍼를 공통 모듈에 넣는 편이 낫지 않나

이번 업무에만 필요한 변환은 공통에 넣지 않는 편이 회귀 범위를 줄입니다. 여러 과제가 같은 입출력을 쓸 때만 본체 수정으로 올립니다.

회귀 화면 수를 아직 모르면 어떻게 적나

0일로 두지 않고 미확인으로 적습니다. 확인 주체와 확인 주를 WBS 선행에 넣어야 그 줄이 일정이 됩니다.

재사용 컴포넌트의 결함은 누구 공수인가

원래 계약 안의 결함은 그 컴포넌트 담당 과제의 수정입니다. 이번 요구 때문에 생긴 분기는 래퍼 공수로 이번 산정에 남습니다.

CBD 재사용 공수 빼기 - 검증 컴포넌트와 신규 래퍼를 산정표에서 나누기

재사용률 70%라는 칸을 보면 공수의 70%가 빠진 견적으로 읽히기 쉽습니다. 이미 돌아가던 컴포넌트를 붙이면 신규 작성보다 가볍다는 말이 회의에서 먼저 나오죠. 입력 규격과 오류 코드, 권한, 로그 항목이 이번 업무와 다르면 래퍼와 회귀 시험은 그대로 남습니다. 조립 일정이 2주라는 가정은 이 두 줄을 빼먹은 채 잡히는 경우가 많습니다. 그 공백이 산정표에 남는 순간 통합 주에 사람이 다시 붙고, 임계경로의 여유일이 먼저 줄어들어요. 이번 포스팅에서는 검증된 본체와 이번 프로젝트용 래퍼, 기존 화면 재시험을 맨먼스 표에서 나누는 기준을 자세히 적습니다. 재사용 비율 한 칸으로 견적을 맞추려는 산정이라면, 세 줄을 다시 나누는 데 참고가 됩니다.

산정 줄	빼도 되는 것	남겨야 하는 것
검증된 본체	이미 운영 중인 로직의 신규 작성	버전 고정과 배포 확인 일수
래퍼	해당 없음	입력 변환, 오류 코드, 권한 분기
회귀 시험	해당 없음	대상 화면 수와 시나리오 일수
예외	원래 계약 안의 표준 오류	이번 업무에서 추가된 예외
공통 수정	이번 저장소 밖 개선 희망	다른 과제 배포 창을 선행으로

재사용 산정에서 빼도 되는 줄과 남겨야 하는 줄

재사용률 한 칸이면 왜 통합 주에 공수가 다시 붙을까?

재사용률은 본체 코드의 비율일 뿐입니다. 이번 업무에 맞추는 래퍼와 회귀 시험은 별도 공수입니다.

재사용률은 보통 기존 소스에서 가져오는 라인 비율로 적혀요. 그 비율이 70이면 신규로 보이는 줄은 30으로 줄고, 견적 회의는 그 30만 일정에 올리는 경우가 많아요.

화면 문구 정도만 30 안에 남고, 코드값 변환과 오류 문구, 권한 분기는 비율 밖에 남죠. CBD 방법론는 검증된 부품을 조립하는 방식이지, 조립 공수가 0이라는 뜻은 아닙니다.

검증됐다는 말은 그 부품의 원래 계약, 곧 입력과 출력과 예외 안에서 그렇다는 뜻이에요. 계약을 넘는 요구는 신규 공수입니다.

맨먼스 표에 재사용 열만 있고 래퍼 열이 없으면, 빠진 공수는 통합 테스트 주에 사람 이름으로 다시 나타납니다. 그 주에 붙는 사람은 계획 인원이 아니라 초과 인원이 되기 쉬워요.

검증된 본체와 이번 래퍼는 어떻게 가를까?

운영 버전을 그대로 호출하면 본체입니다. 필드나 오류 문구, 권한 분기를 더하면 그 줄은 래퍼입니다.

가르는 기준은 호출 방식에 있어요. 운영 중인 버전을 그대로 부르고, 이번 화면이 그 입력과 출력을 이미 갖고 있으면 본체 공수는 버전 확인과 배포에 한정하면 돼요.

필드를 추가하거나 오류 문구를 업무 용어로 바꾸거나, 없는 권한을 막는 분기를 넣으면 래퍼예요. 래퍼를 본체 수정으로 올리면 같은 모듈을 쓰는 다른 시스템의 회귀 범위가 같이 커집니다.

그래서 산정표는 본체를 고치는 줄과, 이번 저장소 안에만 두는 래퍼 줄을 나란히 둡니다. 담당 등급도 달라요.

본체는 그 컴포넌트를 원래 만든 등급이 맞고, 래퍼는 이번 업무를 아는 개발 등급이면 충분해요. WBS에 두 줄의 선행을 비우면, 래퍼가 끝나기 전에 화면 시험을 그린 일정이 돼요.

그 일정은 통합 1주차에 시험 보류로 드러나는 경우가 많아요.

회귀 시험 공수는 왜 본체 공수에 숨으면 안 될까?

회귀를 본체에 섞으면 재사용률만 좋아 보입니다. 다시 돌려야 하는 화면의 일수는 일정에서 빠집니다.

공통 조회 하나를 이번 조건으로 부르면, 그 조회를 쓰던 화면이 12개인 과제가 있어요. 12화면을 다시 돌리는 시간은 조회 함수를 붙이는 시간보다 긴 주가 많아요.

회귀를 본체 공수에 넣으면 이 주가 산정에 안 남고, 재사용률 숫자만 올라갑니다. 회귀 줄에는 대상 화면 수, 시나리오 수, 담당, 소요 일수를 따로 적습니다.

수가 아직 없으면 0일 대신 미확인이라고 적고, 확인 주체를 선행에 넣으세요. 미확인인 채로 0일을 넣으면 그 0일이 나중에 시험 기간으로 바뀝니다.

발주 측이 볼 칸은 재사용률이 아니라, 회귀 대상이 몇 화면으로 확정됐는지입니다. 확정 화면이 4개에서 12개로 늘면 그 차이의 일수를 같은 주에 일정에 반영하는 편이 맞아요.

공통 모듈을 고치면 화면 공수는 어디로 붙을까?

본체를 올려야 하면 다른 과제의 배포 창이 선행입니다. 래퍼로 막을 수 있으면 공통 버전은 고정합니다.

공통 모듈 한 줄을 고치면 영향은 이번 화면에서 끝나지 않아요. 같은 모듈을 호출하는 화면, 배치, 외부 연계가 회귀 목록에 올라오고, 그 합이 통합 주의 실공수예요.

이때 본체를 고치지 않고 래퍼로 막을 수 있는지를 먼저 묻습니다. 막을 수 있으면 공통 버전은 고정하고 변환은 이번 저장소에 둡니다.

막을 수 없어서 본체를 올려야 하면, 그 버전을 쓰는 다른 과제의 배포 창을 선행으로 적어요. 선행이 다른 팀 달력에 있으면 통합 시작일은 그 창 다음이에요.

이 선행을 산정표 각주에만 두고 WBS에 안 넣으면, 주간 진척률은 오르고 종료일만 밀려요. 밀리는 일수는 보통 배포 창의 간격, 1주에서 2주가 한 번에 붙어요.

산정 회의에서 어떤 숫자부터 물어볼까?

재사용률보다 래퍼 기능 수, 회귀 화면 수, 본체 수정 수를 먼저 봅니다. 하나라도 빈칸이면 비율만 있는 견적입니다.

회의에서 처음 볼 숫자는 재사용률이 아니에요. 래퍼로 분류된 기능 수, 회귀 대상 화면 수, 본체 수정이 필요한 컴포넌트 수, 그리고 각각의 소요 일수예요.

셋 중 하나라도 빈칸이면 그 견적은 비율만 있는 상태예요. 빈칸을 채우기 전에 일정을 확정하면 빈칸은 통합 주차의 초과 공수로 돌아옵니다.

초과가 보이면 사람을 더 넣는 제안보다, 본체 수정을 다음 버전으로 미룰 수 있는지부터 정하는 편이 종료일에 닿습니다. 미룰 수 없는 수정만 이번 오픈의 임계경로에 남기면, 재사용은 비율이 아니라 일정으로 읽혀요.

다음 산정부터는 이 세 수의 계획과 실적을 결산 칸에 나란히 두면, 같은 70%가 반복해서 일정을 속이지 않아요.