자신을 연로 한 팀원이 SVN 개념의 기초를 배우도록 설득하는 방법은 무엇입니까? [닫은]

배경 지식으로 시작하기 위해, 나는 이번 여름에 새로운 개발자 직책을 맡았고 팀에서 가장 새로운 멤버가되었지만 벨트 아래에서 가장 많은 경험을 쌓았습니다.

지금까지 낮은 채택 비용 (시간과 노력의 측면에서)으로 인해 충분히 쉽게 위생 계획을 추진할 수있었습니다. 그러나 상황이 조금 높아졌습니다.

경험이 있지만 팀원 중 한 명이 SVN을 실제로 이해하지 못합니다. 당연히 SVN의 대양을 묘사하는 그의 정신지도의 빈 공간은 오히려 이상한 사용 패턴을 채택하게합니다.

예를 들어, "서버 당 디스크 공간이 부족해지기 때문에 개발자 당 하루에 1 SVN 커밋"정책을 선언했습니다. SVN 커밋이 전체 사본이 아닌 델타라고 설명했을 때 그는 의심의 여지없이 대답했으며 오늘날까지도 그것이 무엇을 의미하는지 완전히 확신하지 못합니다.

또한 .projectSVN에 Eclipse 구성 을 포함할지에 대한 열띤 논쟁이있었습니다 . 팀원은 수많은 무의미한 갈등이 발생했지만 우리는해야한다고 주장했습니다. SVN에 개별 개발자 구성 파일을 유지하는 데 반대했습니다. 마지막으로, 팀원은 모든 커밋 후에 "소스가 리포지토리에 커밋 된 코드"인지 확인하기 위해 전체 소스 트리를 다시 체크 아웃하는 방법을 가지고있었습니다. 이것이 그가 SVN에서 프로젝트 구성을 유지하는 데 너무 단호한 이유 였기 때문에 프로젝트를 쉽게 다시 가져올 수 있습니다. 커밋이 작업 사본을 바이트 단위의 원격 바이트로 동기화하여 다시 체크 아웃 할 필요가 없다고 설명했을 때, 팀원은 다시 의심을 품고 결국 전체 문제를 중요하지 않은 것으로 흔들 었습니다.

우리 팀은 SCM과 전혀 공유 할 필요가없는 개발자 별 설정 만 포함하는 프로젝트 구성 파일에서 SVN 충돌을 해결함으로써 시간을 낭비한다고 생각합니다. 누군가가 잘못된 가정에 따라 프로세스를 조정했기 때문에이 모든 혼란.

자신을 연로 한 팀원이 SVN 기본 사항을 더 잘 이해하도록 설득하려면 어떻게해야합니까?

IMO 프로젝트에 직접적인 문제 / 유해를 일으키는 문제와 해당 단일 개발자에게만 영향을 미치는 문제 를 분리하는 것이 가장 좋습니다 . 예를 들어, 하루에 여러 번 모든 것을 체크 아웃하는 것을 선호하면 속도가 느려지지만 다른 사람에게는 영향을 미치지 않습니다. 따라서 (그의 작업에 눈에 띄는 성능 지연이 생길 때까지) 그에게 맡기고 논쟁의 어려움에서 벗어날 수 있습니다.

Eclipse .project파일을 리포지토리에 보관하거나 하루에 한 번 커밋하는 것과 같은 다른 문제 는 팀이 가능한 한 원활하게 진행할 수 있도록 집중해야하는 부분입니다. 우선 , 다른 팀원들 에게도 문제가되는지 여부를 피드백 / 수집 해야 합니다. 다른 사람이 있으면 함께 더 많은 압력을 가할 수 있으며 필요한 경우 관리에 문제를 쉽게 제기 할 수 있습니다.

"SVN의 디스크 공간이 부족합니다"와 관련하여 실험을 통해 (잠재적으로 별도의 테스트 저장소에서) 자신의 믿음 을 반박하기 쉽습니다 . 하나의 거대한 텍스트 파일 또는 많은 파일로 변경 사항을 커밋하기 전후에 실제 리포지토리 파일 계층의 크기를 모니터링하면됩니다. 그래도 설득력이 없다면 아무것도 할 수 없습니다.

