새로운 팀원을 프로젝트에 최신 상태로 만드는 방법? [닫은]

소프트웨어 팀을 위해 1-2 명의 새로운 엔지니어를 고용하려고합니다 (3 명의 개발자, 1 명의 테스터로 구성).

그것들을 팀에 통합하는 단계는 무엇입니까?

내 아이디어는 :

• 문서 읽기 (코딩 표준, 개발 방법론의 문서)
• 기존 코드를 읽도록한다
• 그들에게 몇 가지 간단한 작업을 할당
• 결국 코드 부분에 대한 책임을지게하십시오.

우리는 또 무엇을 할 수 있습니까?

이 프로젝트는 의료 부문 (초음파 시스템)에 있으며 이미 5 년이 지났습니다. 매년 릴리스가 있으며 1-2 명의 엔지니어를 추가하려고 할 때 하나의 릴리스를 완료하려고합니다.

프로젝트는 유지 보수 단계에 있습니다 (레거시 코드 리팩토링 및 새로운 기능 추가). 상황이 거의 일정합니다 (더 많거나 적음).

내 커리어에서 많은 다른 코드베이스를 가속화 해야하는 사람이 왔을 때 제안하는 것이 있습니다.

1. 제품 사용과 관련된 활동으로 짧은 시간 (1 일 또는 2 일)을 소비하여 제품의 기능에 익숙해 지십시오. 버그를 확인하거나 QA 테스트 계획을 실행하거나 사용자 교육을 진행할 수 있습니다.
2. 작고 지역화 된 버그에 대해 작업하십시오. 이를 통해 엔지니어는 많은 아키텍처를 배우지 않고도 응용 프로그램을 빌드 및 디버깅하는 방법에 익숙해집니다.
3. 이상적으로 현지화 된 작은 새 기능을 작성하십시오. 이를 통해 코드 덩어리를 작성할 수 있으며, 코드를 작성할 때 새 코드가 작동해야하는 주변 코드 비트에 익숙해집니다.

여기에서 엔지니어의 경험 수준과 적성에 따라 시간이 지남에 따라 과제의 범위와 복잡성을 확장하십시오. 이를 통해 개발자는 코드베이스에 대한 지식을 자연스럽게 확장 할 수 있습니다.

작업 (문서 또는 코드) 만 읽지 않아도됩니다. 문서를 읽는 것은 정말 지루해지며 임의의 코드를 읽는 것은 아무런 맥락이 없으므로 도움이되지 않습니다. 이미 제품 및 코드베이스를 알고있는 경우 코드 검토를위한 코드를 읽기가 어렵습니다. 코드를 읽는 새로운 엔지니어가 있으면 유용한 것이 없습니다.

내 생각은 대부분의 사람들이 문서를 읽는 것에 대한 내성이 상당히 낮다는 것입니다 (하루 이틀 동안은 좋지만 그 이상은 좀 더 실습을하고 싶어 할 것입니다).

응용 프로그램 자체를 합리적으로 이해하지 않고 응용 프로그램 코드를 실제로 이해할 수 있다고 생각하지 않습니다. 이 소프트웨어는 아마도 사용자로서 '장난감'을 가질 수있는 많은 기능을 가지고있을 것입니다. 그들은 결국 테스트 할 수 있어야하므로 설치, 구성 및 일반적인 작업 수행 방법을 알아야합니다.

나는 개인적으로 높은 수준의 아키텍처 개요가 일반적으로 일이 어떻게 작동하는지에 대한 기본적인 느낌을 얻는 데 매우 편리하다는 것을 알게되었습니다. 어쩌면 첫 주에 수석 엔지니어의 시간 (또는 필요한 경우?)을 1 ~ 2 시간 할당하여 간단하게 진행하십시오. 기본 응용 프로그램의 기본 너트입니다. 예를 들어 타사 소프트웨어 / 라이브러리에서 어떤 비트를 처리하고 사내에서 유지해야하는 비트를 파악하여 모든 하위 시스템과 사물이 어떻게 연결되어 있는지 이해합니다. (귀하의 조직이 진정으로 뛰어난 품질에 대한 최신 문서를 얻지 않았다면, 누군가 화이트 보드를 사용하여 직접 설명하지 않고서는 그런 종류의 물건을 잡을 방법이 없다고 생각합니다. ))

