사전에 이야기 나눈 pr에 어느범위까지 포함되어야 하는가에 대한 예시입니다.
해당 내용이 정답이라고 할 순 없겠지만 위와같은 내용으로 작성된다면 체계적이지않을까? 에서 추출했습니다.
⇒ 해당 pr은 친구가 작성했던 pr이며 작업내용에 대한 스크린샷을 포함해 check List 를 통해 작업내용도 공유되는것 같아 리뷰를 촘촘하게 해서 코드 퀄리티 자체를 높이는데 장점이 있을거라고 예상합니다.
결론은 이전에 이야기했던 내용들이 PR에 포함되면 좋겠고 서로의 코드작업과정을 이해하는데 도움이 될 것이라고 예상합니다.
팀 문화
제시된 팀 문화
- 논의-결정 라운드 분리
- 해당 내용은 모든 사람의 논의내용을 참고하기 위함
- 논의라운드를 거치면서 결정라운드에 도달하기 이르다고 판단되면 1~2회의 논의라운드를 추가로 진행
- 이후 결정라운드를 통해 각자의 최종의견을 전달하고 의사결정을 진행하도록 함
- 기술과 관련된 내용 공유 및 블로그 작성
- 사용법 , 동작원리에 대한 명확한 이해를 위함
- 느낀점, 배운점, 선택이유와 같은 내용들을 블로그로 작성해보는 과정을 거치면 좋겠다는 내용
- 추가코어타임 진행
- 개개인의 시간을 방해할 순 없으니 평소에 진행하되 바쁜일정이 있다면 공유 후 미참여하는 방식
- 시간대는 추후 논의
- 강제성 부여차원에서 진행되면 좋겠다는 의견
- 정보공유 / 잡답 스레드로 매일 별도로 관리
- 의도는 슬랙채널에 공유되는 데이터들을 더럽히지 않는 용도
- 스레드 알림을 꺼놓았을 수 있으니 최대한 멘션을 활용할 것
- 일정관리
- 형식적인 스크럼에서 벗어나기
- 일정공유만하는 방식 x
- ManDay도입하면 좋을 것 같음
- 하루동안 3번의 개발과정을 공유
- 코어타임 이전 예상 일정 산출
- 매일 개발일기 작성하는 방안
- 저녁코어타임 이후 애프터 스크럼 진행
해당 내용은 슬랙의 체크리스트 or 표를 통해 관리하면 좋을 것 같습니다.
ex) Main페이지 특정 컴포넌트 구현 - 2시간
ex) 현재시간 오전 11시30분 컴포넌트 구현완료
ex) 오전9시에 산출한 일정을 공유하고 진행도를 산출 ⇒ 해당 내용이 manday로 이어질 확률이 높음
- PR에 판단해야 될 내용들을 작성해서 공유
- 개발과정에서 고민했던 부분
- 수정해야 할 부분
- 결정했던 부분