이 경우 불행히도 다른 사람이 자신의 존엄성을 상실한 것으로 "낮은 사람"의 조언을 받아들이는 권위 문제가있을 수 있습니다. 이러한 논쟁은 논리적 주장으로 해결할 수 없습니다. 이를 경영진에게 이관해야하지만 그렇게하기 전에 팀원 및 / 또는 경영진으로부터 충분한 지원을 받도록주의하십시오. 이러한 움직임은 상대방이 공개 공격으로 인식 할 수 있으므로 문제가 발생할 수 있습니다 (당신 중 하나 및 / 또는 전체 팀의 평화). 그러기 전에 3 번 생각하고 지원 동료와상의하십시오.

회사에서 Wiki를 사용하는 경우 SVN에 대한 고품질 게시물을 작성하십시오.

• 왜 사용해야합니까?
• 언제 사용해야합니까?
• 어떤 문제가 해결됩니까?

기타

그것은 CTO의 눈을 사로 잡을 것이고, 사용을 거부하는 모든 사람들은 :)를 사용해야합니다.

리더, 관리자 및 팀원으로서 저는 여러 수준에서 전문 및 성격 갈등을 해결해야했습니다. 어떤 역할을 맡아도 일반적으로 역할을 원하지 않는 경우에도 리더로 인정됩니다. 그 이유는 내가 이러한 갈등을 처리하는 방식입니다.

여기에있는 많은 사람들과는 달리, 나는이 상황을 다루는 것이 "포기"또는 "그에게 새로운 도구를 보여 주다"또는 "그의 엉덩이에 엎드리기를 기다린다"라는 것에 동의하지 않는다. 가장 중요한 것은 역할이보다 확실하게 정의 될 때 까지 기다리지 않는 것이 좋습니다 . 이러한 역할은 기다릴 수없는 사람들, 유죄 판결, 윤리 및 사람들의 참여 여부에 관계없이 중요한 상황을 처리 할 수있는 능력으로 정의됩니다.

이러한 상황에서 설명하는 사람의 유형을 처리하는 방법에는 여러 가지가 있습니다. 첫 번째 단계는 왜 자신이 자신 의 방식대로 행동 하는지 조사 하는 것입니다. 그가 알고 있거나 모르는 것과는 거의 관련이 없습니다. 그는 이전에이 정보를 쉽게 알 수 있었기 때문에 문제는 실제로 다음 두 가지 중 하나입니다. 또는 "그가 제공하는 정보를 거부하는 이유는 무엇입니까?" 이를 통해 정확히 해결해야 할 사항을 찾을 수 있습니다.

내 경험에 비추어 볼 때, 프로그래머 (나 자신을 포함하여)는 몇 가지 이유로 모범 사례 나 새로운 도구를 거부합니다.

• 출처는 신뢰할 수 없습니다. "맥의 숭배"와 "MS 숭배자"사이에서 매일 점점 더 양극화되는 산업에서; "오픈 소스 이데올로기"와 "독점적 실용성"등 ...-정보가 제출 된 경우에도 제출자 또는 작가의 편견으로 인해 제공된 정보와 부패 가능성에 대해 항상 의심하는 사람들이 많습니다. 신뢰할 수있는 것으로 확인되었습니다.
• 유사하거나 심지어 동일한 기술이나 실습으로 장기간의 나쁜 경험 . 시작할 때 완벽한 것은 없으며, 많은 기능이 기능의 1/4 미만으로 시작합니다. 제대로 구현되지 않은 단계에서 열등한 제품이나 동일한 제품으로 작업하는 데 몇 시간 또는 며칠 또는 몇 주가 걸렸을 가능성은 전적으로 가능합니다.
• "신뢰할 수있는"출처 ... 가 제시 한 정보와 충돌합니다. "신뢰할 수있는"이라는 말은 그가 신뢰하는 사람이나 단체를 의미합니다. 많은 사람들이 우리가 신뢰하는 사람들을 현실을 나타내지 않는 수준으로 끌어 올리는 경향이 있습니다. 이 출처는이 신념을 그 사람에게 부과 할 필요조차 없습니다. 가장 자주, 우리는 스스로 그것을합니다. 그것은 종종 적어도 한 가지 측면에서 우리에게 뭔가를 열망하거나 무언가를 제공합니다.
• 보안 부족 이것은 이전 포스터에서 강조되었습니다. 우리의 프로그램은 작업을 시작한 순간부터 자산이됩니다. 우리가 일하는 회사뿐만 아니라 우리와 함께 일하는 사람들을 위해. 이것은 단순히 제어 문제가 아닙니다. 우리 중 일부는 우리가 관심있는 사람들에게 깔끔한 것을 보여줄 수 있기를 원합니다. 우리 중 일부는 외부인이나 제품에 의해 피해를받지 않기를 원합니다. 어떤 사람들에게는 그것이 우리가 생각하고 느끼는 방식의 연장이기도합니다. 그것은 우리의 철학과 이념을 담고 있으며 우리의 지적 핵심을 드러냅니다. 많은 사람들에게 그것은 수업, 고용주 또는 고객을위한 것이 든 미래입니다. 어떤 사람들에게는 그것이 전부입니다. 이러한 의미에서 "보안"은 데이터 또는 코드에 적용되지 않습니다.

