Index
Date
의 스크럼 마스터 : 윤영기
Participants
Assignment
페어프로그래밍 관련 수치 혹은 논문 혹은 알아서 개념에 대하여 더 잘 알아오기
팀 자기소개 페이지 (리액트 환경 설정[ 이하령 ])
CRA
styled-component
ESLint + Prettier
TDD 방법론 공부해오기 -> 어떤식으로 사용을 하는지? [Jest?]
XP에 대하여 알아오기
페어프로그래밍을 어떤식으로 발전시켜야 대한민국 혹은 사람들이 쓸 수 있을까에 대한 고민
각자 페어프로그래밍 어떤식으로 했으면 좋겠다에 대한 상상의 나래를 펼쳐보기
Discussion topics
페어프로그래밍
페어프로그래밍 툴의 예시
코드 투게더(Code Together)
플로빗(Floobit)
유스 투게더(Use Together)
튜플(Tuple)
→ 결국 라이브쉐어의 확장판으로 볼 수 있다.
페어프로그래밍이란?
페어 프로그래밍이란 애자일 소프트웨어 개발 중 하나로 하나의 컴퓨터에서 두 사람의 프로그래머가 작업하는 방법
네비게이터(navigator)가 전략을 제시하고 드라이버(driver)가 실제 코드를 작성하며, 이 열할을 각자 번갈아가며 수행
Navigator
문제 해결 방법을 논리적으로 생각하고, 그 과정을 상대에게 말로 설명하는 역할
코드를 직접 말하거나 키보드를 잡아서는 안됨
어떤 식으로 문제를 해결할 수 있는지 명확히 설명
관찰자의 입장으로 코드를 검토하고 지식을 전달하며 생각을 공유
드라이버보다 넒은 관점으로 설계, 구조에 대한 문제와 버그를 파악하는데 집중
Driver
키보드를 소유하고 있는 사람으로, 네비게이터가 설명한 논리적 방식대로 실제 코드를 작성하는 역할
네비게이터와 논의 할 수 있도록 작성하는 모든 코드에 대해 말로 설명해가며 작업을 진행
네비게이터의 질문과 의견에 적극적으로 응해야 함
왜 두개로 쪼개는가?
코드에 대해 서로 다른 두 관점을 가지게 하기 위함
네비게이터는 관찰자 입장에서 설계, 구조적인 부분과 큰 그림을 생각
드라이버는 기술적인 것과 세부사항 등을 생각
장점
지식공유
서로 지식이 다름
지식을 공유하며 새로운 방식을 배워감
기술적인 스킬만이 아닌 페어로 일하며 좋은 습관을 배울 수 있다
팀에 새로운 멤버가 와도 팀의 개발 스타일 및 환경을 배울 수 있다
목표에 집중
각자 어떤 생각을 하는지 계속 전달해야 하므로 집중이 쉬움
개인적인 시간의 최소화
실시간 코드 리뷰
바로바로 크고 작은 오류를 잡을 수 있다
문제 접근면에서 코드 개선이 수월하다
두가지 사고방식
드라이버는 작은 목표에 집중하고, 네비게이터가 넓은 시야를 설계하여 두가지 사고방식을 연습할 수 있다
Collective Ownership
일의 담당자를 지정할 수 없음
팀의 전체 제품에 대하여 함께 고민 및 개발을 할 수 있음
모든 개발자들이 기능에 대하여 추가나 버그수정 및 리팩토링 진행이 됨
특정 업무에 대한 병목을 막을 수 있으며, 함께 아이디어를 내며 공유가 가능
Peer Review
업무적으로 엮이지 않으면 보통 같은 팀 내에서도 알기 어렵지만, 모든 팀원들과 같이 일을 하며 장단점을 더 잘 알 수 있으며 팀워크도 좋아진다
단점
생산성 저하
한명이 할 일을 두명이서 하니 생산성이 줄어든다고 생각한다
논문기준 15% 시간이 걸리고 15% 결함이 줄었다
감정노동
마음이 맞지 않는 팀원과 함께하여 힘들 수 있다
사람마다 성격이나 스타일이 다르다
피곤함
페어와 하루종일 개발 및 대화를 하는것이 생각보다 피로하다
유의사항
집중하기
팀원 옆에서 개인적인 시간은 금물
차라리 협의 후 휴식시간을 가지자
마이크로 매니징 금지
생각할 여지를 두지않고 1부터 10까지 지정 후 시키는것은 좌절감을 준다
조바심 금지
네비게이터가 잘못된 코드나 얘기를 하여도, 시간을 두고 5초정도 기다린 후 이야기하자
드라이버가 알고있는 상황이라면, 네비게이터가 흐름의 방해가 될 수 있음
네비게이터 또한 오류가 있음을 보아도 시간을 두고 말하는게 좋음
키보드 정복 금지
답답하다고 키보드를 뺏지 말고, 기다리면서 잘 설명해야된다
방법
핑퐁
TDD의 경우, 한명은 실패하는 케이스, 한명은 성공하는 케이스를 작성한다
한명이 계속 키보드를 잡는 상황을 피할 수 있음
키보드 & 마우스
한명은 마우스, 한명은 키보드만 사용
새로운 툴이나 단축키를 빠르게 배울 수 있음
몹 프로그래밍
돌아가면서 한명씩 드라이버, 나머지는 네비게이터가 된다
커뮤니케이션 비용을 줄일 수 있다
프로젝트 초반에 코딩 스타일을 맞추거나 코드리뷰시에 좋음
네비게이터가 여러명이라 의견 통합이 어려울 수 있음
진행순서
같이 Pair Work를 진행할 사람을 고른다.
내가 편한 사람
신뢰할 수 있는 사람
종이 한 장을 꺼낸다.(바로 일을 시작하는 것이 아니다!)
우리의 목표을 적는다.
브레인 스토밍을 통해 그 목표에 맞게 여러 task로 쪼갠다.
어떤 task를 먼저 할지, 어떤 식으로 접근할지에 대해 얘기한다.
알람을 맞추고 5분 간격으로 ‘운전자-항해사’가 되어 진행한다.
task를 완료하면 목록에서 지우고 필요한 task를 추가하거나 다시 새로운 task를 선택하여 진행한다.
1시간 동안 6~7번 과정을 반복한다. (1시간에 Pair Work로 6~7개 정도의 task를 수행한다.)
그렇다면 어떤 일을 Pair로 하는 것이 좋은가
두렵거나 지겹거나
내가 못할 거 같은 느낌이 드는 작업
Pair Work를 통해 안정감 있게 할 수 있다.
하기 귀찮아서 계속 미루는 작업
둘이서 하면 재미있다.
즉, Pair Work를 도입하기 전에 두렵거나 지겨운 일이 무엇인지를 파악한 후 거기에 Pair Work를 도입한다.
우리의 생각
과연 대기업에서는 사용할까?
왜 많은 사람들이 사용하지 않을까?
답답하다
한국에서 성공하지 못하는 이유?
시니어들의 시간이 너무 뺏긴다고 느낀다
한국의 정서와 맞지 않다
현재 나와있는 개발문화와 차이가 난다
어떤식으로 대중적으로 친근하게 다가갈 수 있을까?
좀 더 유머스럽게 풀 수 있을까?
강제적으로 5분 혹은 10분마다 드라이버와 네비게이터의 순서를 바꾸기?
답답함을 풀 수 있는 방법이 어떤것이 있을까?
더폼
https://the-form.io/forms/survey/edit/a52b664a-5006-4154-aaff-4d0a4ce1a266
참고자료
https://post.naver.com/viewer/postView.nhn?volumeNo=8711068
https://gmlwjd9405.github.io/2018/07/02/agile-pair-programming.html
http://www.koreascience.kr/article/JAKO201732663195009.pdf
https://medium.com/@amrianto.saragih/how-does-pair-programming-improves-productivity-d09f16a7b778