소규모 회사의 페어 프로그래밍 / 협업

소규모 개발 회사에서 수석 개발자로 일하고 있습니다. 우리는 두 명의 다른 개발자뿐만 아니라 개발자 인 상사도 있지만 실제 코딩을 실제로 많이하지 않습니다.

내가 극복하려고하는 문제는 다면적입니다. 우리는 우리 사이에 많은 협력 없이도 우리 자신의 프로젝트를 수행하는 경향이 있습니다. 사실, 나는 (가장 발달 한 개발자로서) 다른 사람들의 의견 / 도움을 요구하는 것보다 더 많은 것을 요구합니다.

나는 우리의 협력을 강화하고 그것을 그들에게 표현하고 싶습니다. 더 나은 개발자가되고 더 나은 관행을 따르는 방법에 대해 몇 가지를 보여 드리고 싶기 때문입니다. 그러나 다른 개발자의 성격 유형을 고려할 때 혼자 일하는 것이 더 편하다고 생각합니다.

페어 프로그래밍에 대해 읽었으며 일부 개발자는 한 개발자가 다른 개발자보다 나아질 때 잘 작동하지 않는다는 것을 읽었습니다 (내 포럼). 그럼에도 불구하고 우리의 작업이 너무 이질적이지 않도록 협력하기 시작해야한다는 느낌이 듭니다.

내 질문은 누군가 비슷한 상황에 처해 있었는지 여부와 그들에게 무엇이 도움이 되었습니까?

나는 이것이 모든 상황에 맞는 것은 아니라는 것을 알고 있지만, 여러 가지 접근 방식을 기꺼이 제공하고자한다.

우리는 모두 공통된 영역에서 일하며 개발자에게는 개별 사무실 / 칸막이가 없습니다.

페어 프로그래밍이 왜 당신에게 해결책이 아닌지 다른 답변에서 이미 논의되었으므로 , 우리가 현재 실험하고 결과에 만족하는 것에 대해 이야기 할 것입니다.

제 생각에는 공동 작업을 늘리기 위해 할 수있는 일은 각 프로젝트에 두 사람이 함께있는 것입니다. 그들 각각은 프로젝트의 다른 부분에서 작동하지만,이 부분들은 통합되어야하기 때문에 두 개발자는 협력해야합니다. 또한 두 프로그래머가 프로젝트의 아키텍처 (계층화 및 인터페이스)를 논의한 다음 다른 역할을 수행해야합니다.

그리고이 접근 방식으로 회사에서 한 번에 처리 할 수있는 프로젝트 수를 제한하는 경우이 협업 쌍을 두 개의 프로젝트를 동시에 할당 할 수 있습니다.

우리는 최근에이 접근 방식을 실험하여 모델 중 하나 를 api와 통합하고 다른 프로그래머는 뷰 및 컨트롤러를 처리 하도록했습니다 . 이 설정의 장점은 다음과 같습니다.

1. 코드 구조는 프로젝트의 모든 측면에서 하나만 작업하는 것보다 훨씬 더 나은 방법을 제공합니다.
2. 우리는 저장소에 코드를 커밋하는 것에 대해 상기시킬 필요가 없습니다.
3. 전담 QA에만 의존하는 대신 서로 코드를 테스트하는 데 약간의 노력을 기울여야합니다.

제 생각에는 페어 프로그래밍은 제기 한 문제에 대한 해결책이 아닙니다.

페어 프로그래밍에는 두 가지 고유 한 역할이 있습니다. 관찰자 에 의해 작성된 코드에 대한 검토와 피드백이 드라이버 . 중급 프로그래머가 내린 결정을 개선하기 위해 아이디어를 전달하려는 경우, 운전자 역할을 수행 할 때 작성중인 코드를 비판적으로 검토하는 능력이 얼마나 효과적인지 의문입니다.

이러한 역 동성이 없으면 페어 프로그래밍의 이점이 사라집니다.

선임 프로그래머로서 여러분은 상사와 함께 직원 교육 및 개발에 대한보다 강력한 프로그램을 고려할 것을 제안합니다. 주니어 프로그래머에게는 기술을 향상시킬 수있는 틀이 제공되어야합니다. 일반적으로 깨달음, 코딩 표준 문서 작성, 자체 작업에서 분리 된 작업 분리 및 적절한 코드 검토 프로세스를 수행하는 등의 방법을 사용할 수 있습니다.

