이전 포스팅
이전 포스팅에 이어서.. 6주간 진행된 그룹 프로젝트 회고도 작성한다.
*
멤버십 과정의 일부는 외부 유출이 금지되어 있으므로 그 점을 유의해서 작성할 예정입니다.
혹여나 문제가 있을 시 수정 혹은 삭제하도록 하겠습니다.
6주간의 그룹 프로젝트
✔️ 그룹 프로젝트 과정
그룹 프로젝트는 총 6주로, 요약하면 다음과 같다.
- 1주차 : 주제 선정 및 요구사항 분석
- 2 ~ 5주차 : 개발
- 6주차 : 코드 리팩토링 및 버그 해결
공식은 위와 같지만, 실제로는 4 ~ 5주차 중간까지는 거의 마무리가 되어야 한다.
그 이후론 문서화 작업이랑 테스트 코드 작성, 리팩토링, 버그 해결로 정신이 없기 때문이다.
이번 그룹 프로젝트에서 개발한 앱은 밑 Github 링크에서 볼 수 있다.
🧑🤝🧑그룹 프로젝트를 통해...
짧게 요약하면, 협업과 소통이 얼마나 중요한지,
캠프 이후 진행할 개인 프로젝트를 어떻게 진행할 지
시행착오를 통해 많이 알게 되었다.
🎮 프로젝트 주제 설정
우리 조는 주제 잡을 때 1주일이라는 시간을 거의 주제 토의하느라 다 써버렸다.
출시를 위한 평범한 앱보다는 기술적 도전이 많이 보이는 앱을 하고 싶어서였다.
(처음에는 이걸 어떻게 구현하지? 싶던 게 몇 있다.)
실제로 아이디어가 좋다는 이야기를 많이 들었고, 기술적 도전이 몇 있었다.
그저 아쉬운 점이 있다면 프로젝트 주제 선정 당시 서버 개발자의 부재를 고려하지 않은 거다.
대부분 서버가 있다면 걱정하지 않아도 되는 기능 때문에 시간을 많이 쏟았다.
서버 개발에 힘을 쏟기는 어려워서 대부분 클라이언트에서 작업을 처리하는 방식으로 구현했다. 이 또한 하나의 기술적 도전이라고 보면 도전이겠지만, 로직에서 비용이 많이 드는 것이 매우 아쉬웠다.
혹 다른 그룹에서는 외부 API에 너무 의존적인 앱을 만들어서 곤란한 경우도 있었다.
콜백 지옥이거나, 혹은 응답 결과가 이상하거나 하는 문제가 있었다고 했다.
그룹 프로젝트가 끝나면 마스터님 조언대로 개인 프로젝트를 하나 할 생각인데,
위에서 언급한 두 가지를 꼭! 명심한 상태에서 주제를 선정하려고 한다.
🧾 문서 정리
프로젝트 문서는 대부분 Github Wiki에 정리했고(학습 정리는 종종 노션에다가 했다),
칸반 보드는 Github Project를 사용했다.
대부분 Github Repository 안에서 모두 확인이 가능하다.
이를 통한 장점은 여러 곳에 분산되어있지 않아서 관리가 용이하는 거다.
Github Project가 좋았던 게 이슈를 만들고 난 후에 commit 메시지에 이슈 번호를 달면
그 밑에 commit 메시지가 막 쌓이게 된다.
예를 들어 이슈 번호가 #123인 이슈가 있다고 하면,
commit 메시지 footer로 Issues #123이라고 달아서 origin 혹은 upsteam에 올리면 자동으로 그 이슈 밑에 쌓였다.
마일스톤 기능을 추가해서 주 단위로 프로젝트를 관리할 수도 있다.
Backlog는 Draft를, Task는 이슈를 추가했고,
이슈 템플릿과 PR 템플릿은 따로 제작해서 양식에 맞게 작성하도록 했다.
PR 템플릿은 보고 코드 리뷰하는 사람이 무엇을 개발했는지 명확하게 알 수 있도록 하고자 했다.
이슈 템플릿은 데일리 스크럼 때 이슈를 보고 설명할 수 있도록 하는 역할을 했다.
이슈 템플릿은 중간에 제안하게 된 거였는데, 확실히 하고 나서 팀원이 뭘 하고 있는지가 명확하고, 메모 역할을 해서 나중에 설계 내역을 찾아보기가 좋았다. 개발자는 문서로 소통한다는 마스터님의 말씀을 많이 느꼈다.
약간의 아쉬움이 있다면 아무래도 Task-Task 간 연결이 Jira에 비해 자유롭지 않은 점이다.
우리는 사실 처음에는 Jira로 하려 했으나 나중에 Github Project를 선정한 케이스다.
Jira는 스토리, 에픽 등이 기본으로 제공되고, Android Studio랑 연동도 잘 되어있고, 링크도 잘 걸린다.
이슈와 이슈끼리 연결도 가능하고, 이슈 밑에 하위 이슈 이런 식으로 설정도 가능했다.
다만 외부 공유가 어려워서 안하게 된 케이스.
Github Wiki 도 굳이 비교하면 전부 MarkDown 으로 작성해야 하는 게 아쉽다.
학습 정리하면서 느낀 거지만 노션이 가독성이 훨씬 좋고 작성도 간편하다.
MarkDown은 사진 하나 넣을 때마다 인내심 테스트 하는 줄 알았다.
🌏 팀 그라운드 룰 설정
각자 성격도, 코딩 스타일도, 코딩 활동 시간(?)조차 다른데 짧은 기간 맞춰 나가려니 충돌이 일어날 수 밖에 없다.
의견 충돌에 대비하기 위해 우리만의 팀 그라운드 룰을 세우고, Git 컨벤션, 코딩 컨벤션을 정했다.
이는 물론 개발이 아니라서 중요하지 않아보이거나, 그렇다고 의견 충돌이 일어나지 않는 건 아니지 않냐고 볼 수도 있다. 하지만 이런 룰 같은 경우 의견 충돌 발생 예방보다, 대처에 가깝다.
- 의견이 좁혀지지 않을 때 다수결로 정한다거나, 혹은 멘토님께 자문을 구한다.
- 리더는 매주 돌아가면서 진행한다.
- 모르는 게 있다면 꼭 30분 ~ 1시간 가량 혼자서 고민해본 뒤 안되면 알릴 것.
- develop에 marge할 PR은 1명 이상 appove가 이루어져야 한다.
등등 상세하게 정할 수록 협업이 원활하게 진행되고, 의견 충돌 시 시간이 단축된다.
게다가 처음 정한 게 무조건 옳은 건 아니기 때문에
팀 회고 때마다 새롭게 건의하여, 동의 하에 수정을 하게 되는 경우도 많았다.
그 외
1. 이름은 처음에 설정할 수 있으면 최대한 하는 게 좋다..
특히 데이터 클래스.
코딩 컨벤션 때 모듈별 클래스 이름을 정하지 않았어서 많이 헷갈렸다.
2. 개발 중간에는 리팩토링이 정말 어렵다.
개발을 하면서 리팩토링을 너무 너무 하고 싶었다.
코딩 컨벤션을 정했다고 해도 일관성 있는 코드가 되는 건 어렵고, 중복 코드가 여럿 발생한다.
그러나 중간에 하면 브랜치가 자칫 꼬이게 된다.
바로 보이는 부분은 코드 리뷰할 때 고쳐달라고 요청하고, 그 외에 것은 마지막 주차로 미루고 하는 게 심리 상 편안하다.
3. 돌아가면서 역할 맡기의 장단점
우리는 처음에 리더 역할을 주별로 돌아가면서 하기로 했고, 서기, 팀원 상황 물어보기, 발표 등을 모두 몰아주었다.
이렇게 했을 때 장점은 "한 주만 고생하면 된다"는 마인드가 생겨서 할 만했고, 공평하고, 부담감이 조금 덜었다.
단점은 문서화에 일관성이 없다는 것.
그 주에 기록하는 사람이 매번 달랐고, 문서화 방식이 너무 달라서 나중에 보니까 일관성이 너무 없었다.
그리고 다수의 의견 하에 리더가 된 사람의 말을 더 잘 듣게 되고, 질서가 생긴다는 느낌을 받았다.
후반부에 갈수록 단점이 너무 적나라하게 느껴져서 4주차 회고 때 건의하여 받아들여졌고,
남은 2주차는 역할을 나누어서 진행했다.
수료식
그리고 마지막 6주차, 짧으면 짧고 길다면 길었던 14주간의 부스트캠프 여정이 끝났다.
수료식은 챌린지처럼 ZEP에서 모였다가, Zoom에서 진행했다.
수료 기념으로 롤링 페이퍼를 작성하는 시간도 있었다.
그룹 프로젝트 멤버들, 같이 개발했던 안드로이드 캠퍼들, MIT 슬랙 채널에서 만났던 방장님 등등..
롤링 페이퍼를 적으면서 추억을 막 적어보는데 괜히 아련해졌다....ㅠㅠㅠㅠ
이젠 끝이라는 게 막 실감이 난달까...
적으면서 미안했고, 고마웠던 일들이 새록새록 생각났다.
Zoom 수료식 때도 마지막 이야기 들으면서 감동하고 울컥하고...
14주간 내게 과분한 사람들을 많이 만난 것 같다.
부스트캠프 신청했을 때가 엊그제 같은데, 결국 끝났다.
안드로이드 개발자로 부스트캠프에서 커리어를 시작하게 된 것은 너무 큰 행운이다.
같이 그룹 프로젝트 했던 멤버들, 안드로이드 캠퍼들, 마스터님,
그리고 뒤에서 이끌어주신 운영진 분들에게 너무 감사하다는 말씀을 꼭 전하고 싶다!
'Story' 카테고리의 다른 글
티스토리 사용 후기.. 그리고 블로그 다작으로 (1) | 2023.10.11 |
---|---|
[후기] 2022년 부스트캠프 웹·모바일 7기 멤버십 후기 - 학습 스프린트 (4) | 2022.12.22 |
[후기] 2022 부스트 컨퍼런스 후기 (0) | 2022.10.23 |
[후기] 2022년 부스트캠프 웹·모바일 7기 챌린지 후기(+멤버십 합격) (0) | 2022.08.25 |
[후기] 2022년 부스트캠프 웹·모바일 7기 지원 및 합격 후기 (3) | 2022.07.13 |