어떤 요소가 어떤지 알아내는 것은 종종 매우 쉽습니다. 사람을 중립적 인 환경에 놓으십시오. 관찰하고있는 내용을 일반적으로 설명하십시오. 이 행동을 일으키는 원인을 정직하게 물어보십시오. 지금은 항상 잘 진행되지는 않지만, 대부분의 성인은 비이성적으로 행동하는 사람을 돕고 싶을 때 꽤 잘 반응합니다. 그가 비이성적으로 행동하지 않을 가능성은 있지만, 아무도 실제로 무슨 일이 일어나고 있는지 이해할 수 없다는 것을 모른다.

문제가 실제로 무엇인지 알게되면 문제를 해결할 수있는 적절한 도구를 갖추어야합니다. 시나리오 # 1 인 경우 그가 신뢰하는 출처에서 연구를 수행하도록 장려하십시오 (중요합니다).자신의 발견으로 당신에게 다시 연락하십시오. 이것은 자신의 정보가 당신에게 가치가 있음을 알려줍니다. 시나리오 # 2의 경우 이전과 다른 점을 정확하게 비교하십시오. 그에게 시도해 보라고 권유하지만 그것이 잘못 될 경우 백업 계획을 세우십시오. 시나리오 # 3의 경우 정보를 사용하여 소스를 다시 쿼리하도록 요청하십시오. 그의 출처는 자신이 생각하는 견해를 가지고 있지는 않지만 한 번에 한 것 같습니다. 우리 대부분은 시간이 지남에 따라 적응하기 때문에 그의 관점이 바뀔 수 있습니다. 그가 기꺼이하지 않으면, 당신에게 그의 출처를 소개하도록 격려하십시오. 마지막으로, 시나리오 # 4의 경우, 그의 걱정이 자신의 것임을 보증합니다. (그들은 어느 정도 수준이어야합니다.)이 "새로운"도구가 어떻게 자신의 이익을 보호하고 보안을 강화할 수 있는지 보여줍니다. 그렇게 할 수 없다면

나는이 모든 것이 작동하기에는 너무 단순하다고 알고 있지만 때로는 간단합니다. 사실, 성실할수록 더 자주합니다. 그의 요구를 해결함으로써, 당신은 팀의 일원이되기 때문에 "노인"이든 아니든 팀의 요구를 해결하게됩니다. 당신이 그와 같은 페이지에 있고 싶지만 단순히 그렇지 않다는 것을 보여 주면, 당신과 함께 일하기를 권할 수 있습니다. 이 모든 작업을 수행했지만 여전히 해결 방법이없는 경우 팀 리더와의 대화가 부족할 수 있습니다.

FuzzicalLogic

소스 제어와 관련하여 많은 미신이 있습니다. 반 직관적이고 수학은 비열하며 소프트웨어 회사가 소유 한 가장 중요한 자산 하나입니다. 아직도 신뢰하지 않는 부분이 있다는 것을 인정해야합니다. 그러나 나는 그것없이 1 분 동안하지 않을 것입니다.

한 가지 해결책은 리포를 돌보는 책임을 맡을 수 있습니다. 물론, 당신이 그것을 "많은 일이라고 생각합니다. 그리고 이것은 단지 당신이 무엇을하고 있는지 모르는 것"보다는 "내가 경험이있는 영역"일뿐입니다. 더 나은 작업 기회.

