--- tags: reference --- # 개발자가 협업을 위해 하는 과제 조금 코딩을 할 수 있게 된 주니어 개발자가 하는 최고의 걱정은 "작업을 어떻게 하는가"이다. 소위 협업이 어떻게 진행되는가 이다. 이런 부분은 경험과 직결된다. 해본적이 없으니까 두려운 것이다. 협업 스타일에 정답은 없다. 어느 조직을 가더라도 그 방법은 다르고 효율적일수도 비효율적일 수 도 있다. 특히 스타트업의 경우 방법론적 시스템이 잘 되어 있지않아 많은 어려움을 겪는다. 하지만 어느곳이라도 명확하게 정해야 하는 것들이 있다. 정의되지 않으면 개발과정에 큰 문제가 있을 것들. 오늘은 그 것들을 이야기해보고 쓸만한 예시를 하나 들어보려 한다. ### 개발자의 소통 개발의 근본적인 방향성은 issue와 solve이다. 어떤 목적성에 의해 issue가 발생하고 그 issue를 해결하는 것이 개발의 기본 틀이다. issue라는 명칭이 github의 issue란을 생각하게 하는데, issue는 개발하는 프로그램의 오류나 기능에만 국한되는게 아니라 그 프로그램을 만들기 위해 해야하는 지식을 공부하는 과정, 서비스 기획 모든것을 포함한다. 이러한 과정에서 수많은 로그(log)가 쌓이게 되고 이 로그들을 정리하고 기록할 창고(Archive)가 필요하게 된다. 이러한 창고는 모두가 접근하고 잘 사용할 수 있도록 정리되어야 한다. 위 이야기를 종합하면 적어도 개발자는 "issue - develop"을 관리할 툴 / 로그를 정리할 창고(Archive) 툴이 요구된다. 프로젝트를 시작할 때 정해야 하는 최소한의 것이 위 2가지이다. 둘 중 하나라도 정의되지 않는다면 프로젝트가 진행되는 내내 소통의 어려움을 겪을 수 밖에 없다. ### 어떤 툴을 어떤 방식으로? 사실 모든 기능은 github에서도 제공한다. github의 "project"와 "issue"는 "issue-develop"을 관리하기 적합하며, "wiki"나 "commit"으로 로그를 저장할 수 있다. 실제로 필자는 "commit"만으로 모든 소통과 issue관리를 하는 팀도 본적이 있다(물론 이 팀의 경우에는 commit을 날리는 규칙이 굉장히 명확하고 세세하게 명세되어 있었다) Issue관리에 많이 사용되는 툴은 통상 **jira** 와 **trello**이다. 뭐 툴이야 상황에 적합한 아무거나 사용해도 된다. 여러분이 궁금할 것은 이런게 아니라, "그래서 어떤식으로 활용하는데?"라 생각한다. 필자도 그랬다. 더 정확히 말하면 "그래서 issue 관리를 어떻게 하는지 알려줘"를 원한다고 생각한다. 사실 거기에 정답은 없다. 다만 "이런식으로 했다"라는것을 듣고 나면 앞으로 본인 프로젝트에 어떻게 적용할지 생각해보기 좋을것이라 생각한다. ### 일주일간의 프로젝트 developing 흥미롭고 규격적인 방식으로 진행했던 프로젝트가 있다. 그 방식을 한번 설명해보고자 한다. 1. 월요일, 회의를 통해 Issue를 발급한다. 2. 발급된 이슈를 목요일까지 수행, 작업한다. 3. 금요일 발급된 이슈가 어떻게 진행되었는가를 회의로 평가하고 해당 이슈를 완료/재 발급 한다. 위 방식으로 진행하였을 때 첫번째로 발급됬던 이슈는 "이슈 관리 툴을 정하자"였다. 그 다음 과정은 "요구분석 회의"였고 그 다음은 "기능 명세", "API문서 작성"등이 이어졌다. 모든 공유자료는 Notion에 작성되었고 이슈 관리 툴은 trello의 보드로 진행되었다. 굉장히 간단하지만 강력하였다. 정확한 일주일 단위의 micro작업이 진행되며 즐겁게 진행했다고 생각한다. ### 협업툴을 협업툴 답게 사용하는 법에 대해 1. 팀 룰 2. 상대 팀과의 교류를 위한 부분 - 공통적으로 해야하는 것에 대한것 - 속도 체크 방법 - 자기 리소스(? -> 내가 얼마나 할 수 있나) 체크 - 시그널을 못 맞춘다 = 나간다(나는 안될거 같은데?) 3. 스프린트로 짤것 - 전문가:2주 / 통상: 3일 => 몇시간인지 파악