소프트웨어 개발을 할 때 가장 고민되는 것이 “몇 명을 몇 개월이나 투입해야 하는가”이다. 초기에는 프로그래밍 라인 수에 의존했지만 최근에는 기능점수(Function Point), 코코모(Cocomo; COnstructive COst MOdel) 등을 통해 보완하고 있다.
- Function Point: https://en.wikipedia.org/wiki/Function_point
- Cocomo: https://en.wikipedia.org/wiki/COCOMO
하지만, FP나 Cocomo를 통해서도 근본적인 고민은 해결할 수 없다. 소프트웨어의 규모를 이용해 개발 비용을 예측하는 방법이기 때문에 프로젝트 성공을 위한 팀 구성은 알 수가 없다. FP나 Cocomo는 견적을 위해서는 필수라고 할 수 있지만 팀 구성에서는 참고로만 활용하는 것이 좋다.
일반적으로, 팀을 구성하는 이유는 비슷한 일을 하는 사람들끼리 함께 일하며 의사결정이나 협업이 원활하도록 하는데 목적이 있다. 하나의 개발팀도 다양한 세부 팀으로 나누어 구성된다.
세부 시스템 단위로 개발하던 클라이언트/서버 환경에서는 세부 시스템 별로 세부 팀을 구성하였고, 레이어(Layer) 단위로 개발하는 웹 환경에서는 역할에 따라 세부 팀을 구성(그림 1 참조)한다. 최근에는 애자일 팀, 데브옵스(DevOps) 팀과 같이 프로젝트 성격을 구분하여 구성하는 팀도 많아지고 있다.
<그림 1> 역할에 따라 팀을 구성
앞에서도 말한 것처럼, 팀 구성의 가장 큰 목적은 의사결정과 협업이다. 프로젝트를 수행하다 보면 협업이 잘 되지 않아 의사결정이 느려지고 문제가 발생하는 경우가 많다.
예를 들어, 세 명의 팀원이 프로젝트를 수행하고 있는 도중에 작업은 지연되고 납기는 다가오고 있어서 한 명의 팀원을 추가 투입했다. 상식적으로는 프로젝트가 원활해져야 하지만 오히려 더 지연되는 경우가 많다(그림 2 참조).
<그림 2> 프로젝트에 1명이 추가되는 경우 커뮤니케이션 채널의 변화
<그림 2>를 살펴보면, 기존 팀원 간의 커뮤니케이션 채널(실선)에 새로운 팀원은 커뮤니케이션 채널을 추가(점선)로 만들어야 한다. 현재까지 달성한 것이 무엇인지, 지금까지 완성하지 못한 것은 무엇인가를 파악해야 하기 때문이다. 이러한 문제를 정리하여 ‘Brooks의 법칙’이 만들어졌다.
소프트웨어 개발에 사람을 늦게 투입하면 더 지연시킨다.
하지만, Brooks의 법칙이 있다고 납기가 늦어지는 프로젝트에 추가 팀원 투입을 늦출 수는 없다. 프로젝트의 성격을 잘 파악해서 팀을 구성해야 하고, 추가 팀원이 필요한 경우 팀 구성에 따라 적절하게 투입할 수 있어야 한다. 더 보기 >>>
