🧾 WEEK 2 팀 회고록

WEEK 2 팀 회고

김가네 팀에서는 일관된 회고를 유지하기 위해 여러가지 회고 방식 중 KPT 회고 를 선택했습니다.

• 회고 일시 : 2022-11-18 (금) 16:00
• 회고 위치 : zoom
• 참석 인원 : J043_김승현, J046_김우석, J056_김지원
  • J061_김태훈 : 예비군 이슈 🪖

개인 회고

이름	캠퍼ID	개인 회고
김승현	J043	👨🏻‍💻 WEEK 2 개인 회고록 김승현
김우석	J046	👨🏻‍💻 WEEK 2 개인 회고록 김우석
김지원	J056	👨🏻‍💻 WEEK 2 개인 회고록 김지원
김태훈	J061	👨🏻‍💻 WEEK 2 개인 회고록 김태훈

팀 회고

👍 지금까지 잘 지켜진 사항

1주차

• 페어 프로그래밍 하는 부분이 너무 좋았다. ✅
• 필요할 때 마다 줌에서 모여서 회의 하는 부분이 좋았다. ✅
• 여러가지 컨벤션 지키면서 프로젝트 관리하는 부분이 좋았다. ✅
  • 추가로 git hook으로 dev, main 브랜치에 푸시하지 못하도록 컨벤션을 추가했다.
• 아침마다 전날에 한 일이나 이슈에 대해 공유하는 부분이 좋았다. ✅

지난주 회고 돌아보기

😁 Keep: 유지하고 싶은 부분

✅ Good! 잘 지키고 있어요.

- 페어 프로그래밍 하는 부분이 너무 좋았다. 
- 필요할 때 마다 줌에서 모여서 회의 하는 부분이 좋았다.
- 여러가지 컨벤션 지키면서 프로젝트 관리하는 부분이 좋았다.
- 아침마다 전날에 한 일이나 이슈에 대해 공유하는 부분이 좋았다.

• 추가적으로 git hook으로 dev, main 브랜치에 푸시하지 못하는 컨벤션을 추가하는 등 잘 지킨 것 같다.

❓ 음.. 약간 아쉬워요.

- 계획 꼼꼼하게 세운 부분이 좋았다.
- PR 에서 코드리뷰를 진행하고 머지하는 방식이 좋았다.

• 목표는 명확하게 잡았다고 생각하지만, 그 과정에 대해서 조금 더 명확하게 하는 게 좋을 것 같다.
• 점점 개발 할 양이 많아지는데, 과정을 명확히 하지 않으면 개발에 너무 매몰 될 것 같다는 생각이 든다.
• 그리고 코드리뷰 자체는 했는데, 오류가 있어도 발견하지 못하고 통과하거나, 대충 읽고 넘어간 경우가 많았다고 느꼈다.

😞 Problem: 고쳐야 할 부분

✅ Good! 문제를 고쳤어요.

- 테스트 코드에 신경써서 작업하기
- PR 제목이 분명하지 않았던 것 같다.
- PR 에 `Assignee` 부분 다는게 미흡한 것 같다.

• BE는 테스트코드 많이 잘 짰다.
• PR 제목도 읽었을 때 확실히 이해 되도록 지어진 것 같다.
• PR 속성 다는 부분도 이전보다는 많이 나아졌다.

❓ 음.. 약간 아쉬워요.

- FE 테스트 코드 신경써서 작업하기

• 기능 개발이 많다보니 테스트 코드에 신경을 덜 쓴것 같다.

🤔 Try: 도전할 부분

✅ Good! 도전에 성공했어요.

- 디자인은 이번주 주말 활용해서 프로토타입까지는 만들지 말고 디자인을 모두 뽑아보기로 한다.
- 멘토님과의 식사: `2022-11-16 19시 30분`

• 전체적인 디자인과 일관성 부분에서는 성공적이였다고 느꼈다.
• 멘토님과의 식사에 모두 참석해서 많은 이야기를 직접 나눴다.

❓ 음.. 약간 아쉬워요.

- 디자인이 완성되었는지 느끼기에는 아직 부족했다고 느꼈다.
- 데일리 스크럼을 조금 더 체계적으로 해보자.

• 특히 Github Projects 를 활용해보자 했는데 제대로 활용하지 못한 것 같다.

이번주 회고

😁 Keep: 유지하고 싶은 부분

• 다 같이 모여서 dev 에서 main 브랜치로 옮기는 과정이 좋았다.
  • 바로바로 오류 났을때 FE-BE 함께 에러를 잡았던 과정이 굉장히 좋았다.
• 이번주에 BE 테스트 작성이 굉장히 잘 되었다고 느꼈는데, 유지할 수 있도록 노력하려고 한다.
• FE 에서 일관성 있는 디자인을 짠 것 같은데, 유지할 수 있도록 한다.
• 애자일한 개발 방식 (필수 기능을 먼저 구현하고 - 부가적인 기능을 구현하는 방식) 을 유지하자.

😞 Problem: 고쳐야 할 부분

• PR 시 코드리뷰를 조금 더 꼼꼼히, 집중해서 해야 할 것 같다.
• FE 에서 테스트 코드에 조금 더 신경을 써야 할 것 같다.
• Github Projects 활용을 통해 백로그를 관리해야 할 것 같다.
• 데일리 스크럼에서 이슈 공유하고 같이 닫는건 좋은데 그 일정이 체계적인 것 같지는 않다.

🤔 Try: 도전할 부분

• 일주일에 한번씩 기술적 문제 해결, 트러블 슈팅 경험 등 자유 양식으로 문서를 작성하고 위키에 올려보려고 한다.

• Github Wiki 는 토요일에 개편하려고 한다.

• 프로젝트를 한 눈에 볼 수 있는 문서를 만드려고 한다.

• 데일리 스크럼 + Github Projects 를 활용하려고 한다.

  1. 아침에 모여서 데일리 스크럼을 시작한다.
  2. 다 같이 이야기를 하면서 어제 백로그에 대해서 진행중, 완료 여부를 이야기하고, 새로운 백로그도 생성한다.
  3. 정한 역할에 따라 `Github Projects`, `Issues`, `Pull Request` 를 관리한다.
    - Issue 닫기 : 모든 일이 끝났다고 판단 할 경우 Issue Close. 백로그는 자동으로 종료 상태로 변경된다.
    - Issue 추가 : 새로운 할 일을 이야기하고 양식에 맞추어 Issue 를 생성한다. `Assignee`와 `Project`, `Label` 등을 꼭 기입한다.
    - Backlog 변경 : 데일리 스크럼 동안 이야기 한 이슈 중 진행중이거나 진행 할 예정인 백로그들을 `진행중` 상태로 변경한다.
    - 추가로 Github Projects 에서 공개 가능한 스프레드시트로 마이그레이션하는 작업은 Week6 에서 고려한다.
  

• BE 에서 프레임워크 쓰는 구조는 비슷한데, 세부 구현을 보면 개발 스타일이 좀 달라서 통일해보려고 한다.

• FE 에서 .scss 파일에 대한 prettier 가 작동하지 않아서 CSS 스타일 맞추기가 필요하다.

• .env 파일을 google drive에 올리고 링크로만 접근 가능하게 만들고, 팀 슬랙의 책갈피에 추가한다.

• POSTMAN에서 타입을 명확히 명세하는 기능을 추가했으면 좋겠다.