TL; DR : 페어 프로그래밍이 효과가 있다고 생각하지 않습니다. 대신 당신은 자신의 코드의 장기적인 품질에 대해 우려 사람을 얻는 것을 시도하고 그들이해야 원하는 답변을 찾을 수 있습니다. 이것은 비공식적으로 이루어져야합니다.

문화와 품질에 대하여

이 문제는 프로그래밍 방법론이 아니라 문화 에 관한 것 입니다. 내 경험상, 문화는 지시 할 수 있지만 사람들에게 그것에 대해 이야기하는 것은 드물다. 즉, 자연스럽게 진화하지 않았거나 기존 관행에서 너무 멀리 떨어져있는 사람들에게 특정 워크 플로를 강요하려는 것은 부정적인 결과를 초래할 수밖에 없습니다.

다시 말해, 당신은 궁극적으로 당신이있을 때조차도 최신 유행어를 윙윙 거리는 사람들 과 어울리는 것을 원하지 않습니다 . 내가 아는 대부분의 프로그래머는 정신적으로 당신을 배경 소음으로 태그합니다. 회사 벌이되지 마십시오.

제 생각에, 당신이 스스로에게 물어봐야 할 가장 중요한 질문은 "조직이 제시 한 코드의 품질과 비즈니스 가치에 만족합니까?"입니다. 그 대답이 부정적이라면, "어떻게하면 되나요?"라고 물어야합니다.

궁극적으로 품질과 가치는 오직 귀 하나 조직 내 다른 사람 만이 생각할 수 있는 인간 정의입니다.

페어 프로그래밍 및 미세 관리

따라서 조금 앞뒤가 거칠게 들릴 위험이 있으므로 페어 프로그래밍에 대해 읽으면 실제로 어떤 형태의 미세 관리 또는 다른 방식에 대해 생각 하게됩니다. MM은 대부분의 사람들을 소외시키기위한 확실한 방법입니다.

페어 프로그래밍 방어 : 페어 프로그래밍은 다른 남자의 어깨 너머로 보이는 남자에 관한 것이 아닙니다. 그것은 경영진이 얻는 것처럼 미미합니다. PP는 두 가지 수준을 동시에 생각하기 위해 두 가지 마음을 사용하는 것에 관한 것입니다. 한 사람은 높은 수준 의 큰 그림 문제를 처리하는 반면 다른 사람은 작업 코드를 생성하는 데 필요한 너트와 볼트를 처리 합니다. 그리고 겸손한 의견으로는 두 참가자가 장소를 바꿀 위치에 있지 않은 경우에는 거의 효과가 없습니다. 그들은 비슷한 개념의 전문적인 무기고와 전문적인 어휘를 공유 할만큼 충분히 경험이 있어야한다 (우리는 아직 연결되어 있지는 않지만 muhahaha).

귀하의 상황에 대해, 나는 당신이 작은 팀이기 때문에 당신은 실제 경험 (당신의 게시물이 나에게 들리는 것과 같은), 페어 프로그래밍 또는 대부분의 코드를 대부분 검토하는 유일한 사람이기 때문에 말할 것입니다. 작동하지 않습니다. 하루 24 시간 만 있습니다. 대신 몇 가지 솔루션을 고려할 수 있습니다.

• 적절한 언어 태그로 SO에 참여하거나 Code Review SE에서 검토 할 코드 스 니펫을 게시하도록 권장하십시오. 주당 최대 SO 담당자 점수를 얻을 수있는 사람에 대해 비공식적 인 경연 대회를 시작하십시오.

  지속적인 피드백을 제공하고 커뮤니티의 핵심을 따르기 때문에 초보자 개발자에게는 놀라운 일이 될 수 있습니다.

• 그들이 체크인 한 코드 중 일부를 살펴보고 장기 진화에 관한 몇 가지 질문으로 비공식적으로 도전하십시오. 대부분의 초보자 프로그래머는 코드를 읽고 유지 관리 할 수있게 만드는 것에 익숙하지 않습니다. 일단 당신이 그 문제를 머리로 가져 오면, 그들은 당신이나 다른 출처로부터 더 많은 정보를 스스로 찾을 것입니다.

