[Sprint 4] 12‐18 회고 회의
Sprint 3의 보완점 중 하나가 이슈 관리였다. Sprint 4에서는 아래의 방법들을 통해 이슈에 효율적으로 대응했다.
-
버그 발견 시 즉시 공유하고, 확인하는 즉시 피드백을 공유했다.
예시 — 12월 17일 튜토리얼 녹화 과정에서 버그 발견, 수정
슬랙, 단톡을 이용해 버그를 공유하고 서로 빠르게 상황을 확인했다. 중간 회의 후 함께 게임을 플레이해보거나 같은 공간에서 각자 task를 수행하며 버그를 찾고 공유, 해결하기도 했다.
-
Github Issues를 사용해 이슈를 트래킹했다.
**예시 — https://github.com/2024FALL-SWPP/team-project-for-2024-fall-swpp-team-17/issues/96, https://github.com/2024FALL-SWPP/team-project-for-2024-fall-swpp-team-17/issues/86,** https://github.com/2024FALL-SWPP/team-project-for-2024-fall-swpp-team-17/issues/89
버그나 이상 현상을 발견하면 Github Issues에 해당 문제를 등록하고 관리했다. 이를 통해 여러 버그가 동시다발적으로 발생한 상황에서도 각 문제를 효율적으로 관리하고 해결할 수 있었다.
또한 이슈를 등록해둔 덕분에, 이후 비슷한 문제가 발생했을 때 이전의 이슈를 참고해 문제를 빠르게 해결할 수 있었다. 예를 들어 https://github.com/2024FALL-SWPP/team-project-for-2024-fall-swpp-team-17/issues/89 렉 걸림 문제의 경우, 해당 문제가 초기 발생했을 때 등록해두고 체크했기 때문에 WebGL 빌드 후 유사한 렉 걸림 문제가 생겼을 때 효율적으로 대응할 수 있었다.
-
Manual Testing을 지속했다.
예시 — 12월 18일 플레이 과정에서 BGM 관련 버그 발견, 수정
마지막까지 계속 매뉴얼 테스팅을 진행해 사소한 버그들을 찾아낼 수 있었다.
이전 Sprint에서 주된 구현을 모두 끝내놓았기 때문에 가용 시간이 적은 시험기간 동안 꼭 필요한 일만 잘 마무리할 수 있었다.
또한 각자의 시험 기간이 달라 날짜별로, 시기별로 서로의 가용 시간이 매우 상이했는데 이 점을 이용해 scene 편집 시간을 조정하고 conflict를 방지하기도 했다.
게임 데모 세션에서, 게임 클리어에 어려움을 겪는 사람들이 많았다.
게임 퍼블리시에 앞서 팀 내 의견뿐만 아니라 외부의 의견을 얻어 게임 난이도를 더 조정했으면 하는 아쉬움이 남는다.
매뉴얼 테스팅 위주로 진행하다보니 게임에 익숙해져 미리 확인하지 못했던 문제나 당연하게 잘 될 것이라고 생각해 놓친 문제들이 있었다. 예를 들어, 해결한 문제이기는 하지만 앞선 1-a와 1-c의 예시가 이에 해당된다. 외부 베타 테스터가 있었다면 매뉴얼 테스팅의 한계를 보완할 수 있었을 것이라는 아쉬움이 남는다.
또한 WebGL 빌드 후 로컬과 다른 환경으로 인해 발생한 문제들이 있었는데, 시간 제약으로 인해 현실적인 타협을 해야 하기도 했다. 예를 들어 플레이어의 투명도가 웹에서 다르게 보이는 현상, 카메라 조작감이 다른 현상 등이 있었으나 완전히 해결하지 못했다.
마지막에 코드 수정을 하면서 됐던 기능들이 안되고, 이를 뒤늦게 확인하는 경우들이 있었다. main branch에 merge하기 전에 체크해야 할 사항들을 체크리스트로 관리했으면 더 좋았을 것 같다. 예를 들어, 모든 scene에서 1, 2, 3 버튼으로 중력 전환 되는지 확인, pause 후 모든 버튼 눌러보기, 다음 stage로 잘 넘어가는지 확인 등을 체크리스트로 관리해서 수시로 확인했으면 좋았을 것 같다.
프로젝트가 모두 끝난 후에 ChatGPT를 활용하여 모든 스크립트에 주석을 달았고, 이를 Doxygen으로 API 문서로 만들었다. ChatGPT로 주석 달기 같은 경우에는 PR 전에 의무적으로 하고 검토하도록 미리 도입했으면 코드 리뷰하는데 시간이 절약됐을 것 같다는 아쉬움이 남는다.
로컬마다 플레이어 prefab이 다르게 보이는 https://github.com/2024FALL-SWPP/team-project-for-2024-fall-swpp-team-17/issues/86 를 해결하기 위해 페어 프로그래밍을 진행했다. 이는 Sprint 3에서 발생했지만 회의 상의 짧은 공유나 온라인 논의로는 해결하기 어려워 Sprint 4로 연기된 이슈였다. 특정 로컬에서는 플레이어 에셋이 아예 투명하게 보이는 문제로 인해 게임 플레이와 테스팅에 지대한 영향이 있어 가장 빠르게 해결해야 하는 task이기도 했다.
로컬 환경을 일대일로 비교해보고자 페어 프로그래밍을 진행했는데, 이 과정에서 로컬 간 블렌더 경로의 차이를 발견할 수 있었고 결국 에셋이 fbx가 아닌 blend 파일에 의존해 문제가 발생한 것이라는 원인을 파악할 수 있었다.
스프린트 초반에 페어 프로그래밍을 통해 이전 스프린트에서는 해결하지 못한 이슈를 빠르게 해결할 수 있었다는 데에 이번 페어 프로그래밍의 의의가 있다.
테스팅과 디버깅이 중요한 스프린트였던 만큼 빠른 소통이 요구되는 스프린트였다.
슬랙에 메세지를 보내둔 후, 단톡에 메세지를 다시 보내는 현실적인 방법을 통해 소통 속도를 높일 수 있었다. 또, 만나서 각자 작업을 하는 방식을 통해 문제가 생겼을 때 바로 상황을 공유하고 해결할 수 있었다.
최종 디버깅과 게임 난이도 조정, 맵 업데이트를 위해 게임 플레이 및 테스팅이 매우 중요해 해당 task의 우선순위가 크게 상승했다. 조명 배치와 sound effect task도 디버깅을 위해 필요한 task였기에 우선순위가 상승했다.
또한 게임 완성도를 위해 필수적인 opening, ending (game clear, game over) 씬, UI 수정, opening과 ending에 적용하기 위한 우주인 애니메이션 및 움직임, BGM task의 우선순위가 상승했다.
그 외의 task는 모두 완료됐기 때문에 우선순위에 변동이 없었다.
| 프로젝트 제안 시점, 변경 전 | (Sprint 3에서 변경된 후) | 변경 후 |
|---|---|---|
| 맵 디자인 basic | 맵 디자인 Tutorial | 테스팅 |
| 맵 디자인 advanced | 맵 디자인 Stage 1 | opening scene |
| 우주인 basic script | 맵 디자인 Stage 2 | game clear scene |
| 배경 모델링 | 맵 배치 Tutorial | game over scene |
| gravity script | 맵 배치 Stage 1 | UI menu |
| camera script basic | 맵 배치 Stage 2 | 조명 맵 배치 |
| 우주인 캐릭터 모델링 | 우주인 basic script | sound effect |
| game manager script | 배경 모델링 | bgm |
| 맵 배치 basic | gravity script | 우주인 캐릭터 애니메이션 |
| 맵 배치 advanced | camera script basic | 맵 디자인 Tutorial |
| 우주인 advanced script | camera script advanced | 맵 디자인 Stage 1 |
| 블랙홀 장애물 모델링 | 우주인 캐릭터 모델링 | 맵 디자인 Stage 2 |
| 송곳 장애물 모델링 | game manager script | 맵 배치 Tutorial |
| 무거운 물체 장애물 모델링 | 우주인 advanced script | 맵 배치 Stage 1 |
| 일반 물체 장애물 모델링 | 조명 모델링 | 맵 배치 Stage 2 |
| 우주인 캐릭터 애니메이션 | 테스팅 | 우주인 basic script |
| camera script advanced | 조명 맵 배치 | 배경 모델링 |
| effect | UI menu | gravity script |
| sound | sound effect | camera script basic |
| opening scene | bgm | camera script advanced |
| game clear scene | 웜홀 모델링 | 우주인 캐릭터 모델링 |
| game over scene | 가시 모델링 | game manager script |
| UI | 무거운 물체 장애물 모델링 | 우주인 advanced script |
| 운석 조각 모델링 | 일반 물체 장애물 모델링 | 조명 모델링 |
| 운석 조각 배치 | 우주인 캐릭터 애니메이션 | 웜홀 모델링 |
| 웜홀 script | 가시 모델링 | |
| 가시 script | 무거운 물체 장애물 모델링 | |
| 퍼즐 모델링 | 일반 물체 장애물 모델링 | |
| 퍼즐 script | 웜홀 script | |
| opening scene | 가시 script | |
| game clear scene | 퍼즐 모델링 | |
| game over scene | 퍼즐 script |
스프린트 진행 과정에서 추가된 Task들과 추가 이유는 아래와 같다.
추가된 task 외 스프린트 내에서 우선순위가 조정된 task는 없었다.
시험 기간과 겹쳐 바쁜 일정이었음에도 불구하고 완성도 있는 게임을 위해 모두가 열심히 참여하고, 마지막까지 여러 버그들을 수정한 스프린트였다.
전반적인 시간이 부족해 많은 업데이트를 할 수는 없었으나 스프린트 4의 전체 목표, 그리고 프로젝트 제안 시의 여러 기능 상의 목표는 달성할 수 있었기에 의미 있었다.
- 제헌 — 처음으로 다른 사람들과 함께 프로젝트를 진행해보았고 agile process 역시 처음이었다. pm역할을 맡았는데 프로젝트를 제대로 이끌지 못한 것 같아 조금 아쉬움이 남는다. 여러 가지를 신경쓰다보니 이도저도 아니게 된 것 같은 느낌이 조금 들었다. 그래도 스프린트들을 지나면서 조금씩 나아지는 것 같다?라는 생각이 들어 다행이었다. 다음에 또 이런 프로젝트를 진행한다면 더 잘할 수 있을 것 같다. 또, 시간을 온전히 다 프로젝트에 투자하지 못한 것이 아쉽다. 기회가 된다면 진득하게 게임만 만들어보는 시간도 가지고 싶다.
- 민정 — 여럿이서 함께 프로젝트를 진행하는 것이 처음이었는데, 혼자서 작업하는 것과 꽤 다른 경험이었다. 단순히 “되는 코드”를 만드는 게 아니라 다른 사람들이 쉽게 확장할 수 있는 코드를 만들어야 한다는 점에서 코드 퀄리티에 더 신경을 많이 썼던 것 같다. 팀 전체의 진행상황을 모니터링하고, 관리하는 것의 중요성도 알 수 있었다. 걱정이 많았던 프로젝트였는데, 시행착오를 겪으면서 개선해나가는 묘미가 있었다. 회의 주기 단축, github convention, task 관리 페이지, github issue 사용 등이 모두 처음부터 있었던 것이 아니라 필요성을 체감하고 도입했다는 점에서 소개원실 수업의 취지에 꽤 부합했던 것 같다. 팀원 모두가 맡은 일을 성실하게 수행하여서 프로젝트를 즐겁게 마무리할 수 있었던 것 같다.
- 승혁 — 혼자 프로젝트를 진행하면 코드에 대한 구조나 형식을 갖추지 않고 돌아가기만 하면 좋다는 생각으로 진행했었는데, 협업 프로젝트를 하며 이런 부분에 대한 것들으 다시 한번 생각해볼 수 있었다. 더불어 깃허브 사용법을 조금이나마 더 익힐 수 있었고, 협업 프로젝트 도중 일어나는 일들에 대해서 어떻게 대처를 해야 하는지 알 수 있었던 것 같다. 좋은 팀원들을 만나 한 학기 재미있게 프로젝트를 진행할 수 있었음에 감사한다.
- 휘현 — 깃허브를 적극적으로 사용해보는게 처음이었고, 이런 대형 프로젝트도 처음이었다. 유니티와 블렌더라는 생소한 툴에 익숙해져가면서 팀원들과 합을 맞춰 개발하는 과정이 의미있었던 것 같다. 개발이 쉽지만은 않았지만 모든 팀원들이 성실하게 참여했고 완성도 있는 결과물을 만들어서 성공적인 프로젝트였다고 생각한다.
- 수지 — 개인적으로는, 코딩 컨벤션과 구조를 맞추는 것부터 PR을 남기고 리뷰하는 것까지, 깃허브를 통한 팀 단위의 개발에 익숙해지는 경험이었다. 또 UI를 제외한 모든 에셋을 직접 제작하다보니 처음과 비교해 블렌더 모델링 실력이나 유니티의 자잘한 효과를 다루는 실력이 크게 늘었다. 팀 단위로는, 서로 주어진 업무를 데드라인에 맞춰 잘 처리해온 덕분에 처음 계획했던 게임을 잘 완성할 수 있었던 것 같다. 분명 개발에 있어 시행착오는 있었지만, 팀내 큰 갈등이나 소통 문제가 없었던 것에 의의를 두고 싶다.