Skip to content
Permalink
Branch: master
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
73 lines (58 sloc) 8.62 KB

Keyword

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

Reference

상황

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

정리

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

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

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

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

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

내용 질문

  • 페어프로그래밍이란?

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

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

    • 인시(하나의 일을 하는데 시간당 투입되는 인력)가 늘어남
    • 당장 기한이 급한 것은 힘듦.
  • 페어프로그래밍 언제하는게 좋을까?

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

    • 강의하지마라 - 둘다 피곤해짐
  • 전문가와 비전문가 페어는 어떻게 해야하나요?

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

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

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.