일정 관리 및 개발 진도 현황을 위해 사용하던 협업툴 Jira에서 최근에 알게 된 Github Projects로 전환했어요. 그러면서 그 전에 정했던 나름의 개발 프로세스를 다시 정하게 되었고, 이번 포스팅은 이에 대한 내용을 다뤄보려고 해요.
어디까지나 취준생끼리의 좌충우돌 사이드 프로젝트이므로 ,, 내용은 다소 현업과 멀 수 있음을 미리 알립니다.
협업툴을 옮긴 이유?
저희 도시락 팀원들은 의외로 Jira를 사용해본 적이 없더라구요! 그래서 Task 단위의 개발 흐름을 경험해보는 것이 좋을 것 같았고, 유명한 Jira를 한번 써보기로 결정했어요.
하지만 한 달이 지난 지금, Jira의 기능을 십분 활용하지 못하고 사실상 사문화가 되어버렸어요.
나만 쓰는 Jira ...
그 이유를 찾기 위해 팀원들과 의견을 나눠본 결과 다음과 같았어요.
부족한 UI 접근성
Jira는 UI와 기능 면에서 복잡도가 높다고 생각했어요. 팀원들이 제대로 활용하지 못했습니다. 기능을 찾기 어려운 UI 때문에 정보를 찾는데 시간을 많이 소모했어요. 다양한 기능들을 활용하기 위한 학습 비용도 컸습니다. 복잡한 UI와 기능을 제대로 활용하지 못하면 Jira의 가치를 끌어올리기 어려워요.
또한 저도 PM의 역할이 처음이다보니 곁눈질로 배운 흐름을 토대로 진행했어요. 그러면서 많은 자료를 찾고 흐름을 설계를 해보았지만 여전히 불편했어요.
FE와 BE를 나누기 위해서 존재하는 무의미한 티켓들 ....
결국 저를 포함한 팀원들은 Jira의 기능들을 제대로 익히지 못하고 활용하지 못하는 악순환이 벌어졌습니다. 이는 업무 효율성 저하와 생산성 하락으로 이어졌어요.
Github 연동의 불편함
또한 Jira와 GitHub 연동 시 Branch, Commit, Issue, PR에서 Ticket Number를 사용해야 했습니다. 단순히 Ticket Number만으로는 실제 작업 내역을 확인할 수 없고 Jira 페이지로 들어가야만 했어요. 정보 접근의 어려움도 생산성을 떨어뜨리는 요인이었습니다.
오로지 Jira 내에서만 해당 티켓 대한 내용을 확인할 수 있다보니까, Github Repo 내에서 쓰이는 Ticket Number는 오로지 '연동 목적'으로 사용되는 게 아쉬웠어요. 또한, 그 이유로만 쓰다 보니 내용이 불필요하게 길어지기도 했구요.
Github Projects
이에 따라 Github Projects로 협업 툴을 전환했습니다. Github는 익숙한 UI와 직관적인 정보 접근 방식이 큰 장점이었어요. 실제로 Github Projects에서 Issue 기능을 통해 ticket을 생성 및 관리가 가능했고, Repository 내에서 바로 Issue나 PR로의 링크도 가능했습니다.
더 예쁜 디자인 ... !
더 좋은 접근성 ... !
이를 통해 정보를 찾아가는 시간을 대폭 줄일 수 있었고, 나아가 업무 효율성도 크게 향상되었습니다. 또한 기존에 문제되던 무의미한 ticket number를 기입하지 않아도 되어 좋았어요.
하나의 팀, 도시락
무엇보다도 좋았던 건,, 바로 Backend와 Frontend가 비로소 하나의 팀, 도시락 팀으로 엮어졌다는 느낌이었어요. 사이드 프로젝트를 진행하며 제가 경험했던 팀들은 사실 프론트 팀 따로, 백엔드 팀 따로라는 느낌이 엄청 컸거든요. 물론 회사에서는 당연히 그렇게 되겠지만, 총원 4명인 사이드 프로젝트 팀 안에서도 그게 또 나뉘고 각자 할 일만 하는 게 아쉬웠어요. 그러다 보니 서로가 서로의 개발 진행을 몰라서 답답하기도 했구요.
하지만 이제 BE와 FE가 한 화면 안에서 어떤 개발을 진행하는지 한 눈에 알아볼 수 있었고, 본인이 진행하는 기능에 대해서 정보를 확인하며 더 적극적으로 기능에 대해 의견을 나누기 시작했어요.
재촉하기도 편하고(?)
이 같이 하고 있다는 느낌이 참 중요한 것 같았어요. 실제로 팀원 중 한 명은 전에는 혼자만의 템포로 개발을 하고 있었는데, 개발 현황을 알 수 있게 되니 '저 사람도 지금 이걸 하고 있네! 나도 얼른 해야겠다' 라는 생각이 들어서 더 으쌰으쌰 했다고 해요.
고려해보아야 할 점
다만 Github Projects 전환과 함께 몇 가지 새로운 규칙 정립이 필요함을 느꼈습니다. 구체적으로 Branch naming 규칙이나 Commit, PR에서 Issue/PR number를 어떻게 활용할지에 대한 고민이 필요했어요.
기존에는 Jira에서 발급받은 Ticket Number만으로 Branch Name을 적으면 됐었는데, 이젠 그럴 필요가 없어졌습니다. 또, 하나의 Commit에 두 개 이상의 Issue/PR number가 동시에 표시되면 정보 파악에 혼란이 올 수 있습니다. 따라서 이를 방지할 수 있는 가이드라인 마련이 필요했어요.
PR 제목에 Issue Number를 기입했더니 생긴 문제
물론 요 부분에 대해서는 컨벤션 조율을 통해 해결할 수 있는 부분이니 큰 문제는 아니긴 하지만요 ㅎ.ㅎ
Jira에서 Github Projects로 옮기고 나서 든 생각을 정리하고 보니, 왜 더 일찍 쓰지 못했을까..! 하는 아쉬움이 큰 것 같아요. 하지만 덕분에 여러 고민들을 하게 됐으니 오히려 좋아(?)
