짝 프로그래밍 가이드 0.9

짝 프로그래밍 가이드 0.9

1. 개요
본 문서는 애자일 팀에서 어떻게 짝 프로그래밍(Pair Programming, 이하 PP)을 진행 할 것인지에 대한 가이드를 제공한다.
PP는 기술적인 측면보다 사회 문화적인 측면에서 접근/진행하여야 한다. 따라서 대화를 자주 나누고, PP의 목표가 서로가 함께 발전해 나가면서 이를 통해 좀더 좋은 SW를 만들 수 있게 해준다는 것을 인식하여야 한다.
 

2. PP진행의 목적 및 효과
-    코드의 품질을 향상시킨다.
-    개발에 대한 집중력을 높인다.
-    팀 내 커뮤니케이션을 증진시킨다.
-    지속적인 코드 리뷰가 될 수 있다.
-    협업을 통해 서로가 서로를 발전 시킬 수 있다.
-    개발이 좀더 즐거워 질 수 있다.

3. 기본 마음가짐
-    서로를 신뢰하며 공경한다.
-    대화를 논쟁으로 생각하지 않는다. (Winner, Loser 가 생겨서는 안 된다.)
-    코드에 대한 지나친 소유욕을 갖지 않는다. (우리는 ONE TEAM 이다)

4. 짝 프로그래밍 (PP)
4.1  기본 진행방식
-    1대의 PC에서 두 명의 팀원이 함께 작업을 진행한다.
-    이 때, 키보드와 마우스를 잡고 있는 사람을 운전자(Driver)라고 부르고, 옆에 앉아서 함께 작업하는 사람을 조타수(Navigator)라 부른다.
-    일반적으로 Navigator가 주도적으로 작업을 진행해 나가게 된다.
-    Navigator는 자신이 하려는 일을 이야기하고, Driver는 질문과 제안을 한다.

4.2  시작하기
•    “좀 도와 주시겠어요?”
•    “함께 해보면 어떨까요? :)”

4.3  PP 도중에는
•    제가 해볼게요!
•    해보실래요?
•    제 계획은 이렇습니다. 뭔가하면...
•    어떤 식으로 하실 생각이신가요?
•    이제 무얼 할까요? 다음 단계를 뭐죠?
•    뭔가 빼먹은 건 없나 모르겠네요. 생각나시는게 있으세요?
•    우선 좀 짜 보죠.
•    방금 짠 코드는 잘 동작하는 것 같나요? 단위 테스트를 해 보죠.
•    무얼 테스트 하실건가요?
•    좀 더딘것 같은데요. 어떻게 되가죠?
•    잘 이해가 안돼요. 그림을 한 번 그려보시겠어요? 설명해 주세요!

4.4  휴식
•    좀 쉴까요?
•    그만 할까요?
•    자리를 바꿔보면 어때요?
•    나가서 좀 쉽시다!

4.5  경우에 따라서는
•    좀 쉴까요?
•    그만 할까요?
•    자리를 바꿔보면 어때요?
•    나가서 좀 쉽시다!

4.6  절대 하지 말아야 할 것
•    짜증!

4.7  유의사항
•    강요하지 말 것. 짝 프로그래밍을 강요하면 오히려 짝 프로그래밍을 하는 것에 대한 사람들 사이의 반감을 증가시킬 것이다.
•    혼자 너무 오래 코딩 하지 말 것. 돌아가면서 한다.
•    충분하게 코딩 한 다음 키보드를 넘긴다.
(이 때 USB HUB등을 이용해서 키보드와 마우스를 각자 소유할 수 있으면 더욱 좋다.)
•    자주 쉬어라. 쉬는 시간을 건너뛰진 말아라.  
•    짝도 나눈다. 다른 짝들과 바꿔본다.
•    즐겨라
•    믿음을 가질 것
•    자존심을 세우지 말자
•    우선은 자신이 잘못했을 가능성을 먼저 생각하자
•    옆에 있는 사람을 놔둔채 혼자만 달리지 말자
•    자신보다 경험이 적은 사람과 함께 짝이 되어본다.
•    자신보다 경험이 많은 사람과 함께 짝이 되어본다,
•    코드는 짝 프로그래밍을 하는 두 사람 중 어느 사람의 것도 아니다. 하지만 체크인 하기 전까지, 변경에 대한 책임은 둘에게 있다.
•    언제나 코드에 대화를 담기 위해 노력하여라.

