소프트웨어 프로젝트가 파국으로 치닫는 과정
시스템 프로그래밍 일정 관리의 바탕을 이루는 잘못된 가정은 다음과 같다:
모든 작업이 예정된 시간 내에 완료될 것이다.
인간이 무언가를 만들 때는, 그 생각에 불완전함이나 모순이 있더라도 실제로 만들기 시작한 후에야 그것이 명확해진다. 따라서 이론가들에게는 글로 쓰거나 실험하는 등의 실제 해보기
가 필수적인 지침이 된다.
컴퓨터 프로그래밍에서 사용되는 재료 (프로그래밍 언어와 도구들) 는 다루기가 무척이나 쉽다. 프로그래머는 순전히 생각만으로 여러 가지 개념과 그것을 표현할 아주 유연한 방법을 만들어 낸다. 재료가 유연하기 때문에 구현에 별다른 어려움이 있을 것라고 생각지는 않으며, 낙관주의는 이렇게 우리 사이에 만연하게 된다.
그러나 우리
아이디어 자체에 흠
이 있기에 버그가 생겨나며, 우리의 낙관주의는 이렇게 정당성을 잃는다.
맨먼스 (Man-Month) 란... 추정 및 일정 관리에서 투입된 노력을 셈할 때 쓰는 단위로 사람 당 달수를 뜻한다. 핵심은 다음과 같다:
프로젝트 비용은 사람 수와 달수의 곱 (맨먼스) 을 따르지만, 작업 진척도는 그렇지 않다.
사람과 일정은 교환이 가능한 유일한 경우는 각자가 맡은 업무가 다른 업무로부터 완벽하게 독립적인 경우 (밀 수확, 목화 따기 등) 에만 해당된다. (, 인원 (, 사람 수) 증가하면 소요 기간(, 개월) 도 급격하게 줄어듬)
작업의 성격 상 순서가 있어서 나누기 어렵다면 (CPU 의 파이프라인을 떠올려보자) , 거기에 어떤 노력을 더 쏟아 붓더라도 일정에는 아무런 영향을 미치지 못한다. (, 인원에 관계없이 항상 동일한 상수시간()가 소요됨)
분할은 가능하지만 나뉜 하위 작업들을 처리하는 데 커뮤니케이션이 필요하다면, 거기에 들어가는 노력 또한 전체 작업에 포함되어야 한다. (, 는 커뮤니케이션 비용)
커뮤니케이션으로 추가되는 부담은 훈련과 의사소통의 두 부분으로 나뉜다:
여러 사람이 모여서 회의를 통해 문제를 해결해야 한다면 작업을 나눠서 얻는 이점을 상쇄할 수도 있고 이는 위 그래프와 같다.
참고로 그래프는 다음과 같이 그렸다:
소프트웨어를 만든다는 것은 본래 조직적인 활동, 즉 복잡한 상호연관성을 가진 활동이기 때문에 어설프게 인원을 더 투입하는 것은 일정을 단축시키기는 커녕 더 늘어지게 만든다.
위 방식은 일반적인 일정 수립과 비교해서 다음과 같은 중요한 차이점이 있다:
초기에 일정을 수립할 때 시스템 테스트에 충분한 시간을 할애 하는 것은 대단히 중요하다.
희망 사항에서 비롯된 빈약한 예감 대신 추정의 기초를 견고하게 할 필요가 있다:
프로젝트에 소요되는 기간은 순서대로 처리해야 하는 내부 요소에 좌우되며, 필요한 최대 인원수는 독립된 하위 작업의 개수의 좌우된다. 따라서 더 적은 수의 사람
과 더 긴 기간
에 기초한 일정을 수립할 수 있다 (유일한 위험은 제품이 시대에 처지게 되는 것이다).
그러나 더 많은 사람과 더 많은 사람과 더 짧은 기간으로는 실행 가능한 일정을 만들어 내지 못한다.
"늦어진 소프트웨어 프로젝트에 인력을 추가로 투입하면 더 늦어지게 된다."
- 브룩스의 법칙
[그래프] https://www.desmos.com/calculator
[책] 맨먼스 미신: 소프트웨어 공학에 관한 에세이 (프레더릭 브룩스 지음, 강중빈 옮김)