pairProgramming.md

Keyword

애자일 키워드 김창준 페어프로그래밍 짝프로그래밍 몹프로그래밍

Reference

• 김창준 애자일 키워드 팟캐스트 - 짝프로그래밍
• 페어프로그래밍 첫 도전기
• 몹프로그래밍
• 페어프로그래밍으로 TDD하고 있는 스터디 리포지토리

상황

• 회사에서 버그가 생겼을때나 막혔을때 선임과 같은 컴퓨터에서 같이 보면서 이렇게 해보면 어떨까? 저렇게 해보면 어떨까? 하면서 같이 키보드를 번갈아 사용하면서 디버깅,버그를 해결해나감. 이렇게 하면서 옆에서 디버깅하는 습관을 보고 배울 수 있었음. 처음 버그에 부딪혔을때 굉장히 막막했는데 이렇게 같이 해나가면서 버그에 대한 두려움도 많이 줄어들음.
• 페어프로그래밍이 학습과 협력에 효과적이라는 것을 처음 익스트림프로그래밍 책에서 보게됨. 하지만 주위에 같이할 사람이 없음. 짝을 찾아헤메다가 드디어 실제로 페어프로그래밍을 꾸준히 할 수 있는 스터디(TDD 오예!)가 생김. 페어프로그래밍을 모르는 사람도 있어서 내가 알고 있는 부분을 간략하게 설명해주고 같이 팟캐스트와 자료를 찾으면서 서로 알고 있는 지식 수준이 같도록 먼저 작업함.
• TDD 스터디하면서 페어프로그래밍(3명이니 정확히는 mob-prgramming)하면서 느낀 것들 정리
• 애자일 키워드 팟캐스트 들으며 내용 정리

정리

실제 페어프로그래밍을 하면서

• 처음에는 분석없이 바로 각자 역할을 나누어서 들어갔음. 근데 같은 요구사항을 읽어도 각자가 생각하는 다른 경우가 많음. 간단한 요구사항이라 분석이 굳이 필요없을 것 같아서 나중에 이 부분의 간격을 좁히는데 시간이 더 많이 듦.
• 적절한 페어프로그래밍 턴 넘어가는 시간(5분마다 턴 교대? 10분마다?)를 직접 해보면서 우리에게 적절한 시간을 찾아나감
• 그 다음부터는 페어프로그래밍 들어가기 전에 요구사항 분석하면서 이야기함. 서로 다르게 생각하고 있는 부분이 미리 짚어봄. 테스트케이스리스트를 작성해봄.
• 위 과정을 거쳐도 하다보면 서로 다르게 생각했던 부분이 있음. 완전히 같은 생각을 할 순 없음. 일단 턴을 진행해보다가 너무 삽질한다 싶으면 (보통 2개의 턴(10분) 이상으로 삽질) 멈추고 다시 설계를 점검해봄. 스터디에서는 25분정도 실습을 하므로 긴 삽질은 하지 못함. 어차피 회고할때 이 부분 삽질이었음 이런게 자동으로 나옴.
• 몇 번 페어프로그래밍을 하다보면 점점 스타일이 맞아짐. 쿵짝이 맞게되는 순간이 많아짐. 좋은 쪽으로 쿵짝이 맞아가는 거면 좋겠음.
• 이건 우리 코드다! 그 사람이 드라이버였을때 버그가 나는 코드를 작성하더라도 그건 그사람의 책임이 아니라 우리가 작성한 코드의 책임임. 버그를 해결했을때는 함께 기뻐함.
• 페어프로그래밍 하면서 발생한 문제점과 개선사항은 페어프로그래밍이 끝나고 함께 회고하면서 발견해나감.
• 페어프로그래밍 작업 후에 어땠는지 짧게라도 회고를 하면 도움이 될 듯. 회고하세요 회고 꾸준히 하세요.
• 삽질을 두려워하지 않고, 어차피 회고하면서 개선해나갈테니까 빠르게 시도할 것을 결정하고 개선해나감

From 애자일 키워드 팟캐스트 - 짝 프로그래밍

팟캐스트 듣고 떠오르는 질문

• 짝 프로그래밍을 도입하기 좋은 지점은 ‘두렵거나 지겹거나’ 할때라고 합니다. 지금 프로젝트에서는 어떤 부분에 도입하면 좋을까요?
• 애자일에서는 프로젝트의 전체 그림(추상적인 것)과 작은 그림(구체적인 것)을 왔다갔다하면서 피드백을 자주 받으며 계획을 수정해나간다고 합니다. 페어프로그래밍도 네비게이터(한 발짝 벗어나서 전체 그림보기)와 드라이버(구현-구체적인 것)로 나누어서 작업합니다. 그러면 세명 이상의 페어 프로그래밍은 어떻게 작업해나가면 좋을까요?
• 프로그래밍을 할때는 머릿 속으로 생각한 것들을 실제 코드로 구현해나갑니다. 그럼 서로가 머릿 속으로 어떤 생각을 하고 있는지 어떻게 확인해나갈 수 있을까요?

