여기에 적는 내용의 출처는 거의 모두 이곳입니다.

EPF는 아래에 적은 Open Unified Process 방식을 이클립스에서 사용할수 있도록 해주는 Plug-in 입니다.
EPF의 Tutorial 중의 하나가 내용이 너무 좋아서 좀 설명과 함께 인용해보려고 합니다.

MS 오피스 기능중의 하나로 Project라는 것이 있습니다.
OutLook 이랑 연동되면서 스케쥴 관리를 해주는 프로그램입니다.
사실 기능이 꽤 복잡해서 책한권을 사서 보고나서야 좀 어떻게 돌아가는지 이해가 가는 식입니다.

근데 책도 보고 좀 시간도 투자해가면서 다 배우고 나서 보면 아시겠지만,
이게 소프트웨어 프로젝트 관리하는데에는 별로 적합하지가 않습니다.
MS Project 안에 보면, "자원관리"라는게 있는데 여기서 자원이라는 것은 시멘트 몇그람, 자동차 몇개 이런식입니다.
소프트웨어 개발에서는 이런 종류의 물리적 자원은 사실상 거의 관리할 일이 없지요.

그리고 최근 떠오르고 있는 Agile 개발 방법론은 기존의 다른 프로젝트 관리 방법과는 근본적으로 다르기 때문에 MS Project로 게임 개발을 관리할려고 하는 것은 별로 현명한 방법이 아니라고 생각합니다.

이런 문제를 일찍이 파악한 Rational 에서는 Rational Unified Process 라는 Agile 방식의 프로젝트 관리 패턴을 개발했습니다. 그리고 그것을 오픈 소스 커뮤니티에서 일부 차용해서 만든 것이 Open Unified Process (이하 OpenUP) 이고 이 방법론을 소프트웨어적으로 지원해주는 프로그램이 EPF (Eclipse Process Framework)가 되겠습니다.

그럼 OpenUP 는 뭐가 어떻게 다른가? 프로젝트를 어떻게 관리한다는 건가? 하는 것이 EPF 홈페이지에 이미 잘 설명되어있습니다.

1단계 - 프로젝트 계획
아래의 그림을 보시면 왼쪽의 검은 점이 지금 프로젝트가 있는 위치 입니다. 우측의 검은 점이 기획자 혹은 '갑' 혹은 소비자들이 원하는 소프트웨어입니다. 다시 말해서 왼쪽 지점에서 우측 지점으로 프로젝트를 진행 시켜 나가는 것이 소프트웨어를 개발하는 과정인것이고, 그 과정에서 프로젝트 메니져는 조타수 역활을 잘해서 최대한 직선 단거리로 이동하도록 관리하는 것이 임무입니다.
여기에서 OpenUP는 4가지 단계를 제시 합니다. [시작], [정교화], [코딩], [완료]. 번역이 제 멋대로 좀 이상하기는 하지만, 아무튼 이렇게 4가지 단계를 제시 합니다.
그리고 그 4가지 단계는 다시 1주일 단위의 주기(iteration)를 단위로 관리 됩니다. 위의 그림에서는 그 주기가 6개 밖에 표시가 안되어있는데, 그 말은 6주 만에 끝나는 프로젝트라는 말이 되겠습니다. ㅡ.ㅡ;;;; 1년에 대략 50개 정도의 주기를 갖는다고 생각하시면 되겠네요.

여기에서 4단계안에 있는 각각을 구체적으로 설명하면 너무 길어지기 때문에 생략하겠습니다.


2단계 주기(iteration) 계획
프로젝트의 전체 형태 계획이 끝나면 이제 각 주간 일정, 즉 주기(iteration)을 계획할 차례입니다.
여기에서부터 좀 특이해집니다.

위의 그림을 보시면 [작업 리스트(Work Item List)]라는게 있습니다. 이것은 프로그래머가 해야할 일들의 리스트입니다. 물론 이 [해야할일]이라는 것은 소비자 혹은 기획자가 요구한 요구 사항으로 부터 파생되어 나온것들입니다.

이 작업 리스트는 [우선순위]를 갖는데, 핵심 기능에 속하는 것들에 우선 순위를 높여서 먼저 처리합니다. 위험 요소가 높은 작업일수록 우선 순위를 높여서 먼저 끝내도록 하라고도 되어있습니다. 이유는, 위험 요소를 프로젝트 초반에 처리하는 것이 후반에 처리하는 것보다 안전하다는 점 때문입니다.

만약 한개의 작업이 너무 사이즈가 크면 여러개로 쪼갭니다. 쪼개서 새로 생겨난 작업들은 다시 작업 리스트에 들어가고, 아무 때든 작업 리스트에서 필요없어진 것들은 지워버릴수 있습니다.