그들에게 "손에 쥐고있는"것에 관해서는, 유지 보수 / 버그 추적 작업이 잠시 동안 (몇 주 / 개월?) 속도를 낼 수있는 좋은 방법 일 수 있습니다. 특정 기능 영역이있는 상황에 처하게됩니다. 이해, 테스트 및 디버깅이 필요합니다. 코드, 요구 사항, 회사에서 사용하는 도구, 개발 프로세스 및 제품에 대한 지식을 쌓는 데 도움을 주면서 나머지 개발 팀으로부터 너무 많은 시간을 소비하지 않아도되기를 바랍니다.

Lead로서 저는 새로운 개발자들과 최소 2 일을 보냈습니다. 나는 "어떻게 진보하고 있습니까?"라는 피할 수없는 질문을하는 것이 편안하다고 느끼는 관계를 발전시키는 것을 발견했습니다. 필수이다. 어떤 새로운 공동체에도 적응할 수있는 두려움이 있습니다. 우리는 실수를 숨기고, 완벽하게 행동하며, 상황을 개선하고, 어려움을 줄입니다. 다른 사람과 2 일을 보내는 관리자는 자신의 문화가 무엇인지 아닌지 알리고 모범을 보이도록 할 것입니다. 새로운 코더는 어디에서 왔으며 얼마나 멀리 왔는지에 대한 역사 수업이 필요합니다. 문서는 단지 작업 정의를 수행하지 않습니다.

나는 업계에서 10 개월 동안 만 일해 왔지만 (배치시) 다음과 같은 도움이되었습니다.

• 다른 개발자와 팀을 이루어 문제를 해결하는 방법을 관찰합니다.
• 소프트웨어 테스트에 도움이되었으므로 기능 x를 테스트해야합니다. 즉, 기능 x에 대한 설명서를 읽습니다. 나는 이것을 많이했다. 도움이되었다.

두 가지 모두 나에게 상당히 도움이되었다. 행운을 빕니다.

나는 높은 수준에서 낮은 수준으로 갈 것입니다.

최대한 빨리 앱 데모

가장 중요한 것 중 하나는 개발자가 무엇을 할 것인지에 대한 아이디어를 가지고 있다는 것입니다. 데모 중에는 최근 개발중인 것들과 앱이 진행하는 방향을 지적하십시오.

높은 수준의 아키텍처를 설명

이것은 또한 매우 중요합니다. 새로운 개발자가 듣고 질문 할 수있게하십시오. 다른 개발자들과 함께 그룹 운동으로이 작업을 수행하십시오. 이를 통해 새로운 개발자는 공개적으로 정직하게 발언해도된다는 것을 알게됩니다.

멋진 온 보딩 문서를 준비하십시오

훌륭한 온 보딩 문서를 보유하면 새로운 개발자뿐만 아니라 오래된 개발자에게도 도움이됩니다. 예상, 유용한 링크 및 환경 설정 정보를 포함 할 수 있습니다. (새 컴퓨터를 구매할 때 온 보딩을 사용하여 환경을 설정 한 횟수를 말할 수는 없습니다 ...) 이것은 체계적으로 구성되어 있어야하며 모든 지점에 머물러 있지 않아야합니다. 작은 세부 사항.

질문을하도록 장려하십시오 (답변 가능)

답을 가지고 그들을 안내하되, 무엇을해야하는지 말하지 마십시오. 힌트를 주지만 마침내 스스로 알아낼 수있게하십시오.

다른 팀원이 신규 이민자를 환영하도록 지원

누군가 팀에 합류하면 동전의 양면이 있습니다. 팀은 새로운 개발자를 환영 할 수있는 도구가 필요합니다.

그들에게 작은 일을 주워 보자

데모 가능한 프로젝트에 새롭고 가시적 인 것을 추가 할 수 있습니다. 시연되면 누가 그 일을했는지, 그들이 무슨 일을 잘했는지 불러 내십시오. 이것은 실제로 자존감을 높일 수 있습니다. 그들이 가치를 더하는 것처럼 느끼면 빠를수록 팀의 일원이라고 느끼게됩니다. 더 빨리 그들이 최선을 다할 수있는 힘을 느끼게 될 것입니다.

점점 더 편안 해지면 어려운 일을하도록 격려하십시오

좋은 후보자들은 이것을 자연스럽게 할 것입니다.

내가 겪었던 (유용한) 하나의 "방향"흐름은 다음과 같은 내용을 따른 것입니다.

