평범한 지방대의 2024년 회고를 하며 (2)
지난이야기 를 참고해 주세요 ! 그렇게 나는 팀장이 되었고, 내가 생각하는 팀장의 가치관을 팀원들에게 전파했다. 앞으로 우리는 어떤 Rule이 있고 Culture를 만들건지 이야기했다. 팀 조직도는 Front-End 2명(나 포함), Back-End 1명으로 총 3
지난이야기 를 참고해 주세요 !
그렇게 나는 팀장 이 되었고, 내가 생각하는 팀장의 가치관을 팀원들에게 전파했다. 앞으로 우리는 어떤 Rule이 있고 Culture를 만들건지 이야기했다.
팀 조직도는 Front-End 2명(나 포함), Back-End 1명으로 총 3명이었다.
나를 제외한 두명은 서로 친분이 있었고, 둘은 같이 학교 축제 웹 사이트 팀 프로젝트 경험이 있는 친구들이었다.
나는 그 둘에 비해서 팀 프로젝트 경험이 적었지만, 팀장을 한 이유는 그들의 안목에 있었다고 생각해. 둘도 실력도 리더쉽도 모두 있는 친구들이었지만 결정적으로 내가 팀장이 된 이유는 다양한 사고와 경험 그리고 경청하는 자세였던 거 같다.
교내 캡스톤 디자인 시작은 9월이지만, 우리는 방학때부터 아이디어 회의 및 기획을 계속 하고 있었다.
우리는 실시간 공유를 하면서 팀 아이디어 회의를 할 수 있는 플랫폼을 만들기로 기획했다.
하지만, 약 2달 반(?) 정도의 기간이 있고, 팀원은 총 3명 뿐이라 엄청난 몰입을 해서 할 수 밖에 없었다.
팀원들은 프로젝트를 해봤지만, 전체적인 관리 프로세스는 경험해 본 적이 없다고 해서 이 부분을 강조하면서 git을 관리했다.
git 의 Project 를 이용해야지 완만하게 협업이 될 것 같았다.
다른 사람의 진행과정이나, 역할 분담 등 이런 소통들을 효율적으로 하기 위해서는 우리 프로젝트의 문서화 가 무척 중요했다.
팀원들에게 git을 알려주고, push알림을 주고받으면서 무언가의 압박을 주면 몰입이 끊기지 않고 계속 할 수 있을 것 같아서 슬랙에 채널을 나누고 팀원들에게 공지했다.
[GIT RULE]-빈 템플릿 일 때git initgit remote add origin <주소>git pull origin
-issue or pr(remote 연결 되어 있을 때)이슈생성git checkout -b <타입>/<번호>/<간단제목>git pull origin 4. (develop)git statusgit add <파일>git commit -m "[이슈번호]내용"git push (로컬에 없으면, push --set-stream~~ 명령어 작성)pr 요청
p.s. 순서 고집하지 않으셔도 됩니다.
[git 공지 및 상식]기본적으로 git PR을 보내는건 fast forward 즉, 강제 푸시 피알입니다. pull을 통해 본인 feature에서 npm run dev를 항상 확인하고 pr 부탁드립니다. 기존에 하던 코드 승인 과정이 코드 리뷰라고 생각하시면 됩니다.