박종명의 아름다운 개발 since 2010.06

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=475

---

일정 개발의 기법 중 CCM(Critical Chain Method)라는 것이 있다

이는 각 활동 사이의 여유시간을 별도로 관리하여 일정을 타이트하게 운영하는 기법이다
이전에 살펴 봤던 CPM(Critical Path Method)을 통한 네트워크 및 일정 산출 방식은 동일하지만,
각 활동 사이의 여유 시간은 별도로 떼 내어서 필요시 여유시간을 적절히 공급하겠다는 원칙이다


다음과 같이 전체 일정안에서 각 활동을 수행하는 기간에 여유시간이 포함되어 있을 경우

여유시간을 각 활동사이에서 제거하여 별도로 모아서 관리하도록 하는 기법이다
이렇게 하여 불필요하게 노는시간(?)을 없애 프로젝트를 보다 타이트하게 운영하고자 하는 기법이다

눈치챘겠지만 이 기법은 관리자들이 만든 가장 최근에 등장한 기법이다
결론적으로 쉴 팀을 주지 않고 빡빡하게 일을 시키겠다로 해석될 수 있는데
이 기법에는 다음과 같은 이론이 뒷 받침 하고 있다

1) 학생 증후군(Student syndrome)
보통 학생들은 시험기간이 코 앞에 다가와야 벼략치기를 해서 최대의 집중을 발휘 한다
이렇듯 일이 닥치기 전에는 느긋함을 피우는 비효율적인 것을 예방하기 위해 CCM 기법이 만들어 졌다
그러나 이는 잘못하다가는 프로젝트를 지연시킬 수 있는 위험도 내포하고 있다

2) 파킨슨 법칙(Parkinson's Law)
모든 작업은 납기일을 준수한다. 역설적으로 말하자면 빨리 끝낼 수 있는 일이라도 납기일이 남았다면
천천히 수행하여 납기일만 맞춘다는 법칙이다

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=474

---

지금까지 프로젝트 일정을 산출하기 위한 사전 프로세스들에 대해 알아 보았다

활동정의, 활동 순서 부여, 활동 자원 산정, 활동 지속 기간 산정이 그 프로세스 들이다
이러한 사전 프로세스를 거치며 어떤 활동이 필요하며 이를 수행하기 위해 어떤 자원이 언제 필요하며
각 활동들간의 연관관계 및 개발 활동들의 소요 기간을 산정하였다

이제 이를 종합적으로 통합하여 프로젝트를 수행하기 위한 전체 일정을 산출하는 방법에 대해 알아보도록 하자

* CPM (Critical Path Method), 핵심 경로법
개별 활동들을 연결하여 '순방향 분석' 과 '역방향 분석'을 수행하여 각 활동의 시작일과 종료일 그리고 여유시간 및 전체 프로젝트 수행 기간을 산출하는 기법이다

* CP(Critical Path)
CPM에서 CP(Critical Path)는 핵심 주요 구간(경로)로써 각 활동들을 연결했을 때 수행 기간이 가장 긴 경로를 
나타내는데 이 구간은 여유시간이 0 이며 전체 프로젝트 소요 기간을 나타내므로 프로젝트 매니저가 가장
신경을 써야 하는 구간이다

다음의 그림을 보자
아래 표는 각 활동과 활동의 연관관계 그리고 개별 활동의 수행 기간까지 산정된 결과를 나타낸다

각 경로별로 수행기간을 계산 해 보면 다음과 같다
Path 1) start -> A -> C -> F -> end : 8일
Path 2) start -> B -> D -> F -> end : 6일
Path 3) start -> B -> D -> G -> end : 10일
Path 4) start -> B -> E -> G -> end : 13일

총 4가지 경로 중 가장 긴 수행 기간을 가지는 구간은 Path 4 가 된다
즉 Path 4 가 CP(Critical Path)가 되며 이는 곧 프로젝트를 수행하기 위한 총 소요시간이 되는 것이다
물론 프로젝트 매니저가 가장 신경을 써야 하는 구간이된다

참고로 위 표에서는 CP 가 1개 였지만, CP 는 경우에 따라 여러개가 될 수 도 있다
즉 최장기간이 동일한 구간이 여러개가 될 수 있다는 것이다
이렇게 CP가 많아지게 되면 프로젝트의 위험(Risk)이 올라간다

