설계 | 협업환경 구성
이제 협업환경을 구성할 차례입니다. 저희는 github의 projects 기능을 이용했습니다. 개발 가이드, 전체 클래스 명세서, 카드 템플릿, 이슈 리스트를 가장 좌측의 Note 탭에 놓았습니다. 그리고 To-Do, Progress, Review, Pushed의 네 개의 진행상태를 Column으로 만들고 task를 카드 단위로 관리했습니다.
task는 클래스 단위로 만들었지만, 클래스 사이즈가 큰 경우에는 헤더/소스 파일 생성 및 멤버 변수, getter/setter 세팅을 하나로 놓고 메소드 수에 따라 메소드 파트를 분할하여 추가로 카드들을 만들었습니다. 초반에는 모든 카드가 구현(implement) 라벨 카드였고, 1차 구현을 완료한 뒤에는 QA 카드들을 만들어서 QA를 진행, 발견되는 오류들이나 수정사항들은 fix 카드를 만들어서 작업했습니다.
카드 안에는 세부 체크리스트와 특이사항을 정리하고, 개발이 진행될 때마다 체크리스트에 체크하여 진척사항을 공유할 수 있도록 했습니다.
github의 project 기능은 pull request를 연동할 수 있고, 다른 서비스를 따로 쓰지 않아도 된다는 점에서 유용합니다.
팀 협업 가이드
아래는 저희 팀의 협업 가이드입니다. 참고해서 너무 수고스럽지 않으면서도 명확하고 편하게 협업할 수 있는 가이드를 만들어보세요.
팀 내 개발이 필요하다고 판단되는 이슈가 있다면 카드를 To-Do 섹션에 카드를 생성합니다. 신규 개발인지, 오류 수정인지, 개발한 기능에 대한 QA인지에 따라 implement / fix / QA 라벨을 설정합니다.
To-Do 섹션에서 개발하고 싶은 이슈를 누르고 Assignees에 자신의 id를 태그합니다. 신규 개발인지, 오류 수정인지, 개발한 기능에 대한 QA인지에 따라 implement / fix / QA 라벨을 설정합니다.
카드를 Progress 열로 옮기고, 해당 이슈에서 필요한 개발 항목들을 체크리스트로 생성합니다.
다른 개발자에게 공유해야 할 특이사항이 있다면, 체크리스트 위에 특이사항으로 공유합니다.
브랜치를 생성하여 개발을 시작합니다.
개발 진척사항을 알 수 있도록 체크리스트의 항목을 완료할 때마다 체크 마킹을 하면서 진행합니다.
모든 체크리스트가 완료되면 풀 리퀘스트를 날리고, 카드에 해당 풀리퀘를 태그한 후 Review 열로 옮깁니다.
리뷰 열로 넘어온 카드의 풀 리퀘스트에 대해, 다른 개발자들은 코드 리뷰를 남기고 approve 또는 거절을 표시합니다.
마지막으로 코드 리뷰를 하는 개발자는 자신까지 전원 approve한 풀리퀘일 경우 풀리퀘를 승인하고, 카드를 pushed로 옮깁니다.
마지막 개발자까지 리뷰된 풀리퀘에 대해 보류 또는 거절이 하나라도 존재할 경우, assign 되어있는 개발자가 풀리퀘를 닫습니다. 카드를 다시 To-Do 세션으로 옮겨서 앞의 절차를 반복합니다.
참고 이미지
Last updated
