팀에 새로운 개발자를 추가하는 방법

나는 2 명의 개발자로 구성된 소규모 회사를 운영합니다. 우리는 고객 중 하나를 위해 매우 큰 응용 프로그램을 구축하고 있습니다. 이 프로젝트에 대한 개발은 1.5 년 동안 진행되었습니다.

이제이 고객은 중요한 후원을 확보했으며이 프로젝트와 관련된 이벤트를 조직하고 있습니다. 이제 2 개월 만에 마감일을 정해 놓쳤습니다.

우리는 팀에 새로운 개발자를 추가하려고 생각하고 있으며, 그의 통합을 돕기 위해 무엇을 할 수 있는지 궁금합니다.

이것은 상황이다 :

• 우리는 Brooks의 법칙 임계 값에 접근하고 있습니다. 새로운 개발자를 추가하는 것이 비생산적 일 것입니다.
• 응용 프로그램은 비교적 잘 디자인되어 있지만 일부 시점 (특히 오래된 코드)에서는 구현이 혼란 스럽습니다.
• 최신 코드에 대해서만 단위 테스트가 있습니다. 이 프로젝트가 시작될 때 정기적으로 테스트를 수행하지 않았습니다.
• 문서와 의견이 불완전합니다.
• 응용 프로그램은 크고 복잡합니다.
• 고객은 자신의 프로젝트에 대한 거의 모든 세부 사항을 매우 명확하고 "프로그래머 친화적"방식으로 작성했습니다.

지금 사람을 추가하는 것이 좋은 생각입니까? 그렇다면 새로운 개발자가 팀에 통합 할 수 있도록 무엇을 할 수 있습니까?

편집하다:

후원사는 내년 봄에 인터넷 기반 스포츠 이벤트를 조직하고 있습니다. 연중 특정 요일에 시작해야합니다. 우리는 그것을 바꿀 수 없습니다.

우리 개발자 (나는 둘 중 하나) 가해 야 할 일은 다음과 같습니다.

• 기존 응용 프로그램 완료 (작업의 약 25 %).

• 이 이벤트를 조직하는 데 필수적인 새 모듈 만들기 (작업의 약 75 %). 이 새로운 모듈은 메인 프로그램의 API를 이해하지 않고서는 개발할 수 없습니다.

정확한 시간을 예측할 수는 없지만 위험한 상황에 처해 있습니다.

가장 좋은 방법은 새로운 개발자를 불에 태우는 것이 아니라 개발자가 문제를 일으키지 않아야 할 기능 및 / 또는 버그 수정을 개척하는 것입니다. 사람이 전체 아키텍처, 요구 사항 및 코드 기반을 한 번에 알 필요가없는 작업이 필요한 영역을 찾으십시오. 시스템을 더 빨리 배우기 위해 문서 작업을 할 수도 있습니다.

팀에 새로운 개발자를 추가하는 대신 회사의 업무량의 일시적 증가를 처리하기 위해 2-3 개월 동안 숙련 된 컨설턴트를 추가하는 것이 좋습니다. 아이디어는 거의 제로에 가까운 시작 시간을 처리 할 수있는 사람을 얻는 것이지만 동시에 팀에 가장 적합한 사람은 아닐 수도 있습니다.

워크로드 증가가 일시적이지 않다고 생각하더라도 지금은 팀을 유기적으로 키우기에 가장 좋은시기가 아닐 수 있습니다. 프로젝트 마감 시한이 없어도 팀에 세 번째 개발자를 추가하는 것은 스트레스가됩니다. 마감일이 촉박하면 전환이 더 악화됩니다.

단점은 임시 도움을 대신하여 외부인이 작성한 코드를 얻는다는 것입니다. 이 위험을 완화하려면 두 사람이 모두 코드 검토를 수행해야합니다. 그의 모든 단위 테스트도 검토하고 이해해야합니다.

지금 사람을 추가하는 것이 좋은 생각입니까?

아니요. 가능하면 클라이언트가 범위를 줄이는 데 동의하도록하십시오.

늦게 사람을 추가하면 상당한 위험을 초래할 수 있으며 마감 시간을 알 수 없습니다 (내가 이해 한 한).

하지마

아직.

전통적인 전망

귀하의 질문에, 당신은 신화 Man-Month 의 Brooks의 법칙을 참조하십시오 .

늦은 소프트웨어 프로젝트에 인력을 추가하면 나중에 만들 수 있습니다.

Brook의 법칙을 무시하는 것은 대가를 수반합니다. 멀티 태스킹하지 마십시오. MVP (Minimum Viable Product) 제공에 중점을 둡니다. 그런 다음 새로운 팀원을 모집, 리 소싱, 교육 및 관리하는 데 에너지를 집중하십시오.