그리고 각 활동들의 수행 기간이 일부 변경되는 경우가 발생한다면 CP도 변경될 수 있으므로 주의깊에
살펴 봐야 한다
예를 들어 활동 D의 수행기간이 기존 2일에서 7일로 변경된다면
Path 3 일정이 총 15일이 되어 CP가 Path4 에서 Path3으로 바뀌게 된다

CP는 프로젝트 일정에 주의를 요하는 구간인 만틈 CP의 변경사항을 잘 파악하여 적절히 상황에 맞도록
프로젝트를 수행하여야 할 것이다


이제 순방향 분석과 역방향 분석을 통해 각 활동의 시작일과 종료일 그리고 여유시간을 산출해 보도록 하자

* 순방향 분석(Forward Scheduling)
Start 시점으로 부터 왼쪽 -> 오른쪽으로 계산하는 방식이다
ES(Early Start date): 빠른 착수라 해석하며 바로 앞 활동을 마친 후 착수 할 수 있는 가장 빠른 시점이다
EF(Early Finish date): 빠른 종료라 해석하며 ES 이후 활동이 완료되는 시점이다 

다음과 같이 활동(Activity)에 대한 기간 및 ES,EF를 표기하도록 한다

아래 그림은 각 활동들을 연결하여 ES 와 EF를 계산한 예시이다

1일 부터 시작하여 각 활동이 소요되는 기간을 더해 나가는 방식이다
활동 B의 경우를 보면, A 활동을 마친 후 빠르게 착수 할 수 있는 시점(ES)은 4일이 되겠다
그리고 4일, 시작 이후 B 활동을 마칠 수 있는 시점(EF)은 7일이 되겠다

이렇듯 '순방향 분석'을 통해 각 활동의 ES, EF를 계산할 수 있는 것이다
참고로 위 표에서 CP는 A->D->E->F->G 이며 프로젝트 총 소요시간은 18일이 된다


* 역방향 분석(Backward Scheduling)
순방향 분석과 반대로, End 시점으로 부터 오른쪽 -> 왼쪽으로 계산하는 방식이다
LF(Late Finish): 늦은 종료라 해석하며 바로 뒤 활동을 제때 시작하기 위해 본 활동이 종료되어야 하는 가장
                      늦은 시점을 말한다
LS(Late Start): 늦은 착수라 해석하며 LF 시점에 활동이 완료되기 위해 시작되어야 하는 시점을 말한다

다음과 같이 활동(Activity)에 대한 기간 및 LF,LS를 표기하도록 한다

아래 그림은 각 활동들을 연결하여 LF와 LS를 계산한 예시이다

End 일인 18일 부터 시작하여 활동이 소요되는 기간을 빼 나가는 방식이다
활동 F의 경우를 보면 G활동을 제때 시작하도록 하기 위해 종료되어야 하는 시점(LF)가 13일이 되겠다
그리고 13일에 활동이 종료되기 위해 이 활동이 시작되어야 하는 시점(LS)은 12일이 되겠다

이렇듯 '역방향 분석'을 통해 각 활동의 LF, LS를 계산할 수 있는 것이다

* 여유 시간
여유 시간은 말 그대로 프로젝트 수행 기간 동안 여유를 부릴 수 있는 시간을 말한다
CP 구간은 여유 시간이 0, 즉 여유가 하나도 없는 구간이라 했다
그러나 CP 구간을 제외한 경로에서는 여유 시간이 나올 수 있다

여유 시간은 다음과 같이 두 가지가 존재한다

1) Total Float (TF)
Slack Time 이라고도 하며, 프로젝트 납기일을 지연시키지 않으면서 각 활동이 가질수 있는 여유시간을 말한다
공식: TF = Min {LS-ES , LF - EF}. 즉 LS-EF 와 LF-EF 값 중 작은 값이 TF가 된다
CP(Critical Path) 구간은 은 TF가 0인 구간이다

TF > 0 경우에는 일정에 여유가 있는 것이며 TF = 0 은 일정 여유가 없는 CP 구간임을 의미한다

2) Free Float (FF)
후행(직후) 활동의 착수일(ES)를 지연시키지 않으면서 선행(직전) 활동이 가잘수 있는 여유시간을 말한다
공식: FF = EF - 직후 ES


