늦은 프로젝트에 더 많은 사람들을 추가하면 나중에 만드는 이유는 무엇입니까?

늦은 프로젝트에 더 많은 프로그래머를 추가하면 문제가 더 악화 될 수 있다는 것은 상당히 흔한 일입니다. 왜 이런거야?

오버 헤드 소개

각각의 새로운 개발자는 새로운 사람의 시간뿐만 아니라 [a] 선임 개발자의 도움이 필요한 코드베이스 및 개발 프로세스를 소개해야합니다 (빌드 프로세스를 통해 안내, 테스트 프로세스 설명, 도움 코드베이스에 함정, 훨씬 더 자세한 코드 리뷰 등) .

따라서 프로젝트에 새로운 개발자를 더 많이 추가할수록 실제로 프로젝트에 기여할 수있는 시점에 더 많은 시간을 소비해야합니다.

다른 답변 외에도 고려해야 할 또 다른 요소는 커뮤니케이션입니다.

드문 일이 아닌 팀의 통신 채널 양에 대한 최악의 경우는 완전한 그래프 입니다. 상상할 수 있듯이 개발자 를 한 명만 추가 하면 커뮤니케이션 채널을 크게 늘릴 수 있습니다. 보다 효율적인 의사 소통 방법을 사용하면 영향이 줄어 듭니다. 그러나 여전히 더해집니다.

이 책에서 원래 언급 된이 법인 신화 적 인간-월 (Newthical Man-Month )은 의사 소통이다. 그는 다음과 같이 말하면서 시작합니다.

남성과 월은 의사 소통이없는 많은 근로자들 사이에 업무를 분할 할 수있는 경우에만 교환 가능한 상품 입니다. 이것은 밀을 거두거나면을 따는 경우에 해당됩니다. 시스템 프로그래밍의 경우에도 마찬가지입니다.

그는 문제의 일부로 훈련을 언급합니다.

의사 소통의 추가 부담은 두 부분으로 구성됩니다. 훈련과 상호 의사 소통. 각 작업자는 기술, 노력의 목표, 전반적인 전략 및 작업 계획에 대한 교육을 받아야합니다. 이 교육은 분할 할 수 없으므로 작업의이 부분은 작업자 수에 따라 다릅니다.

... 그러나 상호 통신은 훨씬 더 큰 요소입니다.

소프트웨어 구성은 본질적으로 복잡한 상호 관계에서 수행되는 시스템 노력이기 때문에 통신 노력이 훌륭하며 분할로 인해 발생하는 개별 작업 시간의 단축을 빠르게 지배합니다. 더 많은 남성을 추가하면 일정이 단축되는 것이 아니라 단축됩니다.

Fred Brooks (저자)는 자신이 무엇을 말하는지 알고있는 배경을 가지고 있다는 점도 주목할 가치가 있습니다. 이 책의 대부분은 IBM의 OS / 360 프로젝트 관리 경험을 기반으로합니다. 모든 방식의 "개선 된"관리 방법을 설교하는 수십 년간의 지지자들이 있지만, 일부는 멋진 이름 (eXtreme, Agile, Scrum 등)을 내놓을 때에도 본질 ^1이 거의 변하지 않은 것 같습니다.

¹ "본질"의 정의는 ^20th Anniversary Edition of The Mythical Man-Month에 포함 된 동일한 저자의 "No Silver Bullet : No Essence and Accident in Software Engineering"을 참조하십시오 .

그것은 단지 속담이 아닙니다. 검증 할 수 있습니다. Brooks의 The Mythical Man-Month를 확인하십시오 .

이 문제에 대한 몇 가지 생각은 다음과 같습니다.

• 현재 자원을 사용하여 새로운 자원을 활용하여 프로젝트 진행 상황을 가속화해야합니다.
• 새로운 리소스는 코드베이스에 익숙하지 않을 수 있으므로 코드에 적응하는 데 더 많은 시간이 필요했습니다.

