협업 프로젝트 진행 시 팁

개발을 혼자하면 큰 문제가 생기지 않지만
개발을 여러 명이서 같이 협업으로 할 때가 종종 생깁니다.
회사에서 일을 한다면 더더욱 그럴 것입니다.

물론 회사 측에서도 어느정도 방향성과 더불어
틀이 잡혀있긴 할 테지만,
필자와 같이 학교에서 협업을 진행할 경우
방향성 및 틀이 전혀 잡혀있지않아
보통 선배에게 물어보거나 같이 의논하여
방향성과 틀을 잡습니다.

하지만 회사와 같이 서로 의견이 맞지않더라도
방향성을 같이 잡는 다는 것은 학교에서는 쉽지않은 일입니다.

그렇기때문에
1년간, 그리고 앞으로 학교 혹은 사적으로 같이
이런 방식으로 개발을 하면 어떨까라는 생각으로 포스팅하고 있습니다.
(해당 포스트에서 다루는 얘기는 필자가 다니는 현재 학교와 상황 등을 고려하여 작성하였습니다. 참고해주세요)

먼저, 주제를 정합니다.
주제는 요즘 이슈 혹은 불편했던 것들을 주제로 삼는 것이 여러 주제를 떠올리게 만들어
더 좋은 주제를 형성해나가는 데 좋습니다.

두 번째, 직무(분야)를 정합니다.
분야는 현재 팀원에 따라 조정을 해야합니다.
필요에 의해서는 더 팀원이 필요할 수도, 혹은 줄여야할 수 도 있습니다.

만일 팀원 총 6인인데
웹 프론트 3, 서버 및 백엔드 1,
안드로이드 2 이라면 백엔드 담당하는 팀원은
굉장한 책임감과 더불어 해결해야하는 일이
다른 팀원들에 비해 굉장히 많습니다.

이는 개발 속도와 더불어 오류가 많이 생길 수 있는 요인으로도 작용할 수 있습니다.

위 같은 경우, 서버 및 백엔드 담당 팀원을 1~2명을 더 추가하는 방향으로 가야합니다.

필자가 생각하였을 때 가장 이상적인 직무별
팀원 비율은
웹 프론트 2 : 서버 및 백엔드 2 : 안드 1 : IOS 1
입니다.
개인적으로 생각하였을 때에는
서버 및 백엔드는 수가 적어서는 안된다고 생각합니다.

왜냐하면 API를 개발하여 이를 공통적으로
사용을 해서 다른 프론트에 적용을 해야하는 데
이는 개발속도가 느려져서도 오류가 발생해서도 안되기 때문입니다.
(개발이 느려지면 느려질 수록 다른 프론트/클라 역시 같이 느려지기때문입니다.)
(기능 구현에 있어 결국 API를 사용해야하기 때문)

세 번째, 기본 기능과 추후 기능 불리
이는 #code를 진행하면서 느꼈습니다.
기본 기능을 나누어 백엔드와 프론트의 짐을 약간이나마 줄여 긴장을 풀며, 좀 더 생각을 하여
최대한 스펙을 바꾸지않도록 합니다.
스펙을 한 번 바꾸기 시작하면
완전히 갈아엎어버려야할 수 도 있기때문입니다.

네 번째, 커밋 메시지 정하기
커밋을 할 때 남들도 알아보기 쉽게
이모티콘등을 사용하여 어떤 기능을 CRUD하였는 지 손쉽게 확인하기 위해서입니다.

다섯 번째, 문서 작업하기
이는 백엔드 개발과 밀접한데,
API를 만들어 어떻게 사용해야하는 지에 대한
문서(사용법)이 없으면 사용하는 데에 있어
어려움이 있기때문입니다.

여섯 번째, 서로 의견 나누기
분야별 혹은 전체 팀원이 모여 의견을 나눕니다.
스펙을 최대한 바꾸지않는 방향으로 어떻게
초반에 기틀을 잘 잡을 수 있는 지, 그리고
이슈 해결 방안, 백엔드와 클라 측 의견 조성 등
을 해결하기 위해 서로 의견을 나눕니다.

특정 기간 등을 정하여 그때마다 서로의견을 나
누는 것이 좋습니다.

그외 여러가지가 있으나 이는 프로젝트의 종류마다 차이가 있기에 포스팅하지는 않도록 하겠습니다.

긴 글 읽어주셔서 감사합니다.
이상입니다.