TF와 FF는 다음과 같이 표기한다

TF와 FF 의 계산 공식을 도식화 해 보면 다음과 같다

아래 그림은 위에서 계산해 왔던 일정을 토대로 TF와 FF를 계산한 결과이다

지금까지 CPM(핵심경로법)을 통해 프로젝트 전체 일정은 물론이고 각 활동의 시작일/종료일을 산출할 수 있었으며
CP구간을 파악하고 프로젝트 수행 중 여유시간(TF,FF)를 도출하는 방법에 대해 알아 보았다

이렇게 산출된 일정이라 할 지라도, 일정을 단축해야 하는 이슈가 발생할 수 있다
PMI 에서는 프로젝트의 스펙(범위)를 변경하지 않고 프로젝트 일정을 단축하기 위한 방법으로 다음과 같은 기법이
제시된다

* 일정 단축 기법
1) Crashing
크래싱이라 발음하며 자원과 비용을 더 투입하여 일정을 단축시키는 기법이다
Crashing 는 프로젝트 전체 구간 중 CP(Critical Path) 구간에 자원을 먼저 할당하여 프로젝트 전체 일정을 줄이는
기법이다. 단 이 기법은 프로젝트 원가가 상승한다는 단점이 존재한다

2) Fast tracking
순차적으로 진행되는 활동들의 연관관계를 병렬로 작업함으로써 일정을 단축시키는 기법이다
통산 소프트웨어 프로젝트에 많이 사용되는 기법(밤샘?)이며 이는 프로젝트위 리스크가 증가할 수 있으며
재 작업 해야 하는 가능성이 있다는 단점이 있다

이 글은 제가 과거에 운영했던 사이트인 http://mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=473

---

이전 글에서 일정관리를 위한 두 가지 프로세스를 정리 했었다

간략히 요약하자면,
범위관리에서 범위기술서를 분할한 WBS(WBS Package)를 다시 분할하여 활동(Activity)을 정의하고
이렇게 정의된 활동들의 연관관계 및 의존성을 식별하여 Project Schedule Network Diagram을 도출하였다

이 다이어그램의 표기방식으로는 PDM(Precedence Diagramming Method), ADM(Arrow Diagramming Method),
CDM(Conditional Diagramming Method)의 3가지 종류가 있었다. 이 중 많이 사용되는 기법이 PDM이다

이제 이 글에서는 하나의 활동(Activity)를 수행하기 위해 소요되는 기간(일정)을 산출하는 방법에 대해 알아 보자

그에 앞서 어떤 작업을 수행하기 위해 어떤 사람이 몇 명이나 필요할까? 또는 어떤 자원이 투입되어야 하는가?
에 대한 정의를 해야 할 것이다. 이러한 자원에 대해 정의하는 프로세스가 '활동 자원 산정' 이다

활동 자원 산정(Activity Resource Estimating)
각 활동 수행에 필요한 자원의 유형과 양(어떤 자원을 언제, 얼만큼 사용 할 것인지)을 산정한다

이 과정에서는 어떤 자원이 언제 필요하다라고 명시한 '활동 자원 요구사항'을 도출하고 '자원 달력'을 수정,
갱신하게 된다. 자원 달력은 근무일/휴일, 각 일자별 특정 인적/물적 자원의 가용현황을 결정 및 표시하는 수단이다

활동이 정의되고 활동에 필요한 자원이 산정되면 이제 본격적으로 개별 활동에 대한 소요 기간을 산정하게 된다

활동 지속 기간 산정(Activity Duration Estimating)
개별 활동들의 작업기간을 산정한다. 이 과정에서 정량적인 기간 값이 결정된다
기간을 산정, 추정하기 위해 여러 기법이 도입될 수 있는데, 통상 모든 추정의 기법이 되는
전문가 판단, 하향식 추정, 상향식  추정, 유추 추정, 모수 추정 기법이 사용될 수 있다

이러한 추정 기법에 대한 내용은 다음에 차근차근 알아 보도록 하고,
여기서는 일정 관리 분야에서 널리 알려진 PERT에 대해 알아 보자 

