[Flask] Team Project(GameInsight) 01 (프로젝트 기획 과정 및 개요)
ohnyong
2023. 8. 9. 23:55
팀 프로젝트 3일안에 간단한 서비스 페이지 완성해보기
팀장으로 자처해서 팀원들에게 여러 의견을 주도적으로 받고 본인을 포함한 인적 자원의 가능성을 체크했다. 간단한 회의를 통해 팀원들이 보여준 이해도와 자신감으로 우리 팀은 4명으로 충분히 할 수 있다고 판단되는 범위를 정했다.
개발 기간은 3일이지만 사실상 아이디어 창출을 위한 브레인스토밍 반나절, 문서화 2~3시간을 사용했고, 나는 팀장으로써 이전 경험들을 토대로 좀 더 원활한, 안정적인 프로젝트 시작을 위해서 공통 환경 구축, 그라운드 규칙, 개요, 커뮤니케이션 툴, 협업 툴을 체크하고 미숙한 부분이 있으면 핵심적인 부분의 사용법과 간단한, 알기 쉽도록 안내하느라 반나절이 다 지나갔다. 추후 기초적인 발표 준비와 배포 과정까지 생각해야 되서 사실상 3일이 아니라 하루만에 작업을 완료해야 되는 상황이다. 하지만, 비교적 짧은 기간에 각자 맡은 부분을 최선을 다해서 구현해보자는 목표를 가졌다. 또한 아이디어 창출, 기획, 배포, 정리 까지도 개발의 한 부분이다. 사실상 맘편히 쉽게 연습 할 수도 있었지만 우린 마치 마감일이 코앞에 다가와서 프로젝트를 단숨에 끝내야 되는 상황을 스스로 자처한 것이다.
다소 무리해보이는 스케쥴을 가능하게 하기 위해서는 기획 부분에서 개발 부분을 고려할 뿐만 아니라, 인적 자원의 능력, 물리적인 시간, 구현 가능성을 빠르게 판단해야 했다. 구현할 기능의 범위를 파악해야 했고 개인 부분의 범위는 알아서 정해야 한다. 모두 각자 범위를 선택 할 수 있도록 선택권을 주었으며 이번 미니 프로젝트로 개개인에게 좋은 경험이 되었으면 하는 바람도 있었다.
1. 아이디어 회의
공통 분모 찾기
프로젝트의 주제를 정하는 것이 가장 오래 걸릴 수도, 나중에 후회 할 수도, 잘못 선택 할 수도 있는 중요한 부분이다. 실제로 시간은 소모되지만 개발 중 피보팅하기 위험부담이 크기 때문에 신중하게 결정해야 한다.
우리는 공통 관심사를 찾기 시작했다. 좋아하는것? 주변에서 서비스를 본것? 해보고 싶은것? 팀장으로써 적극적으로 아이디어를 발굴하기 위한 질의를 시작했고, 팀원들 모두 적극적으로 본인의 의견을 제시했다.
우리가 정한 관심사와 프로젝트의 주제는 게임 정보로 정해졌다. 남자들로 구성되서 사실상 공통된 주제로 이야기 할 수 있는 것은 정해져있다. 게임, 군대, 이성. 나는 비교적 다양한 취미를 가지고 있지만 다른 팀원들의 이해도가 부족 할 수 있어서 그들의 관심사를 이끌어내고 내것과 비교했다.
나는 수년간 해외 게임 인사이트 분석 작가로 활동했기 때문에 이미 게임 분석과 관련된 정보들을 수없이 접해왔기 때문에 해당 주제로 선택 된 것에서 다양한 아이디어를 빠르게 확장 시킬 수 있었다. 물론 일적으로 접근 안하더라도 남성이라면 기본적인 게임에 관심이 있는 가능성이 높고 관련된 정보들도 찾아보는 것에 익숙할 것이었다. 다행히 모든 팀원이 관심사가 있었다. 또한 이미 다양하게 정보들이 제공되는 레퍼런스가 많다. 나는 Metacritic과 Steam, SteamChart, 한국의 GameMeca, Inven과 같은 게임 언론을 소개했으며 우리가 만들 수 있는 기능들을 정리해봤다. 아이디어를 개연성있고 빠르게 연결 시킬 수 있는 마인드맵(Gitmind)
2. 협업 준비를 위한 내부 테스트 진행
Git, Github의 미니멈 테스트와 기본기 테스트 프로젝트를 빠르게 "착수" 해야 한다. 전처럼 강의를 보는 시간도 아니며, 연습문제를 푸는 시간도 아니다. 나는 우선 팀장으로써 최대한 빠른 착수를 위해서 기초적인 Git 사용 상태를 체크했으며, Github를 통해 내가 생성한 원격 리포에 푸시를 해보라는 실습을 던져주었다. 10분내로 모든 팀원들로부터 Branch가 각자 생성되었으며, 원격 저장소에 Push되어 Pull-Request 방식으로 Merge 할 수 있는 상황이 나타났다. 일부 이해도가 부족한 부분은 빠르고 쉽게 설명하고 간단한 오류를 해결했다.
3. 계획을 기반으로 아이디어 구체화, 실질적 기획단계로 넘어가기 팀 소개 페이지 작성
Google Slide를 통한 화면 설계 실질적인 기획 단계로 빠르게 넘어가야 한다. 간단한 프로젝트기 때문에 DB및 비지니스 로직 플로우 차트는 개요에서 정리하기로 하고 팀 소개 페이지에서 약식으로 API소개 페이지를 작성 할 때 DB 설계등을 진행하는 방식으로 추진했다. 직접 개발 작업과도 연관 되는 화면 설계는 빠르고 자유롭게 화면 구상을 그려낼 수 있는 PPT를 활용했다. 이 부분을 혼자 하려니 너무 시간이 오래걸렸는데, 팀원의 제안을 통해서 Google Slide에서 동시 작업을 진행했다. 따라서 나는 팀원들에게 기초적인 HTML 표준 레이아웃이라는 것에 대해서 설명해주고 이것을 지향하는 쪽으로 페이지를 구성해보자는 의견을 제시했다. 이해도가 높아진 팀원들로부터 공통적인 레이아웃을 토의하여 구성하고 이후 각자 파트에 대해서 화면 설계를 진행 했다.
프로젝트 소개 페이지(Notion) 제작 기획을 마무리 했으면 빠르게개요를 작성해서 프로젝트 전체적인 로드맵을 확인해야 한다. 또한 결국 작업해야 되는 것이며, 프로젝트 시작단계에서 작성하면 기획 기준을 정확하게 인지 할 수 있다. 개발하다가 "뭐하려고 했더라?" 와 같은 상황이 안나타나고 기능 개발에만 집중 할 수 있다. 나는 빠르게 노션으로 소개 페이지 레이아웃을 작성하고 필수적인 요소들을 양식화하고 팀원들에게 배포했다. 각자 부분만 작성하면 된다. 팀장은 주도적으로 안내하거나 양식정도를 제공해주는 가이드가 되어야지 모든것을 해줄 필요는 없다고 생각한다. 오히려 모든 것을 대신 해주면 당장 편하더라도 팀원들의 성장을 방해 할 수 있다고 생각한다. 말그대로 협업이므로 책임을 합리적으로 분산시키고 각자의 주도적인 참여를 유도 하는 것도 팀장으로써 해결해야 할 문제라 생각한다. 아래 링크는 노션으로 제작한 팀 및 프로젝트 소개 페이지이며 모두 제공해준 양식에 따라 빠르게 작성해주었다. https://ohnyong.notion.site/GameInsight-536ac8bfbd5445f19dff65eeddd385b4?pvs=4
프로젝트 개요 README.MD 게시 및 gitignore 추적제외 원격 저장소에 Readme 파일을 통해 개요를 작성했다. 소개 페이지 외에도 Github의 대문도 꾸미는게 기본적인 상식이라 생각했다. README 파일에 대해서 팀원들에게 설명하고 기초적인 정보들을 입력했다. 추후 변경 사항 등이 발생하면 업데이트 될 예정이다. 서비스에 대한 소개, 팀원의 소개, 각자의 구현 기능 소개하고 있다. 또한 불필요한 로컬 System 설정 파일이나 MacOS, Windows의 호환 문제 등을 해결하기 위해서 gitignore.io의 도움을 받아gitignore로 추적을 제외할 파일을 지정하여 원격 저장소 마스터 브랜치로 푸시했다.
4. 팀 커뮤니케이션 Slack
Slack을 통한 커뮤니케이션 및 공지 안내 팀 커뮤니케이션은 Slack을 이용한다. 고정글, 코드블럭, 이미지 등을 자유롭게 공유 할 수 있기 때문에 특히 규칙 및 공통 변경 사항에 대해서 공지 할 때 모두가 확인 할 수 있는 팀 채팅방을 개설했다.
5. 프로젝트 착수
실제 프로젝트 원격 Repository 생성과 기본 프로젝트 구조 생성 및 마스터 배포 이제 시간이 없기 때문에 바로 공통 기초 환경을 구축했다. 모두 아무것도 없는 페이지에서 시작하면 서로 파일의 경로가 다르거나 파일의 이름이 제각각이거나 엉망이 되고 병합과정에서 충돌이 난발해서 오히려 시간이 오래 걸리며, Git을 쓰는 이유 조차 희미해진다.
따라서 나는 시간적 여유가 없기 때문에 보다 분명하게 준비 할 필요가 있었다. 최초 공통 프로젝트 구조를 생성하고, 메인 파일인 app.py와 공통될 라이브러리 임포트, db커넥션, 런 이니시, 포트 설정 등 공통 환경 부분을 작성했다. 주석을 통해서 작업 할 부분을 구분해주고 이제 각자 본인의 코드가 삽입하면 된다.
또한 /template/index.html, /static/js, /static/css로 최소한의 모듈화를 통해서 코드 오류 충돌을 최소화 하고자 환경을 구축했다. 이렇게 최초 프로젝트 시작 버전을 원격 리포에 등록했으며 팀원들이 모두 Pull로 받아 브랜치를 생성했고, 나 또한 Master 브랜치는 병합용으로 원본을 보존하며 병합 시에 나도 동일하게 Pull-Request 과정을 진행하도록 Branch를 생성하여 프로젝트 개발에 착수 했다.
