한 달에이 아기가 필요 해요-나에게 9 명의 여자를 보내줘!

어떤 상황에서 프로그래머를 팀에 추가하면 실제로 이미 늦은 프로젝트의 개발 속도가 빨라 집니까?

정확한 상황은 프로젝트 (예 : 개발 팀, 관리 스타일, 프로세스 성숙도, 주제의 어려움 등)에 매우 분명합니다. 이 문제를 조금 더 잘 설명하기 위해 지나치게 단순화하지 않고 다른 것에 대해 이야기 할 수 있도록 귀하의 질문을 다시 말씀 드리겠습니다.

어떤 상황에서 늦게 실행중인 소프트웨어 개발 프로젝트에 팀 구성원을 추가 할 수있는 경우 기존 팀이 완료 될 때까지 작업 할 수있는 경우와 동일한 품질 수준으로 실제 선적 날짜가 줄어 듭니까?

이것이 발생하기 위해서는 필요 하지만 충분하지 않다고 생각되는 많은 것들이 있습니다 (특별한 순서없이).

• 프로젝트에 추가 될 제안 된 개인은 다음을 갖추어야합니다.
  • 프로젝트의 문제 영역에 대한 합리적인 이해
  • 프로젝트의 언어와 그들이 주어진 작업에 사용할 특정 기술에 능숙해야합니다.
  • 그들의 실력은 각각 가장 약하거나 강한 기존 회원보다 훨씬 적거나 크지 않아야합니다. 약한 회원은 기존 직원에게 3 차 문제를 겪게되며 너무 강한 신입 사원은 팀의 업무 수행과 수행 방식에 문제가 생길 수 있습니다.
  • 의사 소통 능력이 뛰어남
  • 동기를 부여하십시오 (예 : 자극없이 독립적으로 일할 수 있음)
• 기존 팀 구성원에게는 다음이 있어야합니다.
  • 탁월한 의사 소통 능력
  • 뛰어난 시간 관리 기술
• 프로젝트 리드 / 관리에는 다음이 있어야합니다.
  • 우수한 우선 순위 지정 및 자원 할당 기능
  • 기존 팀원의 높은 존중
  • 탁월한 의사 소통 능력
• 프로젝트에는 다음이 있어야합니다.
  • 훌륭하고 완성되고 문서화 된 소프트웨어 디자인 사양
  • 이미 구현 된 것들에 대한 좋은 문서
  • 명확한 책임을 제거 할 수있는 모듈 식 설계
  • 필요한 결함 수준에 대한 품질 보증을위한 충분한 자동화 프로세스 (단위 테스트, 회귀 테스트, 자동화 된 빌드 배포 등)
  • 팀이 현재 사용 중이고 사용중인 버그 / 기능 추적 시스템 (예 : trac, SourceForge, FogBugz 등)

선박 날짜 여부를 논의해야 할 첫 번째 것들 중 하나는 수 미끄러 기능을 절단 할 수 있는지 여부, 그리고이 둘의 조합이 허용하는 경우 기존 직원과 릴리스를 충족하기 위해. 많은 경우, 투자와 동등한 가치를 제공하지 않는 팀의 리소스를 실제로 활용하는 몇 가지 기능이 있습니다. 따라서 프로젝트의 우선 순위에 우선적으로 다른 사항을 검토하십시오.

위 단락의 결과가 충분하지 않으면 위 목록을 방문하십시오. 일정 전표를 일찍 잡은 경우, 적절한 팀 구성원을 적시에 추가하면 릴리스가 저장 될 수 있습니다. 불행히도 예상 배송 날짜에 가까워 질수록 사람들을 추가하는 데 더 많은 문제가 발생할 수 있습니다. 어느 시점에서, (현재 개발 지점 배송 이외의) 많은 양의 변경이 릴리스를 저장할 수없는 "반환 지점"을 넘을 것입니다.

