협업 프로세스

협업을 어떻게 진행할지에 대해 정리한다.

용어정리

협업에 있어 가장 중요한 것은 의사소통이라고 생각합니다. 따라서 의사소통에 필요한 용어를 우선적으로 이해합니다.

스프린트

• 스프린트 개발 주기를 의미한다.

• 스프린트의 기본 단위는 1주일로 한다.

• 스프린트는 크게 3가지로 나눠볼 수 있다.

  1. 개발 계획

  2. 개발

  3. 테스트

스프린트 계획 회의

• 스프린트의 목표와 개발 제품에 대한 요구사항 목록(backlog)을 정리한다.

• 정리된 backlog 에서 우선순위에 따라 이번 스프린트에서 해결할 문제들을 todo 로 만든다.

  • 우선순위는 라벨링과 라벨링에 따른 정렬을 이용한다.

스크럼 회의

• 매일 아침 짧게 진행하는 회의.

  ❗늘어지지 않도록 스탠드업 미팅 의 방식으로 진행한다.

• 어제 한 일 / 오늘 할 일 / 새로 추가한 issue 에 관한 이야기를 한다.

• 그 외에 공유할 내용이 있다면 공유한다.

스프린트 회고

• 스프린트 회고는 스프린트의 종료 시점에 진행한다.

• 효율적이었던 부분, 비효율이 있던 부분을 분석해서 스프린트 과정을 더 효율적으로 만들도록 노력한다.

issue

• issue 는 처리해야할 일의 가장 작은 단위다.

• issue 는 언제든지 추가할 수 있다.

• issue 는 팀원들과의 회의 도중 바로 close 될 수 있다.

• issue 는 관련된 issue 끼리 묶이거나 또는 그 issue 하나만으로 backlog 가 된다.

backlog

• backlog란 개발할 제품에 대한 요구 사항 목록이다.

• 스프린트 계획 회의 에서 백로그를 작성한다.

  ❗프로젝트 계획 단계 또는 스크럼 회의 에서도 작성될 수 있다.

• 하나의 backlog 는 규모에 따라 여러개의 todo 가 될 수 있다.

• 하나 또는 여러 개의 issue 가 하나의 backlog 가 된다.

todo

• todo 는 이번 스프린트에서 완성할 기능이다.

• backlog 를 갈무리해서 todo 로 만든다.

• todo 는 한 PR 의 단위가 된다.

• 기본적으로 스프린트 계획 회의 에서 todo 를 정한다.

  • 진행상황에 따라 스크럼 회의 에서도 backlog 를 todo 로 만들 수 있다.

• todo 는 최대한 자세히 적는다.

  • 체크박스의 리스트로 만든다.

  • 체크박스의 리스트 단위는 하나의 커밋 사이즈가 되어야 한다.

In Progress

• todo 에서 현재 진행중인 작업을 칭한다.

Done

• 작업이 마무리 되면 Done 상태가 된다.

PR

• pull request 의 약자.

• PR 의 단위는 수정 된 line 을 기준으로 300 ~ 500 으로 한다.

• PR 에는 해당 PR 이 해결한 issue 를 link 시킨다.

• PR 은 최소 2명이 리뷰를 진행한다.

• PR 이 성공적으로 마무리가 되면 PR 작성자가 merge 후 원격저장소에 있는 branch 를 삭제한다.

스프린트 진행과정

1. 스프린트 계획 회의 를 통해 이번주의 목표에 도달하기 위한 backlog 를 정리하고 todo 를 작성한다.

   ❗ backlog 는 프로젝트 전체에 대한 기능의 목록인 반면 todo 는 이번 스프린트 에서 해결할 문제들임

2. 팀장은 각 팀원들이 진행할 todo 를 assign 해준다.

3. 각 팀원들은 자신이 맡은 todo 를 진행한다. 진행함과 동시에 In Progress 상태로 만든다.

   ❗각 작업들은 새로운 브랜치를 따서 진행해야한다.

4. 작업 도중 버그 또는 추가 되어야할 기능과 같은 생각이 떠오르면 issue 를 만든다.

5. 매일 아침 스크럼 회의 가 진행된다. 이 회의에서는 어제 작업한 내용을 우선적으로 공유한다. 그리고 새롭게 추가된 issue 에 대한 의견을 나눈다.

6. 작업이 마무리 되면 PR 를 작성한다.

7. 스프린트 의 마무리 날에는 리뷰를 진행한다.

하나의 todo 를 해결하는 과정을 예시로 알아보자

1. 회의 결과 나에게 댓글 기능 추가 가 배정되었다.

   • 기능의 추가와 댓글 이라는 명사가 명확히 주어졌으므로 feat/comment 와 같은 브랜치를 만들면 된다.

2. develop 브랜치에서 feat/comment 라는 브랜치를 만들고 진행한다.

3. 새로운 issue 가 생겼다면 추가한다.

4. 작업 시작 전 스크럼 회의 에 참여해 어제 새로 생긴 issue 를 공유하고, 팀원들의 이야기도 듣는다.

5. 다른 팀원이 PR 을 마무리하면 현재 작업하고 있는 내용을 마무리 또는 git stash 한 다음에 merge 작업을 들어간다.

6. 내 작업을 마무리 짓는다면 PR 를 작성한다.

7. 리뷰가 끝나면 merge 와 해당 브랜치의 삭제를 진행한다.

8. 다음 todo 를 진행한다.

GIT 사용법

GIT

이슈트래킹 툴

이슈트래킹 툴은 ZenHub 를 사용합니다.

왜 ZenHub 를 사용하는가?

ZenHub 는 GitHub와 완벽하게 연동된다.

1. 다른 도구(Jira, Trello, ...)와 다르게 github 와 바로 연동이 된다.

2. 내가 계획한 협업 프로세스를 완벽하게 적용할 수 있다.

3. 무료다.

기존에 사용하던 github project 와 ZenHub 의 비교

1. issues 와 project 의 탭이 분리되어 있어서 한눈에 보는데 불편함. 반면 ZenHub 는 Issue 또한 하나의 칸반보드로 관리함

2. sprint 라는 개념이 존재하지 않아서 milestone 으로 스프린트를 관리해야했다. 반면 ZenHub 는 sprint 가 있음. 실제로 milestone 보다 sprint 기능을 적극 권장함.

3. 우선순위를 라벨링으로만 해야한다. 반면 ZenHub 는 정말로 우선순위 설정 기능이 존재하고, 자동으로 top - bottom 으로 정렬을 해준다.