팀원들이 몇 가지 기본 규칙을 따르도록 설득하는 방법

팀원과 문제가 있습니다. 간단히 말해 : 우리는 경쟁을위한 프로젝트에서 일하는 3 명의 학생입니다. 이 프로젝트는 두 가지 응용 프로그램으로 구성되어 있습니다. 하나는 Windows 용이고 다른 하나는 Android 용입니다 (제 동료가 개발해야합니다). 우리의 코드베이스는 절대 교차하지 않으며 앱은 타사 도구를 통해 통신합니다.

문제는 다음과 같습니다. 작년에 대기업에서 인턴십을하면서 팀에서 일한 경험이 있으며 코드에 대한 코딩 표준을 시행하려고합니다. 또한 코드를 푸시하거나 아이디어를 작성하고 프로토콜을 문서화하는 데 사용할 수있는 git repository / wiki / 협업 소프트웨어를 설정했지만이 도구를 사용하는 유일한 사람 인 것 같습니다.

나는 품질 코드를 작성하고 모든 단계를 문서화하는 것이 장기적으로 우리에게 도움이 될 것이라고 말했지만 그 이점을 보지 못하는 것 같습니다. 또한 몇 가지 통합 테스트를 추가하려고했지만 현재 도구를 사용하여 삶을 더 쉽게 만들지 않는 한 통합 테스트의 유용성을 확신 할 수는 없다고 생각합니다.

피어의 코드의 대부분은 컴퓨터에 있으며 공통 코드베이스를 공유하지 않으며 내가 알았 듯이 USB 스틱을 통해 코드를 만나고 공유하여 조각을 통합했습니다.

내 질문은 : 나는이 문제에 너무 가혹한가요? 터무니없는 규칙을 시행합니까? 이것은 작은 프로젝트이며 요구 사항은 매우 명확합니다 (응용 프로그램의 기능을 지정하는 문서를 만들었습니다) .3 명의 숙련 된 개발자가 3-4 일 안에이 작업을 수행 할 수 있으므로 쓰기 품질의 복잡성이 추가로 표시되지 않을 수 있습니다 현재 방법이 작동하는 한 코드.

git 등을 사용하여 코드 문서화의 이점을 보여줄 수있는 방법이 있습니까?

내 질문은 : 나는이 문제에 너무 가혹한가요?

당신은 말을 물로 인도 할 수는 있지만 그를 마실 수는 없습니다.

"너무 가혹한"지 말하기는 어렵지만, 팀원이 원하는 모든 인프라를 채택 할 것을 기대하는 것은 비현실적 일 수 있습니다. 그리고 팀이 잘 협력하고 있다면 위키를 사용하여 세 사람 사이에 의사 소통하는 것은 과잉 일 것입니다.

기대치를 축소하고 모르는 도구를 사용하지 않고도 목표를 달성 할 수있는 방법을 찾으십시오. 그들이 git 사용법을 모른다면 어쨌든 많은 이점을 얻지 못할 것입니다. 그러나 하드 드라이브 오류 또는 기타 재난이 발생할 경우 모든 코드가 백업되도록하려면 프로젝트 폴더를 Google 드라이브, Dropbox 또는 유사한 온라인 파일 공유 서비스에 정기적으로 복사하도록 요청하십시오. 당신도 똑같이해야합니다.

내 태도는 소규모 프로젝트에서 이러한 일을하는 법을 배울 수 있다면 큰 프로젝트가 나올 때 준비 될 것입니다.

그들이이 프로젝트로 좋은 개발 관행을 따를 경우, 미래의 고용주에게 보여줄 코드를 갖게 될 것이며, 직원으로서 가치있는 경험을 갖게 될 것입니다.

더 확실한 자료를 원한다면 Pragmatic Programmer 또는 Code Complete를 참조하십시오 .

반면에 약간의 여유를 줄이십시오. 프로젝트가 경쟁 직후 비닝되는 개념 증명 인 경우 원하는대로 작업을 수행하도록하는 것이 좋습니다. 모범 사례의 정신적 오버 헤드없이 코드를 처음 작성하는 데 어려움을 겪을 수 있습니다.

당신이 묘사 한 규칙이 전혀 기본이 아닌 것이 두렵습니다.

가장 쉬운 작업 IMO는 팀원이 일부 코딩 표준을 사용하도록 설득하는 것입니다. 그리고 이것을 달성하는 간단한 방법은 형식이 잘 지정되고 스타일이 좋지 않은 동일한 코드 스 니펫을 보여주고 코드를 읽고 코드의 내용을 이해하고 스스로 판단하도록하는 것입니다.

자식 저장소를 사용하면 초보자에게 고통을 줄 수 있습니다. Android 프로젝트에서 3 명으로 구성된 팀에서 일할 때 처음에 버전 관리 시스템에 많은 문제가있었습니다. 그래서 당신의 팀원들도 어려움을 겪을 것으로 기대합니다.

숙련 된 개발자가 프로젝트를 완료하는 데 3-4 일이 소요될 것이라고 언급했습니다 (팀 시간이 2-3 배 더 걸린다고 가정합니다). 이 기간은 매우 짧기 때문에 새로운 도구를 사용하면 장기적으로 도움이 될 것이라는 주장은 효과가 없습니다.

당신이 할 수있는 일은 짧고 간단한 데모를 만들어 도구가 어떻게 사용되는지 보여줍니다. 처음에는 가장 기본적인 기능을 다루고 옆에 앉아서 도구 사용을 도와주십시오. 자식 구성, 위키 페이지 구조 생성 등과 같은 모든 작업을 수행 할 수 있도록 준비하십시오.

