PM(Project Management) 에 대해 알아보자

프로젝트란 무엇인가?
- 제한된 시간 안에 한정된 자원으로 목표로 하는 일을 완수해야 하는 작업을 프로젝트라 한다.

프로젝트는 일반적으로 4가지 특성이 있다.
첫번째는 유일성이다. 프로젝트 결과물은 이전 다른 프로젝트와 똑같은 결과물이 나올 수 없는 유일한 것이다.
두번째는 일시성이다. 프로젝트는 시작과 끝이 분명한 특성이 있다.
세번째는 목적성이다, 프로젝트는 반드시 달성하고자 하는 목적이 있다.
네번째는 점진적으로 상세화 한다. 프로젝트는 처음에는 추상적이었다가 시간이 지나면서 점차 구체롸되는 특징을 가지고 있다.

프로젝트 생명주기?
프로젝트 시작 - 관리 - 분석 - 설계 - 개발 - 완료 - 운영 - 종료

프로젝트에 대한 계약이 완료되면 수주사는 이에 대한 계획을 '프로젝트 관리 계획서' 라는 문서에 담아 발주사에 제출한다. 프로젝트 관리 계획서에는 비용을 어떻게 쓰고 인력관리를 어떻게 할 것이며, 시간을 어떻게 나누어서 관리할지에 대한 상세한 계획이 들어가게 된다.

수주사에서 프로젝트를 본격적으로 진행할 때 가장 먼저 하는 것이 '요구사항 분석' 이다. 고객이 무엇을 원하는지를 제안 요청서, 제안서, 그리고 업무에서 사용하는 문서를 분석하고 고객과의 인터뷰를 통해 알아낸다. 이후에 '프로젝트 설계 - 개발 - 운영 단계로 넘어간다.

PMBOK(Project Management Body of Knowledge)
PMBOK은 프로젝트 관리에 대한 용어와 가이드 라인을 제시하는 표준이다, PMI라는 국제 비영리 기구에서 문서화를 담당하고 있고 PMP 자격증을 주관하고 있다.

PMBOK에서는 프로젝트 관리를 공정관리, 예산관리, 품질관리와 같이 3대 관리 요소로 나누고 계획, 조직화, 인력확보, 지휘, 통제라는 5대 관리 구성으로 분류하고 있다. 프로젝트 관리 지식 분야는 통합관리, 일정관리, 품질관리, 범위관리, 위험관리, 원가관리, 인력관리, 의사소통관리, 조달관리 10개 영역으로 구성된다.

범위, 비용, 일정은 프로젝트의 가장 핵심적인 요소이다.

프로젝트의 애플리케이션 개발 비용산정 기법은 2가지가 있다.
1. M/M(Man Month) : 투입 인력 중심, 전체 투입 인력 단가를 중심으로 산정
  - M/M은 1개월 동안 몇명의 인력이 필요한지 나타내는 단위이다. 2M/M이라 표기하면 1달에 2명이 투입되거나 1명이 2달 동안 투입된다는 의미이다. 현재 견적서에서 가장 많이 사용하는 방식이다.
2. FP(Functionbn Point) : 기능 중심으로 산정, 구현해야 할 기능의 종류와 난이도를 계산해서 산정
  - FP는 시스템이 가지고 있는 기능을 분석하고 기능별로 점수를 계산해서 비용을 산출하는 방식이다. FP는 시스템의 기능을 알고 있어야 하므로 신규 시스템을 구축할 경우 개념 설계가 완료되어야 작성할 수 있다. FP는 개념설계가 이루어져야 하므로 프로젝트 구축 전에 작성하기 보다는 프로젝트 구축 후에 작성해서 유지보수 비용이나 시스템을 재구축할 때 비용 산정 기초자료로 활용하는 것이 좋다.
  - M/M보다 정량적(객관적)으로 규모를 산정할 수 있다는 장점이 있지만, 시스템에 대한 깊은 이해를 필요로 하기 때문에 산업계에서 널리 사용하고 있지는 않다. 그래서 업체에서 FP 기반 견적서를 의뢰하면 기능점수를 산출해서 견적을 주기는 하지만, 정확한 기능점수를 산출하기 보다는 M/M 기반으로 산출한 금액을 다시 FP로 역산해서 보내주는 경우가 대부분이다.

 프로젝트는 '분석', '설계, '개발', '테스트' 단계로 구성된다. 업무를 단계별로 나누고 어떤 업무를 어떤 순서로 해야 하는지 미리 정하는 업무가 바로 '프로젝트 관리 업무' 이다. 또한 업무를 수행할 인력과 등급을 결정하는 것도 관리 업무에 포함된다. 프로젝트의 시작부터 끝까지 프로젝트가 잘 진행될 수 있도록 계획하고 지원하는 모든 업무를 프로젝트 관리라 할 수 있다. 축구에 비교하면 감독 = PM, 주장 = PL, 선수 = 설계자/개발자 라고 할 수 있다.

