프로젝트 진행 과정
1. 아이디어 선정 및 기획 과정
1차 프로젝트 선정 과정
프로젝트 초기 단계에서 저희는 피그마 잼(Figma Jam)을 활용하여 브레인스토밍을 통한 아이디어 추출 및 선정 과정을 진행했습니다.
진행 방식은 메모지에 팀원들 각자의 아이디어를 작성한뒤 투표를 통해 진행할 프로젝트를 선정하는 과정으로 진행되었습니다.
이후 저희 팀은 업무 분담을 명확하게 하지 않고도 서로 자기가 하고 싶은 업무를 선택하여 효율적으로 업무를 진행했습니다.
그 결과 단 2시간 만에 위의 이미지와 같이 그라운드 룰 작성, 시장 조사, 기획서 개요 작성, 요구사항 명세서 및 UML 개요 작성, 주요 기능 정리 등을 마치게 되었는데요.
문제는 모든 정리가 끝이난 후에 발생했습니다.
사전 조사와 주요 기능을 정리하다보니 저희가 구현하고자 하는 똑같은 기능을 이미 구현해서 제공하는 업체를 발견하게 되었고 해당 업체가 제공하는 기능에서 특별한 차이점이 될만한 기능을 짧은 시간 내에 생각하지 못할거라고 판단한 저희는 프로젝트를 엎고 새로운 프로젝트를 진행하는 것으로 결정을 내렸습니다.
2차 프로젝트 선정 과정
아이디어가 선정된 후, 개별적으로 작업을 진행하여 효율적으로 업무를 진행하긴 했으나 소통의 부재로 인해 의견 공유가 부족했고 이로인해 서로가 바라보는 프로젝트에 대한 방향성이 모두 각자 달랐으며 이를 하나로 맞춰야 되는 과정이 필요했습니다.
그래서 저희팀은 새로운 아이디어를 도출하기전에 프로젝트 방향성과 관련된 목록을 설정하였고 투표를 통해 이번 프로젝트의 목표를 바로잡는 과정을 진행했습니다. 이를 통해 저희는 프로젝트의 주제인 DB 프로젝트의 성격에 적합하면서 구현 가능한 정도의 프로젝트를 진행하는 것으로 전체적인 방향성을 맞추게 되었습니다.
따라서 2차 브레인스토밍 과정에선 단순히 아이디어에 대한 내용을 서술하는 것이 아닌 프로젝트 적합성과 프로젝트 범위를 포함한 내용을 포함하여 작성하기로 합의를 보았고 투표로 선정한 프로젝트 방향성에 적합한 프로젝트 아이디어를 선정하는 과정을 거치게 되었습니다.
그렇게 선정된 배달앱 선택 최적화 시스템 아이디어를 다시 처음부터 주요 기능을 정리하고 시장조사를 하게 되었는데 문제는 배달앱 선택 최적화를 위해선 배달 플랫폼업의 데이터를 추출해와야 되는데 이 과정에서 법적 문제(데이터 크롤링 이슈)가 발생할 수 있다는 것이 걸림돌이 되어 결국 두번째 아이디어도 포기하기로 결정하게 되었습니다.
프로젝트 최종 선택
세번째 아이디어를 생각해내야 되는 그 순간에 우리의 첫번째 아이디어였던 모바일 영수증 관리 시스템에서 다른 업체에는 없는 차별화된 기능이 없는지 다시 생각해보는 시간을 갖게 되었고 기존의 영수증 기반 리뷰 시스템에서 사용자 입장에서 번거로움을 유발하는 프로세스(종이 영수증 사진 촬영 후 스캔)를 모바일 영수증 관리 시스템에 리뷰 기능을 추가하면 없앨 수 있으므로 단순히 모바일 영수증을 관리하는것 뿐만 아니라 리뷰 기능을 추가적으로 제공하면 이전에 없던 차별화된 통합 모바일 영수증 관리 시스템을 제공할 수 있다는 판단이 서 기존 아이디어인 모바일 영수증 관리 시스템을 이어 나가기로 결정하였습니다.
2. 요구사항 정의서 작성 과정
아이디어 선정 과정에서 소통의 부재로 인한 문제를 경험한 저희는 요구사항 정의서를 작성하는 과정에선 한공간에 함께 모여 요구사항을 정리하는 과정을 거치게 되었습니다.
처음에는 비효율적인 과정이라고 생각했지만 팀원 모두가 합의한 요구사항을 정리했기 때문에 서로 생각하는 방향성을 한번에 맞출 수 있었고 한번 정리한 초안을 토대로 수정 및 추가 사항을 논의만 하면 되었기 때문에 협업을 더 수월하게 진행할 수 있던 중요한 과정이었던 것 같습니다.
3. 매일 아침 정기 회의(스프린트 미팅) 및 회의록 작성
저희 팀은 매일 오전 8시 40분부터 20분간 짧은 정기 회의를 진행하여 진행 상황을 점검하였습니다. 이번 프로젝트에서 가장 좋았고 유의미했던 과정 중 하나로, 프로젝트 진행 방향을 명확히 하고 모든 팀원이 같은 목표를 공유하고 각 팀원이 진행할 작업과 마감 일정을 명확히 설정하여 프로젝트를 체계화하여 관리할 수 있도록 했던 과정이었습니다.
특히, 회의록을 작성하여 이전 회의에서 논의된 내용과 안건을 기록하고 체크해야 되는 사항들을 체계적으로 관리했던 과정은 협업에 있어서 매우 중요한 과정일 뿐만 아니라 법적 근거 및 책임 부여를 위해 회의 내용을 기록화할 필요가 있는 상황에서 프로젝트와 관련된 모든 내용을 기록화하고 문서화하는 것은 습관화되어야 하며 필요한 과정이라는 생각이 들게 되었습니다.
4. ERD 설계 및 수정 과정
저희 팀은 논리 및 물리 모델링을 업무 분담하여 진행하지 않고 연습을 위해 모두가 설계한 후 한 개의 ERD를 선택하여 해당 ERD를 기준으로 엔터티와 속성을 수정하거나 추가하는 등의 과정을 통해 전체적인 구조를 결정하는 것으로 진행하였습니다.
모든 팀원이 ERD 설계에 참여하면서 프로젝트 구조를 깊이 이해할 수 있는 시간이었고 공동 설계를 통해 다양한 관점을 반영할 수 있어 더욱 풍성한 ERD를 설계할 수 있었던 것 같습니다.
처음엔 개별적인 경험치에 따라 설계해온 ERD가 차이가 많이 날 것이라고 예상했던 반면에 팀원 모두가 서로 비슷한 ERD를 설계해 와서 우선 기본이 될 베이스 ERD를 투표를 통해 선정후 BASE ERD를 스크린샷한 이미지로 이전에 작성한 요구사항 정의서와 비교하여 추가적으로 필요한 엔터티와 속성에 대해 서로 커멘트를 남기고 피드백 과정을 통해 전체적인 초안 ERD를 설계하였습니다.
이후 초기 설계된 ERD를 바탕으로 요구사항 변경에 따라 지속적으로 수정하는 과정을 거치게 되었는데 변경 사항을 구두로 논의했기 때문에 일부 팀원만 이해하고 나머지는 이해하지 못하고 그냥 넘어가거나 구두 논의가 많아 변경 이력이 명확히 기록되지 않아 안건들일 증발하는 등의 문제가 생겨 의견 충돌 문제가 자주 발생하였고 하나로 의견을 합치는 과정이 매끄럽게 진행되지 않았습니다.
해당 문제에 대한 해결책은 프로젝트가 막이내릴때까지 찾지 못하여 프로젝트가 진행되면서 계속 불편함으로 남았던 재목이고 이후 프로젝트 진행 시 프로젝트 진행 시 노션 안건함에 팀원별 안건을 기록하여 모든 팀원이 특정 주제에 대한 변경사항 및 안건이 생길 시 해당 안건을 모든 팀원이 볼 수 있도록 공유하고 기록하며 해당 안건에 대한 커멘트를 달아서 변경 이력도 관리할 수 있으며 모든 팀원이 이해하며 합의할 수 있는 협업 환경을 만들어보는 것을 건의하여 다음 프로젝트 진행시엔 소통 문제를 해결했으면 좋겠습니다.
5. 컨벤션 정리 과정
[컨벤션 정리 URL]
https://www.notion.so/9a17f89103914df192602e1cb4c99ff9
저희는 SQL 컨벤션(네이밍 규칙, SQL 작성 포맷 규칙), PR 컨벤션, 이슈 템플릿, 커밋 컨벤션, 프로젝트 구조 등 다양한 컨벤션 및 구조를 체계화하여 정리하여 연습해보는 것을 목표로 했고 정해진 컨벤션을 기반으로 코드를 작성하고 리뷰하는 과정을 진행하였습니다.
다만, 일부 컨벤션에 대해선 완벽하게 적용하지 못한채 프로젝트를 마치게 되어 아쉬움이 큽니다. 따라서 다음 프로젝트에선 꼭 컨벤션에 대한 완벽한 이해를 토대로 습관하하는 과정을 진행하고 컨벤션을 준수했는지를 검토하는 리뷰 프로세스를 진행해보고자 합니다.
6. 기능 구현 및 테스트 케이스 작성 과정
[테이블 명세서 URL]
https://github.com/DBDIBABIDIBU/be15-1st-DBDIBABDBU-mobile_receipt/blob/main/assets/table_spec.png
테이블 명세서를 기준으로 DDL 구문 작성후 테스트 케이스를 구현했고 요구사항 정의서에 정의한 모든 기능들을 구현후 테스트 케이스를 작성하여 테스트를 진행하였습니다.
저희는 기능 구현과 테스트 케이스 작성 및 시연을 빠르게 진행하기 위해 ERD 클라우드가 제공하는 DDL 추출 기능으로 작성된 초안 DDL을 작성하여 이를 토대로 빠르게 기능을 구현하였고 테이블 명세서와 차이가 나거나 기능 구현에 문제가 되는 요소들을 검토하여 DDL을 수정하여 Github로 DDL 파일을 공유하는 과정을 진행하였습니다.
기능 구현 및 테스트 케이스 작성은 업무를 분담하여 작성한 뒤 코드 리뷰 진행을 통해 구현된 코드가 기능을 완벽하게 구현하는지, 요구사항 정의서에 작성된 모든 기능을 구현했는지를 검토하는 과정을 거치게 되었는데 코드 가독성, 성능, 유지보수성 측면에서 더 심도 깊은 코드 리뷰를 진행하지 못했던 것이 끝내 아쉬움으로 남는 재목인 것 같습니다.
그래서 다음 프로젝트에선 기능 궇녀 및 테스트 케이스 리뷰 프로세스를 명확히 정의하여 코드 품질을 체계적으로 관리하고 향상시킬 수 있는 방법들을 고안하고 프로젝트 초기 단계부터 빠르게 최소 기능을 구현한 뒤 반복적인 개선 과정을 적용하는 순서로 프로젝트를 진행하는 것이 좋을 것 같다는 생각을 하게되었습니다.
