Goal
- Pair Programming의 정의
- Pair Programming의 효과
- Pair Programming 할 때 주의할 사항
- Pair Work를 통해 어떤 것을 배울 수 있는가
[들어가기 전]
- Pair Programming은 대표적인 애자일 실천 방법
- Pair Programming은 각자가 할 수 있는 일을 같이 하고 있으니까 시간낭비..?
Pair Programming의 정의
두 사람이 한 짝이 되어서 같이 프로그래밍을 한다.
- 구체적인 모습으로, 두 명이 앉았을 때 기하학적인 중간 지점에 하나의 컴퓨터를 둔다.
- 한 사람이 5분, 다른 사람이 5분 간격으로 서로 옮겨 가면서 키보드를 작성한다.
- 이 과정이 빈번할수록 좋다.
Pair Programming의 효과
1. 결함수가 적어진다!
둘이서 하면 실수가 줄어든다.
- 관련 논문
- 팀 별로 비슷한 크기의 프로젝트를 주고 한 팀은 Pair Programming을 이용하고 다른 팀은 개인별로 진행했을 때의 결함 밀도(코드 라인 1000줄에 결함 수)를 측정한다.
- 결함 수는 절반 정도로 줄어든다.
- SW를 개발할 때 예상치 못하게 개발속도를 잡아먹는 것이 바로 생각지도 못한 ‘결함’이다.
- 결함의 삽입과 결함의 해결은 완전 비대칭 구조
- 결함이 들어가는 시간은 3초
- 그 결함을 찾는 시간은 한달이 넘을 수도
- 결함의 삽입과 결함의 해결은 완전 비대칭 구조
- 하지만, 결함이 줄어든 대신 개발 기간이 늘어난다.
- 프로그램 개발 기간에 대한 정의를 어떻게 하느냐에 따라 연구 결과도 달라진다.
- 본인이 개발을 다했다고 생각했을 때까지 걸린 시간?
- 이때는 Pair Programming이 불리하다.
- 피드백을 포함해서 수정까지 한 총 걸린 시간?
- 본인이 개발을 다했다고 생각했을 때까지 걸린 시간?
- 프로그램 개발 기간에 대한 정의를 어떻게 하느냐에 따라 연구 결과도 달라진다.
- 예시
- 1) 최대공약수 구하기 2) 년도와 월이 주어지면 그때의 달력을 출력하기
- 1), 2)번의 문제는 각각 1시간이 걸린다고 가정하자.
- 각자 푸는 조
- 하나의 문제에 총 1시간
- 각자가 풀었기 때문에 두 문제에 = 총 1시간
- 1시간 * 2명 = 2인시
- Pair Programming으로 푸는 조
- 하나의 문제에 총 0.7시간
- 0.7시간 * 두 문제 = 총 1.4시간
- 1.4인시
- 즉, 각자가 풀면 빨리 끝낼 수는 있지만 노동력(인시)이 더 들어간다.
- 단 Pair Programming으로 진행하면 인시가 늘어나기 때문에 마감에 쫓기는 회사에서는 도입하기가 어렵다.
2. 통합 시간이 줄어든다!
- 위 예시에서의 제시되는 두 문제가 독립적인 문제가 아닌 통합해서 하나의 프로그램을 만드는 것이라면 이야기가 완전 달라진다.
- 현실에서 대부분의 프로그램은 통합이 필요하고 통합하는 과정에서 예상치 못하게 시간이 많이 걸린다.
- Pair Programming은 만들 때부터 두 사람이 지식을 공유하면서 만들기 때문에 처음부터 통합을 고려하게 되므로 통합하는데 시간이 적게 걸린다.
- 예를 들어, 각 나라의 사례를 조사하여 하나의 보고서를 작성해야 한다.
- 한 명은 영국 사례, 한 명은 호수 사례에 대해서 각자 조사한다.
- 이를 하나의 보고서로 합치는 데는 많은 시간이 걸린다.
- 공통된 스타일(서두 / 문투 / 목차 등)로 맞춘다.
- 누구 하나가 수행했던 것을 전부 바꿔야 할 수도 있다.
- 하지만, 둘이서 Pair Programming을 했다면 시작하는 과정에서부터 계속해서 방향을 조정하게 되므로 통합하는 시간이 줄어드는 것이다.
3. 팀워크를 향상시킨다!
- Pair Programming을 통해 서로 간에 신뢰가 생기고 팀워크가 생긴다.
- 같이 오래 일해도 접촉이 없는 경우가 많다.
- 같은 팀에서 오래 일을 했어도 긴밀한 협력을 해본 적이 없기 때문에 협력을 잘 하지 못한다.
- Pair Programming은 서로 피드백을 잘 받을 수 있기 때문에 협력의 기술 이 늘어날 수 있는 환경을 만들어 준다.
- 협력의 기술을 기를 수 있는 기회는 Pair Programming 말고는 거의 없다.
[참고] 'Agile is fragile'
- 애자일은 모든 프로세스를 깨지기 쉽게 만드는 것이라고 할 수 있다.
- 문제를 최대한 일찍 발견함으로써 더 큰 문제가 되기 전에 빠르게 해결하는 것이 목표이다.
- 즉, 애자일을 이용하면 우리 팀의 문제가 더 잘 드러난다. 이런 문제를 덮으려 하지 않고 더 드러내게 만들어 그때마다 문제를 해결하는 것이 애자일이다.
Pair Programming 할 때 주의할 사항
1. 컴퓨터가 정확히 가운데 있는 것이 왜 좋은가?
- “주체 - 객체”의 형식이면 도움이 안된다.
- 예를 들어, 강의 형태
- 예를 들어, 내가 전문 분야인 코드를 내가 주로 계속 작성하고 옆에선 보기만 하는 형태
- 서로 수평인 관계를 만들어야 한다. 즉, 관계를 평등하게!
- 둘이 공평하게 한다는 느낌으로 해야 협력이 잘 일어난다.
- 앉아 있는 테이블의 위치에 따라 역학관계에 영향을 받는다.
- 따라서 누가 주인인 느낌이 들지 않게 컴퓨터를 정확히 가운데에 두고 앉는 것이 중요하다.
- 공동이 주인!
협력의 기술
- “전문가 - 비전문가”와 같이 관계가 비대칭일 때, 아래와 같은 부작용이 나타날 가능성이 높다.
- 수동적
- 학습이 적어진다
- 기여가 낮아진다.
- 관계가 비대칭인 경우에 전문가는 자신의 파워를 낮추고 상대의 파워를 높여줘야 한다.
- 비전문가에게 질문을 자주하자!
- 물어보는 과정에서 상대가 적극적이 될 수 있다.
- 비전문가가 진행할 수 있도록 유도하자!
- 비전문가도 같이 기여를 할 수 있도록 유도하는 것이 중요하다.
- 직접 진행함으로써 학습이 많아진다.
- 비전문가에게 질문을 자주하자!
2. 왜 빈번하게 왔다 갔다 하는 것이 좋은가?
- 데일리 스크럼이란에서 잠깐 언급했던 것처럼 추상과 구상을 왔다 갔다 하는 것이 중요하다.
- 왔다 갔다 하는 과정 안에서 ‘발견’이 있다.
- Pair Programming을 통해서 키보드를 잡으면 문제를 구체적으로 보게 되고, 키보드를 넘기면 문제를 전체적으로 보게 된다.
- 전체의 그림 확인 -> 구체적으로 진행 -> 다시 전체적인 그림을 확인
- 위의 과정을 빈번하게 반복하는 것이 바로 피드백을 반복적으로 받는 것이고, 이 전환되는 과정에서 ‘통찰’이 생긴다.
- 빈번하게 왔다 갔다 하는 것이 서로에게 학습이 더 빨라진다.
- 애자일은 계획을 계속해서 수정해 나가는 것이다.
- 상대가 어떻게 하는지 보고 그 의도를 파악하고, 다음엔 내가 진행하면서 학습이 빨라지고, 계획을 빠르게 수정해 나갈 수 있는 것이다.
- 알람 을 권한다.
- 치던거 다 안쳤어도 시간이 지나면 바로 다른 사람에게 키보드를 넘기고 다른 사람이 진행한다.
Pair Work를 통해 어떤 것을 배울 수 있는가
페어 워크(Pair Work)
- 반드시 개발 분야에 한정된 것이 아니다.
- Pair Debugging
- 내가 생각도 못한 것을 옆 사람이 쉽게 찾을 수 있다.
- Pair Debugging
- Pair로 여러가지를 할 수 있다.
- 발표자료 만들기
- 전략짜기
- 회의록 남기기
- 수월하고 재미도 있고
Pair Work 진행 방법
- 같이 Pair Work를 진행할 사람을 고른다.
- 내가 편한 사람
- 신뢰할 수 있는 사람
- 종이 한 장을 꺼낸다.(바로 일을 시작하는 것이 아니다!)
- 우리의 목표을 적는다.
- 브레인 스토밍을 통해 그 목표에 맞게 여러 task로 쪼갠다.
- 어떤 task를 먼저 할지, 어떤 식으로 접근할지에 대해 얘기한다.
- 알람을 맞추고 5분 간격으로 ‘운전자-항해사’가 되어 진행한다.
- task를 완료하면 목록에서 지우고 필요한 task를 추가하거나 다시 새로운 task를 선택하여 진행한다.
- 1시간 동안 6~7번 과정을 반복한다. (1시간에 Pair Work로 6~7개 정도의 task를 수행한다.)
- 그렇다면 어떤 일을 Pair로 하는 것이 좋은가
- 두렵거나 지겹거나
- 내가 못할 거 같은 느낌이 드는 작업
- Pair Work를 통해 안정감 있게 할 수 있다.
- 하기 귀찮아서 계속 미루는 작업
- 둘이서 하면 재미있다.
- 즉, Pair Work를 도입하기 전에 두렵거나 지겨운 일이 무엇인지를 파악한 후 거기에 Pair Work를 도입한다.
Pair Work에서의 역할
- Driver(운전사)
- 키보드를 잡은 사람
- Navigator(항해사)
- 옆에서 보고 있는 사람
- 항해사
- 항해사의 입장에서 운전사가 키보드를 치는 표면적인 모습을 보면서 머릿속으로 멍하니 보고만 있지는 않는다.
- 항해사는 운전자의 과정을 보면서 ‘추론’ 을 하게 된다.
- 또한 ‘가설’ 이 생긴다. (저렇게 하려고 지금 이렇게 하는가보다.)
- 운전사
- 추론, 가설했던 것을 가지고 직접 표현해본다.
- 운전사는 혼자서 자신의 사고과정을 중얼거리면서 코딩하는 것을 권한다.
- 항해사가 그런 정보를 들으면서 추론할 수 있기 때문
- 코딩을 하는 중에 의도(설명)를 말하라는 것이 아니다!
- 정말로 혼자 중얼거리면서 생각의 과정을 읊는 것이 좋다.
- 즉, 모두에게 능동적인 학습이 된다.
- 내가 맞는가를 확인하고 직접 맞춰볼 수 있다.
- 상대의 사고 과정을 알 수 있다.
Pair Work를 통해 배우는 것
- 생각하는 과정을 배운다!
- 보통 전문가의 결과(코드)만 배우고 전문가의 과정(사고의 과정)을 배우진 못한다.
- Pair Work를 통해서는 사고방식을 배울 수 있다.
- 암묵지(tacit knowledge) 를 배울 수 있다.
- 암묵지: 학습과 경험을 통하여 습득함으로써 개인에게 체화되어 있지만 언어나 문자로 표현하기 어려운, 겉으로 드러나지 않는 지식을 의미한다.
- Pair Work을 통해 전문가의 암묵지를 배움으로써 전문성의 차이를 만드는 것을 알 수 있다.
- 항해사가 운전사의 생각하는 과정을 보면서 계속해서 ‘추측’, ‘가설’을 하게 되고, 그 추측의 결과물(항해사가 추측한 내용)에 대해서 계속해서 피드백(운전자의 코딩 내용)을 받게 되므로 생각하는 과정을 배우게 되는 것이다.
- 나의 전문성을 키우려면 Pair Work를 도입하는 것이 좋다.
관련된 Post
- 애자일 방법론이란 무엇인가? 애자일 방법론의 핵심은 무엇인가?에 대해 알고 싶으시면 애자일이란을 참고하시기 바랍니다.
- 애자일 자격증의 종류와 그 효용 가치에 대해 알고 싶으시면 애자일 자격증을 참고하시기 바랍니다.
- 애자일 데일리 스크럼의 개념과 도입 방법에 대해 알고 싶으시면 데일리 스크럼이란을 참고하시기 바랍니다.
- TDD(테스트 주도 개발)의 개념과 효과에 대해 알고 싶으시면 TDD(테스트 주도 개발)란을 참고하시기 바랍니다.
近期评论