> [!abstract] Introduction > 프로젝트를 실제로 이행하기 위해서는 다양한 위치에 있는 다양한 사람들이 힘을 보태주어야 하기에, 당연히 계획을 세운 다음 이를 현실로 옮겨야 합니다. 이 글에서는 [[Capability Maturity Model Integration|CMMI]]의 프로젝트 계획 프로세스 영역을 기반으로, 견적 수립*Establish Estimates*, 계획 개발*Develop a Project Plan*, 지원 획득*Obtain Commitment to the Plan*이라는 세 가지 목표를 순서대로 살펴봅니다. # Project Planning 프로젝트 계획*Project Planning*은 프로젝트에서 발생하는 모든 일을 정의하는 계획을 수립하고 유지하기 위한 프로세스 영역이다. 세부적으로는 프로젝트 계획을 세우고, 관련된 이해관계자들과 잘 소통하고, 계획에 대한 지원을 이끌어내고, 계획을 유지하는 과정으로 이루어져 있다. 프로젝트를 실현하기 위한 계획에는 작업물*work product*[^work-product-definition]과 작업*task*의 여러가지 특성을 추산하고, 어떤 자원이 필요한지 결정하고, 협상을 통해 필요한 지원을 이끌어내고, 일정을 짜고, 프로젝트를 실패로 이끌 수 있는 리스크를 분석하고 관리하는 작업이 포함되어 있다. 프로젝트 계획은 클라이언트와의 약속을 나타내는 프로젝트 활동을 제어하고 수행하기 위한 기반을 제공한다. 프로젝트가 진행되면서 요구사항이나 약속이 바뀔 때, 기존의 견적이 정확하지 않을 때, 시정 조치*corrective action*[^corrective-action-definition]가 필요할 때, 프로세스가 바뀔 때 등 여러가지 변화가 발생할 때 프로젝트 계획이 자주 검토된다. 프로젝트 계획은 [[Capability Maturity Model Integration|CMMI]]의 프로젝트 영역 중 하나로, 견적 내기*Establish Estimates*, 프로젝트 계획 세우기*Develop a Project Plan*, 계획을 위한 지원 획득*Obtain Commitment to the Plan*라는 세가지 목표로 구성되어 있다. 세가지 목표를 순서대로 살펴보자. ## Establish Estimates 첫번째 목표는 프로젝트에 대한 견적을 내는 것이다. 프로젝트의 견적을 내기 위해서는 요구사항에 기반해 다양한 프랙티스를 수행해야 한다. 이들의 관계는 아래 다이어그램의 녹색 영역과 같다. ![[ProjectPlanningEstimationDiagram.png]] 이번 섹션에서는 순서대로 녹색 영역에 있는 프랙티스들을 살펴보자. ### Estimate the Scope of the Project 첫번째 프랙티스는 프로젝트의 범위*Scope*를 추산하는 것이다. 프로젝트 범위를 추산하기 위해서는 해야 하는 일이나 필요한 기능 등을 한눈에 볼 수 있는 구조가 필요한데, 이때 필요한 것이 바로 [[Work Breakdown Structure|작업 분석 구조]]*Work Breakdown Structure*라는 문서다. WBS는 프로젝트에 대한 초기 견적을 내기 위한 문서이며, 프로젝트를 작업 패키지*work package*라는 논리 단위로 재구성해 프로젝트를 실현하기 위해 해야 할 일이 무엇인지, 어떻게 일정을 구성하고 인원을 배치할 것인지, 어떻게 업무를 구성할 것인지 등에 대한 견적을 만드는 데 도움을 준다. #### WBS 정의하기 WBS는 프로젝트에서 해야 할 작업을 구성하기 위한 기본 틀의 역할을 하기 때문에 리스크를 파악하고 완화하기 위한 작업, 상품*Deliverable*과 지원 활동*Supporting Activity*을 위한 작업, 스킬과 지식을 습득하기 위한 작업, 구성 관리*Configuration Management*, 품질 보증, 그리고 검증 계획 등 필요한 지원 계획의 개발을 위한 작업을 정의해야 한다. WBS가 정의되고 나면 프로젝트에서 해야 할 작업과 그에 따른 책임 그리고 일정을 특정할 수 있을 만큼 자세하게 작업 패키지를 정의한다. WBS는 프로젝트의 작업에 기울이는 노력과 조직의 역할 그리고 책임을 측정하기 위해 만들어지는데, 세밀하게 구성할 수록 현실적인 일정을 만드는 데 도움을 주고 이를 통해 추가적인 관리의 필요성을 줄이는 데 도움을 준다. 마지막으로 외부에서 가져와야 하는 제품들과 제품 구성요소, 그리고 다시 사용해야 하는 제품들을 파악하고 나면 프로젝트의 범위를 추산할 수 있다. ### Establish Estimates of Work Product an Task Attributes 다음 프랙티스는 프로젝트의 기술적인 접근을 결정한다. 기술적인 접근은 제품의 개발을 위한 최상위 전략을 정의하며, 최상위 전략에는 분산 구조나 클라이언트-서버 구조와 같은 아키텍쳐, 로보틱스, 복합 재료, 인공지능과 같은 최첨단*state-of-the-art* 기술 혹은 기존 기술의 응용, 그리고 안전, 보안, 인간 공학*ergonomics* 등 최종 제품에 기대되는 기능이나 품질과 관련된 속성에 대한 결정이 포함된다. 그 다음 작업물과 작업의 속성이 필요한 자원에 대한 견적을 짜기 위해 활용될 수 있도록 여러 적절한 방법들을 사용한다. 크기[^size-attribute-estimation]와 복잡도를 결정하기 위한 방법들은 검증된 모델이나 역사적 데이터에 기반해야 하며, 속성을 결정하기 위한 방법들은 제품의 특성과 속성에 대한 이해도가 높아지면서 함께 발전한다. 이 프랙티스의 결과물은 작업물과 작업의 속성에 대한 견적이다. 견적에 포함되는 속성들에 대한 예시는 아래와 같다. - 요구사항의 개수와 복잡도 - 인터페이스의 개수와 복잡도 - 데이터의 크기 - 기능의 숫자 - [[Function Point|기능점수]]*Function Point* - 본수산정*Source LInes of Code*[^source-lines-code-metric] - 클래스와 객체의 개수 - 데이터베이스 테이블의 개수 - 재사용된 코드와 새로 작성된 코드의 비율 - 기존 코드 베이스의 품질과 깔끔함 - 페이지의 수 - 입력과 출력의 개수 - 기술적 리스크를 가진 아이템의 개수 - 부품의 개수(PCB, 기계적 부품 등) - 물리적 제한(무게, 크기) - 프로젝트에 참여하는 사람들의 경험치 - 팀의 속도*velocity*[^team-velocity-agile] / 생산성 - 프로젝트 멤버들의 지리적 분포 - 소비자, 최종 유저, 그리고 공급자 사이의 거리 - 소비자의 설득 난이도 ### Define Project Lifecycle Phrases 다음은 프로젝트 생명주기의 과정을 정의하는 것이다. 프로젝트의 생명주기가 어떤 단계를 거칠지 정하게 되면 평가와 의사 결정을 위한 시기를 계획하기 위한 기반이 된다. 큰 프로젝트인 경우 컨셉 탐색, 개발, 프로덕션, 운영, 그리고 폐기 등 여러가지 단계가 있을 수도 있고, 개발 단계 안에 요구사항 분석, 설계, 구현, 통합, 그리고 검증 등 여러가지 절차가 있을 수 있다. 일반적으로 프로젝트의 진행 단계를 결정할 때는 단계 내의 여러 활동의 상호의존성과 적절한 순서 배치를 강조하기 위해 한가지 이상의 개발 모델을 선택하고 개선하는 과정이 포함된다. ### Estimate Effort and Cost 견적을 내기 위한 마지막 프랙티스는 투입되는 노동력과 비용에 대한 견적을 내는 것이다. 프로젝트에 투입되는 비용과 프로젝트의 일정을 추산하기 위해 많은 매개변수 모델들이 발전했지만, 이런 모델들의 근거가 되는 데이터가 프로젝트에 적절한지 검증되지 않았기 때문에 견적의 신뢰도를 높이려면 여러 개의 모델과 방법을 사용해야 한다. 신뢰할 만한 데이터는 이전에 이루어진 프로젝트들의 비용, 노동력, 일정 데이터를 포함해야 하고 그 크기를 적절하게 조정해 다양한 크기와 복잡도에 맞출 수 있어야 한다. 투입되는 노동력과 비용에 대한 견적을 내기 위해서는 프로젝트를 지원하는 인프라에 대한 수요 또한 포함할 필요가 있다. 프로젝트를 지지*support*하는 인프라에는 제품 개발과 지속성의 관점에서 필요한 자원들이 있으며, 개발 환경, 테스트 환경, 프로덕션 환경, 운영 환경, 혹은 이러한 환경들의 적절한 배합 전체에 필요한 인프라 자원에 대한 수요를 산정해야 한다. ## Develop a Project Plan 다음 단계는 프로젝트 계획을 실제로 세우는 것이다. 이 목표에 대한 하위 프랙티스는 총 7개가 있으며 이들의 관계는 아래 다이어그램과 같다. ![[ProjectPlanningDiagram.png]] 프로젝트 계획은 프로젝트의 실행을 제어하고 관리하기 위한 문서이며 규격화되어 있고 검증되어 있어야 한다. 그 기반은 프로젝트의 요구사항과 앞선 목표를 통해 산출된 견적이다. 이제 어떤 프랙티스가 있는지 하나씩 살펴보자. ### Establish the Budget and Schedule 첫번째 프랙티스는 예산과 일정을 정하는 것이다. 이를 위해서 먼저 주요 마일스톤을 설정할 필요가 있다. 마일스톤이란 전체 상황을 점검하기 위해 미리 정해놓은 어떤 이벤트나 시점을 일컫는 것으로, 특정 사건 혹은 특정 날짜에 기반해 어떤 단계에 도달했을 때 마일스톤에 도달하거나 지정된 날짜가 되면 마일스톤에 도달하도록 설정할 수 있다. 다음으로는 어떤 행동을 하기 위한 기간, 필요한 자원, 작업물과 작업의 입출력 등 기본적인 제한사항을 파악하고, [[Critical Path Method|CPM(Critical Path Method)]]이나 [[Program Evaluation and Review Technique|PERT(Program Evaluation and Review Technique)]]와 같은 기술을 통해 작업 간의 의존성을 파악한다. 예산의 경우 관리 준비금*Management Reserve*를 정의해 예산과 일정을 정한다. 시정 조치에 대한 기준을 정하기 위해서는 프로젝트 계획에서 눈에 띄게 벗어나는 상황을 구성하는 요소가 무엇인지 결정할 수 있어야 하고, 이를 위해 이슈와 문제를 측정하기 위한 밑바탕이 필수적이다. ### Identify and Analyze Project Risks 다음 프랙티스는 프로젝트에 부정적인 영향을 끼칠 수 있는 잠재적 위험 요소를 파악하는 작업이다. 업무와 계획에 부정적인 영향을 끼칠 수 있는 잠재적 이슈, 해저드, 위협, 취약성 등을 포괄하여 위험 요소라 부르는데, 이러한 위험 요소를 파악하기 위해서는 위험 분류학*Risk Taxonomy*, 체크리스트, 구조적 인터뷰, 브레인스토밍, 위험 요소 평가 등의 기술이 필요하다. 이렇게 파악된 위험 요소는 리스크의 영향력과 발생 확률, 그리고 우선순위를 기준으로 문서화해야 한다. 그 다음 문서화된 위험 요소들의 정확성과 완전성에 대하여 관련된 이해당사자들과 함께 검토하고 그들로부터 합의를 얻어내야 한다. 그리고 향후에도 새로운 위험 요소가 생길 수 있는 만큼 계속 재검토할 필요가 있다. ### Plan for the Management of Project Data 이 프랙티스에서는 프로젝트 데이터를 관리하기 위한 계획을 수립한다. 데이터는 관리, 엔지니어링, 구성 관리, 재정, 물류, 품질, 안전, 조달*procurement* 등 모든 영역에서 프로젝트를 지원하기 위해 필요한 문서 양식들이며, 보고서, 매뉴얼, 차트, 그림, 명세서, 파일, 서신*correspondence*등 다양한 형태로 존재할 수 있다. 그뿐만 아니라 출력, 그리기, 사진, 멀티미디어 등 다양한 매체 속에 존재할 수 있고, 계약 요구사항에 명시된 아이템처럼 상품이거나 내부 문서나 데이터처럼 상품이 아닐 수도 있다. 데이터를 관리하기 위해서는 우선 데이터 요구사항이 수립되어야 한다. 앞으로 만들어질 데이터 아이템, 그리고 그 내용과 형식은 공통 혹은 표준적인 데이터 요구사항에 기반해야 하며, 데이터 아이템을 위한 내용과 형식의 통일된 요구사항은 데이터 내용의 이해를 수월하게 하고 데이터 자원을 지속적으로 관리하는 데 도움을 준다. 데이터의 비밀과 보안이 보장되도록 요구사항과 절차를 수립한 다음, 그 데이터를 보존하고 보존된 데이터에 접근하기 위한 메커니즘을 수립한다. 그리고, 인식되고 수집된 다음 분배될 프로젝트 데이터를 결정해야 한다. 각 문서를 수집하는 이유는 분명해야 한다. 데이터가 어떻게 쓰일지에 대한 이해 없이 수집되는 상황이 흔한데, 데이터는 비용이 들기 때문에 필요할 때만 수집되어야 한다. 프로젝트 데이터와 계획 중에 버전 관리 혹은 다른 수준의 설정 제어가 필요한지 결정하고 프로젝트 데이터 제어를 보장하기 위한 메커니즘을 수립해야 한다. ### Plan the Project's Resource 프로젝트 활동을 수행하기 위한 프로젝트 자원(노동력, 기구, 재료, 방법)의 종류와 양에 대한 결정은 초기 견적에 기반하고 프로젝트 관리에 사용되는 WBS를 확장하기 위해 적용할 수 있는 추가 정보를 제공한다. 최상위 계층 WBS이 견적을 내기 위한 방법으로서 미리 개발되어 있기는 하지만, 이 단계에서 최상위 계층을 작업 패키지로 분해하면서 확장된다. 작업 패키지는 개별적으로 할당되고 수행되고 추적되는 작업의 단위를 칭하며 이러한 분해는 업무를 더 잘 관리하고 관리 책임을 분배하기 위해 이루어진다. WBS에 존재하는 각 작업 패키지는 추적을 위해 고유한 번호가 매겨지고, WBS는 요구사항, 활동, 작업물, 서비스, 혹은 이들의 조합에 기반할 수 있다. WBS에 존재하는 각 작업 패키지를 위한 사전적 구성은 작업의 실제 분해 구조와 같이 가야 한다. 우선 프로세스 요구사항을 결정해야 한다. 프로젝트를 관리하기 위해 사용되는 프로세스는 확실하게 정의되고 밝혀져야 하며 프로젝트가 진행되는 동안 효율적으로 운영될 수 있도록 관련된 모든 이해관계자와 조화를 이루어야 한다. 다음으로는 소통에 관한 요구사항을 결정해야 한다. 이러한 요구사항은 최종 사용자, 소비자, 프로젝트 스태프, 그리고 다른 이해관계자들과 소통하기 위한 방법의 여러가지 종류를 나타내야 한다. 세번째로, 스태핑(Staffing)[^staffing-hiring-process] 관련 요구사항을 결정해야 한다. 프로젝트에서 고용이나 해고는 WBS에 명시된 작업 패키지대로 프로젝트의 요구사항을 어떻게 작업, 역할, 책임으로 분배하냐에 달려 있으며, 스태핑을 위한 요구사항에는 Plan Need Knowlege and Skills 프랙티스에 정의된 각 포지션에 필요한 지식과 스킬이 반영되어야 한다. 또한, 시설, 기구, 요소에 대한 요구사항을 결정해야 한다. 대부분의 프로젝트는 어떤 측면에서 고유하고 프로젝트의 목적을 달성하기 위한 고유한 에셋의 집합을 요구한다. 이러한 에셋을 미리 결정하고 보유하는 것은 프로젝트의 성공 여부를 결정하는 핵심 요인 중 하나다. 이때 처음부터 끝까지 필요한 아이템들을 파악하는 것이 이들을 요청하는 방식을 결정하는 데 가장 도움이 된다. 요구된 에셋이 고유하지 않을 때에도 모든 시설, 기구, 장비, 공간 등에 대한 리스트를 만들면 검토에 들어가는 시간을 줄일 수 있다. 그 외에도 전기, 사무용품 등 소비재, 지적 재산에 대한 접근 권한, 이동 수단에 대한 접근 권한 등 다른 지속적인 자원에 대한 요구사항까지 결정할 필요가 있다. ### Plan Needed Knowledge and Skills 프로젝트에 필요한 지식을 전달하는 과정에는 프로젝트에 참여하는 직원들을 훈련시키고 외부 지식을 가져오는 과정이 포함된다. 이를 위한 요구사항은 프로젝트 실행을 지원할 수 있는 지식과 스킬에 의존적이다. 우선 프로젝트를 수행하기 위한 지식과 스킬이 무엇인지, 그리고 가능한 지식과 기술이 무엇인지 파악한다. 다음으로 필요한 지식과 기술을 제공하기 위한 메커니즘을 도입한다. 회사 내외에서 교육을 받게 하거나, 새로운 직원을 고용하거나, 알아서 기술을 습득하게 할 수도 있다. 다만, 내부 교육 혹은 외부 강사를 통한 교육 여부는 전문가를 고용할 수 있는지, 프로젝트의 일정, 그리고 비즈니스의 목적에 따라 달라진다. ### Plan Stakeholder Involvement 이해당사자가 개입하는 상황도 미리 계산해보자. 시니어 급의 관리자라면 프로젝트에 큰 영향을 끼치는 비즈니스 이슈를 정의할 것이고, PM 혹은 기술 매니저라면 실제로 프로젝트를 구현하는 사람들을 일하게 만들기 위해 할 수 있는 모든 일을 할 것이다. 실제로 프로젝트를 구현하는 엔지니어들은 제품을 만들기 위해 필수적인 기술을 가지고 있으며 소비자 혹은 다른 이해당사자들은 요구사항을 정의할 것이다. 마지막으로, 이 소프트웨어를 실제로 사용할 사람들은 바로 최종 사용자다. ### Establish the Project Plan 계획을 수행하거나 지원하는 개인, 집단, 조직이 상호 이해와 헌신을 하기 위해서는 관련이 있는 모든 아이템이 있는 문서화된 계획이 필수적이다. 프로젝트를 위해 만들어진 계획은 프로젝트에 투입되는 노력의 모든 측면을 정의하며, 프로젝트 생명주기, 프로젝트 작업과 예산 및 일정, 마일스톤, 데이터 관리, 리스크 인식, 자원 및 기술 요구사항, 이해당사자들에 대한 인식과 상호작용, 인프라 구조에 대한 고려 등을 논리적으로 엮는다. ## Obtain Commitment to the plan 세번째 목표는 프로젝트에 참여하는 모두가 열의를 가지도록 하는 것이다. 효율적으로 일하기 위해서는 계획을 실현할 사람들의 헌신이 필요하다. 하위 프랙티스들의 관계는 아래 다이어그램의 녹색 영역과 같다. ![[ProjectProgrammingDiagram3.png]] 하위 프랙티스로는 총 세가지 프랙티스가 있다. 이제 이들을 살펴보자. ### Review All Plans that affect the project 다른 프로세스 영역에서 개발된 계획들은 보통 전체 프로젝트 계획에 필요한 것과 비슷한 정보를 가지고 있다. 프로젝트에 영향을 끼치는 모든 계획은 프로젝트를 성공적으로 이끌어야 하며, 따라서 범위, 목표, 역할, 관계 등에 대한 합의가 포함되어 있음을 반드시 확인해야 한다. 예를 들어... | Plan | Description | | ---------- | ------------------------------------------------------------------------------------ | | 구성 관리 계획 | 사용될 구성 관리 절차와 구조를 나타낸다. | | 배포 계획 | 소프트웨어와 관련된 하드웨어가 어떻게 소비자의 환경에 배포될 것인지를 나타낸다. 이 계획에는 기존 시스템에서 데이터를 옮겨오는 계획도 포함되어야 한다. | | 유지 계획 | 유지보수에 필요한 요구사항, 비용, 노동력 등을 예측한다. | | 품질 보증 계획 | 프로젝트에 사용될 품질 과정과 표준을 나타낸다. | | 검증(테스트) 계획 | 시스템을 검증하기 위한 방법, 자원, 그리고 일정을 나타낸다. | ### Adjust the project plan to reconcile available and estimated resources 이 프랙티스에서는 실제 가용할 수 있는 자원과 추산한 결과 필요한 자원을 다시 일치시키는 과정을 거친다. 프로젝트가 실제로 실현 가능하도록 관련된 이해당사자들의 지원을 이끌어내고 예상되는 자원과 실제 사용 가능한 자원 사이의 차이를 메꾸는 것이다. 이 과정은 요구사항을 바꾸거나 뒤로 미루기, 협상으로 자원을 더 얻어내기, 생산성을 높일 방법을 찾기, 외주, 직원들의 스킬 구성 바꾸기, 혹은 프로젝트나 프로젝트의 일정에 영향을 끼치는 모든 계획을 재검토하는 방법으로 이루어지곤 한다. ### Obtain Plan Commitment 계획을 실행하기 위해서는 이해관계자들의 참여 혹은 지원이 필요하다. 이를 위해서는 프로젝트 내부, 외부를 가리지 않고 관련된 이해당사자 전체와 상호작용을 하며 약속을 받아야 한다. 개인 혹은 집단은 계획에 대한 확신, 즉 작업이 산정된 비용, 일정, 제한조건 안에서 성공적으로 이루어질 수 있다는 확신이 필요하다. --- [^work-product-definition]: 소프트웨어 공학의 맥락 하에서는 소프트웨어 개발 주기*Software Development Life Cycle*의 모든 산출물을 작업물*work product*라 부른다. 비즈니스를 위한*Business-oriented* 산출물인 각종 문서나, 개발 과정에서 산출된 코드, 그리고 테스트를 위한 UI, 자동화 스크립트 등이 모두 작업물에 포함된다. [^corrective-action-definition]: 이미 일어난 부적합 사항이 다시 일어나지 않도록 취해야 하는 조치를 의미한다. [^size-attribute-estimation]: 크기*Size*는 제품 개발을 위해 투입해야 하는 노력, 비용, 일정을 추산하기 위한 주요 입력 데이터 중 하나다. 서비스 수준, 연결성, 복잡성, 허용성, 구조 등 다른 속성에 기반할 수도 있다. 추산 결과는 프로젝트의 요구사항과 같이 가야 하고 프로젝트에 투입될 노력, 비용, 일정을 결정해야 한다. 상대적인 난이도나 복잡도는 각 크기 속성에 할당되어야 한다. [^source-lines-code-metric]: Lines of Code라고도 부르며, 프로그램 소스 코드 텍스트의 줄 수를 세어 프로그램의 크기를 측정하는 지표다. [^team-velocity-agile]: Team Velocity. 애자일 방법론에서 팀이 스프린트당 처리하는 유저 스토리의 개수를 의미한다. [^staffing-hiring-process]: 정해진 규칙에 따라 직원을 채용하거나 유지하고 퇴출시키는 일련의 활동을 모두 포함하는 개념이다.