신입 사원에게 숙련 된 개발자와 별도의 하위 프로젝트를 제공하면 초보자가 더 빨리 증가 할 수 있습니까?


12

한 팀에 7 명의 개발자가 있으며 짧은 기간 (약 1 개월)에 개발 속도를 두 배로 늘려야합니다. "더 많은 개발자를 고용하면 처음 몇 개월 동안 만 생산성이 떨어집니다"라는 상식적인 규칙이 있다는 것을 알고 있습니다. 이 프로젝트는 전자 상거래 웹 서비스이며 약 270K 라인의 코드를 가지고 있습니다.

지금은 아이디어를 두 개 이상의 독립적 인 하위 프로젝트로 나누고 새 팀이 두 개의 하위 프로젝트 중 더 작은 프로젝트를 진행하도록하면서 현재 팀은 기본 프로젝트를 진행합니다. 즉, 새로운 팀은 결제 기능을 개발할 것이며 결국 커플 링을 줄이기 위해 독립적 인 웹 서비스가 될 것입니다. 이런 식으로, 새로운 팀은 100K 코드만으로 프로젝트를 진행합니다.

내 질문은 :이 접근법은 초보자 개발자가 새로운 프로젝트에 쉽게 적응하는 데 도움이됩니까? 초보자가 버그보다 많은 소프트웨어를 생산하기 시작할 때까지 2 개월을 기다리지 않고 개발 팀을 빠르게 확장 할 수있는 다른 방법은 무엇입니까?

=======

최신 정보

이 기업은 완전히 실패했지만 여러분이 언급 한 이유는 아닙니다. 우선, 나는 새로운 팀의 규모와 능력에 대해 잘못 알고있었습니다. 나는 그들 스스로 평가 했어야했다. 둘째, 그 사이트에서 채용이 어려운 것으로 판명되었습니다. 본사의 사이트에서 채용이 훨씬 쉬웠지만, 두 번째 팀의 도시에서는 자격을 갖춘 개발자가 부족한 것 같습니다. 결과적으로 1.5 개월로 예상되는 대신 작업이 약 4.5 개월로 연장되고 그 중간에 최고 경영진이 취소했습니다.

내가 저지른 또 다른 실수는 Alex D에 의해 경고되었다는 것입니다. 리팩토링을 최고 경영진에게 판매하려고했다는 것입니다. 리팩토링은 판매하지 않으며 기능 만 판매합니다.

어쨌든 스타트 업은 성공한 것으로 판명되었습니다. 결코 일어나지 않은 리팩토링은 기술적 부채로 바뀌 었습니다. 저는 현재 팀에 소속되어 있지 않지만 가까운 시일 내에 완료하기를 바랍니다. 그렇지 않으면 프로젝트의 생존에 대해 1 페니를주지 않을 것입니다.


2
더 많은 개발자를 고용하면 처음 몇 달 동안 생산성이 저하됩니다. 들어 본 적이 없지만 더 확실합니다
BЈовић

2
두 부분을 다시 통합하려고하면 어떻게됩니까? 두 조각이 각각 자체 테스트를 통과 할 가능성이 있습니까? 그러나 전체 로트에 대한 큰 통합 테스트가 실패할까요? 브룩의 법칙이 그렇게 쉽게 우회되지 않는다는 것을 알게 될 것입니다. 훌륭한 창의적 사고; +1의 가치. 그리고 나는 이것이 당신에게 어떻게 효과가 있는지 알고 싶습니다.
Dawood ibn Kareem

1
javana : 숙련 된 개발자를 고용 할 것입니다
Dmitry Negoda

2
@DmitryNegoda 당신이 충분한 시간에 그들을 찾을 수 있다면. 숙련 된 개발자는 일반적으로 일을하지 않으므로 인터뷰를하고 내일 입장을 제시하더라도 현재 고용주에게 시작하기 전에 몇 주 전에 통지해야 할 수도 있습니다. 내가 당신이라면 밤과 주말에 한동안 일할 준비를하는 것과 같은 경우를 대비하여 비상 계획을 준비 할 것입니다.
maple_shaft

4
아무리 놀라운 개발자라도 1 개월에서 3 주 이내에 100k 줄의 코드를 이해하지 못할 것입니다
Ryathal

답변:


1