5. PP도입방식
5.1  Whole Team PP 방식
-    이상적인 형태이며 전체 개발 팀원이 돌아가며 PP를 수행한다.
-    단, 팀 인원이 지나치게 많아서 팀 전체와 업무를 공유하기 어렵거나, 지나치게 적고 Role 달라 협업이 불가능할 경우에는 진행하기가 어렵다.

5.2  부분 PP 방식
-    PP 적용 기간을 정해놓고 PP를 진행한다. (ex. Sprint #1, Sprint #2 등)
-    선임자와 후임자가 업무 전달을 위해 진행한다.
-    분석설계자가 개발자에게 개발 범위에 대한 빠른 지식 전달을 위해 진행한다.

6. PP 도입 시기
-    전체 개발일정에 걸쳐서 PP시간을 정해서 진행할 때
-    개발 영역에 대한 범위를 서로가 빠르게 이해하고자 할 때
-    버그를 찾고자 할 때
-    만들고자 하는 부분에 대한 명확한 그림이 그려지지 않을 때
-    새로운 신입을 팀 내에 빠르게 적응시키게 하기 위해서

7. PP의 상태판단
7.1  Successful modes
-    FLOW: 서로가 서로를 보완해 주는 형태로 진행
-    Coaching: 전문가가 문제영역 해결에 대한 자신의 방법을 함께 일하는 사람에게 전달해 주어서 동일한 문제를 이후 혼자서 해결 할 수 있도록 해준다.

7.2  Failure modes
-    지나치게 쉬운 문제로 전문가의 시간을 낭비할 경우.
-    초심자에게 지나치게 복잡하거나 어려운 문제 영역을 함께 작업하게 되는 경우
-    PP가 개인의 사생활을 제한할 정도로 길게 진행되는 경우
 
참조:
http://softwarecreation.org/2008/pair-programming-to-do-or-not-to-do/
http://c2.com/cgi/wiki?PairProgrammingTipsAndTricks

별첨. 분석 설계자와 개발자의 PP

- 목적
 . 분석설계자와 개발자의 의사소통을 시작한다.
 . 개발 도메인에 대한 개발자의 빠른 이해를 돕는다.
 . 분석설계자는 자신이 설계한 화면이 개발되는 방식에 대한 이해를 증진한다.
 . 화면 테스트를 진행하는 방식을 공유한다.

- 개발 진행
 . 개발자는 원활한 PP를 위한 개발 환경 셋팅을 미리 준비한다.
 . 개발자는 설계 문서를 미리 받아서 살펴 보는 시간을 갖는다.
 . 개발자는 Driver 가 되고 분석설계자는 Navigator가 된다.
 . 개발자에게 화면요소를 설명한다.   
    1. 사용자가 해당 화면을 사용하는 목적   
    2. 구현되어야 하는 핵심기능   
    3. 화면 요소 별 항목이름 및 이벤트 설명

 . 개발자는 화면 요소 중 무엇부터 하겠다고 이야기 한다.
 . 개발자는 자신이 현재 하고자 하는 작업이 무엇인지 이야기 한다.
. 분석설계자는 DB 테이블 이름과 컬럼 이름을 확인해서 변수 작성에 도움을 준다.
. SQL을 작성하게 될 경우, 개발자와 함께 돌아가면서 작성한다.
. 우선 30분 정도로 시작해서 시간을 조절해 본다.
 . 주의! 상대방을 지루하게 만들면 안 된다.
   (본인이 왜 옆에 있는지 의구심이 들게 되면 PP를 중지하고 상황에 대해 이야기 한다)

- 화면(기능) 테스트 진행
 . 개발자가 화면 개발을 마치면 분석 설계자와 함께 화면에서 테스트 하고자 하는 것을 정의한다.    (간단한 메모장에 적어도 무방)
 . 함께 테스트를 진행한다.