코드리뷰 방식, 역할분배, 오류 상황 대처 가이드 결정

코드리뷰 방식

• 멘토님
• PR 받고 나서 24시간 내로 리뷰 해주는건 어떨까요?
• 이 정도는 PR안해도 된다! 라는 부분은 안하는 걸로 해보는건 어떨까요?
• 굳이 PR 남기지말자가 규칙으로 나올수 있다면 좋을 같다고 같아요.
• 이건 저의 생각 & 여러분들의 생각은?

• 동운
• 멘토님 의견에 다 찬성 의견입니다.
• PR 24시간 내로 리뷰 찬성
하고 리뷰 받고 계속 진행하는 형식이 좋다고 생각합니다.
• PR을 남기지 않는 부분도 생각 해보는것도 좋다고 생각합니다.
실제로 해보면 결과적으로 안해도 되는 부분이 없지 않을까 싶은데.. 어차피 남기지 않는 부분은 슬랙에 남겨서 이야기는 당연히 해야될 부분이라 생각이 들고, 이야기만 잘 전달 된다면 코드리뷰 부분도 더 줄일수 있지않을까 싶습니다.

• 병연
• 코드리뷰 방식
• 비동기로 대부분 진행하되, 텍스트로 전달이 어려울 경우 따로 요청한다.
• why?
• 다음 테스크를 이행할 팀원의 일정에 문제가 생길 수도 있기 때문.
• 그럼으로써, 빨리 구현을 진행할 수 있을 것 같다.
• 단, 지켜야 할 조건이 있어야 할 것 같다.

아침 스크럼 때 오늘 pr 할거다 라고 이야기 해야한다.

• 그래야 미리 코드 리뷰 할 시간을 마련해 둘 수 있을 것이다.
• 급한 거 아니면 미리 예언 해주어서 미리 시간을 확보해 각자의 일정이 무리가 없어야 한다고 생각함.
🤷🏻‍♂️
테스크 분배하고 테스크 일정치 보고 코드 리뷰 예정일도 대략 어림잡아 생각해놓으면 될 것 같다는 생각이 듭니다

• 형욱
• 멘토님 의견대로 24시간 내에 리뷰해주는 것에 동의합니다.
• 하지만 24시간 안에 해야 된다고 해서 오늘 안으로 해야지 라는 생각보다는 리뷰를 기다리고 있는 팀원을 위해 최대한 빠르게 해주는 것이 좋다고 생각합니다.
• 모든 팀원들이 리뷰를 해주면 좋겠지만 매 순간 모든 팀원들이 리뷰를 해주는 것도 팀이 협업을 하는 관점에서 본다면 큰 이점만으로 작용할 것 같진 않습니다.
• 따라서 해당 기능과 직접적인 관련이 있는 팀원에 대해 필수적으로 리뷰를 받는 방법과 우선순위가 낮은 기능에선 2~3명 이상이 approve 해주면 다음 작업으로 넘어가는 방법 등 유연하게 가져갔으면 좋을 것 같습니다.

• 진형^0^
• 코드 리뷰는 부담이라고 생각하기보다 일을 수월하게 진행하기 위해서 저희들이 당연히 꼼꼼하게 봐야하는 의무라고 생각합니다.
• 기능 관계자들 끼리는 필수적으로 코드리뷰를 진행하고 그 외의 인원들은 선택적으로 참여하는 것이 좋을 것 같습니다.
• 멘토님 말씀처럼 24시간 내에 리뷰/merge를 하는게 좋을 것 같습니다.
• PR은 코드를 merge하기 전 필수적으로 하고 간단한 PR(코드 포맷팅, 간단한 네이밍 변경 등)도 별로 리뷰를 남길 것이 없다면 Approve만 하는게 좋을 것 같습니다
• 그랩님 토요일 특강에서 “당연한것은 없다” 라는 말을 했듯이 각자가 무조건 당연하다고 생각하고 pr을 날리지 않고 그냥 push만 한다면 다른 팀원에게 어떤 부수효과를 일으킬지 모르고 혼선이 발생할 수 있다고 생각합니다.

• 혜빈ㅋ-ㅋ
• PR 이후 24시간 내로 리뷰하는 것에 동의합니다
• PR 단위를 작게하는 걸로 ex) 현재 저희 pr 작업단위 체크박스 하나정도?, 레이팀 pr
• 관계자는 필수
• PR을 남기지 않아도 된다는 규칙은 현재 적용하기에는 무리가 있을 것 같습니다.
 