나는 계속해서 갈 수 있었지만 주요 포인트를 쳤다고 생각합니다. 프로젝트 외부 및 경력 측면에서 회사의 미래 성공 등 반드시해야 할 일 중 하나는 왜 늦었는지, 조기에 경고를 할 수 있었던 경우, 필요한 조치를 파악하는 것입니다. 앞으로 그것을 막기 위해. 늦은 프로젝트는 대개 다음 중 하나 때문에 발생합니다.

• 시작하기 전에 늦었습니다 (시간보다 더 많은 것들).
• 하루에 1 시간 씩 미끄러졌다.

희망이 도움이됩니다!

리소스 기반 프로젝트가있는 경우에만 도움이됩니다.

예를 들어 다음을 고려하십시오.

4 x 6 미터 크기의 큰 포스터를 페인트해야합니다. 큰 포스터라면 아마 2 ~ 3 명 정도를 앞에두고 평행하게 페인트를 칠할 수 있습니다. 그러나 20 명을 배치하면 작동하지 않습니다. 또한 엉터리 포스터를 원하지 않는 한 숙련 된 인력이 필요합니다.

그러나 프로젝트에서 인쇄 할 수있는 편지 ( You MIGHT won! 와 같은)로 봉투를 채우는 사람이 많을수록 더 많은 사람이 추가 될수록 더 빨리 이동합니다. 많은 작업을 처리하는 데 약간의 오버 헤드가 있으므로 한 사람이 홍보하는 시점까지 혜택을 얻을 수 없습니다. 봉투에 있지만 2 ~ 3 명 이상의 혜택을 누릴 수 있습니다.

따라서 프로젝트를 작은 덩어리로 쉽게 나눌 수 있고 팀원이 빠른 속도로 (예를 들어 ... 순간적으로) 속도를 낼 수 있다면 더 많은 사람들을 추가하면 더 빠르게 진행할 수 있습니다.

안타깝게도 우리 세상에는 그런 프로젝트가 많지 않기 때문에 신화적인 Man-Month 책에 대한 docgnome의 팁이 정말 좋은 조언입니다.

다음 조건이 적용되는 경우 :

1. 새로운 프로그래머는 이미 프로젝트를 이해하고 있으며 램프 업 시간이 필요하지 않습니다.
2. 새로운 프로그래머는 이미 개발 환경에 능숙합니다.
3. 개발자를 팀에 추가하는 데 관리 시간이 필요하지 않습니다.
4. 팀원 간에는 거의 의사 소통이 필요하지 않습니다.

이 모든 것을 한 번에 처음 볼 때 알려 드리겠습니다.

신화적인 Man-Month에 따르면, 늦은 프로젝트에 사람들을 추가하는 주된 이유는 나중에 O (n ^ 2) 통신 오버 헤드입니다.

한 가지 예외가 발생했습니다. 프로젝트에 한 사람 만 있으면 거의 항상 운명입니다. 두 번째 것을 추가하면 거의 매번 속도가 빨라집니다. 그것은 의사 소통이 그 경우 오버 헤드 가 아니기 때문 입니다. 생각을 명확하게하고 어리석은 실수를 줄일 수있는 좋은 기회입니다.

또한 질문을 올릴 때 분명히 알았 듯이 신화적인 남자-월의 조언은 늦은 프로젝트 에만 적용됩니다 . 프로젝트가 아직 늦지 않은 경우 사람들을 추가해도 나중에 만들지 못할 수 있습니다. 물론 제대로한다고 가정합니다.

기존 프로그래머가 완전히 무능한 경우 유능한 프로그래머를 추가하면 도움이 될 수 있습니다.

매우 모듈 식 시스템을 가지고 있고 기존 프로그래머 가 아주 고립 된 모듈에서 시작 하지 않은 상황을 상상할 수 있습니다 . 이 경우 프로젝트의 해당 부분 만 새 프로그래머에게 할당하면 도움이 될 수 있습니다.

기본적으로 Mythical Man Month 참조는 내가 작성한 것과 같은 유죄 판결을받은 경우를 제외하고는 정확합니다. Brooks 씨는 특정 시점이 지나면 새 프로그래머를 프로젝트에 추가하는 데 필요한 네트워킹 및 통신 비용이 생산성으로 얻는 이점보다 더 크다는 것을 입증하기 위해 견고한 연구를 수행했습니다.

