[Project: TEXTRPG] C++로 구현하는 TEXT RPG 프로젝트 9일차.

[26.01.06] 9일차. 개발 마감 D-Day. 릴리즈  발표 준비

오늘은 개발 마감일을 맞아 새로운 기능을 무리하게 구현하기보다는, 지금까지 작업한 결과물을 검증하고 정리하는 안정화 및 문서화에 집중했다.

어제 개인 파트인 Item/Inventory 구현을 완료해서 팀 전체의 프로세스를 점검하는 시간을 가졌다.

 

먼저, 테스트 케이스를 작성하고 QA를 진행했다.

프로젝트 초기 설계 단계에서 작성했어야 할 테스트 케이스가 누락되었음을 알게 되었다.

구성 항목을 "구현 여부, 테스트 여부, 테스트 번호, 책임, 작업, 필요 데이터, 조건"으로 나눠서 테이블로 만든 후 내용을 채워 팀원에게 공유했다.

이를 통해 각 팀원이 구현한 기능과 테스트 통과 여부를 직관적으로 파악 가능해져, 진행 상황 공유 및 후속 작업 속도가 향상됐다.

 

테스트 케이스 목록

 

다음으로, 발표할 때 단순 기능 나열이 아닌 기술적 깊이를 어필하기 위해 팀원들에게 각자 구현한 파트에 대한 기술적 포인트를 요청했다.

- 왜 이 기술/구조를 사용했는지?

- 대안은 없었는지?

- 현재 구현의 장점은 무엇인지?

 

발표자료를 만들면서 내가 작성할 수도 있었지만 팀원 스스로 본인의 코드를 되돌아보고 정리할 수 있는 시간을 가지면서 발전해나가는 것이 더 좋다고 생각했다.

 

 

그리고 팀원들이 작업한 MVP 및 추가 기능 변동 사항을 클래스 다이어그램에 반영해서 최신화하는 작업을 했다.

 

 

MVP 구현된 것을 release-v1.0 브랜치로 두어 관리하고

추가기능 구현된 것을 release-v2.0 브랜치로 두어 관리했다.

릴리즈에 포함된 기능이 있는 feature 브랜치는 모두 닫았다.

 

 

 

오늘의 회고 (Retrospective)

• Keep (잘한 점):
  • 마감일에 무리하게 코딩하지 않고, 코드 프리즈(Code Freeze) 후 테스트와 문서화에 집중한 판단.
  • 기술적 의사결정 과정을 발표 자료에 녹여내기 위해 팀원들에게 질문을 던진 점.
• Problem (아쉬운 점):
  • 테스트 케이스 작성이 너무 늦었다. 본래 기획/설계 단계에서 플로우 차트와 함께 준비했어야 했다.
• Try (시도할 점):
  • 다음 프로젝트에서는 설계 단계에서 '테스트 시나리오'를 먼저 고려하는 TDD(Test Driven Development)적 사고를 적용해 볼 것.