"자기 자신을 노인으로 본다"는 것이 내가 생각하는 것을 의미한다면, 그는 그것을 권위와 통제의 원천으로보고 있기 때문에 그것을 포기하지 않을 것입니다. 따라서 해결 방법은 Git을 로컬로 사용하여 정상적인 커밋 단위 및 분기를 관리 한 다음 요청과 같이 하루에 한 번 svn으로 푸시하는 것입니다. Git은 P2P 시스템으로 설계되었으며 각 로컬 시스템에서 전체 저장소 사본을 갖습니다. 그런 식으로하는 것을 선호하는 다른 개발자에게 git을 제공 할 수 있으며 개별 작업 그룹 (한 명 이상의 개발자, 공식 또는 임시)이 내부적으로 사용하는 SVN의 보완 요소로 남아있을 수 있습니다. 그리고 수석 요원이 회복하거나 다른 부서 나 회사로 이사하거나 SVN 정책으로 회복 할 수없는 상황에 처하게되면 하루 종일 청소를 시작해야합니다.

그들과 대화하십시오. 봐요, 저는 선임 개발자이지만 모르는 것이 있습니다. 그것이 사업의 본질입니다. 그들이 방어 적이거나 공격적이라면 개발자와의 성격 문제이며 팀 리더 또는 팀 리더 인 경우 상사에 의해 처리되어야합니다.

몇 주에 한 번 누군가 점심 시간에 자신이 알고있는 것에 대해 이야기하고 다른 사람에게 선물하는 갈색 가방 계획을 시작하십시오.

SVN을 자세하게 설명하기 위해이 구실을 사용하고 일부 대안에 대한 일부 생각을 할 수 있습니다.

몇 주 후에 다른 사람이 갈 수 있습니다.

나는 내 개인적인 경험에 의해 뒷받침되는 힌트를 줄 것이다.

경험이 있지만 팀원 중 한 명이 SVN을 실제로 이해하지 못합니다. 당연히 SVN의 대양을 묘사하는 그의 정신지도의 빈 공간은 오히려 이상한 사용 패턴을 채택하게합니다.

예를 들어, "서버 당 디스크 공간이 부족해지기 때문에 개발자 당 하루에 1 SVN 커밋"정책을 선언했습니다. SVN 커밋이 전체 사본이 아닌 델타라고 설명했을 때 그는 의심의 여지없이 대답했으며 오늘날까지도 그것이 무엇을 의미하는지 완전히 확신하지 못합니다.

디스크 공간에 문제가 있어도 한 번에 많은 파일을 한 번에 커밋 할 수 있으므로 잘못된 해결책이라고 생각합니다. 또한 SVN은 이진 파일에 대한 델타를 저장하지 않기 때문에 큰 이진 파일을 체크인하여 많은 공간을 낭비 할 수 있습니다. 또한 하루에 한 번 이상의 버그를 수정하는 경우 같이 속하지 않은 변경 사항을 커밋해야하므로 하루에 한 번 체크인하는 것도 좋지 않습니다.

우리 회사에서 채택한 솔루션은 이진 파일을 포함하는 커밋을 거부하는 필터가 있다는 것입니다. 체크인 주석에 특수 키워드를 사용하여 커밋을 강제 실행할 수 있습니다 (SVN에 우리가하는 일을 알고 있음을 보여 주어야 함). 1 ~ 2 년에 한 번 프로젝트 관리자가 오래된 브랜치를 보관하고 리포지토리에서 제거합니다. 이 전략으로 우리는 내가 아는 공간 문제가 없습니다 (저희 저장소는 여러 가지 다른 프로젝트를 지원하고 100000 개가 넘는 개정이 있습니다).

요약하면 디스크 공간이 중요한 문제라는 데 동의한다고 말할 수 있지만 반면에

1. 하나의 모 놀리 식 일일 체크인 대신 기능 관련 체크인의 중요성;
2. 사실 하루에 하나의 큰 이진 파일을 체크인하면 어쨌든 디스크를 채울 수 있습니다.

그런 다음 디스크 공간 사용을 제어하는 ​​전략 (예 : 이진 파일 필터, 정기 백업 및 사용하지 않는 오래된 분기 정리)에 대해 논의하기위한 회의 (다른 개발자 또는 시스템 관리자와도 가능)를 제안 할 수 있습니다.

또한 SVN에 Eclipse .project 구성을 포함할지에 대한 열띤 논쟁이있었습니다. 팀원은 수많은 무의미한 갈등이 발생했지만 우리는해야한다고 주장했습니다. SVN에 개별 개발자 구성 파일을 유지하는 데 반대했습니다. 마지막으로, 팀원은 모든 커밋 후에 전체 소스 트리를 다시 체크 아웃하여 "리포지토리에 커밋 된 코드"를 확인하는 관행을 가지고 있음이 밝혀졌습니다. 이것이 그가 SVN에서 프로젝트 구성을 유지하는 데 너무 단호한 이유 였기 때문에 프로젝트를 쉽게 다시 가져올 수 있습니다. 커밋이 작업 복사본을 바이트 단위의 원격 바이트로 동기화하여 다시 체크 아웃 할 필요가 없다고 설명했을 때, 팀원은 다시 의심을 품고 결국 전체 문제를 중요하지 않은 것으로 흔들 었습니다.