* PERT (Program Evaluation Review Technique)
'퍼트'라고 발음한다
3가지 추정치를 이용해 일정을 산정한다고 하여 3점 추정치(Three-point Estimating)라고도 한다
3가지 추정치란 비관치(p),최빈치(m),낙관치(o) 를 말한다

p (Pessimistic) : 비관치, 비관적 추정치, 최악의 일정(일정을 최악으로 길게 잡는다)
m (Most likely) : 최빈치, 가장 가능성이 높은 일정
o (Optimistic)  : 낙관치, 가장 좋은 일정, 가장 짧은 일정

이 세가지 값이 추정되면 다음의 공식으로 Mean(평균) 값과 Sigma(표준편차)를 계산한다
Mean(평균)        = (p + 4m + o) / 6
Sigma(표준편차) = (p - o) / 6

이렇게 계산된 Mean(평균)값으로 활동의 소요기간을 도출할 수 있으며,
이렇게 도출 된 평균과 Sigma(표준편차)를 이용하면 달성 확률을 계산 할 수 있게 된다

Sigma(표준편차)는 평균값으로부터 벗어난 정도를 보여주는데,
다음과 같이 신뢰도를 평가하게 된다. 신뢰도란 정규분포에서 표준편차에 따른 확률값을 말한다
Mean +- 1sigma = 68%
Mean +- 2sigma = 95%
Mean +- 3sigma = 99%


공식만 봐서는 이게 무신 말인고 싶다. 간단한 예를 보도록 하자

문) 어떤 작업의 수행기간을 PERT 기법을 이용해 기간을 산정하고 있다.
이 작업에 대한 3가지 추정치는 다음과 같다
p: 36일
m: 21일
o: 6일
이때 이 작업의 수행기간은?

답) 공식에 대입해 보면,
Mean = (36 + 4*21 + 6) / 6 = 21 , 즉 수행기간은 21일이 되겠다

문) 위 작업이 11일에서 31일 내에 끝마칠 수 있는 확률은 얼마나 되는가?

답) 달성확률을 알기 위해서는 Sigma(표준편차)를 계산해야 한다
Sigma = (36 - 6) / 6 = 5, 표준편차는 5일이 된다

이제 신되로 공식에 의거하여, 평균과 표준편차를 이용해 11일에서 31일 내에 마칠 수 있는 확률을 계산해 보자
Mean : 21일
Sigma: 5일

11일 에서 31일은 Mean += X*sigma 공식에 Mean 값과 Sigma 값을 대입해 보면 
11일 = 21 - X * 5 => X는 2가 된다
31일 = 21 + X * 5 => 역시 X는 2가 된다

결과적으로 Mean +- 2sigma 영역에 있으므로 95% 라는 확률 값을 얻을 수 있다
작업을 즉 11일에서 31일 사이에 달성할 수 있는 확률은 95%가 된다

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=472

---

프로젝트 수행에 있어 아주 중요한 부분이 시간 즉 일정관리 일 것이다

PMI에서도 프로젝트의 3대 제약사항으로 범위,시간(일정),원가(비용)을 꼽고 있다
이 세가지가 만족했을때 프로젝트 결과물에 대한 품질이 보장된다고 하였다

그럼 지금부터 PMI에서 정의한 시간관리의 프로세스를 살펴보도록 하자

활동(Activity) 정의
프로젝트를 착수할 때 '예비프로젝트 범위 기술서'를 정의해야 한다
이 말은 구체적인 프로젝트 스펙을 처음부터 다 정의할 수는 없지만 무슨 일을 해야 한다는 정도의
추상적인 스펙이 나와야 하는데 이를 정의하는 것이 '예비프로젝트 범위 기술서'라 한다

그리고 난 후, 실질적인 프로젝트 범위에 대한 기획단계에서 스펙을 기획,정의하여 범위기술서를 정의하며
이를 더욱 분할,구체화시킨 것이 WBS명세서이다.
또한 WBS를 다시 한번 세세하게 분할한 것이 WBS Package 라 한다

당연하겠지만, 시간관리 즉 일정을 산출할때 가장 중요한 근간이 되는 것이 바로 프로젝트 범위이기 때문에
범위관리에서 산출된 범위기술서,WBS,WBS Package 가 일정산출에 중요 근간 자료가 된다

