페어 프로그래밍은 언제 작동합니까? 언제 피해야합니까?

우리는 항상 노예로 짝짓기 프로그램을하는 대신 팀에서 선택적으로 짝짓기 프로그래밍을 사용합니다. 다음과 같은 상황에서 가장 효과적이라고 생각합니다.

• 문서 나 코드를 스스로 작성하는 대신 새로운 팀원을 프로젝트에 몰입시킵니다.
• 후배와 상급자들이 함께 일하게하는 것 (보다 숙련 된 개발자의 기술과 요령을 보여주는 데 도움이 됨)
• 누군가가 결함을 추적하려고 할 때 종종 신선한 눈과 짝을 이루는 데 도움이됩니다.

페어 프로그램은 언제 사용합니까?

페어 프로그래밍을 피해야 할 때? 왜?

Laurie Williams가 작성한 연구에 따르면 페어 프로그래밍은 산업 팀에서 가장 잘 작동합니다.

• 쌍은 사양, 디자인 및 복잡한 프로그래밍 작업 에서 작동 합니다 . 실험에 따르면 한 쌍의 간단한 작업을 수행 할 때 품질이 향상되지 않았지만 속도가 향상 될 수 있습니다. 또한 쌍 "프로그래밍"에는 종종 코드 작성 이외의 활동이 포함됩니다.
• 페어링의 각 개인은 거의 동일한 수준의 전문 지식 을 가지고 있습니다. 페어 프로그래밍은 훈련에 유용하지만 페어는 거의 같은 수준에있을 때 가장 관여합니다.
• 역할은 규칙적으로 회전 - 규칙적으로 회전하면 개인이 운전하려고하거나 감지 할 때 가장 많이 기여하는 경향이 있으므로 현재 부조종사를 계속 참여시킬 수 있습니다.
• 쌍은 정기적으로 회전합니다 . 팀은 자신이 구축하고있는 시스템의 다른 부분에 대해 알면서 편안함을 표현했습니다. 페어 로테이션은 지식 이전을 도와 프로젝트의 특정 위험을 줄입니다. 학업 환경에서 종종 쌍이 배정되지만 산업계에서는 일반적으로 스탠드 업 중에 자주 자체 배정됩니다. 두 경우 모두, 두 개인이 짝짓기 활동에 가치가있는 참가자를 기꺼이 참여할 때 가장 효과적입니다.

개인적으로 경험 한 바에 따르면 XP 팀은 개발 시간 쌍 프로그래밍의 평균 60 %를 평균으로 사용합니다. 남은 시간은 개별 개발에 소비됩니다. 초기 디자인을 만들기 위해 짝을 이루는 것은 드문 일이 아니며, 몇 시간 동안 디자인에 대해 혼자 작업 한 다음 다시 모여 까다 롭거나 어려운 코드 부분을 완성합니다.

또한 페어 프로그래밍이 약 1.5 ~ 2.5 시간 블록에서 가장 효과적이라는 것을 알았습니다. 훨씬 적은 것은 셋업하기 위해 너무 많은 오버 헤드를 요구하는 경향이있는 반면, 더 많은 것은 쌍이 복잡하고 피곤 해지는 경향이 있습니다. 불안정하고 피곤하면 의사 소통이 원활하지 않아 결함이 시스템에 유입 될 수 있습니다.

페어 프로그래밍은 매우 적은 상황에서 저에게 효과적이었습니다.

페어 프로그래밍이 실패하는 경우

짧은 이야기는 소프트웨어를 개발하는 주요 방법으로 페어 프로그래밍이 작동하지 않는다는 것입니다. 특히 특정 문제에 중점을 둔 경우 하루 또는 일주일 동안 프로그램을 페어링 할 수 있습니다. 그러나 그 후? 끝났어요 토스트. 나는 누군가를보고 싶지 않으며 누군가와 이야기하고 싶지 않으며, 인간 회사에 다시 어울릴 때까지 동굴에서 적어도 며칠이 필요합니다.

슬픈 이야기이지만, 재미있는 점은 그것이 끝난 방식에 따라 지금 훨씬 더 행복하다는 것입니다. 나는 집이나 커피 숍에서 일하는 계약에 행복하게 종사하고 있으며, 새로운 친구를 사귀고 샌프란시스코를 더 많이 탐험했습니다. 자전거와 노트북이 있으며 마감일을 지키고 코드를 정기적으로 체크인하는 한 내 시간은 내 자신의 시간입니다.

페어 프로그래밍과 관련된 큰 문제를 먼저 나열하고 나중에 세부 사항과 일화를 알려 드리겠습니다.

1. 초점을 분할하십시오.
2. 실험이 없습니다.
3. 높은 메모가 없습니다.
4. 소유권에 대한 자부심이 없습니다.
5. 탈출구가없는...