우리 팀은 SCM과 전혀 공유 할 필요가없는 개발자 별 설정 만 포함하는 프로젝트 구성 파일에서 SVN 충돌을 해결함으로써 시간을 낭비한다고 생각합니다. 누군가가 잘못된 가정에 따라 프로세스를 조정했기 때문에이 모든 혼란.

빌드 서버를 사용하십니까? 우리는 완전한 프로젝트를 체크 아웃하고 매일 밤 컴파일하는 빌드 서버를 가지고 있습니다. 다음 날 아침 테스터는 테스트 준비가 완료된 제품의 설치 프로그램 (마스터 빌드가 올바르게 실행 된 경우)을 가지고 있으며 우리 (개발자)는 모든 경고 (및 오류가있는 경우 오류)가 포함 된 빌드 보고서를받습니다. 물론, 당신은 각 개발자는 다음 프로젝트의 나머지와 함께 그들을 확인할 수 있습니다. 빌드 서버에 대한 표준 구성 파일을 설정하고 그들을 확인해야하지만,이 체크인 할 수 없습니다 모든 로컬 변경.

이 시나리오에서는 전체 프로젝트를 체크 아웃하고 언제든지 빌드 할 수 있어야합니다. 또한 제품의 일부가 아니기 때문에 먼저 확인하지 말아야 할 변경 사항을 병합하는 데 시간을 소비하지 마십시오. 제품은 마스터 빌드이므로 깨끗하게 유지해야합니다. 누군가 마스터 빌드를 중단하면 (예 : 자신의 .project 파일 체크인) 변경 사항을 되돌 리거나 개발자가 문제를 해결하도록 강제 할 수 있습니다.

그가 문제를 다시 제기한다면, 다른 개발자들과 함께 회의를하고 공통된 전략을 함께 찾도록 제안 할 수 있습니다.

자신을 연로 한 팀원이 SVN 기본 사항을 더 잘 이해하도록 설득하려면 어떻게해야합니까?

최선의 전략은 갈등을 개인 수준으로 가져 가지 말고 당면한 문제와 가능한 해결책을 논의하는 것입니다. 그가 개인적 대결을 찾고 있다는 인상을 받았다면 다음과 같은 제안이 있습니다.

• 팀 역학은 어떻습니까? 다른 동료들도이 팀 동료와 비슷한 경험을합니까? 팀이 특정 행동 (작은 농담이나 관찰)을 억제하고 건설적인 대립을 장려 (회의 제안 또는 커피 브레이크 중 비공식적으로 주제를 제기) ). 때로는 좋은 팀이 방해 요소를 신속하게 격리하고 상황을 정상으로 되돌릴 수 있습니다.
• 인사 관리가 얼마나 좋습니까? 우리 회사에는 한 건의 분쟁이 있었으며 상황을 해결하기 위해 인사 책임자가 개입해야했습니다. 그것은 좋지 않았지만 때로는 작업 분위기가 너무 나빠져서 스스로 나아지지 않을 수도 있습니다. 나는 이것이 당신의 사건이 아니기를 바란다.

왜 이것을 쓰고 있습니까? 당신은 "SVN 기본에 대해 더 잘 이해하기 위해 자신을 연로 한 팀원에게 확신 시키려고"하고 싶다고 말합니다. 나에게는 갈등이 너무 개인적인 것처럼 들리는 것 같습니다. 일부 심리학자들은 우리 의사 소통의 70 %가 정서적 수준에 있다고 주장합니다.이 수준이 효과가 없다면 사람들은 감정을 다루는데 너무 바빠서 사실에 대해 말하기를 중단합니다.

따라서 요점을 설명하는 것 외에도 의사 소통을 향상시키기 위해 무언가를 시도 할 수도 있습니다. 커피와 함께 점심을 먹거나 함께 휴식을 취하거나 업무와 관련이없는 주제에 대해 짧은 대화를 나누면 의사 소통을 개선하고 동료의 관심 을 이해하기 원하는 중요한 사실로 되돌릴 수 있습니다. 그가 이런 종류의 의사 소통을 받아 들였다면, 지금까지 겪었던 갈등은 당신이 서로를 잘 알지 못하고 약간의 오해가 있었음에도 불구하고 건설적인 협력을 구축하기 위해 열려있을 가능성이 있습니다. 그가 거절한다면, 그의 편에는 더 큰 적대감이있을 수 있습니다.