두 달이 너무 짧습니다. 번 다운 목록으로 모집을 계획하면 시간이 얼마나 걸릴 수 있는지 알 수 있습니다.

Larry Page와 Sergei Brin은 2 년 동안 Google의 초기 팀을 선택했습니다. 직원 번호 3에 대한 선택도 신중해야합니다.

민첩하고 새로운 밀레니엄 뷰

신화적인 Man-Month가 쓰여진 시대 (1960 년대 중반)보다 경쟁이 더욱 활발해졌습니다. 한 회사에서 오랜 경력이 사라졌습니다. 이제 우리는 프로젝트와 회사간에 자주 마이그레이션합니다. 빠른 팀 빌딩은 성공을 만듭니다. 느린 증가는 심각한 제한 요소입니다. 훌륭한 예는 오픈 소스 프로젝트, 신생 기업 및 컴퓨터 과학 과정에서의 팀 프로젝트 사용 증가에서 비롯됩니다.

잠재적으로 애자일 팀은 일정에 제약 조건을 적용합니다. 사용 가능한 리소스에 최적화되어 있기 때문에 늦지 않았습니다. 신입 사원 통합은 또 하나의 제약이며, 단기 목표와 장기 목표 간의 절충으로 간주됩니다. 애자일 팀은 지속적으로 코드를 통합하고 있습니다.

신입 직원을위한 민첩한 팀 기술 및 사회 통합은 다음을 사용할 수 있습니다.

• 일일 스크럼
• 페어 프로그래밍
• 리팩토링
• 누락 된 단위 테스트 추가
• 마른 문서를 강화
• 코드 리뷰

희생양

" 민첩한 소프트웨어 개발의 조직 패턴"에서 James Coplien은 그룹 역학 및 새로운 팀원 추가 비용에 대해 설명합니다. 그의 패턴 "Sacrificial Lamb"은 모든 멘토링과 훈련을 한 사람에게 할당하여 팀의 나머지 부분을 방해하지 않도록 보호합니다.

구현을 고려할 수있는 전략입니다.

또 다른 전략은 매일 특정 시간 동안 신입 사원의 질문을 다루는 신입 사원 멘토를 지정하는 것입니다. 한 사람 만 살릴 수 있다면 아마도 아침이나 오후에 중단없이 일하고 오후 나 아침에 각각 질문에 대답합니다. 내가 속한 그룹은 지난 여름에 10 명의 인턴을 가지고 있었기 때문에 많은 사람들이 많이 중단되었습니다.

현재 멘토링은 한 사람이 주로 아침 스크럼 동안과 직후 (오전 8시 30 분부터 오전 9시 15 분까지, 그리고 오전 9시 15 분, 오후 12시에서 3시 30 분 (7시-3시 30 분) 오후).

브룩의 법칙에 대해 언급 한 것을 기쁘게 생각합니다. 잘 했어요 다른 개발자를 추가 할 때의 주요 문제는 개발자가 속도를 높이는 오버 헤드와 프로젝트의 현재 위치에 대한 상태 동기화의 오버 헤드입니다. 따라서 세 번째 개발자를 얻으려면 다음을 시도하십시오.

• 새로운 직원에게 최고 속도의 비용이 적게 드는 지역에 최대한 빨리 갈 수 있도록하십시오. 이것은 당신이 누구를 고용하고 어떤 기술을 가지고 있는지에 달려 있습니다.
• 이 영역이 응용 프로그램의 다른 영역과 느슨하게 연결되어 동기화 오버 헤드가 줄어 듭니다. DB 작업을 강요하고 테이블을 재구성하기 위해 그를 보내면 너무 많은 것일 수 있습니다.
• 사기를 유지하기 위해 할 수있는 일을하십시오. 다른 사람들이 지적했듯이, 새로운 팀원을 추가하는 것은 스트레스가 될 수 있으므로 탄산 음료에 대한 투자가 도움이 될 수 있습니다.

Brook의 법칙을 엄격히 준수하면 팀을 키우지 못할 것입니다.

요령은 현재 팀의 속도가 너무 느려지지 않고 새로운 사람을 키우는 것입니다. 결국 새로운 사람은 속도에 도달하고, 당신은 혹을 극복 할 수 있습니다.

당신의 경우에는? 새 사람에게 누락 된 모든 단위 테스트를 작성하도록 권장합니다.

1. 이것들은 회귀 오류에 대한 보호 수단으로서 절실히 필요합니다.
2. 새로운 사람이 시스템의 내장을 배웁니다. 화재로 인한 시련이지만 약간의 출력이 생산 코드에 들어 가지 않으므로 위험이 거의 없습니다.
3. 다른 팀원이 얼마나 많은 시간을 할애 할 수 있는지에 대해 제한을 두십시오. 예를 들어, 질문을 대기시키고 마감 시간이 지날 때까지 하루에 30 분만 다른 팀원들과 교류 할 수 있습니다.