... 동료들에게 내가 본 것을 보았는지, 뭔가 빠진 것이 있으면 무엇이든, 어떻게 작동하는지, 사람들이 계속 어떻게 할 수 있는지 보지 못했습니다. 그들은 내가 잘하고 있다고 말했다. 정착하고 적응하는 데 시간이 걸렸다. 처음에는 모두에게 힘들었습니다.

결국, 나는 나 자신으로 퇴각했다. 눈을 멀게하는 두통, 불면증, 그리고 두근 거리는, 코드를 작성해야 할 때, 입력에 대한 응답을 중단했습니다. 나는 화면을 응시하고 아무것도 볼 수 없었다. 누군가 예기치 않게 나에게 이야기 할 수 있었고 나는들을 수 없었습니다. 나는 직업의 엄격한 요구 사항을 충족했지만 거기에 없었습니다. 나는 하루 동안 방금 보여준 모든 것을 다 써 버렸다. 다른 파트너가 입력 할 때 iPhone을 확인하기 시작했습니다.

마지막으로-3 개월 후에 부끄러워하고 처음으로-페어 프로그래밍시 팀에 적합하지 않다는 이유로 해고당했습니다.

혼자가 아니야

나는 이것을 이해하기 위해서뿐만 아니라 그것에 대해 이야기 할 수 있도록 썼습니다. 페어 프로그래밍은 대부분의 사람들에게 효과적이며 솔로 프로그래밍보다 훨씬 쉽고 빠르다는 가정이 있습니다. 이것은 사실 일 수도 있고 아닐 수도 있지만 장기적으로는 쌍 프로그래밍이 효과가 없습니다. 페어 프로그래밍이 작동하지 않는 다른 사람들이 많이 있습니다. 우리도 역시 ...

우리 팀은 창업 이래로 주로 "익스트림 프로그래밍"스타일 상점의 일환으로 페어 프로그래밍을 해왔습니다. 페어 프로그래밍이 기본 상태입니다 . 사람들은 홀수 또는 때때로 조사를 위해, 특히 적대적인 장비를 엉망으로 만들려고 노력하는 경우에만 싱글 톤으로갑니다.

"주니어 / 시니어"만이 갈 수있는 유일한 방법은 아닙니다. "중급 / 주니어"가 유용합니다. 그것은 중간 수준의 사람이 다른 사람과 정보를주고 받도록하여 얻은 지식을 합성하는 데 도움이됩니다. "중급 / 중급"과제는 두 사람이 함께 협력하여 지식을 공유하고 의사 소통하며 팀의 일원으로 일하는 것입니다. 두 명의 선임 직원이 있더라도 서로 다른 전문 분야를 보유하고 있으며 다른 접근 방식을 사용할 수 있습니다. 지식 공유 측면은 누군가가 프로젝트에 대해 모호하게 "속력을 발휘"한 후에 끝나지 않습니다. 오히려 페어 프로그래밍은 학습 조직 의 전형입니다 . 새로운 기술과 모범 사례가 빠르게 확산됩니다.

페어 프로그래밍은 코드의 품질 (결함이 적은) 및 코드의 정신 (단지는 의도 일을하지 않습니다를 유지하는 데 도움이,하지만 무엇을 그것을 해야 ... 이상적으로 여러 주 rabbit-을 거치지 않고 구멍이 잘못되거나 격렬하게 충돌하는 두 가지 다른 옳은 일). 프로그래머가 집중력을 유지하는 데 도움이됩니다. 여기서는 주당 80 시간의 근무처 인 실리콘 밸리 중심부에서 하루에 8 시간 동안 강렬한 코딩을 수행하므로 일주일에 40 시간 만 일할 수 있습니다. 서로 떨어져. (또한 페어 프로그래밍을 더 오래했다면 아마 뒤집어 지거나 적어도 타 버릴 것입니다.) 이는 업무 / 생활의 균형에 적합하며 빠른 처리 (특히 대기 시간이 짧은 처리)가 필요한 경우 조직에 도움이됩니다.

100 % 복숭아와 크림이 전부는 아닙니다. 페어 프로그래밍은 때때로 특정 문제에 유용한 직관적 인 두뇌 프로세스를 적용하는 데 방해가된다는 것을 알게되었습니다. 가장 최근에는 메모리 누수 작업에서 한 쌍의 유무에 관계없이 시간을 보냈습니다. 하나가 없으면, 나는 한 순간에 내가하고있는 일을 정확하게 설명하는 방법을 모르고 주위를 어지럽히고 실험을 시도하는 것이 더 자유로웠다. 싱글 톤 작업의 이점도 있습니다. 탄젠트를 시작하고 변덕스러운 리팩토링 (XP 방법으로 평가)을 수행 할 수 있습니다.

