생활 룰

프로젝트 기간동안 물리적으로 지켜야 하는 규칙

모든 규칙은 서로를 배려하고 이해하기 위해 존재한다!

out 코어 타임

일정

공유 구글 캘린더

각자 초대한 구글 캘린더로, 일정을 공유한다.
개인적인 일로 참여가 불가능한 경우 (코어타임, 야근, 주말) 일정을 파악하기 위해 사용한다.

• 각자 면접 등의 일정을 캘린더에 적어 서로의 상황을 이해하는 데 초점을 맞춘다.
• 서로의 스케줄을 고려해 작업량을 민주적으로 분배하는 데 사용한다.

메신저

카카오톡 단체 톡방

프로젝트와 관련 있지 않은 일상 내용을 올리는데 사용한다. (지각, 몸 상태, ⚡번개모임 등등)

10시 이후의 메시지는 자제한다.

Slack

프로젝트에 관련된 내용을 올리는 데 사용한다.

• 참고할만한 오픈소스 및 자료의 링크
• 간단한 코드 및 파일 공유

일상 메신저와는 분리된 작업용 메신저의 기능을 온전히 할 수 있도록 한다.

구글 드라이브

프로젝트에 관련된 파일 (github에 올리는 내용은 제외)을 공유하는 데 사용한다. (문서, 이미지)

• 파일 및 폴더 명은 오해의 소지가 없도록 명명한다.
• 프로젝트 진행 중 일정 시간을 할애해 정리하도록 한다.

in 코어 타임

타임 스케줄

지각

지각은 지양한다.
만약 지각할 경우 카카오톡으로 미리 얼마정도 늦을 지 팀원에게 알려야 한다.
지각한 팀원은 작업 시작 후 1시간 동안 서서 작업해야 하는 패널티를 받는다.

작업, 휴식 interval

sprint 주를 제외하고는 작업 - 휴식 cycle을 순회하며 작업한다.

• 프로젝트 참여 인원의 컨디션을 보장하기 위함이다.
• 개인의 규칙적인 휴식시간을 보장하도록 노력한다.

각자 자유로운 스케줄로 작업하도록 한다.

sprint 주차

7주간의 과정 중에서 일정 주차는 sprint 주차로 설정하고 짝 코딩대신 개인별로 프로젝트를 진행하며, 개인이 가능한 최대한의 작업을 진행한다.

1주	2주	3주	4주	5주	6주	7주
			sprint

럼크스 리일데 (마무리 스크럼)

18:45 부터 19:00 간 진행
각자 당일 작업한 내용, 달성도, 컨디션 등을 공유한다.
데일리 스크럼과 같이 wiki에 간략히 작성하도록 한다.

야근

당일 할당량을 채우지 못한 경우나, 추가적으로 학습이 필요한 경우 야근을 할 수 있다.

• 야근을 한 인원은 다음날 작업을 분배할 때, 작업양이 최소가 되도록 분배하는 것을 지향한다.
• 각자 야근으로 인해 컨디션이 망가지지 않도록 관리한다.

프로젝트 진행

daily 회의 (짝 코딩)

데일리 스크럼 외에도 팀원간 프로젝트 이해도를 높이기 위해 주기적인 회의를 진행한다.
모든 인원이 하나의 회의에 참여하는것이 어려우므로, 회의 후에는 참석하지 않은 팀원을 위해 기록, 정리해서 설명한다.
회의에 참여하지 않는 인원은 프로젝트에 대한 내용을 회의 참여자들에게 위임할 수 있다.

코드 리뷰

하루에 한번 씩 각자의 코드를 리뷰하는 시간을 가진다.

• 코드 리뷰의 내용은 다음과 같은 경우 comment를 남길 수 있다.

  1. 코딩 rule에 어긋난 경우
  2. 이미 존재하는 method를 직접 구현해서 사용하는 경우
  3. 함수의 호출 순서의 이해가 명확하지 않아 개선이 필요한 경우
  4. password등을 hard coding해 보안상의 문제가 존재하는 경우
  5. 자기가 진행하는 내용과 merge시 충돌이 우려되는 경우

• 코드 리뷰의 경우 다음과 같은 규칙을 따른다.

  1. comment를 달 때는 높임말을 사용한다.
  2. commit을 시간순으로 한번 훑어 본 뒤 comment를 달 수 있다.
  3. 이미 앞에서 지적한 내용이더라도 반복되는 경우 comment를 달아야 한다.
  4. code review가 끝나고 마지막 comment에는 자신이 이해한 내용을 적는다.

weekly leader

매 주 돌아가면서 PM 역할을 수행한다.
자신이 주로 담당한 기능이 진행되는 주인 경우 PM 권한을 자처할 수 있다.

작업 분배

서로 그날그날 가능한 작업량을 가져갈 수 있도록 노력한다.
각 feature마다 작업 점수를 할당해 (걸리는 시간과 비례) 각자의 그날 작업 량을 파악하도록 한다.
연관되어 있는 작업들의 경우, 우선순위가 높은 순으로 작업한다.

• 현재 진행하는 작업이 마무리 되기 전에, 다른 작업을 우선 해야 할 수 있다.
• feature branch를 진행하는 경우는 꼭 commit 규칙을 지키지 않아도 된다.
• feature branch를 merge하기 전 commit convention을 지켜 commit을 리팩토링 한 뒤 merge한다.

각자 역량에 따라 진행한 작업의 총 량이 다를 수 있으므로 이해할 수 있도록 한다.

Pull Request

PR을 merge하기 전 최소 2명의 code review를 진행해야 한다.
짝코딩으로 만든 PR의 경우 code review를 만족한 것으로 한다.

Pull Request를 날릴 때 다음과 같은 제목과 내용을 작성한다

• 제목에는 PR의 작업 내용을 요약한 내용을 추가한다.
  • commit convention의 태그 + 제목과 유사하게 한다.
• 내용에는 다음과 같은 내용을 가진 문단을 각각 추가해야 한다.
  • 진행한 내용들을 열거하는 문단
  • 왜 그렇게 코드를 작성했는지에 대한 간략한 설명
  • 공유해야 하는 지식 keyword (옵션)

PR의 merge는 그 주의 PM이 권한을 갖는다.