1차 Mybatis 프로젝트에서 협업을 원활하게 하기 위해 프로젝트 방법론 및 관리, 코드 컨벤션,브랜치 전략, 코드 리뷰 등 팀 나름대로 여러 규칙들을 세워 진행하였다.

나름 만족하여 좋았다고 리뷰한 항목들도 있었지만, 대부분의 협업 규칙에 개선이 필요했다.

그중 가장 크게 개선이 필요하다고 느낀 부분은 프로젝트 관리 측면의 룰이었다.

이번 포스팅에서는 프로젝트 관리 측면에서 정한 룰들을 KPT 방식으로 회고해 보려고 한다.

전체적으로 프로젝트 관리에 크게 미흡했던 이유

우선, 전체적으로 프로젝트 관리에 크게 미흡했던 몇가지 이유를 살펴 보면 다음과 같다.

1. 팀원 모두가 처음 팀 프로젝트를 진행함
2. 모두가 Mybatis라는 SQL Mapper 기술 처음 접해 error가 잦고, 어느정도 익숙해지기 까지 오랜 시간이 걸림
3. 복잡한 도메인을 처음 접함
   -> 기획 및 설계에 기본 1주를 계획했지만, 2주 이상이 걸렸으며, 개발을 진행하면서도 도메인에 대한 이해를 거치며 거듭 수정함
4. 나 포함 팀원이 대학생 신분으로써 학교 생활과 병행하며 크게 시간을 할애하기 어려웠음
5. 데일리 스크럼 및 회의 시간이 지나치게 김

애자일과 스크럼(스프린트)

애자일과 스크럼에 대해서는 다음 포스팅에서 설명한다.
-> 애자일과 스크럼

우리 팀은 해당 프로젝트에 변화하는 요구사항에 유연하게 대처하고 재빠르게 대응하기 위해 애자일 프로젝트 방법론을 선택했다.
그 중에서도 가장 인기있는 애자일 방법론 중 하나인 스크럼 방식을 선택하여 3개의 스프린트 단위로 진행했다.

🦕 KEEP

1. 주기적인 리뷰와 빠른 피드백 적용
   스프린트의 주기적인 검토와 및 논의와 빠른 피드백은 프로젝트의 방향을 즉각 조정하고 적절하게 대응할 수 있는 기반을 마련해주었다.

🔍Problem

1. 요구사항 변화가 너무 잦음
   도메인에 대한 이해가 부족한 상태로 설계 후 개발을 하며 문제점들을 발견하고 즉각 요구사항도 변경하며 반영하다 보니 3주까지는 거의 매일 설계를 수정하였다.

2. 스프린트 경계가 흐려짐
   설계 및 도메인 규칙을 계속 수정하다 보니, 그만큼 개발 진도가 느려져 지키지 못하거나, 다음 스프린트로 미루게 된 상황이 종종 발생했다.

3. 촉박한 스프린트 설계와 실패 인한 부담감
   도메인과 Mybatis에 대한 이해가 제대로 갖춰져 있지 않은 상태에서 설계를 하다보니, 이정도는 금방 하지 않을까? 그렇게 어렵지는 않지 않을까? 하며 욕심을 꾹꾹 눌러 담아 스프린트 단위를 가졌다.
   그에 따라 점점 포기하거나 미루게 된 기능들이 생겨났고, 그로 인한 부담과 좌절감을 종종 겪었다.

💡Try

1. 도메인 전문성 강화
   1차 프로젝트를 거치며 도메인에 대한 이해와 분석을 어느정도 거쳤지만, 2차 프로젝트에서는 더 고도화된 기능들을 개발할 예정이므로 비슷한 과정을 계속 겪을 것으로 예상한다.
   도메인에 대한 이해는 개발 외 일상 시간에 여러 서비스 및 프로젝트를 참고하며 고민해 보는 시간을 가져야 겠다.
2. 기술 전문성
   Mybatis를 처음 사용하다 보니, 적응하는데도 오랜 시간이 걸렸고, 에러를 자주 맞닥뜨리게 되었다. 다음 프로젝트에서는 조금이어도 공부와 경험이 있는 JPA로 진행할 예정이어서 어느정도는 해결될 수 있는 부분인 것 같다.
3. 조금 더 유연하게, 조금 더 빠르게 결정하기
   애자일과 스크럼의 본질인, 빠르게 변화하는 요구사항에 대응하기 위해 고안된 프로젝트 방법론이라는 것을 간과한 것 같다.
   고민되는 각각의 과정에서 너무 긴 토론 및 수정 과정을 줄이고, 더 유연하고 빠르게 결정하고 넘어가도록 노력해야 할 것 같다.

데일리 스크럼

협업 과정에 있어 서로의 진행 상황을 공유하고 이슈 식별 및 해결을 위해 매일 오후 11시 Discord로 데일리 스크럼을 진행하고, Google Docs에 정리하였다.

🦕 KEEP

1. 팀원들의 개발 상황 및 이슈를 파악하는데 큰 도움이 됨
   매일 회의를 진행하며, 팀원들이 어떤 파트를 개발하고 있는지, 문제되는 이슈사항은 어떠한 것들이 있는지 매일 공유하여 빠르게 상황을 확인하고 대처할 수 있었다.

2. 팀워크 강화
   매일 회의를 진행하며, 모두 I의 성향을 가져 어색했던 분위기가 많이 풀어지고, 서로에 대해 더 잘 알 수 있는 시간을 갖게 되었다.