• 새로운 사람들이 테스트에 집중한다면
• 새로운 종속성을 생성하지 않는 독립적 인 기능을 분리 할 수있는 경우
• 프로젝트의 일부 측면 (특히 시각적 디자인 / 레이아웃, 데이터베이스 튜닝 / 인덱싱 또는 서버 설정 / 네트워크 구성과 같은 비 코딩 작업)을 직교 화하여 한 사람이 작업하고 다른 사람은 응용 프로그램 코드를 처리 할 수있는 경우
• 사람들이 서로, 기술, 비즈니스 요구 사항 및 디자인을 알면 서로의 발가락을 밟을 때와 그렇게하지 않는 방법에 대한 지식을 가지고 일을 할 수있을만큼 충분히 물론 그렇지 않은 경우 정렬하기가 매우 어렵습니다.)

그 말기에 아직 아무도 다루지 않은 독립적 인 (거의 프로젝트의 다른 부분과 거의 0 %의 상호 작용) 작업이있을 때만 해당 도메인의 전문가 인 사람을 팀으로 이끌 수 있습니다. 팀원을 추가하면 나머지 팀의 업무 중단을 최소화해야합니다.

프로그래머를 추가하는 대신 관리 도움말을 추가하는 것에 대해 생각할 수 있습니다. 주의를 산만하게하거나 집중력을 향상 시키거나 동기를 향상시키는 것은 도움이 될 수 있습니다. 여기에는 시스템과 관리뿐만 아니라 점심을 먹는 것과 같은 더 유창한 것들이 포함됩니다.

분명히 모든 프로젝트는 다르지만 대부분의 개발 작업은 개발자간에 일정한 양의 협업을 보장 할 수 있습니다. 이 경우 내 경험에 따르면 신선한 자원은 실제로 의도하지 않은 사람들이 속도를 높이기 위해 속도를 늦출 수 있으며 어떤 경우에는 이것이 핵심 사람들이 될 수 있습니다 (실수로 '주요'사람들이 될 수 있음) 새로운 교육 시간). 그들이 때 입니다 속도까지, 그들의 작품은 팀의 나머지와 함께 설립 '규칙'또는 '직장 문화'에 맞지 않는다는 보장은 없습니다. 다시 말하지만, 그것은 선보다 더 많은 해를 끼칠 수 있습니다. 따라서 다음과 같은 상황이 유리할 수 있습니다.

1) 새로운 리소스에는 다른 개발자와의 최소한의 상호 작용과 이미 입증 된 기술이 필요합니다. (즉, 기존 코드를 새 플랫폼으로 포팅하여 현재 기존 코드베이스에 잠겨있는 죽은 모듈을 외부에서 리팩터링).

2) 프로젝트는 다른 상급 팀원들과 시간을 공유하여 최신 정보를 신속하게 제공하고 작업이 이미 수행 된 작업과 호환되도록하는 방법으로 멘토링 할 수 있도록 관리됩니다.

3) 다른 팀원들은 매우 인내심이 있습니다.

작업이 끝날 때 사람들을 추가하면 다음과 같은 경우 속도가 빨라질 수 있다고 생각합니다.

1. 작업은 병렬로 수행 할 수 있습니다.

2. 추가 된 자원으로 절약되는 시간은 프로젝트 경험이있는 사람들이 경험이없는 사람들에게 설명하도록함으로써 잃어버린 시간보다 많습니다.

편집 : 언급하는 것을 잊었습니다. 이런 일이 너무 자주 발생하지는 않습니다. 일반적으로 테이블에 간단한 CRUD를 수행하는 관리자 화면과 같이 매우 간단합니다. 요즘에는 이러한 유형의 도구를 대부분 자동 생성 할 수 있습니다.

그러나 이런 종류의 작업을 수행하는 관리자는주의를 기울여야합니다. 그것은 훌륭하게 들리지만 실제로는 프로젝트에서 중요한 시간을 충분히 끝내는 것만으로는 충분하지 않습니다.