편집 : 의견에 대한 대답으로, 명확한 작업, 예측 및 마감 시간을 설정하고 소요 시간을 추적하는 것이 자식 또는 유사한 도구를 사용하는 것보다 중요하다고 생각합니다. 나중에 응용 프로그램에서 작업 할 계획이라면 이미 수행 한 작업과 각 기능의 소요 시간을 추적하는 것이 매우 중요합니다. 따라서 작업 관리에서 시작하여 사용하려는 도구로 넘어가는 것이 좋습니다.

나는 그가 당신이 그런트 일 때 할 수있는 일 을 하기에 , Joel Spolsky 자신의 생각을 실제로 좋아 합니다. 요약:

1. 그냥하세요 -makefile을 작성하고 매일 빌드 서버를 만드십시오.
2. 아무도 소스 제어 또는 버그 데이터베이스를 사용하지 않습니까? 직접 사용하십시오. 누군가가 작업에 대해 버그를보고하면 버그 데이터베이스를 사용하여 버그를보고하도록 정중하게 요청하십시오. 그렇지 않으면 머리에 똑바로 두거나 고칠 수 없습니다. 사소한 프로젝트에는 소스 제어만으로 해결할 수있는 상황이 있습니다. 코드에 대해 소스 제어를 직접 사용하고 그러한 상황이 발생할 때 하루를 절약하기 위해 영웅적으로 급습하십시오. 이 일이 몇 번 발생하면 확신 할 것입니다
3. 우수성 창출 -지정, 일정 수립 등 자신에게 맞는 일을하십시오. 이것은 작업 프로젝트처럼 보이지 않으므로 고용 할 수 없기 때문에이 조언을 끝까지 취할 수있는 것처럼 보이지 않습니다. 당신의 메시지를 믿는 새로운 팀원
4. 귀중한 사람이 되십시오 -팀에서 영향력을 강화하는 데 크게 기여하고 있음을 보여주십시오. 그렇지 않으면 결과보다 프로세스 및 도구를 중요하게 생각하는 사람으로 알려질 위험이 있습니다.

문서, 위키, 버전 관리 소프트웨어, 방법론 등은 시간이 지남에 따라 배운 경험과 교훈입니다. 여러 프로젝트 및 아마도 여러 팀의 작업. 그리고 그것은 이미 이미 고용되어 있거나 산업을 진지하게 받아들이는 사람들을 고수합니다. 그들은 학생이므로, 그들의 관심은 아마도 미래에 일어날 일보다 부족할 것입니다. :)

그러나 귀하의 질문에 답하려고 노력하십시오.

당신이 그들과 팀에 있다면 당신은 그들의 이익에 도움이되는 방식으로 중요하다고 생각하는 것을 적용해야 할 것입니다. 예를 들어 : 그들은 USB를 공유 할 때 코드를 많이 깨는 것에 대해 불평해야합니까? 그런 다음 SVN (git 대신)을 버전 관리 도구로 사용하는 간단한 방법을 제공합니다.

나는 또한 arnaud의 의견에 동의합니다.

이러한 도구를 사용할 때 이러한 도구의 이점을 모두 보았으므로 도구의 가치를 보았으며 그 사용법을 이해하는 이유입니다. 팀원이 현재 수행하는 방식에 부가가치를 보지 못하면 적용하지 않습니다. 그리고 슬프게도 이것은 모든 수준의 경험을 가진 사람들로 구성된 팀에게도 중요합니다.

이 접근법에는 문제가 있습니다.

1. 당신의 접근 방식은 대칭이 아닙니다. 다른 팀원은 변경해야하지만 모범 사례는 배우지 않습니다. 이와 같은 상황에서 규칙을 시행하는 것은 어렵습니다. 더 나은 접근 방식은 모든 팀원으로부터 좋은 규칙과 관행을 수집하는 것이며 모든 사람은 결과 문서를 읽습니다.

2. 학습이 어렵다. 다른 사람들의 규칙은 프로그래머가 기대하는 논리적 구조를 갖지 않기 때문에 의미가 없습니다. 이해되지 않는 규칙을 시행하는 것은 유용한 활동이 아닙니다.

3. 모두가 다른 것을 배웠습니다. 다른 배경을 가진 프로그래머들이 다른 것들을 배운 것은 당연합니다. 그들의 강점과 코드 작성 스타일이 다릅니다. 그들이 사용하는 도구는 다릅니다. 한 세트의 규칙 / 도구 / 스타일을 적용하는 것은 개발자가 오랜 세월 동안 학습 한 힘을 상실하기 때문에 악몽이 될 것입니다.
4. 변경에는 시간이 걸립니다. 규칙을 발명 한 사람은 규칙을 따르는 데 꽤 쉬운 시간이 있지만 다른 모든 사람들은 어려움을 겪고 있으며 새로운 규칙을 배우는 데 시간을 보냅니다. 이것이 팀의 모든 사람이 규칙을 변경할 수있는 이유 중 하나입니다.
5. 전체 팀을위한 도구 / 코딩 규칙 또는 스타일을 선택하는 것은 어려운 작업 입니다. 시간이 지남에 따라 천천히 수행 할 수 있으며 작동하는 것과 작동하지 않는 것을 테스트 할 수 있습니다. 50 개의 규칙을 따르기 위해 2 주 동안 팀을 제공하는 것은 효과가 없습니다.

나는 대학 에서이 문제를 발견했습니다. 많은 사람들이 단순히 다른 (그리고 더 전문적인 접근 방식) 작업 방식을 배우려고하지 않습니다.

나는 당신이 시스템을 가지고 있고 시스템을 사용하는 방법을 설명하면 많은 사람들이 그것을 시도하려고합니다. 또한 리포지토리는 사용되는 도구가 매우 적으며 사람들은 일반적으로 dropbox와 같은 것을 사용한다고 생각합니다.