3. Discord 유지
   Meeting에 있어 Discord를 사용하였는데, 사용성이 좋고 각자의 화면을 공유 및 확인하며 회의를 진행하는 데 있어서 불편함이 없었다.

🔍 Problem

1. 데일리 스크럼 시간이 너무 길었다.
   초반 2주 정도 가량은 기본 2시간씩 진행했던 것 같다. 그 이후로는 점차 시간이 줄었지만, 초기에는 아무래도 협업도 처음하고, Mybatis도 처음 사용해 보며 각자 겪는 고충들을 함께 나누고 해결하다 보니 데일리스크림의 본질에서 새어 나오거나 흐려졌다.

2. Google Docs가 불편했다.
   Google Docs로 문서들을 정리하는 것은 생각보다 접근성이 떨어지고, 정리하고 다시 확인하는데 있어 사용성이 떨어졌다.

💡Try

1. 시간 관리, 용건만 간단히
   데일리 스크럼을 최대 15분으로 제한하고, 각자의 상황 및 이슈에 대해 브리핑하고 정리하는 시간으로 최대한 간단히 가져가도록 한다.

2. 데일리 스크럼과 회의를 확실히 분간하기
   데일리 스크럼의 주요 목적은 진행 상황의 간략한 업데이트와 중대한 이슈 및 장애물의 식별이다. 반면, 별도의 회의는 보다 심층적인 논의를 필요로 하는 복잡한 문제들을 해결하기 위해 사용된다.
   각 세션의 목적을 명확히 하여, 데일리 스크럼이 너무 길어지는 것을 방지하고, 필요에 따라 별도의 회의를 계획하도록 한다.

3. 문서는 Notion 및 Github Wiki로
   다음 프로젝트에서는 Google Docs는 더이상 사용하지 않기로 하였다.
   접근성을 위해 사적인 성향을 띄는 문서는 Notion으로, 그 외 문서는 Github Wiki와 Lab 같은 기능을 사용하기로 하였다.

Jira

팀에서는 프로젝트 관리 툴로 Jira를 선택하고 적용해보았다.
소프트웨어 개발의 스크럼 템플릿으로 시작해 도메인 별로 Epic을 생성하고, 하위에 Story, Story Point, Story 하위 이슈로 각 작업단위를 나누고 관리했다.

🦕 KEEP

1. 프로젝트의 상황을 한눈에 보고 관리할 수 있다.
개발 현업에서 많이 쓰이는 만큼, 프로젝트를 견고하게 관리 하기 위한 좋은 도구임에는 틀림 없다. 각 이슈 및 작업 관리와, 문서, 타임라인, 보드 등 팀프로젝트의 협업에 있어 필요한 대부분의 기능을 지원하고 있다.

🔍 Problem

1. 활용 방법이 무궁무진하다. 그만큼 커스터마이징 해야한다.
Jira는 활용 방법이 정말 무궁 무진하고, 잘만 사용하면 확실히 좋은 도구이다.
하지만 자유도가 굉장히 높고 꽤나 불친절하다는 느낌이 많이 들었다. 그만큼 공부와 팀에 맞게 커스터마이징이 필요했다.

2. 어렵다.. 어렵다.. 어렵다! (접근성이 떨어진다.)
Jira가 좋은 도구임에는 틀림 없지만, 프로젝트에 도움이 되어 사용한다는 느낌 보단, 끌려다니는 느낌이 강했다.
정말 프로젝트 관리의 효율성을 위해서는 공부가 더 많이 필요해 보였다.
또한 초기 설정에도 많은 시간을 쏟아야 했다.

3. 스프린트 경계가 흐려지며 자연스럽게 멀어졌다.
   이후에도 Jira에 할애하는 비용이 꽤 크고, 프로젝트에 차질이 생겨 스프린트 경계도 흐려지며 팀원 모두 점점 손이 잘 가지 않게 되었다.

💡Try

1. Github Project
Jira를 더 잘 사용해보고 싶지만, 각 팀원들이 여러 대학 생활 및 기타 생활에 있어 Jira를 좀 더 심도있게 공부하기까지는 여유가 많지 않았다.
따라서 현재 상황에서 Jira 공부는 배보다 배꼽이 더 큰 느낌이 들어, Github에서 제공하는 조금 더 친화적이고 접근성이 좋은 Github Projects를 사용해보려고 한다.

그 외에도..

Discord와 Github hook 연동

그동안 PR을 올리거나 Merge를 하면 모두가 카톡에 알리거나 확인을 해야했다.
최근 학교에서 IT 서비스 개발 동아리를 운영하며, Discord에 Github 실습을 위해 hook을 연동하여 사용중이었다.
해당 레포지토리 및 Organization의 각 상황에 대한 알림을 즉각적으로 확인할 수 있어 정말 편리하고 좋은 기능이라는 생각이 들어 팀원들에게 공유하고 적용해볼 예정이다.

돌아보며

처음 진행하는 팀 프로젝트에서 여러가지 규칙과 툴을 도입하다 보니 우여곡절이 많았다.
잘 지켜지지는 않았지만 애자일의 스크럼 방식도 경험하고, 스프린트 설계도 열심히 해보고, Jira도 사용해보며 많은 경험과 깨달음을 얻을 수 있었다.
그 과정에서 팀 성향에 맞게 각 규칙과 룰을 서서히 만들어나가는 것이 협업에 있어 무엇보다 중요하다는 것을 깨달았고, 우리 팀도 서서히 하나씩 찾아나가는 과정에 있는 것 같아 기쁘고 더 나아갈 일만 남았다!
앞으로도 화이팅😊😊!!