이 경우 역할이 명확해질 때까지 기다려야한다고 생각합니다. 당신의 팀원이 당신보다 공식적으로 더 높은 순위를 가지지 않는다면, 당신의 일을 개선하려는 시도에 짜증을내는 것은 아무 의미가 없습니다. 시간이 지남에 따라 그는 자신이 더 잘 알고 있음을 나타내려고 계속 노력한다면 그것을 받아들이거나 자신을 속 여야합니다. 만약 그가 더 높은 순위를 가지고 있다면 , 당신은 이것이 논의 중이 아님을 이해할 수있는 방법을 찾아야합니다. 당신의 관찰은 생산성을 향상시키고 그의 위치를 ​​훼손하지 않는 것을 목표로합니다. 이것은 100 % 명확해야합니다. 역할이 명확 해지더라도 건설적인 제안이나 비판을 받아 들일 수 없다면 자부심이나 그와 비슷한 문제가 실제로 있어야합니다.

따라서 위의 모든 전략이 실패하고 좌절감을 느끼는 경우, 합리적인 방법은 물건을 포장하고 더 좋은 곳을 찾는 것입니다. 나는 3 년 전에이 경험을했고 지금 훨씬 만족스러운 회사를 찾았습니다. 어쩌면 이것은 당신의 경우가 아니지만 (물론 희망하지는 않지만)이 점을 이해하려고 노력하십시오.

그냥 내 2 센트.

SVN 작동 방식과 SVN 사용시 모범 사례에 대한 학습 자료를 제공하십시오.

@Peter가 말했듯이-전투를 신중하게 선택하고 기본을 이해하지 못하는 사람과 싸우는 데 에너지를 낭비하지 마십시오. SVN은 최첨단 기술이 아니며 한동안 여기에 있었으므로 이에 대한 충분한 정보가 있습니다.

'SVN 시간 낭비'에 대한 로그를 유지하십시오. 해결해야 할 충돌 / 체크 아웃 / 버전 문제가있을 때마다 문제 해결에 소요되는 시간을 기록해 두십시오. 매주 상당한 시간을 낭비하는 것으로 밝혀지면 그와 관리자에게 이관하십시오. 업무 프로세스의 간단한 변경만으로 생산성을 향상시킬 수 있다는 사실을 경영진이 곧 솔루션을 요구할 것이라고 확신합니다.

또는 팀이 체크인 시스템 (현재 프로젝트 및 코드베이스로 쉽게 달성 할 수있는 경우)을 사용하는 시험 주를 갖도록 동료를 설득하십시오. 작동하지 않으면 일주일이 지나면 이전 시스템으로 다시 전환 할 수 있음을 약속하십시오. 그러나 그는 스스로 시도한 후에 돌아올 수도 있습니다.

1. Subversion이 문제를 해결하도록하십시오. 당신이 말하는 방식으로, 동료는 Subversion과 관련하여 비교적 정교하지 않습니다. 이 경우 기술 솔루션이 좋은 옵션이 될 수 있습니다. 팀의 나머지 팀이 동의하고 관리자의 축복을받을 수있는 global-ignores경우 리포지토리 구성 파일에 필드를 추가하여 버전 제어에서 원하지 않는 .project 파일 및 기타 파일을 제외 할 수 있습니다 .

2. 그를 도와주세요. 그에게 일을하는 방식을 강요하는 대신, 다른 사람에게 문제를 일으키지 않으면 서 그 사람이 자신의 일을하도록 도와주십시오. 동료가 자신의 지사에서 일하고 있다면 실제로 커밋 한 것을 신경 쓰지 않아야합니다 . 그가 전체 디렉토리의 새로운 사본을 체크 아웃 할 수 있도록 자신의 .project 파일을 커밋하려는 경우 아무런 문제가 없습니다. 주의해야 할 것은 그가 .project 파일을 공통 개발 지점으로 다시 병합하지 않는다는 것입니다. 개발 브랜치 에서 ignore 속성 을 설정 하여 .project 파일을 제외 함으로써 다시 관리하기 쉬워야 합니다.

