Skip to content
cadenzah edited this page Jul 28, 2021 · 9 revisions

Ground Rule

스프린트 운영

  • 매주 화요일 저녁마다(시간 유동적) 간단히 스프린트 리뷰 / 다음 스프린트 플래닝 진행
    • 리뷰 내용은 Wiki에 작성
  • 매주 화요일마다 Milestone 새로 생성하고 개발 항목 점검
    • 지난 스프린트에 마치지 못한 이슈 있을 경우 이관
  • 진행 중 공유 사항, 논의 사항, 질문 사항은 실시간으로 공유

Issue, Project, Milestone 운영

  • Issue: 템플릿 양식을 참고하여 개발 내용 구체화.
    • 신규 생성시 Milestone, Project 등 가능한 선에서 최대한 지정
    • Backlog 성격인 경우 Project만 지정 (대응하는 Project가 없으면 새로 생성)
    • Assignee는 서로 충분히 협의하여 지정
  • Project: 같은 범주에 속하는 개발 항목들을 묶어서 이슈 관리
    • 포함된 일감 모두 완료시 Close
  • Milestone: 상기 스프린트 기간 운영 방식에 따름

개발 프로세스

  1. 개발 항목에 대하여 작성 및 Github Issue 등록 → 현재 진행중인 Github Project의 [To do] 보드에 자동 등록
  2. 개발 담당자가 결정되면 해당자를 Assignee로 지정하고, 해당 프로젝트의 In progress로 옮기기
  3. 해당 이슈에 대하여 브랜치 생성 (issue/<이슈번호>-<내용>으로 브랜치명 사용)
  4. 해당 이슈에 대하여 작업
  5. 작업 완료되면, push 한 뒤 Pull Request 생성. 이때, base 브랜치는 master가 아닌 dev

번거롭더라도, 함께 코드 리뷰를 꼭 진행하도록 해요

코드 리뷰는 예의바르게, 객관적으로, 차분하게, 실질적인 대안을 제시할 수 있는 자리가 되도록 (참고)

  1. 해당 PR이 머지되면, 2번부터 다시 진행
  2. 스프린트가 완료될 때마다 masterdev를 머지하고, 버전 업 Tagging

브랜치 규칙

  • master: 완전하게 동작하는 형상. 매 스프린트마다 업데이트
  • dev: 개발 형상
    • issue/<이슈번호>-<내용>으로 브랜치 checkout 하여서 각자 작업
    • 단, chore 성격의 내용 또는 개발 환경 수준의 수정 내용인 경우 별도 브랜치 없이 dev에 직접 커밋(작업 편의 도모)