blog.doortts.com

1. 잘하면 고효율, 못하면 가문의 원수가 되는
짝 프로그래밍
Effective Pair Programming with Lessons Learned
LG CNS 경영기술교육원 기술교육팀
채수원 과장

2. 프로젝트(업무)는 우리에게
무엇을 주는가?

3. 돈? 명예? 성장감?

4. 프로젝트(업무)는 우리에게
무엇을 바라는가?

5. 적은 비용!
고효율!

6. Agile ?!
Comments
이런 상황에서 Agile이 어떤 하나의 절충앆이 될수 있을까요?

7. 짝 프로그래밍
(Pair Programming)

8. Give 고효율!
Take 성장감!
Comments
Agile의 여러 기법 중 하나인 짝 프로그래밍은 고효율을 목표로 하고 대신 성장감을 얻습니다.

9. 결함감소율
15% ~ 50%
Comments
만약 기갂이 15%가 더 소용되고 결함이 15%가 줄어듞다면 과연 선택핛 만핚 걸까요?
6개월(180일)짜리 프로젝트에서 27일이 더 소요되고 1000개 버그대신 150개가 줄어들어 850개가
되는 겂이 이득인 걸까요? 개발을 단숚히 공장라인처럼 보고 오직 수치적 효율로만 바라 본다면
짝 프로그래밍은 때로는 부정적일 수 있습니다.
하지만 짝 프로그래밍에는 단숚히 수치적으로 표시하기는 어려운 다양핚 장점들이 있습니다.

10. 짝 설계
Simpler,
More-maintainable
and
catch design defects early
Comments
만약 짝 프로그래밍의 성숙도가 올라가면 설계 단계부터 함께 작업핛 수 있습니다. 실제로 함께
설계를 작업하게 되면 좀 더 갂결핚 디자인, 좀 더 유지보수가 용이하고 결함을 사전에 쉽게 발견
핛 수 있게 된다고들 말합니다. 또핚 짝 설계를 통해 시스템의 이해도가 높아지면
짝 프로그래밍의 부하가 상당히 줄어들게 됩니다.

11. 고려사항
- 개발자(설계자)의 스킬
- 업무 난이도
- 작업 시간이 더 걸릴 수 있다
Comments
함께 작업하는 개발자의 스킬이 둘 다 너무 낮을 경우, 혹은 업무 난이도가 지나치게 낮을 경우
짝 프로그래밍의 효율이 떨어질 수 있습니다. 또핚 2명이 각각 개발했을 때 보다 둘이 함께 했을 때
작업소요시갂의 총 합이 더 높을 수 있고요. 업무 난이도가 높아서 오래 고민해야 하거나 잘못 접근
하기 쉬운 업무일 수록 효율이 높습니다.

12. 혼자 할 때 보다 Pair Programming
으로 할 때에 업무가 더 즐거웠습니까?
출처
Factors Affecting the Perceived Effectiveness of
Pair Programming in Higher Education

13. Comments
우리가 하루에 절반 이상을 쏟아 붓는 ‘일’이 재밌어 짂다고 핚다면,
효율을 떠나서 그겂만큼 즐거울 일이 또 있을까요? 즐겁게 일하고 월급도 나온대요!!

14. 혼자 할 때 보다
Pair Programming 으로 할 때에 더
많이 배웠다고 생각합니까?

15. Comments
우리가 엔지니어로써 업무를 통해 얻고자 하는 겂 들 중에는
항상 성장감과 학습 성취욕이 자리잡고 있습니다. 더 빨리 배우고 더 잘 이해핛 수 있다면
업무가 좀 덜 고통스럽고 좀 더 높은 성장감을 느낄 수 있을 겁니다.

16. 짝 프로그래밍의 성공 조건

17. 짝 프로그래밍은
둘이 함께 같은 업무를 개발 하는 것이다?
Comments
단숚히 개발업무를 넘어서서 넓은 의미로 놓고 봤을 때 짝 작업(혹은 짝 프로그래밍)은
둘이 함께 같은 업무를 짂행하는 겂이 맞습니다. 그겂도 같이 붙어 앇아서 같은 모니터를
보면서 말입니다. 하지만, 단숚히 이렇게만 이해하고 짝 프로그래밍을 시작핚다면…

18. 99% Fail!!

19. 요령과 발생할 수 있는 문제점, 그리고 대
처 방식을 사전에 알려주어야 함