3. 위에서 지원을 요청하십시오. 그 사람과의 "당신은 내 상사가 아니에요"주장에 빠지지 말고, 그의 행동이 당신을 위해 문제를 일으킨다면, 당신의 매니저가 그 상황을 알고 있는지 확인하십시오. 관리자에게 접근하는 방법을 잘 모를 경우 다음과 같이 조언을 구하십시오. "마이크, 나는 래리와 대화를 시도했지만 지금은 지나치지 않습니다. 그는 X, Y, Z를 고집합니다. 우리 중 나머지 사람들은 문제를 해결하는 데 불필요한 시간을 많이 보냅니다. 그 사람을 어떻게 대해야하는지 알려줄 수 있습니까? "

4. 그를 무시하십시오. 팀원은 왜이 사람의 말을 듣습니까? 프로젝트에 대한 실질적인 권한이 있습니까? 정책을 시행 할 권한이없는 경우 개발자 당 한 커밋 정책을 선언하면 누가 걱정 합니까? 그가 기분이 나아진다면 그가 거북 인 Yertle Turtle 이라고 생각 하게하라.

새로운 기술을 향한 그의 발 뒤꿈치 끌기와 명백한 오염으로 사람을 해고시키고 끝내십시오. 아니면 정말로 그의 마음을 날려 GIT 사용을 시작하십시오. 만약 그가 SVn을 이해할 수 없다면 그는 반드시 GIT에 의해 날아갈 것입니다.

당신은지는 전투와 싸우고있는 것처럼 보이지만 당신은 빠져 나올 수 있습니다. 왕자의 마키아 벨리는 현상 유지를 바꾸는 것이 얼마나 어려운지를 설명했다. 나는 그 장을 다시 읽은 다음 그가 제안한 것을하지 않는 것이 좋습니다. 가혹할 수 있습니다.

수석 개발자에게 개인적으로 우려 사항을 제기하고 자신이나 다른 개발자가 아닌 일이 수행되는 방식을 건설적으로 비판해야합니다. 그런 다음 대화를하고 모범 사례 가이드를 작성하도록 제안하십시오. SVN을 더 잘 이해하는 것이 삶을 더 쉽게 만드는 방법을 보여줍니다. 궁극적으로 비용과 효율성에 관한 것입니다. 발가락을 밟지 않고 일을 개선하는 방법을 증명할 수 있다면 이길 수 있습니다.

고위 관리자가 저장소를 그대로 사용하는 이유를 이해하십시오. 그들의 관심사는 무엇입니까? 그들은 무엇을 달성하려고 노력하고 있습니까? 생산성 향상을 어떻게 도울 수 있습니까? 무엇보다도 침착하고 전문적인 접근을 유지하십시오. 좌절하기 쉽다. 자기 주장 : 직장에서의 주장 : Ken Back과 Kate Back의 어색한 상황을 다루는 실용 안내서 는 잘 읽습니다. 마지막으로 "어떻게 스스로 전환하도록 설득해야합니까?"라고 생각하십시오. 정직한 악마 옹호자가되어 좋은 대답과 질문을하는 데 도움이 될 수 있습니다.

참고로, 나는 유머를 사용하기 위해 조심할 것입니다. 경이로움을 느끼거나 마치 like 소리처럼 들릴 수도 있습니다. 따라서 나는 그것을 피할 것입니다.

기본적으로 이기지 못할 수도 있으므로 신중하게 전투를 선택하십시오. 이 경우 더 이상 신경 쓰지 않거나 다른 직업을 찾으십시오. 혹시 알아요

SVN이 합리적으로 새로운 기술이었던 8 년 전쯤에 나는 당신의 입장을 반대로 바 꾸었습니다. 수석 개발자였으며 ​​주니어 개발자가 SVN을 설치하도록 요청 / 버그했습니다 (실제로 개발자보다 IT 지원이 더 정확했습니다). 작업량 증가, 불필요한 복잡성 등에 대한 초기 의혹에도 불구하고 열린 마음을 품은 후 열렬한 팬이되었습니다.

제 생각에, 당신이 묘사 한 바에서이 문제는 분명히 팀 성격에 달려 있습니다. 그의 완고함은이 문제에 대해 팀 전체에 방해가되고 있습니다. 이 시점에서 물러나서 팀의 나머지 부분으로부터 자연스럽게 손을 강요하는 압력을 가하는 것이 더 나을 수 있습니다.

