페어 프로그래밍 환경에서의 성능을 어떻게 증명합니까?

최근에는 작업에 대한 성능 검토가 이루어졌으며 흥미로운 위치에있었습니다. 우리 팀은 많은 페어 프로그래밍을 수행하는데, 이는 팀 멤버 간의 기술 차이를 평균화하는 경향이 있습니다 (특히 페어 회전을 고려할 때). 일반적으로 성능 검토를 수행 할 때는 수행 한 작업을 되돌아보고 달성 한 내용과 인상 또는 기타 혜택을 협상하려는 기대를 어떻게 초과했는지를 보여줍니다.

이와 같은 환경에서 개별 성능을 어떻게 시연 (또는 측정)합니까?

퍼포먼스 리뷰에 페어 프로그래밍에 추가 한 가치를 포함 시키십시오-다른 프로그래머가 유용한 것들을 배우도록 도와 주셨습니까? (그리고 그 반대의 경우, 현인의 조언을 듣고 잘 협력 했습니까?)

성과 검토는 경쟁이되어서는 안되며, 개인적인 목표 (회사 목표와 일치하고 연초에 상호 합의 된 것으로 간주)에 대한 코칭 평가 여야합니다.

하나의 성능상의 이점을 과학적으로 다른 것으로 입증하는 것은 어렵습니다.

귀하의 가설은 페어 프로그래밍이 개발자의 성능을 높이고 품질을 향상 시킨다는 것입니다. 테스트에는 특정 아키텍처로 제한되는 요구 사항 세트를 제공하고 구현해야합니다.

이 경우 귀하의 통제는 동등한 자격, 기술 및 경험을 가진 단일 개발자 (동료가 객관적으로 판단한)에 동일한 요구 사항을 부여하고 동일한 아키텍처 내에서 제한하는 것입니다.

시간 성능의 가설을 검증하려면 쌍 프로그래머가 제어 시간의 절반 미만으로 작업을 완료해야합니다. 품질에 대한 가설을 검증하려면 객관적인 제 3자가 실험 쌍과 제어 코드를 검토하고 객관적인 QA 그룹이 어떤 팀이 무엇을 생산했는지 알려주지 않고 두 그룹의 결과를 테스트해야합니다. 페어 프로그래밍 그룹에는 더 나은 코드와 버그가 없어야합니다.

완벽한 실험은 아니지만 누군가 비슷한 것을 시도하면 들리게됩니다.

그러나 이것 외에도 페어 프로그래밍이 주어진 기능에서 단일 프로그래머보다 우수하다는 것을 실제로 증명할 수있는 방법을 알 수 없습니다.

성과 측정 항목에서 1) 개별 성장 및 개발, 2) 멘토십 및 동료 지원을 별도로 요청하십시오. 각 직원이 자기 평가를하고 리드의 피드백을 통합 할 수 있습니다. 회사 문화에 적합한 경우 동료 평가 또는 회원 평가를 고려하십시오.

올바르게 수행하면 페어링에서 최대한의 교육적 가치를 얻는 직원은 팀에 기여할 수있는 장기적인 능력에 대해 보상을 받고, 빠른 속도로 도움을주는 직원은 지식과 경험을 전달한 것에 대한 보상을받습니다. 중학교 어딘가에있는 사람들 (후배에서 상급자로 이동하는 대신 새로운 영역을 배우는)은 방정식의 양쪽 끝을 인식합니다.

실제로는 개별 성능을 평가하는 것이 가장 까다로운 경우입니다. 원한이나 경쟁의 감정을 느끼지 않으면 서하기가 매우 어렵습니다. 그러나 팀에 대한 개별 기여를 평가하고 학습과 교육을 모두 소중하게 생각하면 다소 덜 마찰력으로 작동 할 가능성이 있습니다.

쌍이 자주 바뀌는가? 그렇다면 익명 리뷰를 사용하여 게이지를 만들 수 있습니다. 예를 들어, 사람 A가 B가 작업의 60 %를 수행했다고 말하고 사람 C가 B가 작업의 30 %를 수행했으며 사람 D가 사람 B가 작업의 90 %를 수행했다고 말하면 B를 수행하는 사람에게 평균을 내릴 수 있습니다 작업의 60 % 개인 B가 자신의 쌍으로 달성 한 작업의 상대 요소가 100 점인 경우, 개인 B는 60 점의 작업을 수행했습니다!

그러나 이것은 (어디서나) 완벽하지는 않습니다. 사람들은 다른 사람보다 더 많은 신용을 줄 가능성이 높으므로 계산시이를 고려해야합니다. 이것은 또한 쌍이 서로 의심되는 환경으로 이어질 수 있습니다. 함께 일하는 사람을 좋아하지 않는 사람이 계산을 변경할 수도 있습니다.

우리 중 두 사람이 X를 만들기 위해 함께 일했다면 두 사람 모두 X를 완성하고 배포 한 것으로 인정받습니다. 문제가있을 수있는 곳은 쌍의 한 부분이 전혀 작동하지 않은 경우입니다. 이 경우, 관리자는이 모든 것에 대해 정보를 얻었으므로 성능 검토에 대한 의견을 작성할 때 해당 피드백을 사용해야합니다.

선생님이 게임 개발 커리큘럼에서 학생들을 안내하는 정확한 상황에 있습니다. 우리는 짝을 이룹니다 (교실 규모와 프로젝트 규모에 따라 2, 3 또는 4 명). 그리고 결국 우리는 프로젝트와 관련하여 각 개별 팀원과 우리 자신을 평가하고 어떤 작업이 수행되었으며 다른 팀의 프로젝트 전체. 이러한 평가에 따라 성적이 공식화됩니다.

팀을 구성하는 동안 교사는 의도적으로 강력한 프로그래머와 약한 프로그래머를 서로 배치하고 도움을주기를 원하지만 약한 프로그래머가 스케이트를 타거나 전혀하지 않는 시간의 99 %를 그들이 무엇을하고 있는지에 대한 단서가 없습니다 (이것은 고급 과정이므로 매우 실망 스럽습니다).

평가는 비공개로되어 있지만 모든 사람들이 더 이상 함께 일하기를 거부하는 사람들이 몇 명 있다고합니다.

페어 프로그래밍은 어떤 사람이 무엇을 어떻게해야하는지 생각하고 다른 사람은 코딩 원숭이를하는 것을 의미합니다. 그런 다음 어느 시점에서 그들은 전환합니다 (하나는 지루하고 피곤합니다). 둘 다 그들의 활동에 방해받지 않기 때문에 좋습니다.

어떤 사람들은 그것을 "스테로이드에 대한 코드 검토"로 간주합니다. 더 높은 품질을 의미하는 검토 된 코드를받습니다.

좋은 질문. 중요한 것은 단순히 당신이 기여하는 것이 아니라 동료들이 당신의 기여를 보는 방법입니다. 그들에게 솔직한 피드백을 요청하십시오.이 피드백이 당신이 더 나은 '무엇이든' 될 수 있도록 도와줍니다 . 진지하게, 동료가 당신의 기여를 이해하고 그들이 당신과 짝을 짓는 동안 공정한 학습을 ​​할 때만 그것을 이해하는 것이 중요합니다. 따라서 행복한 코딩, 공유 및 학습으로 수익을 올릴 수 있습니다.

페어 프로그래밍의 단점은 숙련 된 프로그래머의 생산성이 단기, 중기 적으로 가장 숙련 된 프로그래머의 생산성으로 제한된다는 것입니다. 중년 개발자의 경험과 생산성이 장기적으로 향상되었습니다.