범위를 구체적으로 정의하고 세부적으로 분할한 WBS(WBS Package)를 더욱 분할하여 '활동(Activity)'을 정의한다
WBS에서 정의된 각각의 세부 범위를 수행하기 위한 활동을 파악하고 정의하는 것이다

지금까지 이야기한 내용을 그림으로 나타내면 다음과 같다

활동 순서 부여
이렇게 하여 활동이 정의되면, 각 활동들 간의 연관관계를 파악해야 한다
이를 '활동순서부여'라 하는데 정의된 활동들간의 관계를 파악하고 각 활동의 순서를 부여하는 것이다

이때 사용되는 기법이 Project Schedule Network Diagram 인데 이는 다음과 같이 나우어 진다
각 활동을 표현하고 활동들간의 연관관계(의존성)을 표현한 다이어그램 표기 기법이라 할 수 있다

1) PDM(선후행 도형법, Precedence Diagramming Method)
각 활동을 노드(node) 위에 표시하고 화살표로 각 활동의 의존관계를 표현한다
노드에 표현된다고 하여  AON(Activity-on-node)라고도 한다
PDM을 이용하면 각 활동들간의 연관관계를 4가지 형태로 표현할 수 있다
- FS(Finish-to-start)
  말그대로, 앞의 작업이 끝나야 뒤 작업을 시작할 수 있는 개념
- FF(Finish-to-finish)
  앞으 작업을 마쳐야 뒤 작업도 마칠 수 있는 개념
- SF(Start-to-finish)
  앞의 작업을 착수해야 뒤 작업을 마칠 수 있는 개념
- SS(Start-to-start)
  앞의 작업을 착수해야 뒤 작업을 시작 할 수 있는 개념

2) ADM(연결선 도형법, Arrow Diagramming Method)
각 활동을 노드가 아닌 화살표(arrow)위에 표현한다
화살표에 표현된다고 하여 AOA(Activity-on-arrow)라고도 한다
ADM으로는 각 활동들의 연관관계 중 FS(Finish-to-start)만 표현 가능하다
기타 연관관계가 필요하면 Dummy Activity(점선)으로 표현할 수 있다

3) CDM(조건부 도형법,Conditional Diagramming Method)
이는 마치 각 활동의 관계를 프로그래밍 처럼 조건에 의해 순환(loop),분기(if)되는 구조를 표현한다


아래 그림은 소프트웨어 프로젝트에서 Project Schedule Network Diagram를 표현한 예시인데,
PDM으로 표현한 것이다.

중요한 것은 Project Schedule Netowrk Diagram 에서는 활동과 활동들간의 연관관계만 표시하지,
소요되는 시간 및 기간정보는 표현하지 않는다는 점이다.

프로젝트의 일정개발은 각 활동을 수행하기 위해 소요되는 자원(리소스)를 산정하고 개별 활동의 기간을 개개별로
산정하여 일을 통합함으로써 완성된다

경우에 따라서는 각 활동들의 연관관계를 보다 세밀하게 정의하기 위해서 선도 및 지연을 정의할 수 있다

Lead(선도)는 FS(Finish-to-start)관계, 즉 앞의 활동이 완료되어야 뒤의 활동을 시작할 수 있는 관계를
조정하여 앞의 활동이 진행 중일때 뒤의 활동을 시작하여 일정을 단축시키는 개념이다

Lag(지연)은 반대로 FS관계에서 앞의 활동이 끝난 후에 일정기간이 지난 뒤 뒤의 활동을 시작하는 개념이다

이 글은  제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=449

---

프로젝트 관리에서,
주어진 일정과 오픈 예정일은 아주 민감한 부분이죠.

'인간사'에서도 약속을 잘 지켜야 하듯이,
프로젝트도 약속을 잘 지켜 적시 완료를 보장해야 기본을 한 것 이겠죠 

PMBOK 의 프로젝트 관리 9대 지식영역 중, '6.1 시간관리'에 대해 정리합니다.
내용이 방대하지만 나름 핵심만 정리해 봅니다

6.0 시간관리 

* 프로세스 매핑표

 * 일정기획(계획)은 ‘4.0통합영역’ 기획 프로세스그룹의 ‘4.3 프로젝트관리계획개발’ 프로세스에 선행됨

* 시간관리 도식화