이것은 "권한이 결여 된"경우에 해당하며 자신의 두려움의 힘을 적용하여 사물을 "통제"상태로 유지하는 사람입니다.

이 문제를 해결하려면 팀원에게 영감을 준 사람이나 SVN과 같은 것을 사용하는 충동을 설명 할 수있는 사람을 찾으십시오. 그런 식으로 변화에 대한 그의 두려움과 기본적으로 "권한을 잃는"것은 놀이가 아니기 때문에 팀원이 그에게 무엇을해야 하는지를 말하는 것은 아닙니다. 이 사람에게 말을 걸기 위해 관리자 같은 사람을 사용하지 않는 것이 좋습니다. 압력 만 가중시키고 더 스트레스가 많은 상황을 만들 수도 있기 때문입니다.

저는 최근 기술 변화 추진 : 팀원들이 좋은 아이디어에 대해 행동하지 않는 이유와 그들이 어떻게해야하는지 설득하는 방법을 읽습니다 . 이 책은 기술 변경을 도입하기 전에 알아야 할 배경, 변경에 반대하거나 거부하는 사람들의 여러 패턴, 변경 구현 기술 및 이러한 기술과 모든 사람들의 사용을 극대화하기위한 전략을 제공합니다. 당신.

귀하의 게시물을 바탕으로, 귀하의 팀원이 아마도 정보가 없거나 냉소적 패턴에 빠졌을 수도 있지만, 그는 또한 비이성적 인 사례 일 수도 있습니다. 이러한 유형의 사람들에 대응하기 위해 권장되는 기술 중 일부는 대상 환경 내에서 경험을 쌓아 다른 사람들이 발생하기 전에 겪을 문제에 대한 답변을 제시하고 올바른 문제를 해결하며 열정적으로 메시지를 전달하는 것입니다. 열성적이지 않고 분석법과 도구의 장점을 명확하게 보여줌으로써 기술을 보여주고 유기적으로 판매하지만 (문제를 해결하기 위해 문제를 일으키지 않음) 다른 팀으로부터 홍보하고 구매하십시오. 그러나 만약 그가 비이성적이라면

마지막으로 이러한 기술을 사용하기 시작하면 전반적인 전략이 필요합니다. 적대적이거나 비합리적인 사람들이 당신을 늦추지 않도록하는 것이 중요합니다. 무시하십시오. 대신, 당신이 더 나은 방법을 가지고 있음을 입증하고 확신 할 수있는 사람들을 찾아서 그들 자신을 기반으로 적절한 기술을 적용하십시오. 더 많은 사람들이 당신의 지식이 제공하는 개선 사항을보고 나면 다른 사람들을 계속 설득하기 위해 그것들을 사용하십시오. 마지막으로,이 풀뿌리 노력을 통해 경영진에게 더 나은 방법이 있다는 것을 확신 시키되 이해가 가능한 시간 (시간, 돈, 품질)으로 정리하십시오.

이 사람에게 "설득"하려고하지 마십시오. 사람들 (프로그래머조차도)은 자신이 주니어라고 생각하는 사람의 합리적인 / 논리적 주장에 반응하거나 존중하지 않을 것입니다. 호흡을 낭비하지 마십시오. 대신이 사람과 신뢰 수준을 구축하십시오. 이 사람은 당신이 열려있을 때만해야 할 말을들을 것입니다.

그 동안 실제 문제가 있습니다.

1. 남자는 자신의 .project 파일을 저장소에 체크인합니다. 무시하십시오. 파일을 수정할 필요가 없으며 팀의 다른 누구도 더 잘 아는 사람이 없습니다. 놓아 줘 그것이 당신의 "노인"에게 보안 담요처럼 따뜻하고 행복한 느낌을 준다면, 그렇게하십시오.
2. 디스크 공간에 예산이 있다고 생각됩니다. 이것은 Senior가 하루에 1 번 커밋을 지시하는 이유입니다. 우주의 부족은 실제적이거나인지 적인가? 방금 인식 된 경우라도 그 인식을 바꾸기 위해 할 수있는 일이있을 수 있습니다. 즉시 처리해야합니다. 주도권을 잡으면 신뢰 구축에도 도움이됩니다.

또한이 사람이 자신의 아이디어라고 생각할 때 더 나은 SVN 사례를 채택 할 의사가 있다고 덧붙일 수 있습니다. 그것은 당신의 일부에 대한 예측을 필요로 할 것이고, 그는 더 나은 관행을 확립하는 것에 대한 신용을 취할 것입니다.