• 아직 시작되지 않은 독립형 모듈
• 통합 가능한 부족한 개발 도구 (자동 빌드 관리자와 같은)

기본적으로 저는 현재 개발중인 사람들의 길을 벗어날 수있는 것들을 생각하고 있습니다. 나는 Mythical Man-Month에 동의하지만 모든 것에 예외가 있다고 생각합니다.

사람들을 팀에 추가하면 프로젝트 자체에 추가하는 것보다 프로젝트 속도가 빨라질 수 있습니다.

동시 프로젝트가 너무 많다는 문제가 종종 있습니다. 해당 프로젝트에만 집중할 수 있으면 해당 프로젝트 중 하나를 더 빨리 완료 할 수 있습니다. 팀원을 추가하여 다른 프로젝트를 전환 할 수있었습니다.

물론 이는 대규모 프로젝트를 상속하고 독립적으로 학습 할 수있는 유능하고 자발적인 개발자를 고용했다고 가정합니다. :-)

추가 리소스가 기존 팀을 보완 하는 경우 이상적입니다. 예를 들어, 프로덕션 하드웨어를 설정하려고하고 프로젝트에서 다음 작업을 수행하는 좋은 dba에서 시간을 빌리는 좋은 결과를 반환하는 대신 (팀이 도메인 전문가로 알고 있음) 데이터베이스가 실제로 조정되었는지 확인하십시오. 많은 교육 비용없이 팀의 속도를 높일 수 있습니다

간단히 말해서. 남은 시간과 생산성을 비교하고 다른 리소스를 사용하는 데 걸리는 시간을 제외하고 생산성을 높이고 기존 리소스로 교육하는 데 소요되는 시간을 빼는 것이 좋습니다. 주요 요인 (중요한 순서) :

1. 자원이 얼마나 잘 집어 드는가. 최고의 개발자는 새로운 사이트를 방문하고 거의 도움없이 거의 즉시 버그를 수정하여 생산성을 높일 수 있습니다. 이 기술은 드물지만 배울 수 있습니다.
2. 작업의 분리 가능성. 기존 개발자를 넘어서서 속도를 늦추지 않고도 객체와 기능에 대한 작업을 수행 할 수 있어야합니다.
3. 사용 가능한 프로젝트 및 문서의 복잡성. 바닐라 모범 사례 ASP.Net 응용 프로그램 및 잘 문서화 된 일반적인 비즈니스 시나리오 인 경우 훌륭한 개발자는 바로 사용할 수 있습니다. 이 요소는 기존 자원이 교육에 투자해야하는 시간과 새로운 자원의 초기 부정적인 영향을 결정합니다.
4. 남은 시간입니다. 이것은 종종 잘못 추정되기도합니다. 논리는 종종 우리에게 x 주가 남았으며 누군가에게 속도를 내기 위해서는 x + 1 주가 소요될 것입니다. 실제로이 프로젝트는 미끄 럽게 진행되고 있으며 실제로 2 배의 개발 시간이 남았고 나중에 더 많은 리소스를 확보하는 것이 도움이 될 것입니다.

팀이 이미 프로그래밍을 페어링하는 데 사용 된 경우, 특히 TDD 스타일로 개발을 진행중인 경우 이미 페어링에 숙련 된 다른 개발자를 추가 하면 프로젝트 속도가 느려지지 않을 수 있습니다.

새로운 개발자는 코드베이스를 더 많이 이해함에 따라 천천히 생산성이 높아질 것이며, 오해는 그들의 쌍이나 모든 체크인 전에 실행되는 테스트 스위트에 의해 매우 일찍 발견 될 것입니다 (그리고 이상적으로는 체크가 있어야합니다) 적어도 10 분마다).

그러나 추가 통신 오버 헤드의 영향을 고려해야합니다. 프로젝트에 대한 기존 지식을 너무 많이 희석하지 않는 것이 중요합니다.

추가 개발자가 제공 한 생산성이 해당 개발자를 교육하고 관리하는 데 손실 된 생산성을 초과하면 개발자를 추가하는 것이 좋습니다.