그러나 모두가 혜택은 비용을 훨씬 능가하며, 창업 단계부터 대기업 인수 및 후속 통합에 이르기까지 페어링은 우리를 위해 훌륭하게 효과를 발휘했습니다. (즉, 페어 프로그래밍은 확장을 통해 약간의 전환에도 불구하고 문화의 연속성을 유지하는 데 도움이되었습니다).

(우리는 Perl에서 ~ 4,000,000- $ 40,000 정가의 소프트웨어 어플라이언스를 개발합니다.)

"Pair Programming"설정에서 작업 한 적이 없지만 목록에있는 세 가지 환경의 일부라고 주장 할 수 있습니다. 언급 한 시나리오는 도움 / 훈련 단계에 따라 "정규 프로그래밍"으로 보입니다. "페어 프로그래밍"이 시작되기 전에이 모든 것을 수행하지 않았습니까? 페어 프로그래밍, 팀 내에서 공유하는 프로세스가 즉각적인 작업이나 당면한 문제를 해결하는 순간을 멈추지 않는 좀 더 헌신적 인 접근 방식이 필요하다고 가정합니다. 그러나 이것이 내가 "알고있는"것이 아니라 "생각하는"것입니다.

개인적으로 페어 프로그래밍을 위해 저는 지식을 배우고 공유 할 수있는 기회를 얻을 수있는 팀에서 일하고 싶습니다. 당신과 함께 일하는 모든 사람들이 당신보다 앞서있는 불균형 팀이거나, 그보다 훨씬 낮은 수준의 팀은 매우 흥미롭지 않을 수 있습니다. 또한, 나는 그들의 신념을 가지고 설득하기 어려운 사람들과 일하는 것을 두려워합니다.

우리는 지난 몇 달 동안 팀에서 페어 프로그래밍을 실험 해 왔습니다. 나는 당신이 다른 팀원과 아이디어를 신속하게 and 수 있고 검증 / 무효화 할 수 있기 때문에 새로운 기술 (새로운 기술, 새로운 기능 등)을 작업 할 때 매우 유용하다고 생각합니다. 또한 병렬 검토를 통해 버그를 방지 할 수 있습니다.

다른 팀원은 ATDD를 수행하기 위해 테스트와 함께 페어 프로그래밍을 사용하려고 시도했으며 결과에 매우 만족했습니다. (계산에 따르면 개발 비용이 20 % 증가하면 테스트 시간이 약 50 % 감소했습니다)

안녕히 주무세요

우리는 익스트림 프로그래밍과 페어 프로그래밍의 관행에 대해 여러 번 토론했습니다 . 과거에는 프로그래머가 집중과 고립이 필요했기 때문에 프로그래밍이 단독 활동이라는 것을 이해할 수있었습니다. 당시 프로그래머들은 코드에 효율적으로 집중하고 멋지고 창의적인 결정을 내릴 수있는 정신 상태 인 존 에있었습니다.

한 프로그래머가 서로 인터럽트한다고 가정하면 페어 프로그래밍은 위험한 것처럼 보입니다. 반면에 두 프로그래머가 함께 일하는 것을 방해하는 것이 더 어렵습니다. 예를 들어 솔로 프로그래밍에서는 인터럽트가 더 쉬워 지므로 솔로 프로그래머가 "영역"에 머무르는 것은 거의 불가능합니다.

데드 라인이 바로 근처에있을 때 코드 품질은 또 다른 것입니다. 사람들은 항상 서두르거나, 페어 프로그래머 또는 솔로 프로그래머가 될 것입니다. 특정 모범 사례를 적용하지 않고 단위 테스트를 잊어 버릴 것입니다.

나는 쌍 프로그래밍을 고수 할 것이다. 한 프로그래머가 사라지면 위험에 처할 때마다 프로세스를 문서화하고 다른 사람들에게 그 작동 방식을 가르쳐 줄 다른 사람이 항상있게됩니다.

사소한 복잡성에 대한 작업은 페어 프로그래밍의 좋은 후보가되기 때문에 코드 기반의 일부를 아는 한 명의 개발자가 아니라 여러 사람이 코드를 이해하게됩니다. 또 다른 경우는 누군가가 기술을 전수하고자하는 경우입니다. 예를 들어 단위 테스트에 능숙한 사람이 개념에 익숙하지 않은 사람과 짝을 이뤄서 무언가에 대한 초기 습관을 얻는 데 도움이 될 수 있습니다.

페어 프로그래밍을 피할 수있는 위치에 대해서는 작업을 두 그룹으로 나누고 각 개발자가 작업을 수행하기 위해 개별적으로 일부 작업을 수행 할 수있는 작업을 간단하게 수행하십시오. 일부 작업에는 약간의 타이핑이 필요할 수 있지만 너무 크지 않아 각 개발자가 몇 가지에 대해 무차별 대입 방식을 취하면 수행 할 수있는 더 좋은 방법을 찾으려고 노력할 가치가 있습니다. 시간.