[Pair Programming] 페어프로그래밍 알아보기(2)

 이번 포스팅은 조금의 페어 프로그래밍 경험과 여러 포스팅 내용을 읽고 이해하고 공감한 것들을 잊지 않기 위해 정리한 글입니다. 정리할 내용이 많기 때문에 시리즈로 작성될 예정입니다. 

 이전 포스팅을 통해 페어 프로그래밍의 방식과 주의할 점들에 대해 알아봤습니다. 이번에는 코드 작성을 제외한 페어 프로그래밍 활동들에 대해 알아보겠습니다.

 우리는 요구사항을 구현하기 위해 코드를 작성하는 것 외에도 많은 작업들을 수행하고 있고, 이때도 페어링을 통해 여러 가지 이점을 얻을 수 있습니다. 

 

계획 세우기 - 목표는 무엇인가?

 처음에 무엇인가 작업을 할 때는 즉시 코드를 작성하지 마시고 목표를 달성하기 위한 계획을 세우세요.
이 단계는 오해나 누락된 전제조건들을 사전에 파악해서 이후의 시간낭비를 피할 수 있는 좋은 기회입니다. 

 

1. 문제에 대해 이해하기: 요구사항을 읽고 여러분이 그것을 어떻게 이해하고 있는지 서로에게 말하세요.
2. 해결책 고민하기: 문제에 대한 해결책이 무엇인지 브레인스토밍을 하세요. 함께 생각할 수도 있고 나누어서 생각한 뒤 서로의 생각을 제시할 수도 있습니다. 둘 중 한 명이 도메인이나 기술에 대해 잘 모르는 부분이 있다면 필요한 내용들을 서로 공유하세요.
3. 문제 해결 계획 세우기: 해결책을 선택할 경우 '어떤 과정을 통해 해결해야 하는가?' ,'염두해야 두어야 할 특정 업무 순서가 있는가?' ,'어떻게 테스트할 것인가?' 에 대해 명시하는 게 좋습니다. 이런 작업은 진행상황을 파악하거나, 다른 사람이 새로 참여할 경우에 도움이 됩니다.

조사하기 

 둘다 익숙하지 않은 기술을 사용해서 기능을 구현해야 할 때는 먼저 조사를 해야 합니다. 이 작업을 할 때는 이전에 설명한 Driver-Navigator, Ping Pong Pairing 방식은 맞지 않습니다. 예를 들어 동일한 화면에서 함께 검색하는 것은 효과적이지 않습니다.

 다음은 조사 시 페어링을 통해 문제를 해결하는 한 가지 방법입니다.

 

1. 적절한 솔루션을 제안하기 위해서는 답변해야 하는 질문 목록을 정의합니다.
2. 질문 목록을 여러분끼리 나누거나 같은 질문에 대한 대답을 따로 찾으세요.
3. 합의된 시간이후 다시 모이고 찾은 내용에 대해 토론하고 공유하세요.

문서화

 코드작성 이외에 함께 작업해야 하는 것은 문서화입니다. 
문서화는 종종 업무의 마지막 과제로 남겨질 때가 있고 이를 수행하지 않았을 때 "완료되지 않았다"는 느낌이 들 때가 있습니다. 이때 우리는 이를 생략하고 싶은 유혹에 빠지게 됩니다. 하지만 페어링으로 진행함으로써 문서화는 둘이 함께해야 하는 업무의 하나로 포함됩니다. 수행한 작업에 필요한 문서가 있으면 함께 반영하고, 이를 통해 미래에 가치 있게 사용되는 문서들을 작성하게 됩니다. 

 

Pair Rotations

Pair Rotation 은 한쌍의 페어가 얼마간 작업한후 둘 중 한 명이 떠나고 다른 한쌍으로 계속 진행하기 위해 새로운 누군가가 온다는 것을 의미합니다. 한쌍중 머무르는 사람을 "anchor" 라 부릅니다. 페어를 순환하는 이유는 다음과 같습니다. 

 

1. 페어링 파트너가 아프거나, 휴가로 인해 부재중일 수 있습니다.
2. 일부로 페어링 파트너를 뒤섞기 위해서입니다.
    둘 중 어느 쪽이든 한동안 함께 많은 시간을 보냈다면 "cabin fever" 의 조짐이 보이기 시작할 수 있습니다. 아니면 여러분은 매우 지루하고 에너지 소모하는 작업 중 일 수 있습니다. 이때 순환을 통해서 여러분 중 한 명에게 휴식을 줄 것이고 새로운 사람의 시각과 에너지를 가져올 수 있습니다.
   * cabin fever: 제한된 공간에 장기간 갇혀있을때 경험하는 과민성 증후군으로 지루하거나 무기력한 느낌을 받을 때 직면할 수 있는 부정적이며 고통스러운 감각.