1. "큰 그림"으로 구성 요소가 무엇인지, 적합한 방식 및 일반적인 아키텍처를 간략하게 소개합니다.
2. 나에게 할당 된 구성 요소의 기본 로직을 처리하는 기능을 소개하는 코드 개요. 코딩 규칙 및 스타일과 관련된 내용을 다룹니다.
3. 다수의 공개 된 이슈와 우선 순위가 낮은 버그가 할당되었습니다 (나에게 할당 된 구성 요소에 주로 국한되어 있으며 상당히 단순함).
4. 나는 응용 프로그램을 디버깅하고 해독 할 수없는 것들에 대한 도움을 요청해야했습니다.
5. 수정이 끝나면 통합 릴리스 프로세스 (코드 검토, 개발자 수준 테스트 등)를 진행했습니다.
6. 할당 된 나머지 작업 / 버그에 대해 반복하십시오.

나는이 접근법 (및 그 변형)이 다음과 같은 이유로 유용 할 것이라고 생각합니다.

• 이것은 더 실습적이고 상대적으로 독립적이었습니다 (손잡이가없는 등). 따라서 새로운 사람이 코드에 익숙해지고 팀에서 작업이 수행되는 방식에 충분한 공간 / 시간을 제공합니다.
• 우선 순위가 낮은 몇 가지 작업 / 버그를 해결할 수 있으므로 팀 전체에 도움이됩니다. 새로운 사람들을 돕는 사람은 지속적으로 손을 잡을 필요가없고, 새로운 사람이 직면 할 수있는 문제 / 문제를 다루기 위해 시간을 구체적으로 계획 할 수 있기 때문에 그들에게 할당 된 작업을 처리하는 데 더 많은 시간이 있습니다.

초기 고용에는 작지만 너무 작지 않고 잘 정의 된 작업이 필요합니다. 이렇게하면 작업을 수행하는 방법을 파악하여 코드 구성 방식에 대한 느낌을 얻을 수 있습니다. 이 과정에서 질문이 나오고 그 시점에서 코드 기반을 내재화하는 데 사용할 수있는 문서 나 기타 리소스로 질문을 보낼 수 있습니다. 또한 개발, 커밋, 배포주기가 짧고 가능한 한 빨리 작업 결과를 확인할 수 있습니다.

이것이 내가가는 방법입니다

1. 프로젝트와 관련된 몇 가지 작업을 제공하십시오 (예 : 프로젝트가 데이터베이스 응용 프로그램 인 경우 데이터베이스에 연결하고 간단한 작업을 수행 할 응용 프로그램을 만들도록 요청하십시오).
2. 그들이 일의 아이디어를 이해했다는 것을 알게되면, 프로젝트의 데모를 제공하십시오
3. 그들에게 문서를 읽도록 요청하십시오.
4. 코딩 스타일과 표준에 익숙해 지도록하십시오
5. 나중에 프로젝트의 흐름을 알기 위해 디버깅 연습을하십시오.
6. 그들에게 당신이 이미 고쳐 놓은 점을 고치도록 요청하십시오 (논리를 찾기 위해).
7. 마지막으로 프로젝트의 일부로 만드십시오.

기억하십시오 : 얼마나 많은 노력을 기울이더라도 참여자가 프로젝트를 완전히 이해하기 전까지는 가장 효율적으로 작업을 수행 할 수 없습니다.

첫째-먼저 소프트웨어를 사용하여 사용자의 관점에서 어떤 문제가 해결되는지 알아 봅니다. UI가없는 경우 (예 : 백엔드 서비스 등) 사용 가능한 인터페이스를 사용하도록합니다. 소프트웨어에 대한 사용자의 관점을 새롭게 파악하는 것이 항상 좋으며, 이미 프로젝트에 포함되어 있기 때문에 새로운 직원이 귀하가 할 수없는 것을 보는 데 도움이 될 수 있습니다.

그 후, 좋은 첫 번째 프로젝트는 기존 코드베이스에 필요한 지식의 양을 최소화하면서 소프트웨어에 추가 할 애드온 또는 새 모듈과 같은 것일 수 있습니다. 새로운 것을 작성하는 것은 버그 수정을 수행하는 것보다 항상 쉬울 것입니다. 많은 소스 파일에서 많은 변경이 필요할 수 있습니다. 제 생각에는 새 직원에게 버그 수정 작업을 제공하면 회사를 끌 수도 있습니다.

