프로젝트 계획(5) - 팀 구성, 조직 계획 [소프트웨어공학]

비용, 일정 예측도 했으니까 이제 누가 할 지를 짜야겠지?

그렇다면 팀은 어떻게 짤지 알아보자

 

 

---

 

축구팀 짜듯이 그냥 엎어라 뒤쳐라 하면 될까? 묵찌? 그렇게 하면 프로젝트 작살난다.

 

개개인의 역할을 정의하고 프로젝트에 적절히 할당해서 목표를 이뤄야한다. 

비용, 일정 다 잘 예측해도 사람을 제대로 배치 안하면 망한다. 

//경찰한테 집에 불난 것 끄라하면 제대로 하겠나? 소방관한테 맡겨야지

 

그래서 서로 협력도 잘하고 상호 작용도 잘 이뤄지게 팀을 짜야한다. 

 

각설하고

소프트웨어 개발은 조금 다른 특징을 가지고 있어서 조직 구성 방법에 따라 품질이 달라질 수 있다.

//축구 포메이션이랄까? 선수는 같아도 포메이션 마다 성적이 다른 느낌??

 

 

팀을 구성하는데 고려할 점을 살펴보자 그 후 방법을 살펴볼 것이다.

 

1. 프로젝트의 기간

기간이 긴 프로젝트일 때

프로젝트 기간이 길어진다는 것은 사기를 높이고 개개인의 만족도를 높여서 중간 이탈이 없게 구성하여야 한다. 또한 경험이 많은 사람과 적은 사람이 적절히 혼합되어있는 것이 좋다. 경험자들은 도전적 일을 시도하고 초보자는 경험자들로부터 그 외의 일을 배우면서 진행한다.

 

기간이 짧은 프로젝트일 때

이직이 크게 고려될 요소는 아니다. 경험자와 초보자의 역할을 나누어 각자 할 수 있는 일에 집중하는 것이 최선의 방법이라 할 수 있다. (일을 배우기에는 그것이 더욱 비효율을 초래할 수 있다)

 

2. 작업의 특성에 따른 구성원들 간 의사소통 필요

문제의 규모에 따라 팀의 규모도 달라지는 것은 당연지사이고 이는 COCOMO 모형으로 몇 명이 필요한지 파악할 수 있다.  일반적으로 팀은 3-8명의 구성원으로 이루어지고 그 이상이 되면 중간 관리자를 두어 여러 계층으로 조직하는게 보통이다.

 

3. 소프트웨어의 특성

만드려는 소프트웨어의 모듈 결합도가 높다면 모듈을 여러 사람이 나누어서 개발한다면 많은 의사소통이 필요하다.

그러려면 설계 할 때부터 모듈을 프로그래머들에게 할당하기 쉽게 설계하고 팀 구성도 고려해야한다. 

그럼으로 팀 구성을 원칙적으로 하기 보다는 시스템 설계를 기초로 해야하고 작은 팀에서 시작하여 진행됨에 따라 큰 팀으로 구성되어 구현하는 그런 식으로 수행되어야 한다.

 

4. 원칙(관리자의 권한)
팀을 시스템 설계에만 기초하여 구성할 수는 없다. 일정, 예산, 품질 등 모든 것을 고려해서 판단하는 것이다. 

 

5. 의사 결정권

리더가 설계와 기타 모든 기술적 문제를 해결해야할 권한과 의무가 있다면 "집중형"

그룹의 합의가 강조된다면 "분산형" 

 

 

---

고려할 점을 알아봤으니 팀 구성 모델들을 한 번 살펴보자

 

3가지 정도 모델들이 있다.

1. Chief Programmer 팀 구성
2. Ego-less 팀 구성
3. 계층적 팀 구성

 

---

1. 책임 프로그래머 팀 구성(Chief Programmer)

책임 프로그래머 팀 구성은 팀 구성원이 관리자의 명령을 따라 일하고 결과를 보고하는 방식이다.

++팀 구성원은 개인적인 창의성을 발휘할 기회가 없다.

 

팀원들의 역할
 책임 프로그래머: 요구사항분석, 설계, 핵심부문 코딩, 중요 의사 결정, 작업의 지시

 프로그램 사서: 프로그램 리스트 관리, 설계 문서 및 테스트 계획 관리

 보조 프로그래머: 기술적 문제에 대하여 상의, 고객/출판/품질 보증 그룹과 접촉, 부분적 분
석/설계/구현을 담당

 프로그래머: 각 모듈의 프로그래밍

 

 

 

특징으로는

의사 결정권이 리더에게 주어여 있는 것이 특징이다. 그래서 의사 결정이 빠르고

소규모 프로젝트에 적합하다. 또한 초보 프로그래머를 훈련시키는 기회로도 적합하다.

 

단점으로는

한 사람의 능력과 경험이 프로젝트를 좌우하고

보조 프로그래머의 역할이 애매하다.

 

 

---

2. 에고리스 (Ego-less) 팀 구성

 

민주주의 식 의사결정을 하는 것이 가장 큰 특징이다.

 서로 협동하여 수행하는 비이기적인 팀(Ego-less)
 자신 있는 일을 알아서 수행
 구성원이 동등한 책임과 권한
 의사 교환 경로  //화살표가 의사 교환 패턴을 나타낸다 

 

다른 특징들로는
작업 만족도 높음 // 팀 구성원 모두가 동등한 레벨( 계층이 없음)
의사 교류 활성화 (적극성을 띔)
장기 프로젝트에 적합(복잡하고 이해가 되지 않는 프로젝트를 의사소통으로 해결)

 

 단점으로는 
책임이 명확하지 않은 일이 발생 // 모두가 책임을 나눈다는 것은 아무도 책임지고 싶어하지 않는다를 의미

대규모에 적합하지 않음(의사 결정 지연 가능) // 집단의 합의를 이끌어내야하기 때문

 

 

 

---

3. 혼합형 팀조직, 계층적 팀 구성

 

 

집중형, 분산형의 단점을 보완하기 위해 나온 모델이다.

 

특징으로는
 프로젝트 관리자와 고급 프로그래머에게 지휘권한이 주어짐 (맨 위)
 의사교환은 초보 엔지니어나 중간 관리층으로 분산 // 의사 교환 경로를 줄임
 개발 시스템이 기능적으로 명확하게 나눠지는 프로젝트에 적합
 

단점으로는 
 기술인력이 관리를 담당 // 중간 관리자가 부담이 생김 개
 의사 전달 경로가 길어짐 // 의사 교환이 프로젝트 관리자까지 오는 경로가 길어짐