3. knowledge silos 를 피하고 집합적 코드 소유권을 증가시키며 이동을 통해 더 많은 코드를 검토하기 위함입니다. 페어링 자체는 이미 이러한것들을 돕고 있지만 순환을 통해 투입되는 구성원수를 증가시킬 수 있고 더 많은 오류를 발견할 기회를 만들 수 있습니다.
   * knowledge silos: 특정지식이 공유되지 않고 특정 사람만 알고 있고는 현상.

 

 이상적인 순환빈도는 의견이 갈리지만 어떤 사람들은 2-3일에 한 번씩 순환하는 것이 지식의 확산과 품질을 보장하는데 중요하다고 믿습니다. 모든 순환에는 비용이 들기 때문에 연속성에 대한 일정한 anchor 가 없는 경우 문제 및 솔루션에 대한 암묵적인 지식이 손실되고 재작업을 촉발할 위험이 증가합니다. 따라서 이러한 비용과 이점 사이의 절충을 선택해야 합니다. 예를 들어 팀이 이미 읽기 쉬운 코드 및 설명서를 사용해서 고품질의 지식공유를 보유하고 있다면 빈번한 Pair Rotation 을 통해서 집단적 코드 소유권이 거의 향상되지 않을 것입니다.

 

페어링 공간 준비하기

 페어링은 한 책상이라는 물리적 공간에서 매우 긴밀하게 협력해야 하는 것을 의미합니다.
이는 개인만의 테이블 공간을 쓰는 것과 매우 다릅니다. 서로 물리적으로 가까이 있는다는 것은, 서로에 대한 일정 수준의 존중과 관심을 필요로 합니다. 그렇기 때문에 둘 모두 편안한 분위기를 파악하는데 시간을 할애할 가치가 있습니다.

 

• 둘이 있기에 충분한 공간인지 확인하고 필요하다면 책상을 정리하세요.
• 책상 앞에 의자 2개가 들어가기에 충분한 공간인가요? 쓰레기통과 가방을 치우세요.
• 2개의 키보드? 1개의 키보드? 마우스도 2개? 1개? 명확한 규칙은 없습니다. 각 상황에 가장 적합한 방법을 사용해보는 게 좋습니다.
• 추가적인 모니터가 있습니까? 그렇지 않다면 원격 페어링처럼 화면 공유를 시도할 수 있습니다.
• 파트너의 특정 선호사항이나 요구사항이 있는지 확인합니다. (예: 글꼴 크기 등..)

원격 페어링

 요즘은 재택근무를 하는 분들도 있으실 겁니다. 안정적인 인터넷 접속만 가능하면 원격 상태에서도 페어 프로그래밍을 계속할 수 있습니다. 원격 페어링을 위해서는 화면 공유 솔루션이 필요합니다. 단순히 화면을 보는 것뿐만 아니라 상대방의 컴퓨터를 조작할 수 있어야 합니다. 많은 원격회의 프로그램들은 이를 지원하기 때문에 상황에 맞는 프로그램들을 선택해서 사용하면 됩니다. 
 또한 전체 팀이 분산되어 있지 않고 한 명 또는 몇 명만 원격으로 근무하는 경우 사무실에서 발생하는 모든 토론에 원격 파트너를 포함시켜야 합니다. 우리는 종종 같은 공간에 있는 것만으로도 얼마나 많은 정보들을 나누고 있는지 잊어버리는 경향이 있습니다.
 마지막으로 원격 페어링은 헤드폰을 사용해서 산만함을 없애기 때문에 현장 페어링보다 집중하기 더 쉽습니다.

 

세레머니 만들기

 함께 과제를 완료했을 때 서로 축하해주세요. 하이파이브를 하는 것이 이상해 보일 수 있지만 이는 여러분이 다음일을 준비를 할 수 있는 에너지를 주는 작은 세레머니 입니다.

 

페어링 시간

 페어 프로그래밍에 전념하는 팀은 때때로 하루 8시간씩 페어 프로그래밍을 합니다. 경험상 이는 지속 가능하지 않습니다. 첫째로는 너무 지칩니다. 둘째로는 코딩 외에 다른 작업들이 많기 때문에 실제로 작동하지도 않습니다. 예를 들어 이메일 확인, 1:1회의, 조사/학습 등으로 말이죠. 따라서 하루를 계획할 때 이점을 명심하고 100% 코딩이 함께 이루어질 것이라고 생각하지 마십시오.

 

 이전에도 언급했듯이 페어 프로그래밍은 여러 가지 방식이 있고 이를 수행하는 데 있어서 정해진 올바른 방식은 없습니다.
 페어링 방식은 여러분의 스타일, 성격, 경험, 상황, 업무 그리고 많은 요소들에 달려 있습니다. 결국 가장 중요한 질문은 다음과 같습니다. 당신은 적용하고 있는 방식을 통해서 기대했던 혜택을 얻고 있습니까? 그렇지 않다면, 다른 것을 시도하고, 반영하고, 토론하면서 더 나은 방식을 찾기 위한 시도를 하세요.

 

오늘은 여기까지~!

 

참고 링크 : martinfowler.com/articles/on-pair-programming.html

참고 링크2 : medium.com/@weblab_tech/pair-programming-guide-a76ca43ff389