HomeAboutMeBlogGuest
© 2025 Sejin Cha. All rights reserved.
Built with Next.js, deployed on Vercel
🍗
[New] 조규현팀
/
인스타뀨램
인스타뀨램
/
🔉
깃컨벤션, 이슈관리, 유저스토리, 전체 일정 로드맵
🔉

깃컨벤션, 이슈관리, 유저스토리, 전체 일정 로드맵

생성일
Jun 14, 2022 05:05 AM
tag
깃 컨벤션
이슈관리
유저스토리
Property
깃 컨벤션<기존의 컨벤션> 이슈 관리유저 스토리전체 일정 로드맵FIX앞으로 해야 할 것들작업 단위(MUST)분할 - 2

깃 컨벤션

<기존의 컨벤션>

feat : 새로운 기능 추가
fix : 버그 수정(핵심 비즈니스 로직)
refactor : 코드 구조 변경 및, 네이밍 변경 포함 - (삭제 파일 포함)
style : 마감 처리 , 컨벤션
setting : dependency 설정
test : ${xxxx} 테스트
docs : readme 기능 리스트 추가
 
동운
  • 기존 컨벤션 이하동문인데, init 은 있어도 되지 않을까 싶었습니다.
병연
  • 기존 컨벤션 기반 작성
  • 형욱님인가? 동운님이 컨벤션 적용이 안된거 같음 패키지
  • * 와일드 카드 제거해야함
  • 커밋단위는 기능단위 이되 테스트는 따로 커밋 단위로 가져갈지 고민해봐야 함.
형욱
  • 기존 컨벤션 기반 좋은 것 같습니다.
진형
  • 기존
  • 와일드카드 관련 설정 수정해서 한사람이 노션에 .xml 뿌리기(진형이 뿌리기)
혜빈
  • 기존 컨벤션으로 가져가도 괜찮지 않나 생각합니다.
 

이슈 관리

동운
  • 지라
병연
  • 지라 + 노션
형욱
  • 지라 + 노션
진형
  • 지라 + 노션
  • 지라로 간단한 이슈 생성
    • 공유할만한 내용이면 노션에 트러블 슈팅 과정 작성
      • 상황
      • 분석
      • 해결
혜빈
  • 지라로 진행 중인 상태는 확인 가능하니까 해당 이슈가 있었다는
    • 사실과 기록 관리? 처럼 가져가는건 어떨지
    • 현재 저희가 노션에서 이슈 관리하듯이 테이블 사용
  • 이슈 템플릿
    • 이슈가 일어난 상황 , 시도했던 방법 , 현재 상황
    • 쭉 쓰고 해결했으면 마지막에 해결한 방법 쓰면 되지 않을까요?
    • 특별한 템플릿이 필요할까 ? 라는 생각이 듭니다.

유저 스토리

user story - 1
notion image
  • 예시
notion image
https://brunch.co.kr/@workingus/36

전체 일정 로드맵

동운
  • ERD → 분담
  • 패키지구조
  • 깃 컨벤션
  • 코딩 컨벤션? - DTO 규칙 등
 
  • 내일
    • 나머지
병연
화요일
  • 테스크 분할 후
  • erd
  • 패키지 구조
  • dto 규칙
  • 네이밍 규칙
수요일
  • 지라 관리 사항 결정
  • 시퀀스 다이어그램
형욱
  • 화요일
    • 깃 컨벤션,
    • DTO 네이밍 전체적인 코드 컨벤션과 관련된 규칙 정하기
    • 유저스토리 작성 완료하기
    • 패키지구조
  • 수요일
    • ERD, 유즈케이스 필요한 다이어그램 작성하기
    • 유저스토리 지라로 옮기기?
  • 목요일
    • 업무분담
진형
  • 오늘은 프로젝트 규칙, 패키지 구조, 깃 컨벤션, 코딩 컨벤션 DTO규칙(서비스 컨트롤러 DTO규칙), DTO 네이밍 규칙 등 정할 수 있을듯
  • ERD, 유스케이스 다이어그램, 시퀀스는 무리일수도?
  • 지라 지식 동기화 하기
  • 내일
    • 지라 대략적으로 실습해왔을거니까 에픽, 이슈 옮기고 스토리 포인트 할당?
    • 시퀀스다이어그램 채우기
    • API 명세 채우기
혜빈
  • 오늘 내일 안에 끝내기로 한 것 같은데 무리일 것 같아요
  • 유스케이스 - 15일
  • ERD - 15일
  • 시퀀스 - 16일
  • 패키지 구조 - 16일
  • DTO 규칙 - 16일
 

FIX

오늘까지 (코어타임전까지)
1. 업무분담
  1. ERD
  1. 패키지 구조
  1. DTO 규칙
 
내일까지 (사전지식이 필요해 보임)
  1. 유스케이스 다이어그램
  1. 시퀀스 다이어그램
    1. api
 
 

앞으로 해야 할 것들

동운
병연
형욱
진형
  1. 유스케이스 먼저아닌가?
  1. 그다음 행동에 의해 연관관계가 나올 것 같다.
  1. ERD
  1. 업무 분배
  • 이게 맞지 않나?
 
혜빈
  • ERD 빨리 나왁!!!!!!!!!!!

작업 단위(MUST)분할 - 2

  • 각자 하고 싶은 기능들 리스트
  • User - 2명
  • Post -2명 : 동운, 형욱
  • Comment -1명
 
조를 나눈 다는 느낌
  • Post + Comment 3명
  • User 2명
 
동운
  • Post - User - Comment
병연
  1. User
  1. Post
  1. Comment
형욱
  1. Post → Comment → User
진형
  • 노상관 User→ Post→ Comment
혜빈
  • Post→ User → Comment
 
  • 유스케이스 - 3
  • ERD - 4
시퀀스 - 5
  • API 설계
notion image
notion image
  • 테이블 안에 내용들이 스토리들이 될 것이다.
  • 실제로 api 라고 적기보다는 회원은 자기 데이터를 어쩌고 저쩌고를 한다 라는 스토리로 표기하는 것
패키지 구조
진형
  • 도메인 중심 패키지 기반
  • 더 자세한거는 나중에 얘기나올 때 ㅇㅇ
DTO 규칙
진형
  • Service에서 엔티티 끊는거 선호합니다.
  • XXXRequest 내부에 이너 스태틱 클래스로 CreateXXXRequest, UpdateXXXRequest 레코드로 작성하는것 선호합니다.
  • 네이밍 Create,Update,Delete XXX Request,Response
 
 
USECASE - 진형님, 혜빈님
ERD - 병연님,형욱님
지라 - 동운님
6시까지