새로운 것을 프로젝트에 익숙하게하는 당신의 개요는 합리적입니다. 그러나 처음부터 배울 것이 많다는 점을 명심하십시오. 이것은 일반적으로 압도적 인 상황입니다. 인내심을 가지고 동일한 질문에 반복적으로 답해야합니다. 이것은 정상적인 현상이며, 새로운 개발자는 많은 것을 배워야하며,이를 과소 평가하지 마십시오. 이 반복되는 질문에 대해 화를 내면, 그들이 질문을하지 않고 최선의 속도는 느리지 만 자주 불가능한 것들만 찾으려고 시도 할 위험이 있습니다. 또한 그들은 링고를 배워야 할 것입니다. 대부분의 팀 프로젝트는 자신의 언어를 개발합니다. 의식적으로 설명 할 때 링고를 피하십시오. 엄마에게 설명 하듯이이 물건을 설명하십시오. 다시, 인내하십시오.

또한 커피 컵을지지하는 4 장의 종이로 45 분 안에 다리를 짓는 등 평가 센터 스타일 작업을 시도하여 이미 팀의 다른 팀과 통합 할 수 있습니다. 우리는이 기술을 소프트웨어 공학의 실제 과정에서 사용하여 8 명의 학생 그룹이 3 주 동안 단일 프로젝트를 수행하기 전에 얼음을 끊게합니다. 팀 형성 단계를 가속화하는 데 도움이됩니다.

1) 코드 규칙 및 지침에 대한 설명을 제공하십시오. 또한 응용 프로그램 작동 방식 및 일반적인 코드 구조에 대한 일반적인 설명을 제공하십시오.

2) 다른 코드와 크게 독립적 인 작은 버그 나 프로젝트를 찾으십시오. 코드의 어디에서 수행해야하는지 설명하고 정기적으로 확인하십시오.

3) 크고 작은 프로젝트를 천천히 확인하면서 점점 더 큰 프로젝트를 시작하십시오.

4) 때때로 옆에 앉는다. 다른 사람이 어떻게 문제를 해결하는지 살펴보면 많은 것을 배울 수 있습니다. "아, ctrl-을 눌러 코드에서 함수를 찾을 수 있습니다."와 같은 작은 것들 매우 유용합니다.

이제 두 가지 극단 이 있음을 발견했습니다 .

• 5 분마다 질문을하는 사람. "이 Path.Join은 무엇을합니까?" Google은 먼저 답변을 받아야하며 답변을 찾을 수 없을 때만 귀하에게옵니다.

• 그리고 다른 극단적 인 사람은 한 번의 질문없이 반나절 동안 일하는 사람입니다. 질문을하는 것이 좋은 것처럼 느껴 져야합니다. 나는 그들이 먼저 스스로 시험해보기를 원한다.

이것들은 나의 공식이었고 몇 가지 새로운 사람들과 함께 사용되었습니다.이 단계는 매우 효과적이라는 것이 입증되었습니다.

a) 모든 신규 개발자에게는 2 일 동안 프로젝트 요구 사항 및 개발 프로세스에 대한 소개가 제공됩니다.

b) 적용 범위가 충분하지 않은 코드에 대한 Junit 테스트 작성 3 주 작업 할당.

c) 3이 완료되면 작은 작업을 할당하십시오

d) 복잡한 작업을 할당하고 완료합니다.

작은 작업을 할당하고 몇 가지 단위 테스트를 작성하도록 요청하고 회귀 오류를 디버그하도록 생각합니다. 너무 크거나 까다로운 것은 아니지만 발에 갖기에 충분합니다.

또한 선임 개발자, 바람직하게는 후보자를 멘토링하는 데 도움이 될 수있는 새 개발자별로 지정해야합니다.

그리고 네, 그들이 시스템에 대해 배우고있는 것을 문서화하십시오. 내부 위키 페이지가 있다고 가정합니다. 그렇지 않다면 장기 및 단기 모두에서 반드시 필요한 것입니다-사람들을 놀라게하는 놀라운 방법입니다. Wiki 페이지에는 코드 문서뿐만 아니라 알려진 제한 사항 (소프트웨어 : D), 해결 방법, 시간 / 메모리 성능 메트릭 등과 같은 내용도 포함되어야합니다.

코딩의 모범 사례와 표준 만 설명하지 말고 판독 코드의 구조를 설명하십시오. 소프트웨어가 수행해야 할 작업과이 작업을 수행하거나 수행 할 방법을 설명하십시오.

그들은해야 할 일이있을 때까지 이해하지 못하므로 실제 작업을 시작하기 전에 한 부분과 작업을 시작한 후에 두 부분으로 나눌 것입니다. 그들은 일부 코드 나 문서를보고 " WTF !? " 라고 생각 합니다. 이 일이 발생하면 누군가가 동반하여 사소한 세부 사항을 설명합니다.