이제 테스트를 위해 새로운 리소스를 추가하는 것은 나쁜 생각이 아닐 수 있습니다. 테스트 사례가 제대로 작성된 경우 테스트 프로세스 속도가 향상 될 수 있으며 테스트 도구를 사용하면 도움이됩니다.

프로그래밍은 기본 생산 라인 작업이 아니기 때문입니다. 소프트웨어 프로젝트의 속도를 높이려면 시간이 걸립니다. 새로운 사람들은 부정적인 생산성을 이끌어내는 많은 질문을해야합니다 (즉, 새로운 사람 학습, 노인들에게 교육-> 실제 작업이 수행되지 않음).

단순화하기 위해 1 주일로 예정되어있는 비교적 간단한 1 인 프로젝트를 상상해보십시오. 목요일에는 정시에 완료되지 않으며 한 프로그래머가 6-7 일과 같이 더 걸릴 것임을 알고 있습니다 이 시점에서 다른 프로그래머를 추가하는 경우 적어도 몇 시간 또는 하루 정도 programmer1과 함께 작업해야하며 속도 등을 맞추기 위해 많은 질문을해야합니다. 나머지주의 순 긍정적 인 생산성. 새로운 프로그래머는 프로그래머가 아닌 기존 코드를 알지 못하기 때문에 몇 가지 추가 버그가 발생할 가능성이 있으므로 구현 및 테스트주기를 하루나 이틀 더 날려 버릴 것입니다. 이 프로젝트는 원래 프로젝트 대신 2 주 동안 지속됩니다.

프레드 브룩스 (Fred Brooks)는이 질문에 대한 답변으로 "The Mythical Man-Month"책을 썼습니다.

다음은 quick-n-dirty 버전입니다.

1) 더 많은 프로그래머에게 할당하기 위해 프로젝트를 별개의 조각으로 나눌 수있는 양에는 제한이 있습니다.

2) 프로젝트를 더 많은 사람들로 분할하면 응용 프로그램의 모든 부분을 조정하는 데 필요한 통신량이 증가합니다. 더 많은 의사 소통 = 더 많은 일.

3) 프로젝트에 추가 한 모든 사람에 대해 팀으로 이동해야하는 둘 이상의 통신 채널을 추가합니다. 이 숫자는 기하학적으로 증가하고 발생해야하는 통신량을 증가시킵니다. 더 많은 의사 소통 = 더 많은 일.

4) 각 팀원을 추가 할 때 "J-Curve"가 있습니다. 즉, 기존 생산 자원은 새로운 사람들이 프로젝트 작업에 소비 할 수있는 속도를 낼 수 있도록 시간을 소비해야합니다. 궁극적으로 용량을 늘릴 수 있지만 일시적으로 프로젝트 속도가 느려집니다. 프로젝트의 후반부에 더 많은 것을 배워야하므로 효과가 더욱 두드러집니다.

내가 언급하지 않은 또 다른 요소는 특정 작업을 특정 순서로 수행해야한다는 것입니다. 작업 3이 3에 종속되어 있기 때문에 작업 3이 완료 될 때까지 작업 4를 수행 할 수 없습니다. 누군가가 작업 3을 수행하는 동시에 작업 4를 수행하도록 누군가를 고용하는 것은 좋지 않습니다. 종종 프로젝트가 끝날 때 먼저 다른 작업을 완료해야하는 작업이 나머지 작업입니다.

또한 수행해야하는 가장 복잡한 작업 중 하나이며, 이미 완료된 작업을 중단하지 않으려면 전체 디자인을 최대한 이해해야합니다. 또한 일반적으로 가장 광범위한 비즈니스 영역 지식이 필요합니다. 몇 달 동안 프로젝트를 수행 한 후 일주일 이내에 작업을 수행 할 수 있습니다. 새로운 누군가는 일주일 이상을 빨리 (그리고 질문에 대답하기 위해 그 시간을 잘 활용하기 위해 내 임무에서 멀어지게) 보내고, 극도로 숙련 된 사람이라도 그 일을하는 데 더 오래 걸릴 것입니다. 유능하지는 않지만 프로젝트의 실제 구조 나 데이터베이스 백엔드에 익숙하지 않기 때문입니다.