또, 각각의 작업은 [크기(size)],[속도(Velocity)], [예상 노력(Effort)]의 3가지 값을 갖습니다. 크기는 해당 작업이 다른 작업들과 비교했을때 상대적으로 얼마나 큰가 작은가를 나타내는 것이고, 속도는 얼마나 빠른 속도로 이 작업이 처리되는가, 다시 말해 쉬운 일이어서 속도가 빨리 끝나는 작업인가 아니면 난이도가 높아서 시간이 많이 걸리는 녀석인가를 나타냅니다. 예상 노력이라는 것은 몇시간 짜리 작업인가를 예측하는 값입니다. (시간 단위 혹은 날짜 단위)

이렇게 작업 리스트를 가지고 있으면 이제 매주 새로운 주기(iteration)이 시작될때마다 위에서 부터 차례대로 몇개나 끝낼것인가를 계획합니다.

요렇게 할일을 정하고나면 (저는 이것이 상당히 중요하다고 생각하는데) 작업이 완료되었는지를 확인할 수 있는 테스팅 프로그램을 먼저 작성합니다. 다시 말해 TDD 방식으로, 테스팅 코드를 먼저 작성하고 실제 코딩을 나중에 하는 것입니다. 그러면 주기가 다 끝나기 전에도 매일 매일 작업이 얼마나 진행되고 있는지 쉽게 확인할수 있습니다.
한가지 여기 자료에서 설명이 잘 안되어있는 부분을 제가 보충하자면, 프로젝트 진행 초기에 기획자나 소비자로부터 [요구사항(Requirements)]을 전달 받고 나면, [Use case Model]이라는 것을 만들게 됩니다. 이것은 흔히 짝대기 인간(Stick man)이 등장하는 UML 모델을 생각하시면 되겠습니다. 하지만 Use case Model로는 부족하고 여기에서 더 나아가서 각각의 Use case 를 구체적으로 한단계 한 단계씩 설명하는 [Use cases]를 또 만들어 내야 합니다. 예를 들어, 인터넷 뱅킹 시스템을 만든다고 하면, Use cases 의 로그인 항목은 이런식이 되겠습니다.

• 1. 웹 브라우져에 주소를 입력한다.
• 2. ID를 입력한다.
• 3. 암호를 입력한다.
• 4. [로그인] 버튼을 클릭한다.

이렇게 하나 하나 단계별로 명확히 절차적인 설명서를 만들고 나면, 이것을 기반으로 Test case를 만드는 것은 어려운 일이 아닙니다.

UML을 도입한 설계 과정에서 Use cases 개발은 매우 큰 비중을 차지하는 중요한 과정인데, 그 Use case 의 특성상, 이게 Test case로 전환하는게 매우 쉽기 때문에 TDD(Test Driven Development)와 UML 이 Use case 를 중심으로 매우 긴밀하게 연관되는 것입니다.

사실 Use case가 얼마나 강력한 요구사항 분석 방법인지를 여기에서 다 설명할 수가 없습니다. 다음에 기회가 되어서 다시 설명할수 있었으면 좋겠네요... 흔히 하는 오해는 Use Case Model과 Use cases를 혼동하는 것입니다. 위에 있는 그림은 Use cases 가 아니라 Use Case Model 입니다. 이 모델 안에 나열되어있는 각각을 다시 세부적으로 파고 들어서 절차적으로 하나 하나 말로 표현하는 것이 Use cases 가 되겠습니다.


3단계 - 각 작업에 대한 코딩
주기(iteration)단의로 할일을 정했으면 이제 매일 매일 할일을 정합니다.
다시 말해 코딩을 시작하는 것이죠.
여기에도 몇가지 유용한 트릭들이 있는데, 매일 매일 서서 하는 회의을 짧게 갖을 것을 권하고 있습니다. 서서 하기 때문에 다리가 아파서 오래하지 않는다는 좀 우스운 방식입니다. 이 회의에서는 매일 매일 진행과정을 보고 하는 것인데, 여기에서 [평가]는 하지 않습니다. 평가는 그 주기가 끝나는 시점에서 하도록 권하고 있습니다.

그래서 최종적으로 아래 그림과 같이 처음 계획한 직선 형태로 프로젝트가 진행되지는 않더라도 매 주기마다 메니져가 프로젝트 진행 방향을 관리하기 때문에 완전히 어긋나지 않고 제 갈길을 찾아간다는 이야기입니다.
대충 이정도가 OpenUP를 사용해서 프로젝트를 진행하는 방법입니다.
구체적인 소프트웨어 사용법도 설명이 잘 되어있지만 여기에서는 생각합니다.