Skip to content

2023.08.07 3차 스프린트 중간회고

헤인 edited this page Aug 7, 2024 · 2 revisions

K (좋았던 점)

  • 미리 데모데이 앞당겨서 한 점
  • 데일리 팀 나눠서 한 것 (백 + 프 함께 팀으로 작업해본 점)
  • 다들 ‘좋은 팀’에 대한 이상이 비슷해서 좋음 ⇒ 농담도 하고 재미있게 팀으로 일하는 것
  • 주 사용자가 팀 내부에서라도 정해진 것 같아서 좋았음
  • 피드백 서로 공유한거
  • 중간점검의 시간을 가졌던 점 ⇒ (목요일)
  • 노션 최소화 ⇒ 위키, 디스커션 사용
  • 질문을 눈치 안보고 할 수 있었음

P (아쉬웠던 점)

  • 막판에 PR을 코드리뷰 없이 올리게 되었다. ⇒ 화요일 마감이면 월요일까지 PR 올려야했다.
    • **마감에 대한 정의를 확실하게 하고 가면 좋을 것 같아요!
    • 리뷰 단위도 중요! + 리뷰도 빨리빨리 되어주어야…
  • 사용자 시나리오 아직도 몰라요… ⇒ 로그인, 카테고리, 태그가 왜 필요한지!!
  • develop으로 올리는게 너무 늦다. 한 번에 모아서 올리다보니 개발 서버의 의미가 없어진다. dev/be 와 dev/fe 가 없어도 될 것 같다. 개발서버가 개발서버가 아님 느낌…
  • develop으로 올라갈 때 백, 프 CD 둘다 돈다. ⇒ 리소스 낭비
  • 기능개발 PR 의 단위가 너무 큼 ⇒ PR을 나눠야할 것 같다. (이건 백프 둘다!)
  • 너무 생각보다 CICD에 시간이 많이 들었다. ⇒ 오히려 수동배포보다 힘들었…🥲 3분 편하려고 3시간 쓰는 느낌
  • 회의를 하기 전에 이 회의에서 결정해야 하는 범위에 대해 명확하게 정리되지 않아서, 그 회의에 참여 여부를 결정하기 어려웠다.
  • 진정으로 페어를 함께한 느낌이 적어서 아쉬웠다. ⇒ 시간을 조금 더 들이더라고 같이 설명해주면서 했어도 좋았을 것 같아요!
  • 백엔드 내에서 기능 / 인프라로 양분하여 개발. 두 스프린트째 역할 분담이 스위칭되지 않아서 역할 고착화가 걱정됨.
  • 모니터링의 경우 지금 수준도 충분하다고 생각, 그러나 모두가 공유되지 않아서 어느정도 수준으로 모니터링 하고싶은지 합의를 보고싶다! ⇒ 공유말고 회의 필요!

T (시도해볼 점)

  • 앞으로도 미리 데모데이를 앞당겨서 해보기 + 중간 점검 시간 가지기!

  • 모든 문서는 깃헙으로! 디스커션을 적극 활용하기

  • 잦은 배포가 더 중요한 것 같다. 자주 배포하고 자주 문제를 빠르게 맞이해보자! ⇒ 금요일

  • PR을 나눠야할 것 같다. (이건 백프 둘다!) ⇒ 작은 기능별로 나누자!

  • 마감에 대한 정의 ⇒ 마감이란 무엇인가?


< 코드잽 2주 스프린트 간의 일정>

1주차 기간

  • 월, 화, 수 - 각자 기능 개발

  • 목 16시 - 중간 점검 (Z 스프린트)

  • 금 - 리뷰 + 각자 기능 개발

2주차 기간

  • 월요일 밤 23시 59분 - PR 올리기

  • 화요일 18시 - 리뷰 + PR 머지 + 배포 (A 스프린트)

  • 수, 목 23시 - QA 문제 확인 및 문제해결

  • 금 - 데모데이+ 회식 😎 - (P 스프린트)

⚡️ 코드zap

프로젝트

규칙 및 정책

공통

백엔드

프론트엔드

매뉴얼

백엔드

기술 문서

백엔드

프론트엔드

회의록


Clone this wiki locally