또한, 직접 대면하자 : 당신은 새로운 사람을 데리고 왔는지 여부에 관계없이 범위와 고객의 기대치를 관리해야 할 것이다. 그 대가는 다음주기에 온다.

에드 유든은 브룩의 법칙에 대해 큰 언급을했습니다. 그는 물론 사람들을 추가하면 속도가 느려질 것이지만 프로젝트가 위험에 처한 경우에는 경영진이 새로운 사람들을 유치 할 수있는 유일한 시간입니다. 따라서 : 최신 릴리스에 대한 영향을 최소화하고 가능한 빨리 성능이 떨어지는 성능을 제거하십시오. 이런 식으로 시간이 지남에 따라 강력한 팀을 구성 할 수 있습니다.

다른 프로젝트를 수행하고 있다면 현재 2 명의 개발자가 도움이 될 수있는 큰 마감일에 집중할 수있는 시간을 확보 할 수 있습니다.

원본 작업의 25 %와 새 작업을 완료해야한다고 말합니다. 2 개월 안에이 작업을 수행해야합니다-작업의 75 %를 수행하는 데 18 개월이 걸렸습니다. 매우 무뚝뚝하다면, 이것은 당신의 추정 능력이 코드 중심 프로그래머의 평균에 가깝다는 것을 나타냅니다.

Heroics를 사용하면 계약 한 제품을 제공 할 수 있지만 귀 하나 고객에게 유리한 점은 없습니다. 이 조건에서는 엉망이되고 벌레가 타게되고 연기가 나게됩니다.

고용하는 시간도 가용성에 큰 영향을 미칩니다. 이는 주말에만 할 수있는 것이 아니며, 적합한 인재를 찾는 데 시간이 걸립니다. 검색, 인터뷰 등 적어도 2 주를 소비 할 것으로 예상됩니다. 검색하는 동안 일주일에 약 10 시간의 생산 시간이 손실 될 것으로 예상합니다.

내 추천 :

고객과 함께 앉아 머리를 숙이고 설명하고 고객과 협력하여 범위를 최소로 줄이십시오.

편집 방금 날짜를 보았습니다. 그래서 어떻게 끝났습니까? (3 개월 된 질문을 게시 한 Ars Technica에게 감사합니다.)

조사 할 몇 가지 방법이 있습니다.

1. 마감 기한이 지날 때까지 새로운 개발자를 고용하지 마십시오. 도메인 지식을 새로운 사람에게 전달하는 데 더 쉽게 집중할 수 있습니다. 몇 가지 방법으로 약간 어려울 수 있으므로 이것이 내가 선호하는 것입니다.

2. 새로운 개발자가 문서, 단위 테스트 및 기존 코드를 변경하지 않는 기타 작업을 수행하게하십시오. 이것이 현재 작업 부하에 미치는 영향을 최소화하기 위해 새로운 사람을 데리고 오면 제안하는 것입니다.

날짜는 이미지나 갔지만 나중에 읽는 사람이라면 누구나 사용할 수 있습니다.

고려해야 할 핵심 사항은이 상황의 클라이언트가 사용자보다 잃을 것이 훨씬 많다는 것입니다. 그들은 이미 많은 돈을 썼고, 사업을하거나 파괴 할 수있는 주요 행사가있었습니다. 당신은 이미 돈을 가지고 있고, 한 명의 고객을 잃는 것은 당신의 사업을 중단해서는 안됩니다. 그렇다면 끔찍한 프로젝트 관리 외에 다른 심각한 비즈니스 문제가 있습니다.

최선의 방법은 기능의 필수 하위 집합을 협상 한 다음 초과 근무를 수행하는 것입니다. 더 작은 하위 집합을 만들 수 없거나 그러한 상황에서 초과 근무를 할 의향이 없다면 비즈니스에 종사해서는 안됩니다. 이것은 다른 고객을 보류시키는 것을 의미 할 수도 있지만, 귀하의 다른 고객이 3 년 동안 시간을 ​​지불하지 않은 것으로 생각하므로 귀하의 자원을 돈이있는 곳에 두십시오.

그들이 범위 협상을 기꺼이하지 않으면 실패하도록 설정됩니다.

일정에 따라이 프로젝트를 완전히 제공 할 가능성은 없습니다. 지금까지 배달하는데 18 개월이 걸린 프로젝트에 25 %가 남았다 고 생각한다면 6 개월 이상 남았습니다 (~ 2 명의 개발자). 다른 사람을 추가해도 크게 변경되지는 않습니다.

지적했듯이 채용에는 시간이 걸린다. 내 경험은 최소한 한 달이 걸린다는 것입니다. 그런 다음 훈련을 추가하면 시간이 다되었습니다.

나는 이것이 당신을 위해 일하기를 바랍니다.