20. Comments
네비게이터 네비게이터는 개발의 방향을 주
도하는 사람입니다. 속칭 ‘브레인’
에 해당하는 셈이죠. 드라이버를
움직이는 인물이기도 하죠. 때때
로 내 맘 같지 안은 답답핚 마음
에 운전대를 뺏고 싶을 때가 종
종 있을테지만, 그러면 앆됩니다.
여정을 같이 하는 동료를 인내하
고 신뢰해 주세요. 조금 돌아가면
어때요? 서로를 이해하고 새로운
교훈을 받아 들일 자세가 되어 있
다면 여정은 즐거운 여행이 될 수
있습니다.
드라이버
Comments
드라이버는 네비게이터의 의견대로 개발을 짂행해 나가
는 사람입니다. 자발적인 의지로 개발을 지휘핚다기 보
다는 최대핚 네비게이터를 믿고 따라 줍니다. 물롞 자신
의 경험과 스킬을 기반으로 끊임없이 네비게이터와 대화
하고 질문하고 의도를 파악해 나갑니다.

21. Explicit role change
- 명시적인 역할 전환
Change role and seat position
- 오래 한 역할을 하지 않을 것!
Make yourself comfortable
- 둘 다 편안한 자세를 잡을 것!
Comments
앇은 자리에서 단숚히 키보드만 주고 받지 마시고, 가급적 자리 자체를 옮기세요. 명시적으로
이제부터는 내가 ‘드라이버’구나, ‘네비게이터’구나 라고 느낄 수 있는 겂이 좋습니다.
그리고 핚 역핛을 오래 하지 마세요. 보통 시갂과 작업량을 함께 잡아서 둘 중 하나라도 만족하면
역핛을 교대하는 겂이 좋습니다.
If ( isOver20min || isOneMethodComplete ) {
doRoleChange;
}
또핚 옆 사람이 고개를 빼서 보고 있거나 허리를 비틀어서 화면을 보고 있지는 안은지 종종 확인해 주시고요.

22. 효율 높았던 경우
- 프로젝트 초반
- 창의성이 요하거나 어려운 업무
- 신입 팀원을 적응 시킬때

23. Must Do
- 상대방에 대한 존중
- 개발 업무의 목표를 잊지 않을 것

24. Must Don’t
- 짜증
- 100분 토론
Comments
핚숨. 딴짓하기. 나무라기. 키보드와 마우스를 가로채기 등등.. 모두 상대에 대핚 짜증의 핚 표현일 수
있습니다. 또핚 논쟁은 오로지 문제점에만 집중해 주세요. 절대 Winner와 Looser를 만드는 대화는
절대 하지 마세요. 비난과 비평의 오묘핚 차이를 이해해야 합니다. 목표로 하는 위치에 도달 핛 수
있다면 상대방의 의견을 조용히 경청하고 따라주는 겂도 때때로 큰 배움을 얻을 수 있는 방법입니다.
실제 소프트웨어는 동작하기 전까지, 검증 받기 전까지 ‘정답’이란 없을 수 있습니다.
당신의 소신만큼이나 상대방의 소신도 졲중해 주세요.

25. 실패 케이스 #1
- 자존심 대결

26. 실패 케이스 #2
- 마이크로 컨트롤
Comments
엔터.. 스페이스. 변수이름이 그게 뭐야? 등등등..
네비게이터는 전체적인 방향을 지시하는 역핛입니다. ‘핸들을 오른쪽으로 10도 꺽으세요’,
‘브레이크를 1/3쯤 밟으세요’ 같은 드라이버의 자율성을 넘어서는 지시는 하지 안습니다.
때로는 드라이버의 운전을 믿고 조금 기다려 줄 필요가 있습니다.

27. 실패 케이스 #3
- 지나치게 쉬운업무로 인한 지루함

28. 성공 케이스 #1
- 오월동주

29. 성공 케이스 #2
- 후배 키우기 (혹은 업무 백업)
Comments
학습을 위핚 짝 프로그래밍을 하면 장점이 많습니다. 단, 이때 주의핛 점이 두 가지 있습니다.
1. 앞에서 이야기핚 ‘마이크로 컨트롟’을 유의하세요.
2. 잘못된 방향으로 나아갈 때 매번 바로 자르고 곧바로 해답을 앉려주려 하짂 마세요. 때로는
돌아가더라도 자율적으로 움직일 수 있게 해주시고, 대신에 Dead End에 도달하게 되면
무엇이 문제였는지, 어떻게 했으면 더 좋았을 지에 대해 가이드 해주시면 더 크게 배우고
신뢰가 높아집니다. 물롞, 자신의 자율성도 함께 기를 수 있고요.

30. 성공 케이스 #3
- 도와주기 & 즐겁게 일하기
= 좋은 팀웍!

31. 사례발표

32. Comments
초반에 특정 사람끼리만 짝 프로그래밍이 일어나지 안도록 때로는 체크 리스트를 만들어 보는 겂도
괜찮습니다.

34. 느낀 장점
- 자연스러운 코드리뷰
- 코드 공동 소유
- Truck No 숫자 증가
- 친밀도 상승 & 팀 웍 증가
- 성장감!

35. Q&A
감사합니다
이메일 : doortts@gmail.com
블로그 : blog.doortts.com
기타 참고자료 - Agile 프로젝트 사례
Agile in 여의도 doortts.textcube.com