직장에서 페어 프로그래밍은 얼마나 흔합니까?

저는 항상 페어 프로그래밍에 관심을 보였지만 12 년 동안 개발 한 이래로 그들이이 관행을 사용한 곳에서 일한 적이 없었기 때문에 사람들이 그것을 어떻게 보는지에 대해 항상 회의적이었습니다.

나는 이것이 돈 / 시간 때문인지 (한 코드에서 작업하는 한 컴퓨터에서 두 사람을 발견하는 뾰족한 머리 보스 !!!! 어떻게 감히!) 또는 다른 이유로 궁금합니다.

나는 15 년 동안 같은 공연을했으며 최근에는 최근 12-18 개월 동안 애자일 기술을 채택하기 시작했습니다. 페어 프로그래밍이 사용되는 경우 결과 스토리 / 기능은 결함없이 적시에 구현되었습니다. 나는 아직도 그것이 충분히 자주 사용되었다고 생각하지 않습니다.

Agile을 채택하기 전에 다른 개발자 한 명과 여러 해에 걸쳐 키보드를 자주 공유했습니다 (3-4 개월에 한 번). Google 관리 팀은 주저하는 것처럼 보였지만 일반적으로 다음 중 몇 가지를 달성 했으므로 비공식적 인 페어링을 통해 항상 만족했습니다.

• 팀의 사일로 감소 (팀이 6-8 명인 경우 큰 승리)
• 결함이 적은 생산 된 코드
• 각 개발자는 일반적으로 기술을 집어 들었습니다.

나는 경영진이 꺼려한다고 말하지만, 아기 발걸음을 내딛고 나중에 그 기능이 더 나은 것 (비용 절감) 및 / 또는 각 (또는 한 명) 개발자가 어떤 기술을 습득했다면 (앞으로 지불) 증명할 수 있다면 당신은 당신이나 당신의 팀에 맞는 연습을 찾으십시오.

제 생각 엔 개발자들로부터 많은 저항이있을 것입니다. 대학이나 고등학교 때 세계에서 가장 동기 부여가되지 않은 사람들과 함께 일해야한다는 것을 기억하십니까? 그 사람들은 여전히 ​​존재합니다. 모든 "최고 수준의"사람들로 구성된 팀이없는 한, 이러한 유형의 설정은 그룹에서 약간의 적개심을 유발합니다.

공식적으로하지는 않았지만 문제가 발생할 때마다 개발자에게 전화를 걸어 솔루션을 함께 연구 할 것입니다. 아이디어를 바운스하고 한 사람은 다른 사람이 구현하는 동안 생각하게 해주는 훌륭한 방법이므로 아이디어를 입력하기 때문에 생각의 흐름을 잃지 않습니다.

더 많이 이루어 졌으면 좋겠다.

나는 그것을 신경 쓰지 않는다 :

1-코딩하는 동안 음악을 듣고 싶습니다. 모두가 귀에서 슬레이어 블 래스팅을 듣고 싶어하는 것은 아닙니다.

2-나는 사람들의 어깨를 매우 무례하게 바라 보는 것을 생각하고 사람들이 그것을 할 때 매우 불편 해졌습니다.

3-매우 빠르다고 생각하고 솔루션 스레드에있을 때 답을 찾기 시작할 때 중단되는 것이 가장 마지막에 필요한 것입니다.

4-포럼과 뉴스 그룹을 꼼꼼히 살펴보기 위해 휴식을 취할 수 없습니다. 어쨌든 어떤 사람들은 그것이 부적절하다고 생각할 수도 있지만 계속 개선하는 데 매우 중요합니다. 때때로 나는 너무 산만 해지지 만 일반적으로 지식 향상에 대한 혜택은 생산성에 미치는 영향보다 더 큽니다.

다른 팀에서는 다를 수 있다고 생각하지만 실제로 실제로 무언가에 얽매여 NEED가 도움이 될 때 거의 항상 솔루션을 내놓는 사람은 거의 항상 있습니다. 나는 내가하는 일을 정말 잘하지만 더 많은 일이있을 수 있다고 생각합니다 ... 어쨌든, 어려운 문제를 해결하는 것이 더 좋으며 일반적으로 혼자하는 것이 더 좋습니다. 오만하게 들릴지 모르지만 그것이 사실이 아닙니다.

나는 그것이 실제로 다른 사람들이 내 기술 중 일부를 선택하는 데 도움이 될 수 있다고 생각했지만 # 3을 고려하면 어쨌든 내 생각의 기차를 끊지 않고 질문을 거의 할 수 없었습니다.

모든 말은, 나는 때때로 그것을 시도했다. 때로는 약간의 이점이 있지만 일관된 것으로 볼 수는 없습니다. 고독한 늑대 시스템은 저에게 효과적이며 팀에게는 효과적입니다.

페어 프로그래밍은 사소하고 어려운 것을 시작하거나 수행하는 좋은 방법입니다. 더 일상적이고 간단한 작업은 단독으로 수행하는 것이 좋습니다.

나는 창업 / 차고 회사와 대기업 모두에서 여러 쌍의 페어 프로그래밍 세션에 참여했습니다. 새롭고 어려운 것을 받아 들일 때, 즉 일 년에 두 번, 몇 주 동안 일어났다. 회사에서 얼마나 자주 발생합니까?

우리는 그것을 결코 부르지 않았지만, 그 당시 우리는 항상 새로운 문제를 공격했습니다. 우리는 솔루션을 시작하기 위해 짝을 지었지만 일반적으로 세부 사항을 개별적으로 마무리 / 정리하기 위해 나눕니다. 더 이상은 아닙니다. 점점 더 희귀 해지는 것 같습니다.

흔하지는 않습니다. 지난 10 년 이상 동안 모든 상점에서 한 번 본 적이 있습니다. 가장 느리고 효율이 낮은 상점에서. 시끄럽고 스트레스가 많은 환경을 만드는 것 같습니다. 한 사람이 운전을하고 다른 사람이 전혀 생각하지 못하도록 끊임없이 말을합니다.

그룹별로 또는 쌍으로 코드 검토를 위해 팀을 구성하고 개발자에게 고유 한 공간을 제공하십시오. 최신 민첩한 유행을 쫓는 것보다 장기적으로 더 좋습니다.