나는 다른 모든 사람들과 마찬가지로 다음과 같이 동의합니다.

"... 지연된 프로젝트에 더 많은 개발자를 추가하면 프로젝트가 더 지연됩니다 ..."

나는 느낌이 있습니다. 당신은 어디서나 그것을 할 것입니다.

기존 프로젝트가 모듈, 서브 시스템 또는 서브 프로젝트별로 충분히 구성되어 있다면 아이디어가 도움이 될 수 있습니다.

시도하고 싶은 것은 모든 프로젝트 대신 작업을 위해 프로젝트의 작은 조각 / 모듈 / 양식 / 클래스를 제공하는 것입니다.

데이터베이스를 사용하는 경우 데이터가있는 작업중인 DB의 사본을 작성하고 작업 할 코드의 서브 시스템 또는 모듈에서 액세스 할 수 있습니다.

프로그래밍 언어 나 프로그래밍 환경을 알고있는 새로운 개발자를 보유하는 것만으로는 충분하지 않습니다. 소프트웨어 적용은 매우 복잡해질 수 있습니다.

UML, ER, Codd-Yourdon 등과 같은 응용 프로그램에 대한 문서가 있습니까?

행운을 빕니다.


우리는 100K 라인의 코드에 대해서만 이야기하고 있지만, 그렇게 복잡하지는 않지만 걱정 해 주셔서 감사합니다
Dmitry Negoda

1
@Dmitry Negoda : 복잡성은 LOC의 기능이 아닙니다.
jmoreno

프로그래머의 생산성이 평균적으로 LOC의 기능이라는 것을 보여주는 상당한 연구 (예 : Boehm)가 있습니다.
Dmitry Negoda 2016 년

15

내 질문은이 접근법이 초보자 개발자가 새로운 프로젝트에 쉽게 적응하는 데 도움이 될 것인가?

"초보자"는 당신에게 새로운 것을 의미하거나 전혀 소프트웨어 개발자로서 새로운 것을 의미 할 수도 있습니다. 일정에 따라 중요한 프로젝트를 수행하기 위해 개발자 그룹을 고용하려는 경우, 최소한 대부분의 신입 사원은 경험이 풍부한 개발자이며, 가급적 시도하는 것과 유사한 프로젝트를 작성한 사람이어야합니다. 짓다.

개발팀이 소프트웨어보다 많은 소프트웨어를 생산하기 시작할 때까지 2 개월을 기다리지 않고 개발 팀을 빠르게 확장 할 수있는 다른 방법은 무엇입니까?

  • 직접 제작하지 않고 기존 제품을 구매하거나 라이센스를 부여하십시오. 당신이 할 정말 체크 아웃 바퀴를 재발견해야합니까?

  • 위에서 말했듯이 원하는 시스템을 구축 한 경험이있는 사람들을 고용하십시오.

  • 이 새 팀을 고용하기 전에도 기존 팀에 대해 알아야 할 사항을 고려해야합니다. 교육 세션을 진행할 수 있도록 충분한 시간을 예약하십시오.

  • 서면 요구 사항을 작성 했습니까? 그렇지 않다면 지금하십시오. 새 팀이 그렇게하지 않고 프로젝트를 디자인 할 계획이라면 명확한 디자인 문서도 준비해야하지만 새 팀 구성원의 의견에 따라 변경 사항을 공개해야합니다.

  • 잘 정의 된 개발 프로세스가 있습니까? 버그 데이터베이스? 버전 관리? 코드 검토 과정? 스타일 가이드? 그 물건들을 제자리에 두십시오.

  • 기적을 기대하지 마십시오. 당신이 원하는 일곱 사람이 팀을 고용하고 2 주 만에 생산적으로 작업하지만 당신이있을 수 있다는 것을 의미하지 않는다하고자합니다. 당신이 어디에 있는지에 따라, 단지 7 명의 적합한 사람들을 찾는 데 1 개월 이상이 걸릴 수 있습니다. 지금 물건을 서두르려고하면 나중에 고통과 비용이 발생할뿐입니다.


1
요구 사항을 서면으로 +1하면 약간 구식입니다.
Dmitry Negoda

