WBS (Work Breakdown Structure)에서 정의한 활동을 달성하기 위해 구체적인 활동 식별
🌱 프로젝트에서의 활동 (Activity) 관리 측면에서 진행 상황을 판단할 수 있도록 가시적 산출물을 생산하도록 조직되어야 함.
🌱 Milestones (이정표) 프로젝트 진행 과정에서 중요한 이벤트 또는 활동의 완료 시점
🌱 Deliverables (산출물) 고객에게 제공되는 프로젝트 결과물
2. 활동 순서 정의(activity sequencing)
활동 간의 논리적인 순서 관계를 정의
3. 활동 자원 추정(activity resource estimating)
개별 활동의 수행을 위해 필요한 자원을 추정
4. 활동 기간 추정(activity duration estimating)
개별 활동을 완료하기 위해 필요한 작업 기간을 추정
5. 일정 계획 수립
개별활동의 순서, 기간 및 필요한 자원 등을 분석하고 개발 프로세스를 이루는 활동을 파악하여 순서와 일정을 정하는 작업
🌱 PERT/CPM 차트 Program Evaluation and Review Technique/Critical Path Method 세분화된 작업을 효율적으로 일정 관리하고 지원하기 위한 기법이다. 관리에 대한 작업도 포함 가능하다. 작업시간을 정확하게 예측할 필요가 있다.
장점 관리자의 일정 계획 수립에 도움이 된다. 프로젝트 안에 포함된 작업 사이의 관계가 표현된다. 병행 작업을 계획할 수 있다. 일정 시뮬레이션이 가능해진다. 일정 점검과 관리가 가능하다.
절차는 다음과 같다.
1. 산출물 생산에 소요되는 작업 결정
2. 작업 예상 시간 결정
3. 선행 작업 파악 : 작업의 종속 관계(선후 관계) 파악
위를 바탕으로 PERT/CPM 차트를 그릴 수 있다.
🌱 임계 경로(Critical Path) 구하기
임계경로란 Pert Chart에서 소요 시간이 가장 긴 경로를 말한다. 프로젝트를 완수하기 위해 필요한 최소 시간(minimum time)을 나타낸다.
🌱 간트(Cantt) 차트
활동 별로 작업의 시작과 끝을 나타낸 그래프
가로축은 시간, 세로축은 작업, 마름모 표시는 milestore, 파란색 막대는 여유시간을 뜻한다.
계획 대비 진척도를 표시한다.
개인별 일정표이다.
🌱 애자일 일정 계획
스토리카드 단위의 일정 계획을 말한다.
사용자 스토리, 점수(유스케이스 개발에 소요되는 노력), 비즈니스 우선순위, 연관된 스토리 등을 기록한다.
6. 일정 통제
계획 대비 일정 차이를 모니터링하여 필요한 조치를 취함.
📁 프로젝트 인적 자원 관리
프로젝트에 이상적인 사람(ideal people)을 선정하지 못할 가능성이 있다.
프로젝트 예산으로 인해 고임금 인격의 채용이 어려울 수 있고, 적절한 경험이 있는 인력이 제공되지 않을 수 있으며, 조직은 소프트웨어 프로젝트를 통해 직원들의 역량이 개발되기를 원한다.
관리자는 특히 훈련된 인력이 부족할 때 위와 같은 제약조건 내에서 일할 수 있는 능력을 갖춰야한다.
조직(팀)의 구성은 결과물 및 소프트웨어 개발 생산성에 큰 영향을 끼친다.
역할과 책임 배정
조직 관리
조직 선택에 영향을 주는 요소는 작업의 특성과 팀 구성원의 의사 교류 횟수이다.
소프트웨어 개발 팀 구성은
계층형 팀
에고리스(egoless) 팀
책임 프로그래머 팀
🌱 계층형 팀
초보자와 경험자를 분리한다.
프로젝트 관리자와 고급 프로그래머에게 지휘 권한이 주어진다.
의사 교환은 초보 엔지니어나 중간 관리층으로 분산된다.
장점
- 소프트웨어의 구조가 계층적으로 잘 나누어진 경우에 적합하다.
- 대규모 프로젝트의 경우 여러 계층으로 구성
단점
- 기술 인력이 관리를 담당
- 의사 전달 경로가 김
🌱 Egoless 팀
민주주의 방식 의사 결정
서로 협동하여 수행함
자신의 일을 알아서 수행
구성원이 동등한 책임과 권한
장점
- 작업 만족도 높음. 더 적극적으로 임하고 문제에 책임감을 느낌
- 의사 교류 활발
- 복잡하고 이해되지 않는 문제가 많은 장기 프로젝트에 적합
단점
- 책임이 명확하지 않은 일이 발생
- 대규모 프로젝트에 적합하지 않음.
- 의사 결정 지연 가능.
🌱 책임 프로그래머 팀
작은 팀으로 구성되고, 책임 프로그래머가 통제한다.
외과 수술 팀 구성에 서 따온 Chief programmer team.
책임 프로그래머 : 제품 설계, 주요 부분 코딩, 중요한 기술적 의사 결정, 작업 지시
프로그램 사서 : 프로그램 리스트 관리, 설계 문서 및 테스트 계획 관리
보조 프로그래머 : 기술적 문제에 대해 상의, 고객/품질 보증 그룹과 접촉, 부분적 분석/설계/구현 담당
프로그래머 : 각 모듈을 프로그래밍, 테스팅, 디버깅
장점
의사 결정이 집중되어 있어 의사 결정이 빠름
소규모 프로젝트에 적합
초보 프로그래머를 훈련시키는 기회로 적합
단점
한 사람의 능력과 경험이 프로젝트의 성패 좌우
효과적인 팀 규모를 선택하는 방법
man/month와 같이 예상 개발 노력이 주어지면, 최적의 팀 규모를 정할 수 있다.
팀 규모를 두 배로 늘린다ㅗㄱ 개발 시간이 절반으로 단축되지는 않는다.
서브 시스템과 팀은 필요한 지식의 총량과 정보 교환이 감소하도록 크기가 정해져야한다.
프로젝트 반복의 경우, 한 팀의 인원 수는 일정하지 않을 수 있다.
스케줄보다 늦을 경우 그것을 따라잡기 위해 일반적으로 인력을 추가할 수 없다.
팀에 필요한 기술
– Architect
– Project manager
– Configuration management and build specialist
– User interface specialist
– Technology specialist
– Hardware and third-party software specialist
– User documentation specialist
– Tester
📁 프로젝트 위험 관리
위험 관리란 위험을 식별하고 프로젝트에 미치는 영향을 최소화하기 위한 계획을 수립하는 것이다.
위험이란 어떤 불리한 상황이 발생하는 것.
- 프로젝트 위험(project risks)은 일정 또는 리소스에 영향을 미친다.
- 제품 위험(product risks)은 개발중인 소프트웨어의 품질 또는 성능에 영향을 미친다.
- 비즈니스 위험(business risks)은 소프트웨어를 개발하거나 조달하는 조직에 영향을 미친다.
🌱 소프트웨어 위험
🌱 위험 관리 프로세스
1. 위험 식별(risk identification) : 프로젝트, 제품 및 비즈니스 위험 파악
2. 위험 분석(risk analysis) : 각 위험의 발생가능성 및 심각성과 결과 평가
3. 위험 대처 계획 수립(risk planning) : 위험의 영향을 회피하거나 최소화하기 위한 계획 작성
- 회피 전략(avoidance strategies) : 위험이 발생할 확률을 줄인다.
- 최소화 전략(minimisation strategies) : 프로젝트나 제품에 대한 위험의 영향을 줄인다.
- 비상 계획(contingency plans) : 위험이 발생할 경우, 그러한 위험을 다루기 위한 비상계획
4. 위험 모니터링(risk monitoring) : 프로젝트 전반에 걸쳐 위험 모니터링 및 평가
식별된 각 위험을 발생 가능성이 낮아지는지 여부를 결정하기 위해 정기 적으로 평가하고, 위험의 영향이 변경되었는지 여부를 평가한다.
각 주요 위험은 관리 진도 회의(management progress meeting)에서 논의되어야 한다
