프로젝트 팀 조직
소프트웨어는 프로젝트 팀 구성이 프로젝트 운영과 소프트웨어 결과물에 중요한 영향을 미친다. 개발 팀을 직능별로 나누어 부서를 나누거나 또는 다른 방식으로 부서를 형성할 수 있다. 프로젝트 팀 조직은 다음 세 가지를 정하는 것이다.
- 역할과 책임이 어디 있는가?
- 어떤 통로로 정보가 전달되고 결정되는가?
- 어떻게 갈등을 해소할 것인가?
소프트웨어 개발을 위한 인력 자원과 작업 목표가 주어졌을 때 각자의 임무와 역할이 무엇인지 결정해야 한다.
직능별 조직 구성
개발자들의 역할에 따라 같은 부서에 속하게 하는 것이 직능별 팀 조직이다. 직능별 팀 조직은 서로 다른 부서가 한 프로젝트의 다른 단계에 들어와 작업을 수행하고 나가는 것이다. 부분적으로 완성된 결과물이 한 부서에서 다른 부서로 전달되면서 소프트웨어가 진화해간다.
소프트웨어 개발 조직에서 일반적으로 분류하는 직능은 다음과 같다.
- 프로젝트 관리자 (Project Manager)
- 시스템 운영자 (System Administrator)
- 시스템 분석가 (Ststem Analyst)
- 시스템 개발자 (Software Engineer)
- 데이터베이스 엔지니어 (Database Engineer)
- QA 관리자 (QA Manager)
- 기술 지원 (Technical Support)
- 하드웨어 엔지니어 (Hardware Engineer)
- 웹 개발자 및 디자이너
프로젝트별 조직 구성
서로 다른 역할을 담당하는 직능별 개발자들이 프로젝트에 배정되어 프로젝트 별로 부서를 조직하는 방법이 프로젝트별 조직이다. 프로젝트별 조직은 다양한 인력 자원이 프로젝트 안에 배치되어 프로젝트 관리자가 독립성을 가지고 관리하며 조정할 수 있다.
매트릭스 조직
매트릭스 조직은 프로젝트별 조직과 직능별 조직을 혼합한 것으로, 관리자와 개발자는 직능별 조직에 속하지만 전문지식이 필요한 지정된 프로젝트를 위해 간헐적으로 일하는 것이다. 직능별 조직의 관리자가 프로젝트 책임을 가지고, 직능별 조직 부서에 소속된 개발자가 프로젝트에 참여한다.
매트릭스 조직에서는 모든 팀원이 보고하는 두 명 이상의 관리자가 존재한다. 따라서 커뮤니케이션 스킬이 더 많이 요구된다.
애자일 조직
애자일을 따르는 개발은 5~9명의 적은 인원의 팀을 구성하여 서로 밀접하게 협력한다. 개인보다는 팀이 중요시 되기에 책임과 역할이 교환될 수 있다.
애자일 조직에서는 “결과와 이슈에 대한 오너쉽을 공유한다”는 것이 중요하다. 팀원이 여러 직능을 담당하거나 팀을 재구성하는 것도 가능하다. 결국 고객의 요구와 가치를 만족시키기 위하여 역동적이며 융통성 있고 최적화된 조직을 구성한다.
애자일 팀의 단점은 적은 인원으로 구성되어 규모가 큰 프로젝트에 맞지 않는다는 것이다.
실행과 모니터링
계획을 짠 이후, 계획이 실행되지 않거나 실행에 도움이 되지 않으면 의미가 없기에 프로젝트를 실행하는 동안 모니터링하고 현재 상황을 반영하여 계획과 비교하고 수정해야 한다.
프로젝트 실행
프로젝트를 실행하면 두 가지의 관리 작업이 시작된다.
작업 시작 미팅: 팀원들에게 작업이 시작됨을 알리고 회의를 열어 팀이 작업의 목표와 형식에 맞춰졌는지를 확인한다.작업 결과 수집: 프로젝트의 결과물을 체계적으로 수집하는 과정으로, 여러 가지 요소를 평가하기 위한 기회이다.
프로젝트 모니터링
모니터링은 프로젝트의 현황을 파악하고 차이를 분석하여 조치를 취하기 위하여 진행하는 과정이다. 모니터링을 중점적으로 해야 할 부분은 “일정”, “비용”, “진척도”로 각각을 모니터링하는 방법은 다음과 같다.
일정 모니터링: 주어진 시간 계획의 스냅샷을 기초로 실행 값을 비교한다. 실제로 들어간 노력과 진행 상황을 비교한다.어닝 밸류 분석(Earning Value Analysis): 비용과 일정을 통합하여 모니터링하는 방식으로, 계획된 노력(비용), 실제 진적도(어닝 밸류), 노력(실제 비용)을 금전적 가치로 측정하여 통합된 모니터링을 제공한다. 이때 맨파워(Manpower)를 비용으로 간주하여 미래의 비용과 일정을 예측한다.
번다운 차트 (Burndown Chart)
번다운 차트에서는 구현될 각 기능에 이상적인 투입 시간을 할당하고 각 기능은 스프린트에 배정되어 기능이 완성되며 소멸되는 스프린트 점수로 기록한다.
결국, 번다운 차트는 기능이 출시되는 속도를 측정하고 잔여 작업량과 잔여 시간을 계산하고 시각화하기 위해 사용된다.
리스크 관리
리스크 관리란 위험 요인을 파악하고 평가 관리하는 기술과 프로세스를 의미한다.
리스크 파악
리스크를 관리하기 위해서는 우선 프로젝트에 영향을 줄 수 있는 리스크가 무엇인지 이해하고 특징을 파악해야 한다. 리스크를 찾는 방법은 다음과 같다.
회의: 리스크 파악을 위한 회의를 통해 아이디어를 도출한다.문서 분석: 프로젝트와 관련된 문서를 읽고 리스크를 찾는다.리스크 분할 구조: 리스크 아이템을 분할하여 계층 구조로 그리거나 체크리스트를 만들어 파악한다.유추: 비슷한 프로젝트 유형과 비교하여 유추한다.
리스크 평가
리스크를 프로젝트에 대한 영향도에 따라 평가하고 우선순위를 매긴다. 평가하는 방법은 정성적인 방법과 정량적인 방법으로 분류된다.
정성적인 방법: 리스크 발생 확률에 대한 정확한 정보가 없을 경우 사용하는 방법으로, 주관적인 판단으로 평가하는 방법이다.정량적인 방법: 리스크 확률을 고려한 영향을 돈으로 환산하는 방법으로, 확률과 영향도에 대하여 채택된 스케일로부터 출발하여 리스크 메트릭스에 리스크 요소를 표시한다.
리스크 관리
결국 리스크 관리의 목표는 프로젝트에 대한 부정적 사건이 발생할 가능성을 줄이고 긍정적인 사건이 일어날 가능성을 높이는 것이다. 리스크 요소는 계속 관찰하여 계획과 차이가 나면 원인을 찾아내어 해결 방안을 제시하거나 계획을 수정한다. 미리 인지된 리스크는 대처하기가 쉽지만 예상치 못한 리스크는 인식하고 분석하는 모든 과정의 작업이 필요하다.
리스크 관리 시 완전히 큰 위험 요소의 경우는 애초에 프로젝트 시작을 포기하면 된다. 그리고 프로젝트가 지연된다거나 지체보상금이 부과되는 것과 같은 “영향”을 원인과 혼돈하지 말아야 한다.
