이슈 단위를 제대로 정의하자

[kyum-q]

08/12 17:30 | 15분간

결정 사항

스프린트 실행 시 이슈를 먼저 생성하고 시작하자

• 기능 구현 -> fe/be 같이

• 추가적인 리펙터링

  • 코드에 관한 -> 각자

• 추가적인 버그

  • 기능에 대한 -> 같이
  • 코드에 관한 -> 각자

---

문제 정의

이슈 단위에 대한 관점이 다 다른 것 같다.

이슈

1. PR과 같은 작은 단위로 사용

검색 구현 시, keyword로 검색할 수 있다
검색 구현 시, categoryId로 검색할 수 있다

• 장점
  • 프로젝트의 세부적인 진행 상황을 추적하기에 좋다.
  • 작업 단위가 작아지면 코드 리뷰나 버그 수정 등의 피드백 사이클이 빨라져 개발 속도가 향상될 수 있다.
  • 또, 각 이슈가 구체적이기 때문에 누락되는 작업이 줄어들 수 있다.
  • 프로젝트 사용 시 이슈가 세분화 되어있기 때문에 진행중인 기능 파악이 쉽다
• 단점
  • 이슈가 너무 많아져 관리가 복잡해질 수 있다.
  • 또한, 작은 이슈들 간의 의존성을 관리하는 것도 번거로울 수 있다.

2. 하나의 기능 단위로 사용

검색 구현
(그리고 이슈 content에 사소한 구분을 적어 놓는다)

• 장점
  • 이슈의 수가 적어져 관리가 쉽고, 기능 단위로 작업이 정리되기 때문에 한눈에 파악하기 좋다.
  • 큰 그림에서 기능별로 진행 상황을 추적할 수 있어 프로젝트 관리가 단순하다.
• 단점
  • 하나의 이슈에 너무 많은 내용이 포함되면, 세부적인 진행 상황을 추적하기 어려울 수 있다.
  • 이슈가 모호해지거나, 특정 세부 사항이 누락될 위험도 있다.

결정해봐요

• 이슈 단위를 명확하게 정한다.
• 이슈 단위에 따라 프로젝트 사용 방법을 정한다.

내 주장

• 이슈 단위: 하나의 기능 단위로 사용
  • 대신 이슈에 세부적인 내용을 잘 적고 체크를 잘 하자
• 프로젝트 사용 방법
  • 이슈 단위로 확인하는 프로젝트 -> 전체적인 기능 진행 사항 확인 목적

[kyum-q]

이슈를 기능단위로 가져간다고 해도 프로젝트가 의미가 없어지지 않는다.

[kyum-q]

스프린트 실행 시 이슈를 먼저 생성하고 시작하자

• 기능 구현 -> fe/be 같이

• 추가적인 리펙터링

  • 코드에 관한 -> 각자

• 추가적인 버그

  • 기능에 대한 -> 같이
  • 코드에 관한 -> 각자