- 팀원이 가져야할 마음가짐을 지켜요
- 우리는 매일 오후 1시 30분에 프론트 회의를 하고 2시에 전체 팀 회의를 한 후 회의록에 기록해요.
- 데일리 스크럼을 진행한 후에 회의를 시작합니다.
- 회의는 스크럼 마스터가 진행을 합니다.
- 회의는 회의 템플릿에 있는 것에 따라 진행합니다.
- 전날에 의견을 나눠야 할 주제를 미리 정리하고, 팀원들은 각자의 의견을 준비해옵니다.
- TASK가 정해지면 JIRA 티켓을 만들어요.
- 회의를 통해서 Task를 추출하고 백로그에 추가합니다.
- 백로그에 추가할 사항은 논의하여 스프린트 전에 스토리포인트를 고려하여 작성합니다.
- TASK는 각자의 역할에 맞게 분담합니다.
- 4일마다 스프린트를 진행하고 스프린트 규칙을 지켜요.
- 스프린트 회의는 주기 동안 진행해야 할 업무를 백로그를 바탕으로 분배합니다.
- 지난 4일 동안의 작업 완료 현황을 파악하고 백로그와 스토리포인트에 따라 다음 스프린트를 재조정합니다.
- 팀원들은 TASK Jira 워크 플로우에 맞게 JIRA 티켓을 관리합니다.
- 프로젝트는 프로젝트 로드맵에 따라 진행합니다.
- 계획을 JIRA 로드맵에 작성하고 로드맵에 따라 진행합니다.
- 개발을 할 때 코딩 컨벤션을 지키면서 합니다.
- 폴더명, 파일명 PascalCase
- index.ts로 작성하지 않고 관련 파일명으로 작성할 것
- index.ts에는 èxport {default as ${fileName}} from ‘./’
- [논의 필요] 함수명은 camelCase로 작성하며, function | arrow를 사용합니다.
- 변수명의 경우 camelCase로 작성합니다.
- 파일을 import 할 경우 alias를 사용합니다. @components/atoms/
- 백엔드와 프론트엔드는 함께 개발합니다.
- Github에서 형상관리를 합니다.
- 브랜치 전략은 Gitflow를 따릅니다
- main - 최종 배포
- release - develop에서 검증 후
- develop - 배포 전 모든 기능 개발, 수정 사항 Merge 브랜치
- [논의 필요]feature - 기능을 개발하는 브랜치
- feature/기능 || feature/DK-10 으로 할 것인지
- refactor - refactoring 브랜치
- hotfix - 바로 고쳐야하는 버그 브랜치
- commit은 Git 컨벤션을 지켜요
- feat: Add | Fix | 기능 추가
- chore: 설정 파일 추가 삭제
- refactor: 코드 구조 변경, 네이밍 변경
- test: 테스트 작성
- docs: 문서 작성
- 모든 팀원들은 PR을 날리고 팀원들끼리 코드리뷰를 진행해요
- 템플릿을 사용하여 PR을 만듭니다.
- 사소한 것이라도 PR을 올립니다.
- 기능 관계자는 필수로 코드리뷰를 비동기적으로 진행합니다.
- 리뷰는 24시간 안에 진행합니다.
- 당일 PR을 날릴 일이 있으면 미리 양해를 구하고 예고합니다.
- 2명 이상의 PR 확인 시 슬랙에 공지 후 Merge합니다.
- 스프린트 단위로 회고를 하고 회고록에 기록합니다.
- 스프린트 단위가 끝나는 당일에 회고를 진행합니다.
- 스프린트 동안 부족한점 말하고 싶은 점, 일정관리 등 개선되어야 할 사항에 대해 논의합니다.
- 자신과 상대방에 대해 객관적으로 피드백합니다.
- 시간 관리
- 1시30분 프런트 회의
- 2시 전체 데일리 스크럼(각자 뭐 했고 뭐 할 것이고 주요 논쟁 사항)
- 2시 15분~ 7시 개발
- 그 외에는 자유로 진행 개발 진행, 허나 맡은 일은 완료할 것
- 코어타임: 디스코드
- 그 외 시간: 게더 || 구글 미팅 || 디스코드