🔖 결론

• PR 24시간 내로 리뷰 해주기
• 리뷰를 기다리고 있는 팀원을 위해 최대한 빨리 해보기
• 미리 이야기 할 수 있다면, PR 예고 해주기
• 2~3명 이상의 approve 해주면 넘어가도록 유연하게 운영

• PR은 모두 남겨야 한다.

당신은 아침형 or 저녁형?

• 병연
• 12 :00 AM ~ 11 :00PM

• 형욱
• 10:00 AM ~ 새벽 3시까지 ? 길면 4시?

• 동운
• 8:00 AM ~ 길어도 새벽 1시?

• 혜빈
• 9:00 AM~ 길어도 새벽 2시 ?

• 진형
• 낮 12시 ~ 새벽 5시

역할 분담 정하기

• 동운님
• 개발자 희망, 굳이 한다면 PO..?
• SM: 병연님

• 병연님
👉🏻
하고 싶은 역할 := 개발자
• SM : 형욱님, 혜빈님
• PO : 진형님, 동운님

• 형욱님
• 이번 프로젝트는 최종 프로젝트를 진행하기전에 많은 삽질과 실패를 경험해 볼 수 있는 기회라고 생각이 되어서 돌아가는 방향보다 고정이 되면 더 좋을 것 같습니다. 거의 팀원 모두가 처음이기 때문에 자신이 맡은 역할이 아니라고 해서 가만히 있는 것보다 부족하거나 어려운 부분은 같이 채워 나가면 좋을 것 같습니다.
• 하고싶은 역할 순위 : 개발자 >>> SM >>> PO

• 진형님
• 역할을 돌아가면서 수행하는것도 나쁘지 않은 선택이지만 돌아가면서 하다보면 그 역할에 집중하지 못하고 분산될 수 있을 것 같은 우려가 됩니다.
• 프로덕트 오너가 신경써야 될 부분, 스크럼 마스터가 신경써야 될 부분과 전체적인 그림은 프로젝트를 진행하면서 차근차근 쌓아온 경험에서 나오는것이지 않을까 싶습니다.
• 저는 이번만큼은 역할을 fix하는 방식으로 해보면 좋지 않을까 싶어요
• 저는 꼼꼼하지 않고 자주 까먹는 습성이 있어서 굳이 역할을 맡는다면 스마보다는 프로덕트 오너나 개발자가 더 어울리지 않을까 싶습니다~

• 혜빈님
• 스마 or 개발자 하고싶어용

• 1순위

• 2순위

• 3순위

• 형욱님
• 동운님
• 진형님

• 혜빈님
진형님 - 결정에 있어서 PO의 의견을 우선적으로 따라가야 될것같고 저보다는 두분이 의견이 잘 맞을 것 같아요
• 동운님
• 병연님

🔖 Fix 된 사항

• SM
• 형욱, 혜빈

• PO
• 동운, 진형

오류 상황 대처 가이드

• 멘토님
끊임없이 돌아가는 공장처럼 그 담당자가 없더라고 폴백 전략도 세워야 한다! ( fallback 전략 : 실패 대응책 전략 )
예시)
1. 전문적이라 담당자가 꼭 해야 된다!
2. 단순한거라 내가 하고 따로 수정했다고 알려준다.
 
이걸 미리 정하는 이유는 여러분의 시간적 리소스는 한정되어 있으니, 이런 시간들을 아끼는 것이 여러분들이 하고 싶은 걸 더 많이 반영할 수 있습니다. 미리 정해놓고 매 스프린트 회고하면서 구체화, 개선, 고도화 하는 것이지요!

• 동운
• 갑자기 오류 발생 → 2-3시간 삽질 → 알고보니 설정이나 오타 때문이었음. 이런 상황이 사실 너무 빈번하게 일어나는 일이니… 이 상황을 피하기 위해서라면..?
• 시간을 딱 정해놓고, 시간 초과되면 HELP 요청하기.
• 해당 업무는 미루고 다른 업무를 찾아보기…? (현실적으로 불가능할 거 같긴한데,,)
• 위의 상황 외에는 아래와 같은 상황이지 않을까 싶습니다만…
Comment에 이 기능 만들려고 보니까 Post의 이 기능이 필요한데.. 없네?? (Post 담당자는 자고 있는디..? 🤔 )
1. Fix 시킨다.
2. 임시로 추가 및 진행 → 비동기 통신 → 이야기가 필요하면 회의 GoGo!
1번이 맞긴 한데.. 현실적으로는 2번으로 해야 되지 않을까 싶습니다.