3
누가이 새로운 직원을 인터뷰하고, 서면 요구 사항과 디자인 문서를 업데이트하고, 버그 데이터베이스를 채우고, 교육 세션에 시간을 할애 할 것입니다. 현재 개발자입니까? 왜냐하면 그들은 풀 타임으로 개발하지 않을 것이기 때문입니다. 그래서 개발 속도가 간다 아래로 . 죄송합니다.
MarkJ

코드는 자체 문서화되어 있으며 숙련 된 개발자 만 고용 할 것입니다. 그렇습니다. 현재 개발자들은 새로운 개발자를 도울 것이며 그들의 속도는 약간 떨어질 것입니다. 100K loc 프로젝트에서 개발자를 고용하는 것이 270K loc 프로젝트에서 고용하는 것만 큼 고통스럽지 않기를 바라고 있습니다. 이것이 문제였습니다.
Dmitry Negoda 2016 년

내부 위키가 있습니까, 아니면 워드 문서에 저장된 모든 것이 LAN을 통해 흩어져 있습니까?
스펜서 Rathbun

1
100k, 50k 또는 10k는 모두 같은 것을 나타냅니다. 아무도 머리에 옮길 수없는 수많은 코드입니다. 수백 줄의 코드가 있다면 합리적입니다. 당신이 수천을 넘으면 복잡한 시스템을 가지게되고 속도에 대한 희망이 종종 달성되지 않습니다.
Michael Durrant

12

IMHO는 기존 팀과 분리 된 모든 새로운 개발자를 새로운 프로젝트에 배치하는 데 문제가 있습니다. 예, 이로 인해 기존 팀이 현재 속도에 따라 다소 일을 계속할 수 있습니다. 그러나 새로운 사람들은 전체 아키텍처와 큰 그림에 대한 단서가 없으므로 속도를내는 데 많은 시간이 걸리고 심지어 잘못된 방향을 향하고있을 수도 있습니다.

기존 팀을 둘로 나누고 두 팀 모두에 새 구성원을 고용하는 것이 좋습니다. 이런 식으로 두 팀 모두에 이민자를 멘토링하고 공통적이고 일관된 아키텍처 비전을 유지할 수있는 사람들이 있습니다.

그렇지 않으면, 명확한 요구 사항을 문서화하고 개발 프로세스와 도구를 정의하며 교육 시간을 예약하는 것과 관련하여 Caleb에 동의합니다. 또한 7 명으로 구성된 팀이 한 달 안에 고용되어 속도를 낼 수 있다는 것은 비현실적입니다.


4
+1-기존 개발자를 사용하여 새로운 직원을 선임하고 싶습니다. 이것이 조금 느려지 게하는 것은 불가피합니다.
mikera

+1도. 노련한 개발자가 새로운 사람들을 멘토링하기를 원합니다. 새로운 직원들이 많은 경험을 가지고 있더라도 회사가 어떻게 행동하는지 정확히 알지 못할 것입니다.
Andy

9

짧은 시간에 개발 속도를 두 배로 늘리는 Dmitry는 엄청나게 야심 찬 목표입니다. 여기에 좋은 제안이 게시되었습니다. 그러나 무엇을 시도하든 그것이 일어나지 않을 수 있다는 점에 유의 하십시오 . 개발 속도가 두 배가 되지 않으면 비즈니스 관점에서 어떤 결과가 발생합니까? 마감일을 맞추기 위해 노력하고 있습니까?

마감일을 맞추려고 할 때 기능을 잘라보다 안정적으로 할 수 있습니까? 고객이 "누락 된 마감일"을 수용 할 수있는 좋은 방법을 찾았습니다. 증분 릴리스를 수행하는 것입니다. 필요한 기능의 서브 세트가있는 버전을 릴리스 한 후 더 많은 기능이 준비되면 최종 릴리스까지 점진적으로 릴리스하십시오.


아직 마감일이 없습니다. 파트너쉽을 만들어 잠재적 고객 수가 크게 증가 할 것으로 예상됩니다. 파트너가 우리를 선택할 수 있도록 솔루션의 경쟁력을 높이고 싶었습니다. 우리의 마감 기한이 아니라 새로운 기능을 제공 할 수있는 입증 된 능력입니다. 그러나 걱정 해 주셔서 감사합니다.
Dmitry Negoda

