첫 협업 프로젝트를 준비하면서 가장 큰 고민이 무엇인가요?
리아와 스펜서가 여러분들의 고민을 모아 멘토님에게 조언을 구해보았습니다!
코발트에서 함께 근무하고, 데브코스에서 멘토로 활동해 주시는 김지은&조규현 멘토님과 첫 협업을 멋지게 시작해봅시다. 🏃🏃🏻♂️
- 마지막 업데이트 일시: 2021-11-26
- 질문자: 리아
- 답변자: 프론트 멘토 김지은님, 백엔드 멘토 조규현님
Github 관련
회사마다 다르겠지만 지은, 규현님이 근무하시는 코발트에서의 깃헙 이슈 관리 규칙이 궁금합니다!
지은 멘토- 저희의 이슈는 크게4가지 입니다. 버그, 개선, 기능, 리팩토링
- 이슈 라벨을 다음과 같이 정했습니다. (개선, 기능, 버그, 디자인, 에픽, 리팩토링, 릴리즈, 문서)
- 이슈에 따라 문서를 다르게 적습니다.
- 개선이면 기존과 무엇이 개선이 되었는지, 연관된 이슈가 무엇인지,
- 버그라면 버그설명, 재현경로, 필요하다면 스크린샷 등 어떤 환경에서 버그가 발생되었는지.
- 그리고 연관된 이슈가 있으면 같이 링크를 걸어주고, 이 이슈의 pr이 생긴다면 linked pull request에 pr을 연결합니다.
규현 멘토- 저희는 시나리오 기반(문서, 다이어그램) 으로 이슈를 생성하고 있습니다.
- 시퀀스 다이어그램을 활용한다면 로직 흐름을 정리 할 수 있어서 좋습니다.
- 다이어그램을 활용하다면 의사소통의 비용을 낮출수 있습니다.
- 해당 이슈 내용중 중요한 내용은 체크리스트로 관리합니다.
- 연관 이슈 이외에도 디자인, 혹은 관련 링크가 있다면 최대한 많이 링크를 걸어 줍니다.
추천 도구
실무에서 통상적으로 쓰이는 PR 템플릿이 있나요?
Q. 템플릿은 아니더라도 반드시 PR에는 이런 내용이 포함되어야 할 것 같다~라는 멘토님의 의견도 궁금합니다.
지은 멘토- 일반적으로 많이 쓰이는 템플릿은 있지만, 보통 회사에서 만들어서 사용합니다. 저희는 아래와 같은 내용을 작성합니다.
- 연관이슈, PR설명, 리뷰할 부분, 비고
- 어떤 이슈랑 연관되었는지. PR설명 (어떤 기능이 추가되었거나, 어떤 버그를 수정했는지 등)
- 커밋 리스트 중에서 한 커밋만 리뷰를 받고 싶다면 이 커밋만 리뷰해 달라는 내용도 적습니다.
- 그리고 작업하다가 고민되는 부분도 비고란에 적기도 합니다.
- 가끔 이슈에서 브랜치를 따 작업하다가 PR올릴때 이슈와 관련 없는 코드를 작성 할 때도 있습니다. 이럴경우는 따로 이슈를 만들어서 다른 브랜치에서 작업 후 따로 PR을 올려야 합니다.
- 최대한 PR은 관련된 이슈와 관련된 내용으로 올리고, 최대한 작은 단위로 올립니다.
- 너무 덩치가 커지면 리뷰해주는 사람도 보기가 힘들어집니다.
그 외 Github 관련하여 유의해야 할 것들이 있을까요?
Q. 실제 함께 협업 중인 두 분에게 각각 프론트, 백엔드 입장에서의 조언도 궁금합니다.
지은 멘토- 처음에 git 사용 규칙을 잘 정해서 사용하시면 될 것 같아요.
- 충돌나는 걸 무서워해 다른 사람의 코드 merge하는걸 기다렸다가 거기에서 브랜치 따서 작업하고 이러진 않았으면 좋겠습니다.
- 유의해야 할 것들보다는 git 기능들을 이것저것 많이 사용해보시는 걸 추천드립니다.
- 나중에 git 커밋정리, git 꼬였을때 당황하지 않고 잘 해결 할 수 있도록요!
규현 멘토- 항상 실행 가능해야 하는 브랜치와, 개발을 진행하는 브랜치를 잘 나누어서 관리하는 것이 좋을 것 같습니다.
- Force push 를 지양 하는 것이 좋을 것 같습니다.
- 합칠수 있는 커밋은 최대한 합치는 것이 좋을 것 같습니다.
- rebase 를 잘 활용 하면 좋을 것 같아요
Workflow 관련 (작성 예정)
참고 링크
협업 관련
어떻게 일을 분배해야 할까요?
Q. 개인 또는 소수의 인원과 협업을 진행했지만 이번처럼 많은 인원과의 협업은 처음입니다. 일을 분배할 때 보통 어떤 식으로 결정하게 되나요? 팀장이 적재적소에 배치해 주는지, 만약 팀장이 없다면 현명한 방법이 있을지도 궁금합니다.
지은 멘토- 저희는 먼저 디자인 보고 페이지 단위로 일을 우선순위 정합니다.
- 이때는 필요에 의하면 기획자까지 참여해서 어느 페이지를 선작업 해줬으면 좋겠다고 의견을 주면 거기에 맞춰서 작업을 합니다.
- 그 페이지 안에서도 목록을 가져오는 api를 먼저 요청하고, 그 다음에 조작하는(PUT, PATCH, DELETE) api를 요청합니다.
- 보통은 프론트가 백엔드한테 api 작업 순서를 요청드리는 것 같아요!
- 목록을 가져오는 api요청하기 전에 디자인을 보고 response모델을 같이 정의한 후에 각자(프론트,백엔드) 작업을 시작합니다.
- 만약 업무 정리가 안되어서 우왕좌와 하고 있을때는 팀장이 일정에 차질 없도록 업무를 정해서 우선순위 매겨줍니다 (이런것들의 팀장님 역할 아닐까요?ㅎㅎ)
규현 멘토- 해당 스프린트에 관련 일정들을 체크하고 우선순위를 먼저 정합니다.
- 모든 사람이 함께 참여하여 우선순위를 함께 정합니다.
- 선행이 필요한 작업이 있을 수도 있지만 없을 수도 있습니다.
- 스프린트에 포함 되지 않는 일은 해당 스프린트에서 일을 결정합니다.
- 기능 개발 이외에도 개발자가 해야 하는 일은 여러 가지 있다고 생각합니다.
- 인프라, 문서, 기획, 회의도 업무에 포함됩니다.
- 모든 인원이 같은 일을 할 필요는 없다고 생각합니다.
- 도메인 기준으로 나눠서 일을 해도 좋습니다.
- 이슈 유형으로 나눠도 좋습니다.
- 리팩토링이 필요할 경우 모두 다같이 리팩토링 할 필요는 없다고 생각합니다.
협업을 위해 뭐부터 시작해야 할까요? 😢
Q. 지금 우리는 아래와 같은 고민을 갖고 있어요. - FE : 백엔드가 어떻게 구성되어있는지 모르니 어떻게 요청드려야할 지 모르겠다. - BE : 프론트 파트에서 기능명세서를 주셔야 우리가 도와드릴 수 있을 것 같다. 그래서 시작조차 하지 못하고 있는데요... 뭐부터 시작해야 할지, 어떻게 풀어나가야 할지 고민입니다.
지은 멘토- 서로 어디서 대화를 주고받을건지, api문서는 어디서 확인할 건지, 각자 작업상황을 어떻게 확인할 건지 작업 순서를 어떻게 가져갈건지 이런걸 정해야 겠죠?
- 그 다음에 할일을 정해서 작업 할 티켓(이슈)를 먼저 만듭니다.
- 그리고 이슈가 생길때 저희는 인력이 별로 없기 때문에 슬랙 DM으로 바로 요청하거나, 바쁠떄는 github issue, pr comment를 적극적으로 사용하고 있습니다.
- 기능 명세서를 작성한다면 저는 프론트, 백엔드가 같이 작성하는 것이 맞다고 생각합니다.
- 백엔드에서 Rest api를 사용한다면 response 모델을 같이 어느정도 맞추고 작업을 시작하는 것도 좋을 것 같습니다.
규현 멘토- 첫 번째로 서비스, 기획에 대한 공통적인 이해를 먼저 하는 것이 좋을 것 같습니다.
- 협업 툴을 정합니다.
- 어떤 툴을 사용할 것인지, 해당 툴에서는 어떠한 것들을 담당할지 정합니다.
- 서비스에서 필요한 기능들을 나열합니다. 큰 항목부터 세부적으로 정리합니다.
- 스프린트를 정합니다.
- 해당 스프린트에서 작업 할 기능들을 정하고, 함께 회의를 진행합니다.
- 어떤 화면들이 필요한지, 어떤 기능들이 있는지 함께 진행합니다.
- API 스펙을 함께 정하여 프론트엔드 & 백엔드가 병렬로 개발 할 수 있도록합니다.
- 엔드포인트, Request, Response 가 정의 되어 있다면 어느 한쪽이 완료 되지 않더라도 개발을 할 수있습니다.
- 스프린트를 기반으로 할일 목록(이슈) 들을 작성합니다.
- 스프린트를 시작하면서 각각의 티켓 (할일) 을 상태(완료 여부)를 알려줍니다.
- 완료된 티켓(할일) 에 대해 연동하고, 함께 QA 를 진행합니다.
- QA 에서 버그, 개선점이 생긴다면 해당 티켓(할일) 에 관련된 사람을 멘션을 이용하여 comment 를 남깁니다. (비동기적으로 일 할 수 있어요)
- 핫픽스일 경우 최대한 핫픽스에 먼저 집중하여 해결 합니다.
스크럼은 모두가 함께하나요?
Q. 스크럼은 각 포지션끼리 하는지 혹은 모두가 함께하는지 궁금합니다! 그리고 어떤 이야기를 주로 나누는지도 궁금해요.
지은 멘토- 네 저희는 모두가 함께합니다. 일단 저희가 전원 인력이 적기 때문에 한팀으로 이루어집니다.
- 그리고 모두가 함께 해야 작업 진행상황이 공유가 되며, 막히는 부분이 어딘지 알 수 있고 같이 해결 하는데 더 좋다고 생각합니다.
- 단 모두가 솔직해야 합니다! 적극적이어야 하고요!
규현 멘토- 관련된 모든 인원이 참여하게 됩니다.
- 현재 진행 상태와 진행중 발생하는 문제점, 이슈들에 대해 공유합니다.
- 이슈해결에 있어 시간이 많이 소요될 경우 일정을 재산정하기도 하며, 같이 해당 자리에서 같이 해결하기도 합니다.
- 이슈에 관련해서는 숨기거나 부끄러워 할 필요가 없습니다.
- 혼자 해결하지 못했다는 생각보다 더 빨리 해결하기 위해 공유한다고 생각하면 좋습니다.
- 개발자들은 백로그에 있는 작업이 얼마나 남았는지 공유합니다.
- 번다운 차트를 통해 스프린트 동안 얼마나 작업이 남았는지 추적 할 수 있습니다.
하나의 이슈를 처리하는 흐름이 궁금합니다.
지은 멘토- 스프린트에 먼저 개발할 기능을 정합니다.
- 기획자, 디자이너가 화면을 구성합니다. (없다면 개발자 끼리 와이어프레임을 그립니다.)
- 개발자 끼리 작업 우선순위를 정합니다.
- 에픽단위의 이슈를 만듭니다. (상황에 따라 기능이슈일 수 있습니다)
- 백엔드, 프론트 각자 이슈를 만듭니다. 이슈에 설명을 자세하게 적습니다.
- 이슈에도 체크리스트를 따로 만들어서 작업이 어디까지 되고 있는지 상황 파악도 합니다.
- 해당 이슈의 작업을 할 브랜치를 땁니다.
- 이슈가 크다면 브랜치를 여러번 만들어서 PR을 여러번 날립니다.
- PR 리뷰가 마무리 된다면 머지를 합니다.
- QA후 버그 수정까지 마무리가 되어 운영에 배포가 된다면 이슈를 close 합니다.
찐 동료로서 규현님, 지은님이 협업 시 유의할 점을 조언해 주신다면 어떤 것이 있을까요?
지은 멘토- 다른 사람이 작성한 코드를 존중 해줍니다. (서로 성장하는데 도움을 주어야 합니다)
- 예를 들어, 프론트개발자가 컴포넌트를 공통으로 만들어서 작업을 해야하는데 다른 api가 수정이 필요하다. 수정요청 했을때 백엔드 개발자한테 충분한 이해를 시킨다. 그런데 충분한 이해가 안 되었다. 백엔드 개발자는 프론트 개발자가 작성한 코드를 내려받고 왜 response를 바꿔야 하는지 분석하려고 하지 않는다. 다른 충분한 방법으로도 제안 할 수 있다. (서로 존중해줘야 합니다)
- 이럴때 프론트 개발자는 백엔드 구조 및 상황 설명을 듣고 왜 바꿔줄 수 없는지 파악한다. 서로 이 건에 대해 어떻게 해결할지 논의한다. (이런게 건강한 논의라고 생각합니다.)
- 다른 예시로는 프론트가 백엔드 조금 안다고 또는 백엔드가 프론트 조금 안다고 훈수를 두면 안된다. 예를들어 프론트가 백엔드 쿼리 조금 안다고 백엔드개발자는 열심히 개발하고 있는데, 여기는 이 쿼리 쓰면 될텐데 그 쿼리 쓰신거에요?, 또는 백엔드가 프론트 조금 안다고 여기는 response를 이렇게 줄 테니 화면을 이런 방식으로 만드시면 될거에요. 이런 훈수를 두게 되면 상대방이 기분 나쁠 수 있다. (물론 안 그런 사람도 있을테지만) 모를때 물어보고 서로 같이 해결하는 방식이 좋을 것 같습니다.
- 이것은 백엔드-프론트 사이가 아니더라도 프론트-프론트, 백엔드-백엔드 에서도 조심해야 할 것 같아요
- 그리고, 남이 작성한 코드 또는 남이 해결하지 못하고 있는 코드를 재작성 하려고 할때 조심스레 물어본다. 이 코드 이부분보다는 이렇게 수정하는 것이 더 가독성에 좋을 것 같은데 같이 바꿔봐도 될까요? 제가 바꿔도 괜찮을까요? 등.
- 서로 의견을 낼때 혼동되는 용어가 오간다면 용어를 정해서 한 용어로만 대화합니다. 서로 협업하며 단어 사용으로 헷갈리는 부분을 최소화 해야 합니다.
규현 멘토- 이기려고 논쟁을 하기보다는 현 상황에 선택 가능한것들에 대해 논의 하는 것이 좋습니다.
- 기억에 의존된 논의 보다 자료 기반의 논의를 하는 것이 좋습니다.
- 자료가 없다면 다같이 회의 하여 불필요한 논쟁을 줄입니다.
- 간혹 내가 기억하기론.. 이라는 말을 할 때가 많습니다.
- 당연하다고 생각하는 부분은 없습니다.
- 이건 당연한것 아닌가? 라는 생각보다는 다를 수 있다라는 점을 생각해야 합니다.
- 변경점에 있어서 나에겐 단순하다고 생각 할 수 있지만 단순 하지 않을 수도 있습니다.
- 같이 일하고 싶은 개발자 이야기
- 프론트엔드 개발자가가 같이 일하고 싶은 백엔드 개발자 되기
- 서로 사용되는 용어가 달라 오해하기 쉬우니 공통된 용어로 통일하는 것이 좋습니다.
- 도메인 기반으로 소통하는 것이 좋습니다.
- 서로 다른 용어를 중간언어로 만들어서 관리하는 것도 좋습니다.
- 프로젝트가 끝나는 시점에 프로젝트도 남겠지만 사람도 남으니 잘 지내시면 좋겠습니다.
- 표현을 하더라도 상처가 되지 않게 신경써주세요.
- 단! 솔직하게 주장해야 하는 말을 하지 말라는 것이 아닙니다.
- 변화가 잦을 수 있다는 것을 기억 해주었으면 좋겠다.
- 규칙에 벗어난 일이라면 무조건 적으로 규칙을 따르기 보다 예외를 만들고 해당 예외를 규칙으로 관리 하면 더 유연하게 협업 할 수 있을 것이라 기대 합니다.
함께 읽으면 좋은 링크