페어 프로그래밍이 환경에서 도움이 될 것이라고 생각하지 않습니다. 숙련되지 않은 개발자가 기술을 익히는 데 도움이되지는 않습니다 . 다양한 기술 수준의 엔지니어와 쌍 프로그래밍에 대한 프로그래머의 질문 도 있습니다 . 지식 공유 및 적은 오류와 같은 이점이 있지만 페어 프로그래밍에는 더 많은 시간 투자가 필요합니다. 3 명의 개발자로 구성된 팀과 개발 배경 / 경험이있는 4 명만 있으면 페어 프로그래밍 루틴을 유지하는 것이 어려울 것 같습니다.

귀하의 상황에서 더 나은 대안은 코드 검토, 특히 적절하게 조정하는 경우라고 생각합니다. 코드 검토는 한 사람이 작은 코드를보고 한 시간 또는 두 시간 동안 한 방에서 여러 사람 (팀 전체)에게 피드백을 제공하여 전체 구성 요소의 설계 및 구현을 살펴볼 수 있습니다. 이들은 특히 팀의 지식, 경험 및 요구에 따라 수행되는 작업에 따라 다양 할 수 있습니다. 여러 사람이 문제를 찾고, 제안을 제공하고, 의견을 검토하기 전에 의견을 자신의 작업에 통합하기 위해 리뷰의 결과를 읽음으로써 지식을 얻는 것을 통해 지식 공유 측면을 얻을 수 있습니다. .

내 질문은 누군가가 비슷한 상황에 있었는지 여부와 그들에게 효과가 있었던 것입니다.

당신이 경험을 초대하기 때문에 여기에 내가 한 일이 있습니다. 나는 저 위험 접근법을 선택했고 나보다 수십 년 어린 누군가에게 함께 일하는 데 시간을 보내라고 요청했다. 우리는 활동에 라벨을 붙이지 않았습니다. 저 외에는 아무도 우리가 새로운 기술을 시도한다는 것을 알지 못했습니다.

정확히 어떤 세부 정보를 연관 시킬지 잘 모르지만 프로세스는 매우 효과적이었습니다. 그는 멘토가되기를 원했습니다. 이것은 미리 힌트가 없었습니다. 그래서 매우 긍정적 인 방법으로 양방향으로 커뮤니케이션을 시작했습니다.

사실, 나는 (가장 발달 한 개발자로서) 다른 사람들의 의견 / 도움을 요구하는 것보다 더 많은 것을 요구합니다.

현재하고있는 일의 논리적 진행으로 이것을 구성 할 수있는 것처럼 들립니다.

이 질문을 제기 한 지 몇 개월이 지나서 결과에 만족한다고 말해야합니다. 그러나 처음에 내가 받아 들인 것은 아닙니다. 이 팀은 소규모 팀이므로이 솔루션이 모든 사람에게 적합하지는 않습니다.

모든 사람이 자신의 작업을 수행하도록하는 것이 가장 좋습니다. 그리고 시간이 지남에 따라 우리는 문제에 부딪 치면 다른 사람들을 도와달라고 서로 신뢰를 발전 시켰습니다. 나는 누군가가 누군가의 어깨 너머로보고 싶어한다고 생각하지 않습니다. 나는 때때로 누군가의 뒤에 앉아서 때로는 간청하지 않고 문제를 해결하도록 도와줍니다. 때때로 나는 추가 할 것이없고, 그것들을 조금 귀찮게 할 수도 있습니다. 그러나 그들은 내가 그들을 괴롭히지 않는다는 것을 이해합니다. 나는 주로 내가하고있는 일을 잠시 중단하고 약간의 협업을 소개합니다.

내가 찾은 것은 (소규모 팀에서) 시간이 지남에 따라 올바른 사람들이 다른 사람들이하는 일을 선택하고 동기화한다는 것입니다. 항상 잘못하고있는 일을 미세 관리하거나 다른 사람에게 말할 필요가 없습니다.

때때로 전문가 나 배우는 사람 또는 둘 다인 동안 누군가와 함께 앉아서 문제를 해결하십시오. 왜 다른 방법과는 반대로 어떤 방법으로 행동하거나하지 않을 것인지 설명하십시오. 좋은 아이디어는 일반적으로 포착되는 반면 다른 아이디어는 남겨집니다. 그리고 마지막 날에는 다른 일을하고 있지만 공통의 목적을 공유하는 생산적이고 응집력있는 사람들 그룹이 있습니다.