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


20

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

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

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

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

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

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

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


2
귀하와 다른 개발자는 개별 사무실, 칸막이가 있거나 공동 구역에 앉아 있습니까?

@hatchet 우리는 모두 공통된 영역에서 일합니다.
Ryan Williams

답변:


12

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

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

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

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

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

1
나는 이것에 대해서도 생각할 것이다. 뷰와 컨트롤러 개발을 모델에서 분리하는 것이 정말 좋습니다. 개발자가 모델에 대한 좋은 API를 강요하기 때문입니다. 동시에 작업하기 위해 관련 테스트를 작성해야합니다.
라이언 윌리엄스

1
이 답변을 수락하고 몇 명의 팀원들과 이야기를 나눈 후 공동 작업을 유도하는 가장 좋은 방법은 동일한 프로젝트에서 역할을 나누는 것입니다. 작동하지 않을 수도 있지만, 내가 들어 본 것 중 가장 잘 맞는 것 같습니다.
Ryan Williams

7

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

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

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

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


나는 당신의 생각을 고려할 것입니다. 우리가 현재하고있는 것에 대해 정신적으로 파싱하고 수정하는 것이 약간입니다. 내가 가진 정직한 느낌은 수석 개발자로서의 내 위치에 약간의 불안감입니다. 나는 기술적 인 관점에서 편안하지 않기 때문이 아니라, 다른 개발자 둘 다 나보다 나이가 많고 (한 명은 그렇지 않은 사람), 몇 년은 더 많은 경험을 가지고 있기 때문입니다. 그렇다면 전통적인 코드 리뷰는 어색해 보일 것입니다. 왜냐하면 목을 숨쉬는 것처럼 보이지 않기 때문입니다. 그런 다음 다시 그럴 수도 있습니다.
라이언 윌리엄스

다른 것. 내가 운전사 인 경우 프로그램을 그들과 짝을 짓는 것보다 이점이 적다고 생각하십니까? 그것은 여전히 ​​모범 사례를 지적하는 방법으로 사용될 수 있으며 여전히 관계에 불균형이 있더라도 내가하고있는 일에 대한 의견과 피드백을 가지고 있습니다.
라이언 윌리엄스

페어 프로그래밍 관계가 한 가지 방법이라면, 동료와의 관계가 어려울 수도 있고 어쩌면 약간의 후원이 될 수도 있습니다. 모델링 방법에 따라 "프로그래밍 방식과 최상의 접근 방식"으로 쉽게 알 수 있습니다. 이 페어 프로그래밍에는 컴포넌트가 모두 없으므로 실제로 호출하지는 않습니다.

나는 그것이 정말로 두려워하는 것 같아요. 생각해 주셔서 감사합니다. 나는 당신의 첫 번째 답변을 받아 들일 것입니다. (다른 좋은 것도 몇 개있었습니다.)
Ryan Williams

@RyanWilliams 코드 리뷰는 "목을 깰"것이 아닙니다. 당신이 그들을 통제하는 것이 아닙니다. 우리는 ReviewBoard를 플랫폼으로 사용하고 서로 코드 에 주석을 달았습니다 . "계층 구조"는 없습니다. 이 경우의 학습은 "암시 적"입니다. 그들은 당신과 다른 개발자의 질문과 그 질문에 대한 답변 / 의견에서 당신과 그들의 코드를 읽는 법을 배웁니다. 그리고 그들은 코드베이스의 다른 부분을 알게되는데, 이는 IMHO에게 매우 유익합니다.
Johannes S.

5

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


문화와 품질에 대하여

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

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

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

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

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

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

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

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

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

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

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


다른 사람들과 마찬가지로 귀하의 의견에 감사드립니다. 내가 이것을 게시 할 때 깨달은 한 가지는 어깨 너머로보고있는 사람이되어 불편 함을 느낀다는 것입니다. 그들은 실제로 나보다 나이가 많고 경험이 훨씬 더 많습니다. 그래서 나는 CE를 둘러보고 코드 검토를 요구하는 사람들로 그들을 묘사하지 않습니다. 그들은 초보자가 아닙니다. 그러나 그들은 다른 언어와 정통 관행에서 비롯됩니다.
라이언 윌리엄스

내가 참조. 어깨 너머로 쳐다 보는 것이 편하지 않다는 생각이 듭니다. 아무도 자신이하는 모든 키 스트로크를 과장되게 추측하기를 원하지 않습니다.
idoby

4

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

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


대중적인 의견 인 것 같습니다. 코드 검토 아이디어가 마음에 듭니다. 그러나 내 마음 속에 나는 그들의 성격과 기술 수준으로, 리뷰를하는 사람이 나일 것이라고 생각할 것입니다. 하지만 더 참여할 수있는 방법이있을 수 있습니다. 나는 그것에 대해 생각 해봐야 할 것 같습니다.
라이언 윌리엄스

또한 명확하게하기 위해, 우리는 항상 페어 프로그래밍에 대해 이야기하지 않았습니다. 오히려 더 크거나 복잡한 기능을 위해 일주일 동안 중요하지는 않지만 상당 부분을 작업에 바칩니다. (이는 부분적으로 실질적인 필요성에서 벗어난 것입니다. 나는 충족시켜야 할 내 자신의 요구가 있습니다.)
Ryan Williams

2

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

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

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

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

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


내 걱정은 그들이 "멘토"되고 싶어 확신이 없다는 것입니다. 그들은 나보다 나이가 많고 하나는 (나이가 많을수록) 실제로는 몇 년 동안 더 많은 경험이 있습니다. 그러나 나는 당신의 조언의 두 번째 부분을 좋아합니다.
라이언 윌리엄스

정보가 없기 때문에 무언가를하기 전에 걱정하는 것이 당연합니다. 내 경험은 당신이 방금하면 사람들이 당신이 걱정하지 않는다는 것을 느끼게 될 것이고, 당신이 편안하고 그들이 갈 것이라는 것을 알게 될 것입니다. 그런 다음 작동하면 계속하고 그렇지 않으면 다른 것을 시도하십시오.
dcaswell 1

어쩌면 내가 보통하는 더 큰 프로젝트에 참여하게하는 것이 조금 쉬울 수 있습니다. 예를 들어 CMS를 곧 다시 시작합니다. 그래도 아이디어에 익숙해지기 위해서는 약간의 시간이 필요합니다.
라이언 윌리엄스

0

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

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

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

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

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.