• 병연
• 팀원이 자고 있으면 내일 한다.
• 미리 생각하고있는 테스크 분할은 미리 정해놓고 하고 있는 것으로 가정
• 내가 어떤 팀원과 연관되서 일을 할지 모르기 때문에 이와 관련된 버그가 발생하면 어떻게 될 수 있다 라고 미리 말해둔다.
• 예상할 수 없는 버그가 갑자기 발생한 경우라면 팀원이 자고있으면 철저하게 문서화 해놓고 대기한다. 그리고 다른 할 것을 하고 있는다.
• 30-1시간 동안만 고민한다.
• 그리고 바로 문서화 한다.
• 그리고 아침에 상황을 공유하거나 슬랙으로 미리 보내놓는다.
👉🏻
내가 작성한 코드가 아닌 다른사람의 코드를 변경해서 pr을 날리면 절대 절대 NEVER ‼️ 안된다. 다른 사람의 코드 변경에 대해 미리 알려야 한다. 무조건 ‼️

• 형욱
• 공통적으로 해당 오류에 대한 문서화를 상세히 해야할 것 같습니다.
• 아직 단순함의 정도가 어느정도 인지 판단이 서질 않지만 큰 이슈가 없을 것 같다면 진행하고 자세히 문서화 해서 담당했던 팀원에게 전달해주면 좋을 것 같습니다 !
• 전문적인 부분이라면 이 부분에 대해서는 담당자가 처리하는게 맞을 것 같습니다. 이해도가 아무리 높더라도 결국 담당하는 사람이 코드를 제일 잘 이해하고 있기 때문에 건드리지 않고 어떤 부분에서 문제가 있는지 문서화를 해서 전달한다.

• 진형
• 스프린트 시작시 업무를 분배할때 아침형 + 새벽형팀원을 짝지어서 관련 기능을 분배를 한다?(서로가 없는 시간에 매꾸어 줄 수 있어야한다?)
• 연관 관계가 있는 기능을 만드는 팀원끼리는 서로 코드 이해도가 다른사람들에 비해 높아야된다.
• 코드 이해도가 높은 사람들 끼리는 유사시에 대신 코드를 수정하고 추가할 수 있어야된다.
• 예를 들어 게시판과 댓글기능은 연관관계가 깊으므로 게시판은 아침형, 댓글은 새벽형사람이 맡아 업무를 진행..? - 단점 : 아침형과 새벽형이 겹치지 않는 시간에는 진행에 병목이 있을 수 있다. 둘의 시간대가 맞는 코어한 시간에는 가장 중요도가 높은 업무를 우선 진행할 수 있도록 해야할듯..
• 새벽에 게시판 코드를 수정해야되는 상황이면 댓글기능을 만드는 새벽형 팀원이 코드를 대신 수정할 수 있을만큼 서로의 코드 이해도가 높아야된다?!(이 사람이 왜 이렇게 코드를 짰었지? 라는 상황이 나오면 안됨, 그렇기 때문에 PR을 할 때 연관관계가 깊은 기능을 만드는 팀원끼리는 코드리뷰 필수 빨리빨리)

• 혜빈
• 전문적인거라 담당자가 꼭 해야한다 싶으면 미리 상의를 해서 그런 부분을 정하면 어떨까요
• 문서화 하고 기다리는게 맞다고 생각함

🔖 총합 사항 

• Issue 발생 시, Fix
→ 문서화 및 공유 → 해결
• 문서를 상세하게 작성하기
• 큰 이슈가 아니라고 판단되면 진행 후에 문서화 및 공유

• 삽질 시간 최대치 : 1시간

📌 스프린트 2회 3회 진행하고 문제가 발생한다면 이런 방법도 고려해보자

• 기능 분배를 아침형 / 새벽형으로 나누어 관리
→ 나누어진 팀원끼리 코드 이해도가 높아야 되고, 이렇게 함으로써 유사시에 코드 추가, 수정 가능 하도록 운영
→ 페어 프로그래밍

📌 멘토님 말씀

내일까지 주말 숙제 완료하기(소나큐브, 플라이웨이)

소나큐브

• 동운

• 혜빈

• 진형

플라이웨이

• 형욱

• 병연