---

• 코어타임 : 10시 ~ 19시
• 점심시간 : 12시 ~ 13시 (일정 따라서 변경)
• 게더타운이 코어타임 중 회사라고 생각하기
• 상대방을 생각하며 말하기
• 공지 & 비상 채널 읽으면 체크표시
• 트러블 슈팅이 있었다면 문서화 & 다른 사람들은 해당 문서 읽어보기
• 질문이 있다면 손을 들고 기다려요
• 진행상황 확인을 위해 하루에 하나 PR을 날려요. (단위가 안맞아서 거절당해도 괜찮아요.)
• 프로젝트 리더 ‘죄송합니다’ 금지
• 프로젝트 리더에게 ‘죄송합니다’ 금지

• 코드 치기 전에 하려고 하는 것을 적기. 이후 작업이 종결되었을 때, 작업 내용을 공유하기 (로그를 남기는 것에 포커싱)

• 이후 이 내용을 정리하여 모두가 작업 내용을 이해할 수 있도록 함. (이슈, 학습 사항, 레퍼런스 등)

• 읽을 사람을 생각하며 코딩하기 & PR 날리기 & 커밋 메세지 쓰기

• 30분 고민해보고 한 명에게 물어보기, 이후 그 사람도 모르면 전체 소집

  ⇒ 2명이상이 한 트러블 슈팅과 혼자한 트러블 슈팅은 따로 분류하기

  💡 우리 undefined의 트러블 슈팅 분류 기준

  🐶 도지 하나 : 혼자 고민한 문제 🐶🐶 도지 둘 : 둘이서 고민한 문제 🐶🐶🐶 도지 셋 : 다같이 고민한 문제

• 전 날 한 일

• 가볍게 코드리뷰
• 전체 코드리뷰가 아니라, 팀원들의 코드 가독성 맥락 맞추기에 중점
• 가독성을 위주로 코드리뷰 한다.

• 전날의 이슈와 스크럼을 토대로 Feature List 갱신

• 갱신된 Feature List를 반영하여 개발하기

• 하루 정리가 아니라, 중간 체크포인트 개념
• 오늘 개발 사항 간단히 공유 (+ 2명 이상 모였던 내용이 있었음을 나누기)

---

10:00 ~ 10:30 : 데일리 스크럼 (커뮤니케이션, 일정 관리 - 코드 제외)

10:30 ~ 11:00 : 데일리 코드리뷰 (가독성에 중점)

11:00 ~ 12:00 : Feature List 갱신

12:00 ~ 13:00 : 점심시간

• 의사결정과정

  • 성현님 : 파편화된 시간 사용이 좋다.

  ⇒ 관경, 대호 : 파편화된 시간은 루즈해집니다.

  ⇒ 성현님께서 코어 이전 시간에 사용하시기로 함.

---

13:00 ~ 17:00 / 19:00 : 개발

16:30 / 18:30 ~ 17:00 / 19:00 : 마무리 스크럼

• 슬랙 비상 채널에 올라오는것에 읽었으면 체크 이모지 남겨주기

---

• 유대감, 연결감을 위해서 접속하기

• 음질이 가장 깔끔함.

• 알람을 켜놓기

  그룹프로젝트_web17 : 공지

  undefined : 잡담방

• 회의록
• 각종 문서 저장
• 회고 등등

• Github만의 이슈 관리가 불편했다. (데이터 시각화 부족)
• 새로운 기술에 대한 학습 vs 거기서 나오는 코스트
• Jira에 대한 흥미

장점

• 개인적으로 써보고 싶다.
• 현업에서 많이 쓰니 사용경험 해보고 싶다.
• Jira를 사용하는 프로세스에 대해 배울 수 있을 것 같다.
• Github과 연동이 좋다.

단점

• 배워야한다.
• 읽을 사람이 알아야할 것.

장점

• 프로젝트 볼륨에 맞다.
• 연동 필요 없이 편리하다.
• 보여주기도 편하고, CI / CD로 이어졌을 때도 좋을 것 같다.

단점

• 시각화가 Jira보다는 덜하다.

• Jira와 Github를 연동해서 쓴다.
• 읽을 사람들을 생각해서 Github으로 결정하되, Issue를 관리하는데에 있어서 필요한 도구들(Project 탭, wiki, Issue 자동 Close 등)을 이전보다 적극활용하기.
• Trello : Jira와 이유가 겹치고, Jira가 더 매력적
• Excel : 더 나은 도구가 많다.

• 조직의 소유권이 없어서 코드 공유가 어렵고, Github Projects를 사용해보니 충분히 프로젝트 관리가 가능했다.