항상 나를 위해 일하는 격언은 한 달에 9 명의 여성이 아기를 낳을 수 없다는 것입니다.

DeMarco와 Lister의 "Peopleware"도 제안합니다.

그리고 DeMarco의 "The Deadline"은이를 비롯하여 여러 다른 소프트웨어 프로젝트 관리 질병 및 오류를 밝고 읽기 쉬운 방식으로 제시합니다.

또한 프로젝트 / 팀 작업을 수행하는 사람들의 역학을 탐구하고 의사 소통 및 소개와 같은 것들이 팀의 사용 가능한 작업 시간을 고갈시키는 방법에 대해 자세히 설명합니다.

이 책들은 아주 싸기 때문에 (Amazon 또는 The Book Depository에서 가져 와서) 읽어보십시오. 여기에 짧은 대답은 실제로 질문에 대한 정의를 할 수 없습니다.

프로그래머를 고용, 훈련, 개발 및 감독하는 것만으로도 특정 프로젝트를 신속하게 진행할 수있을뿐 아니라, 다음과 같은 계획을 수립하고 테스트를 수행하는 데 시간이 걸리지 않습니다.

개발자 팀을 관리하는 경우, 오프닝이있는 경우 지금 채용하려는 사람들과 여러 담당자가 있어야합니다. 개발자 그룹에 참여하십시오.

새로운 개발 시스템을 얼마나 빨리 준비하고 준비 할 수 있습니까?

다른 프로젝트의 개발자에게 프로젝트 문서 및 사양을 보여줌으로써 테스트 한 적이 있습니까? 그들은 그것을 보았고 필요한 경우 프로젝트 작업을 시작할 수 있다고 결정 했습니까?

프로젝트 일정은 얼마나 최신입니까?

프로젝트가 뒤 떨어지면 허리케인과 비슷하기 때문에 비오는 날을 절약하십시오.

커뮤니케이션 문제 (다른 모든 답변에 대해 이야기하고 있다고 생각합니다) 외에도 프로젝트에 추가 된 사람이 코드를 아직 잘 모르기 때문에 버그를 만들 수 있습니다.

프로젝트에 추가 될 때마다 항상 문제를 해결하지 않으려 고 노력합니다. 이것은 처음에 물건을 고치는 데 훨씬 느리다는 것을 의미합니다.

나는 다른 답변에 의해 지금까지 완전히 무시 된 것을 지적하고 싶습니다.

사람들이 늦은 프로젝트에 추가 될 때까지 조직 전체에 많은 문제가 발생했습니다. 경영진과 고객은 행복하지 않습니다. 사람들은 그것에 착수하라는 압력을 받았습니다. 상황이 꽤 긴장됩니다.

이제 당신이 그 팀에 있다고 상상해보십시오. 분명히 이것은 당신의 잘못이 아닙니다. 계획 (아무도 당신의 것이 아님)은 너무 낙관적이었습니다. 모든 잘못된 결정은 귀하와상의하지 않고 내려졌습니다. 당신은 그것을 최대한 활용하려고 노력하고 있으며 갑자기 많은 새로운 사람들이 참여하고 있습니다. 이것은 어떤 메시지를 전달합니까?

위층 사람들은 분명히 당신에 대한 믿음을 잃었습니다. 그들은 당신이 엉망인 것을 보충하기 위해 큰 소년들에게 전화했습니다.

당신은 여전히 ​​이것을 성공시키기 위해 동기를 부여받을 것입니까? 아니면 ... 당신은 더 좌절하고 결국 모든 것이 추락 볼 수 있습니까?

당신의 시간이 걸릴 :-).