내용 질문

• 페어프로그래밍이란?

  • 모니터를 가운데 두고 번갈아가면서 5분씩 키보드를 움직이며 키워드를 입력
    • 왜 모니터를 가운데 두나요? 앉은 자리위치에 따라 누가 주도하고 소셜파워가 강한지 역학관계가 달라짐(보통은 역학관계에 따라 앉은 자리가 달라짐.최대한 그런 걸 느끼지 않도록)- 모니터 가운데에 두면 누구 한 명이 주인인 느낌이 덜 듬. 공동주인인 느낌이 들도록 모니터를 가운데에 배치.
  • 한 명은 내비게이터(옆에서 전체를 보는 역할. 길잡이), 한 명은 드라이버(직접 타이핑)으로 번갈아 역할을 수행함. 드라이버는 중얼중얼거리면서(설명이 아님) 타이핑함. 듣고 어떤 거 하고 있는지 알 수 있도록.
  • 네비게이터, 드라이버 왜 나눌까?
    • 애자일에서 계획은 수정해나가는것임. 피드백을 자주 받으면서. 전체 그림 보고 작은 그림보고 추상적인 것과 구체적인 것을 왔다갔다함.
  • 네비게이터 장기 훈수둘 때 더 잘 보이는 경우가 있지 않나? 한 발짝 멀리서 떨어져서 보면 전체 상황이 잘 보이게 됨. 키보드에 손을 떼서 벗어나게 되면 장기 훈수두는 것처럼 멀리보게 됨. 계속 몰입되어있으면 잘 안보이는 경우가 많음
  • 서로 역할을 번갈아가면서 전체를 봤다가(내비게이터) 구체적인 것을 보는 걸(드라이버) 계속 하게됨. 페어프로그래밍 텀을 왔다갔다 많이 하면 학습이 더 빨라짐
  • 사람이 동시에 멀리보기 가까이보기 두 가지 하기 힘듦. 페어프로그래밍은 이렇게 볼 수 있도록 도와줌.

• 페어프로그래밍 효과

  • 결함(bug) 줄어듬 (페어프로그래밍 찬반입장에 상관없이 모든 학자가 인정함)
  • 팀웍을 경험할 수 있음. 단순히 시간을 같이 오래보낸다고 협력하는 근육이 늘어나지 않음. 일을 나눠서한다면 상대가 하는 일, 일스타일 등을 깊게 경험하지 않음.
  • 통합시간이 줄어듦. 하나의 프로젝트를 나눠서 하면 각자 작업한 것을 통합하는 시간이 필요함. 처음부터 같이 작업하므로 이 시간이 줄어듦
  • 갈등을 드러나게 함. 애자일에서는 갈등을 피하는 것보다 갈등이 드러나는 걸 더 긍정적으로 봄. 나중에 커질 문제를 미리 겪는 것임.
    • 단 문제를 해결할 의지와 능력이 없을 경우 힘들어진다.

• 페어프로그래밍 도입 전 체크

  • 인시(하나의 일을 하는데 시간당 투입되는 인력)가 늘어남
  • 당장 기한이 급한 것은 힘듦.

• 페어프로그래밍 언제하는게 좋을까?

  • 언제? 두렵거나 지겹거나 할 때
  • 두렵다 == 불확실성 높고, 내가 못할 것 같다 - 옆에서 함께 봐주면 나아짐
  • 지루함 == 같이 하면 재밌어짐. 예를 들면, 인형눈붙이기 같은 지루한 작업은 같이 하면 나아짐
  • 도입할때 두렵거나 지겨운 포인트를 찾아서 그 부분부터 점진적으로 도입해보자

• 페어프로그래밍 하면서 주의해야할 점

  • 강의하지마라 - 둘다 피곤해짐

• 전문가와 비전문가 페어는 어떻게 해야하나요?

  • 협력의 기술 들어갑니다. 관계에서의 비대칭. 비전문가는 기여를 적게하고 학습을 적게하면서 아웃사이더가 됨
  • 내 파워가 쎈 경우, 내 파워를 낮추고 상대를 높여줘야함. 상대에게 자꾸 물어보기. 물어보는 과정 속에서 상대가 적극적으로 될 수 있음. 이 부분은 해보실래요? 하고 건네줌. 내용을 몰라도 타이핑해야할껄 불러줌. 몰라도 할 수 있도록 그 사람이 직접 해보게 해야함.

페어프로그래밍을 넘어 페어웍(pair work) GoGo