폭포수 모델이란 분석, 설계, 개발, 테스트의 전 과정을 차례로 접근하는 방식이다. 폭포수 모델은 전체 과정이 이해하기 쉽고 관리가 편리하다는 장점이 있지만 초기에 완벽한 요구사항 정의가 어려우므로 프로젝트 후반부로 갈수록 문제가 많아지는 단점이 있다.

<애자일 개발 방법론>

애자일 방법론은 절차보다는 사람을, 문서보다는 작동하는 소프트웨어를, 미리 철저하게 계획하기 보다는 변화에 민첩한 대응을, 계약과 협상에 얽매이기보다는 고객과의 협력을 중요하게 생각한다.

애자일 방법론은 먼저 개발 범위 안에 있는 요구사항을 분석해 우선순위가 높은 요구사항을 먼저 개발한다. 개발한 부분까지 실행해서 보여주고 고객의 평가를 받아 요구사항과 개선사항을 반영해 다음 요구사항 개발에 참고한다. 

애자일은 특정한 방법론을 지칭하는 것이 아니라 애자일(민첩)하게 개발하는 다양한 방법론을 통칭하는 것이다. 애자일 방법론에는 XP(eXtreme Programming), SCRUM, FDD, Crystal 방법론 등이 있다. 
XP 개발 방법론은 개발 우선순위를 정하고 가장 시급한 부분부터 개발을 시작한다. 개발을 시작할 때 맨 처음 개발하는 것이 사용자 스토리다. Use Case는 고객에게 필요한 것이 무엇인지 기술한다. 이는 개발시점에는 요구사항 명세서의 역할을 수행하고 테스트할 때는 테스트 시나리오를 제공해 준다. 다음으로 스파이크를 개발한다. 스파이크는 불확실성을 제거하기 위한 일종의 프로토타입과 비슷한 역할을 수행한다고 보면 된다. 이후 배포 진행함

범위와 일정을 관리하는 WBS(Work Breakdown Structure)의 경우에는 중요도가 높고 변경의 빈도가 잦기 때문에 관리 계획서와 별도로 관리되는 경우가 많다. WBS는 프로젝트에서 수행되어야 할 작업을 관리 가능한 단위(2주)로 나누고 순서를 정해 담당자가 할당되어 구조화된 체계를 말한다. WBS는 범위관리에도 사용되지만 일의 순서를 잘 지정해 놓으면 가장 길이 긴 업무가 프로젝트 전체 일정이 되므로 일정관리에도 사용할 수 있다. WBS는 지속적으로 수정이 이루어 지므로 'MS Project'가 가장 많이 사용되는 프로그램이다.

프로젝트 범위는 WBS(Work Brerakdown Structure)와 요구사항, 이 두 가지와 밀접한 관련이 있다.
WBS는 프로젝트에서 해야 할 일을 최상위 단계에서 하위 단계로 분할하여 산출물 중심으로 정리한 것으로서 계획 대비 진척을 관리하기 위한 핵심이다. 요구사항은 초기에 모호할 수 있고 변경 가능성이 있지만 가급적 구체적으로 정리해야 한다. 
가급적 2주 이내로 관리 가능한 Task로 일정계획이 구체적이어야 한다. 납기일을 고려하여 역산으로 일정을 세우지 말고 포워드 방식으로 하라(현실성이 없기 때문). 분석 단계는 쉬는 단계가 아니므로 너무 짧게 잡지 말것(선행단계가 후행 단계보다 중요하다). 프로젝트 오픈 이후 안정화 기간을 계획기간에 반영하라.

폭포수 모델/반복형 모델, 반복형 모델은 크게 점진적 모델과 진화적 모델로 구분할 수 있다. 점진적 모델은 기능 묶음별로 단계별로 개발하여 통합하는 방식이다. 진화적 모델은 소프트웨어를 릴리스 할 때마다 기능의 완성도를 업그레이드 하는 방식이다. 

[요구사항 분석]

요구사항은 해결되어야 하는 문제를 정의한다. 시스템은 어떤 목적을 위해 필요한 모든 것을 정의할 뿐이지 문제를 해결하는 솔루션을 정의하는 것이 아니다. 요구사항은 무엇이 구현되어야 하는지에 대한 명세이다.

요구사항 분석은 모든 이해관계자가 이해할 수 있게 요구사항을 정제하고, 요구 사항의 누락이나 오류 등이 있는지 부족한 부분이 있는지를 세밀하게 검토하는 것이다. 요구사항 분석에는 상위 요구사항을 적절한 수준으로 분해하고 구체화하고 우선순위를 평가하는 것 등이 포함된다. 이러한 요구사항 명세는 시스템 구현의 베이스라인으로서 관리된다.