이 경우 개발 속도를 한 단계로 두 배로 늘리는 것이 아니라 일정 기간 동안 "강조"할 수 있습니다.
Alex D

4

그래서 당신은 신화 적 인간의 달에 희생되지 않는 팀이 되려고 노력하고 있습니다 . 몇 가지 문제가있을 수 있습니다. 팀원 중 누군가가 기술 인터뷰를해야하고, 직원들이 입장을 수락 한 후 시작하기 전에 몇 주를 기다려야합니다. 새로운 개발자들이 키보드를 사용하기까지 두 달이 걸릴 수 있습니다.

모든 신입 사원은 처음 몇 개월 동안 생산성이 떨어집니다. 현재 개발자가 멘토링을해야하므로 생산성이 더욱 떨어집니다.

MMM의 다른 부분은 팀이 성장함에 따라 통신 문제도 커진다는 것입니다. 회의가 커지고 이메일 체인이 길어집니다 ...

나는 작은 그룹으로 그것들을 가져오고 오랫동안 생산성이 팀의 규모가 커지는 것에 비례하지 않을 것이라는 것을 알고 있습니다. 또한 탑승 비용 및 장비로 인해 처음 몇 개월 동안 현금 흐름의 배수가 중요 할 수 있음을 인식하십시오.

Alex D에 대한 귀하의 의견에서 "이후의 마감일이 아니라 새로운 기능을 제공 할 수있는 입증 된 능력"이라고 언급했습니다. 따라서 더 작은 청크에서 더 자주 기능을 수행하는 개발 스타일로 전환하십시오. 팀의 새 구성원이 새 기능을 테스트하도록하여 코드 기반을 이해하는 데 도움이됩니다.


새로운 기능을 테스트하는 것이 코드 기반을 이해하는 데 어떻게 도움이되는지 이해하지 못합니다. QA 엔지니어도 채용하고 있으므로 개발자가 테스트하고 테스트 할 수 있습니다.
Dmitry Negoda

2

새로운 직원을 고용하지 않고 프로세스를 살펴보고 더 빠르게 진행할 수있는 위치를 확인하는 것이 좋습니다. 버그가 빨리 발견 될수록 버그를 수정하는 데 걸리는 시간이 줄어 듭니다. 어떻게 테스트하고 있습니까? 코드 검토를하고 있습니까? 요구 사항의 품질에주의를 기울이고 있습니까? 빌드 및 디플 로티먼트 프로세스가 간소화 되었습니까? 자동화 된 테스트가 있습니까? 매일 스탠드 업 회의를하고 있습니까 (매일 누군가가 당신의 행주를 요구할 때 얼마나 빨리 개발할 수 있는지 놀랍습니다!) 민첩한 프로세스를 사용하고 있습니까? 나머지 개발 속도를 높이기 위해 해결해야 할 몇 가지 기본 설계 결함이 있습니까? 나쁜 설계는 개발 프로젝트의 속도를 늦출 수 있습니다.

신화의 달을 읽으십시오. 고위 경영진에게 왜 프로젝트 속도를 높이기 위해 착용 옵션을 선택했는지 설명 할 수 있어야합니다. .


모든 질문에 그렇습니다. 마지막 질문을 제외하십시오.
Dmitry Negoda

0

절벽에서 버리고 날 수 있는지 보시겠습니까? 나는 당신이 스스로 물건을 발견 할 때, 당신에게 해결책을주는 것이 아니라 장기적으로 당신을 고집하는 경향이 있다고 생각합니다. 그러나 실제로는 더 나은 솔루션을 발견한다고 가정합니다. 나는 당신이이 팀이 자격을 갖춘 지도자가 자신의 실수를 저지르고 질 좋은 예를 통해지도와지도를하게하는 균형 잡힌 리더를 가질 수없는 이유를 모르겠습니다.


Mike Partridge가 내 질문을 변경했습니다. 나는 절벽에서 아무도 버리지 않을 것이다. 물론 새로운 개발자는 다른 하위 프로젝트에서 숙련 된 전문가와 함께 작업 할 것입니다.
Dmitry Negoda

100K loc 프로젝트에서 개발자를 고용하는 것이 270K loc 프로젝트에서 고용하는 것만 큼 고통스럽지 않기를 바라고 있습니다. 이것이 문제였습니다.
Dmitry Negoda
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.