회고 (5)

 

 

벌써 메인 프로젝트 기간 끝.

 

메인 프로젝트 시작한게 엊그제 같은데 ... 벌써 내일이면 데모데이네요.

메인프로젝트는 9월 7일에 시작해서 10월 12일까지 한달밖에 안되는 짧은기간이었습니다.

이제 막 코딩시작했던거 같은데 벌써 끝난다니..!! 아직 서비스 완성도 안됐는데..!!!! 

 

벌써?!!?!?!?!?

 

저희팀은 "냥빌리지🐱"라는 고양이 SNS 겸 커뮤니티 서비스를 기획하고 제작하였습니다.

냥빌리지 메인화면!

간단하게 팀원들과 회고를 진행하면서 좋았던 점과 아쉬웠던 점 등을 정리해보았습니다.

 

 

 

기획과 설계


기획 단계에서 한번 밖에 없을지도 모르는 기회라 생각했기에 모두가 애정과 열정을 가지고 만들 수 있는 서비스를 기획하자고 결정하였습니다. 그래서 모두가 하고싶은 서비스를 기획하다보니 "고양이"라는 공통 관심사에서 "냥빌리지"라는 서비스가 탄생하게 되었습니다.

기획서 작성을 마치고 API 명세서 간단하게 초안을 작성하면서 ERD, 피그마 등을 함께 만들었는데요. 이 과정에서 저희가 기간은 생각하지 않고 넣고 싶은 기능을 넣다보니 서비스가 좀 커져버렸습니다.

 

피그마

 

ERD (테이블 23개..)

 

설계하고나서 저희가 이걸 다 만들 수 있을까..? 약간 걱정되었지만 최선을 다해서 할 수 있는 만큼 한 것 같습니다.

 

 

♥️ 좋았던 점


팀원과의 협업, 오버커뮤니케이션 🔥

가장 좋았던 점이라고 하면...

역시 모든 문제를 팀원들과 협업하며 해결해 나갔던 것이라고 꼽을 수 있을 것 같습니다.

저는 혼자 일하는 것보다 누군가와 함께 일하는 것을 훨씬 선호하는 편입니다. 그래서 그런지 몰라도 프로젝트하면서 커뮤니케이션으로 힘든 부분은 아예 없었고 즐겁기만 했습니다. 팀원 한분한분이 열정을 가지고 임해주셨고 쿠션어를 사용하며 서로에게 상처가 되지 않게 피드백을 주었던 것 같습니다. 그리고 다들 팀 전체를 생각하는 마음에서 지금 내 의견이 기각되더라도 더 좋은 의견이 있다면 수용하는 태도로 임해주셨습니다. 한분한분 덕분에 커뮤니케이션에 아무런 문제없이 즐겁게 프로젝트 진행할 수 있었습니다.

또한 혼자라면 아마 오래걸렸을 문제들을 같이 공유하고 고민하며 더 나은 해결책을 찾을 수 있었고, 서로의 부족한 점들을 매꿀 수 있었습니다. 👍

 

 

🚀 배포 자동화 구축

기술적으로 좋았던 점이라고 하면...

코딩 초반에 CI/CD를 먼저 구축한게 너무 뿌듯했습니다. 배포 자동화를 먼저 셋팅 해놓자는 의견에 다들 찬성해서 프론트엔드와 백엔드 다같이 배포 환경을 우선 셋팅하였고 깃허브 액션과 Code Deploy를 사용하여 배포 자동화를 구축했습니다. 이과정에서 수많은 우여곡절(?)이 있긴 했지만 그래도 같이 하기에 빠르게 해결하고 셋팅할 수 있었습니다.

짧은 프로젝트 기간동안 배포자동화를 구축하기란 쉽지 않지만 해냈다는 성취감에 너무 뿌듯했습니다. 😁

배포자동화를 구축한 덕분에 이후에 변경사항이 바로바로 서버에 반영되서 너무 편했습니다.!!

 

 

그외 다양한 좋았던 점들

그외에도 셀수 없이 많은 좋았던 점들이 있었던 것 같습니다.

  • 디자인이 너무 예쁘게 잘나왔던 점
  • 모두가 항상 적극적으로 의견을 제시했던 점
  • 다들 밤새가면서 열정적으로 프로젝트 하셔서 열정 에너지를 얻을 수 있었던 점
  • CORS 에러 다같이 해결했던 것
  • 처음보는 문제(에러)에도 다들 적극적이고 긍정적이게 해결하려한 점
  • 다들 예스맨이라는 점
  • 코드 작성하면서 상의할 부분은 바로바로 했던 점
  • 오버커뮤니케이션으로 서로가 어떤 업무를 하고 있는지 바로 알 수 있었던 점
  • Pull Request에 코드 리뷰를 꼼꼼하고 상세하게 했던 점
  • 깃허브 이슈탭을 활용하여 발견한 에러나 이슈를 올려놓고 차근차근 해결한 점
  • 주말에 급하게 회의할 때도 모두 참석했던 점
  • 유용한 단축키나 명령어를 공유했던 점 ㅋㅋㅋ

 

 

 

🥲 아쉬웠던 점


아쉬웠던 점은...딱히 없는 것 같습니다..

굳이 꼽자면 프로젝트 기간이 너무 짧다는 것이 아쉬운 점이라 할 수 있겠네요.

저희가 기간은 생각하지 않고 팀원 모두가 만들고 싶은 서비스를 기획하다보니 기능이 너무 많아진 것 같긴합니다만ㅋㅋㅋ

그래도 기능이 복잡한 만큼 해결해나가는 재미가 있었습니다.

앞으로 수료 이후에도 같이 완성하기로 해서 앞으로도 기대됩니다.

 

 

 

배운 점


프로젝트 동안 여러 문제를 만났고 그 문제들이 저와 팀원들을 많이 성장시켜 주었습니다.

  • Spring Security에서 CORS 해결을 위해 AllowedOriginPattern을 사용할거면 정규표현식을 올바르게 써야한다는 점
  • DB에서 식별관계로 매핑하고 PK 2개이상 설정하는 방법
  • Github secrets는 프로젝트 내부의 yml 설정 코드등에 자동으로 적용이 안된다는 점...
  • 깃허브 명령어
  • 트러블 슈팅은 그때그때 기록하지 않으면 까먹는다는 점
  • DB 테이블에서 겹치는 테이블은 하나의 테이블로 묶는게 효율적이라는 점
  • 협업할때는 메서드 이름을 통일하고 시작하는게 좋다는 점
  • 다른 엔티티의 서비스의 호출이 필요할 때는 서비스단에서 주입하는것이 좋다는 점
  • 웹사이트 도메인을 구매하고 aws에 연결하는 모든 과정
  • 로드밸런서의 사용법
  • 웹사이트에 이미지를 업로드하고 브라우저에서 보여지는 플로우
  • EC2 건강하지 않다는 오류 해결법
  • CORS 해결하는 다양한 방법..

 

 

 

 

메인 프로젝트를 마치며...


저희의 서비스 개발은 아직 끝나지 않았지만 코드스테이츠에서 정한 기간이 끝나 다같이 회고를 작성하고 있습니다.

프로젝트 시작할 때 기대와 설렘을 가득 가지고 시작했는데 기대보다도 더 즐겁고 유익한 시간이었고 다사다난했지만 그만큼 즐거웠습니다.

팀원분들과 즐겁게 코딩하면서 많이 배워 감사한 시간들이었습니다.

프로젝트기획 단계 중간에 디자이너도 합류하고 다들 참 열심히 달려왔던것 같네요.

가끔은 밤을 새가고 가끔은 하루종일 회의를 하기도 하면서 다들 열정이 넘쳐서 즐거웠습니다.

발표영상 찍은 후의 우리의 모습

다들 열심히 한만큼 녹초가 되어있었지만 그래도 즐겁고 뿌듯했습니다.

 

 

 

 

부족한 팀장이었지만 다들 열심히 잘 해주셔서 너무나 감사합니다. 

팀원분들께 압도적 감사!!!!

 

 

배포 링크 : https://catvillage.shop 

 

Cat Village

 

catvillage.shop

깃허브 링크 : https://github.com/codestates-seb/seb39_main_059

 

GitHub - codestates-seb/seb39_main_059: 🐱Community For Cat Lover! 냥빌리지🐱

🐱Community For Cat Lover! 냥빌리지🐱. Contribute to codestates-seb/seb39_main_059 development by creating an account on GitHub.

github.com

 

 

 

 

 

 

짧았던 프리 프로젝트 기간이 어제부로 끝났다. 우리는 인원 부족으로 프론트엔드 팀원 한 분이 들어오면서 프리 프로젝트가 끝났다.

팀원이 늘어나면서 팀번호가 바껴버려서 팀 번호 럭키 7을 잃었다...🥲

메인 프로젝트 첫날은 OT형식으로 진행되었고 프리 프로젝트에 대한 회고 시간을 가졌다.

 

 

⚡️ 프리 프로젝트 진행하면서 좋았던 부분?

 

프리 프로젝트 진행하면서 좋았던 것, 배웠던 것 참 많았다.

그 중에 가장 좋았던 건 팀원들 이다. 난 운이 정말 좋게도 좋은 사람들만 만나서 팀 내에 커뮤니케이션 문제, 팀원간의 이슈는 없었고 서로에게서 많이 배우고 자극 받는 좋은 관계를 만들 수 있었다. 서로 대화할 때도 쿠션어를 사용하고 비난이나 불만을 표출하지 않고 잘 따라와주었다. 사실 내가 팀장으로 크게 한 일은 없었고 전체적인 일정 관리나 회의 진행하고 의견 하나로 모은 정도가 다였다.

다들 긍정적인 덕분에 매번 즐거웠고 같이 하면서 좋은 에너지를 많이 받을 수 있었다. ⚡️

프리 프로젝트를 하면서 특별한 일이 없으면 매일 2번의 회의를 했다.

우리가 짧은 시간과 적은 인원(3명)으로 사용자 요구사항 명세서(SRS)에 정의한 모든 기능을 모두 완성하진 못했지만 훈훈하게 우리의 작품을 뿌듯해하며 마무리를 하였다.

모두가 일단 가장 좋았다고 뽑은건 팀 분위기, 커뮤니케이션 부분이었다.

 

개인적인 좋았던 부분

  • 기술적으로 이슈들은 항상 바로바로 연락을 하고 깃허브 이슈 탭을 적극 활용한 점이 좋았습니다. 😄
  • 유용한 기능은 혼자 알지 않고 서로 공유해서 너무 좋았습니다.
  • 논의, 토론을 하면서 서로를 존중하고 기분 나쁘지 않게 대화하는 점이 좋았습니다.
  • 팀원분들 통해서 몰랐던 부분이나 헷갈렸던 부분들 많이 배울 수 있었습니다.
  • 열정 넘치고 긍정에너지 넘치는 팀원들을 통해 에너지를 많이 얻을 수 있었습니다.
  • 모두가 적극적으로 의견을 제시해서 팀 전체가 계속 더 좋은 방향으로 나아갈 수 있어서 좋았습니다.
  • 부족한 팀장을 잘 도와주셔서 부담을 많이 덜수 있었습니다. 다들 너무 고맙습니다. 😻

 

개발에 있어서 전체적으로 만족했던 부분

  • 문서 작성을 자세하게 했던 부분 (API 명세서, 화면정의서)
  • 설계 단계에서 다같이 상의한 점
  • 프론트엔드와 백엔드가 각자 코딩하고 모여서 합쳤을 때 동작한 것
  • 서버 단에서 각자 도메인 별로 나눠서 코딩하고 한번의 run 없이 합쳤는데 큰 문제 없이 합쳐진 것
  • 배포할 때 프론트엔드 백엔드 같이 에러를 확인하고 해결해나간 점
  • 배포에 AWS를 사용하면서 aws의 전체적인 흐름과 사용법을 익힐 수 있었던 부분

 

 

☄️ 팀 문화와 팀 룰

 

팀원들과 팀 문화와 팀 룰을 초반부터 정해서 지켜갔는데 이게 팀 분위기를 형성한 데 도움이 된 것 같다. 특히 오버커뮤니케이션을 지향했기 때문에 우리의 슬랙 채널은 항상 뜨거웠고 덕분에 서로 성장하는데 도움이 될 수 있었다.



팀문화 페이지

 

프로젝트 룰 페이지

 

그리고 프리 프로젝트를 마무리하면서 회고 날 전에 우리 팀에서는 이미 팀룰과 팀 문화에 있어서 KPT를 진행하였다. 모두들 팀 룰과 팀 문화에 만족하고 있었고 프리 기간동안 입증이 끝난 상태였다.

팀 룰에서 commit과 git branch 그리고 코딩할 때 코드의 통일성을 맞추기 위해서 coding convention까지 정했었는데 이게 큰 도움이 된 것 같다. 팀원들이 모두 프로그래밍 룰을 잘 지켜준 덕분에 git issue창과 branch가 깔끔하게 정리되었다. 추가로 깃에서 Pull Request의 템플릿을 만들어 기본으로 지정할 수 있는데 이게 PR 글들을 깔끔하게 정리해줬고 PR을 들어가면 자세하게 정리되어 있어서 커밋을 하나하나 찾아볼 필요가 없었다. 😄 깃 관리가 잘 된것 같아 아주 만족했다~

 

 

 

✨ 아쉬웠던 점과 개선할 부분

 

개인과 팀 전체로 나눠서 아쉬웠던 점과 개선할 부분도 같이 회고하였다.

 

개인적인 측면에서 아쉬웠던 부분

  • 시간적 자원과 인적 자원이 모자라서 계획한 것을 100프로 구현하지 못한 점
  • 다른 포지션과의 협업이 처음이라 개발 초반에 프론트엔드와 백엔드의 소통이 부족했던 것 같습니다.
  • 클라이언트와 서버 통신을 미리 테스트 하지 않고 개발이 어느정도 된 상태에서 하니까 급작스럽게 처음보는 문제들을 마주쳤습니다.
  • 시간이 부족하여 기술적인 구현 연습을 충분히 못했습니다..
  • 에러에 대해서 깃헙 이슈에만 남겨놓고 회고로 남겨놓진 못했습니다.
  • 깃헙 액션 사용 못해서 배포 자동화 테스트 못해본것

 

개인적인 측면에서 개선할 부분

  • 다른 포지션 팀원들과의 소통에 더 적극적으로 임할 필요가 있습니다.
  • 개발 초기 단계에 개발 서버에서 클라이언트와 서버 통신이 정상적으로 되는지 확인하면 좋을 것 같습니다!
  • 에러 일지 등 회고 작성하면서 할 필요가 있겠습니다!! 📝

 

팀원 모두가 아쉬웠던 부분

  • 처음 설계하는 거라 빠졌던 내용이 많아서 중간중간 수정이 잦았습니다.
  • API 명세서를 구글 스프레드 시트로만 작성하고 다른 좋은 툴을 활용하지 못했던 부분
  • (백엔드) 서버에 Spring Security를 적용하지 못한 점
  • (백엔드) 테스트를 구현해보지 못한 점
  • 배포 서버 테스트를 미리 하지 않은 부분 → 첫 배포에서 많은 오류를 겪었습니다..
  • 개발 서버와 배포 서버를 분리하지 않고 동일하게 사용한 부분

 

팀원 모두가 개선해야겠다고 생각한 부분

  • 메인 프로젝트 때는 API 명세서를 Swagger로 정리하자
  • (백엔드) 상속 및 확장 관계에 대해 한번 더 생각해보고 설계 및 개발하기(클래스 관계도 다이어그램 미리 그려보기!)
  • (백엔드) 처음부터 시큐리티를 적용하여 프로젝트 진행하기
  • 중간중간 build해서 체크가 필요합니다.
  • 장인 정신 좋지만 시간을 고려할 필요가 있습니다.
  • 배포 서버 테스트를 개발 초기 단계에 미리 해보면 좋겠습니다.
  • 시간적으로 가능하면 배포 서버와 개발 서버를 분리해 봅시다. → AWS 프리 티어 계정 2개로 분리
  • 회고... 기록을 너무 안남겼다... 에러를 잘 적어놓자..

 

 

 

모두가 즐거우면서도 유익한 회고 시간이었다.

팀원 모두가 메인 프로젝트 때는 프리 프로젝트 때보다 더 불태우려는 의지를 보였다! 🔥🔥🔥

우리는 프로젝트에 열정을 담아서 팀명을 24/7로 지었다. ㅋㅋㅋ (블랙기업이냐고 얘기가 나왔다..ㅋㅋㅋ)

 

 

 

 

 

 

👉🏻 기초 문서작업 (뼈대) 완성

 

프로젝트가 다가올 수록 문서작업에 대한 고민이 많았다.

생각나는 거라고는 데이터베이스 diagram(ERD)과 API 문서 정도였다.

다행히 코드스테이츠에서 프로젝트 팀이 결성되고 바로 문서에 대한 가이드를 제공해 주었다.

어떤 문서를 작성하는 것이 좋고 어떤 방식으로 하면 좋은지 프론트, 백엔드 모두 이해할 수 있도록 안내를 받았다.

프론트엔드 개발자가 작성해야하는 문서에 대해서는 몰랐는데 화면정의서라는 것을 처음으로 알게 되었다.

백엔드에서 작성해야할 문서는 API 명세서데이터베이스 명세서이다.

어제 작성을 마친 사용자 요구사항 정의서를 토대로 API 명세서를 먼저 작성하였다.

처음엔 API 명세서는 프론트 엔드 팀원분들과 같이 작성을 하다가 백엔드에서 작성하고 넘기는게 효율적일 것 같다는 의견이 나와서 백엔드 팀원분과 같이 작성했다.

API 명세서를 반드시 Spring Rest Docs를 사용할 필요는 없고 데이터베이스 명세서도 반드시 ERD로 만들 필요는 없다고 해서 문서화작업을 최대한 빠르게 마치고 코딩으로 넘어가기 위해서 간단하게 필수기능만 작성하기로 했다. 

데이터베이스 명세서는 API 명세서의 데이터를 토대로 작성하는 거라서 다른 팀원분이 ERDcloud 라는 쉽고 직관적인 사이트를 알려주셨다. 내가 알던 dbdiagram.io는 테이블과 칼럼, 속성 등을 sql문으로 작성해야 했는데...ERDcloud는 너무 편했다. 엔티티를 그리는 것도 편하고 작업을 개인이 아닌 팀으로 설정하면 팀원을 추가해서 같이 작업할 수 있다! 데이터베이스 명세서는 백엔드 다른 팀원분이 맡아서 해주신다하셔서 너무 감사했다. (안그래도 할일이 밀린데다 오랜 회의로 피로가 많이 누적되 있었다.) 그리고 몇 시간전에 완성된 것을 확인했다. 😄 

프론트엔드 팀원분들도 화면정의서를 필수기능 위주로 간단하게 작성해주셨다. 사실 굉장히 빠르게 마치셔서 놀랐다. 우리 팀의 프론트 분들의 작업속도가 빠른 편인 것으로 보인다. ㅎ 

다행히 문서 작업이 예상보다 굉장히 빠르게 끝났다!!!

우리의 목표는 이번주 내로 끝내는 거였는데 시작한지 몇일 안된 오늘 (수요일)에 끝났다..!ㅠㅠ 팀원분들 만세ㅠㅠ

 

 

👉🏻 5명으로 시작해서 몇일만에 4명으로 줄었다..ㅠ

 

저번주 금요일에 프로젝트 팀이 정해지고 이번주부터 제대로 프로젝트에 돌입했는데 팀원 한분이 자리를 비우고 회의에도 참석하지 않았는데 하차하신다는 연락을 받았다.ㅠㅠ 사정이 있어서 그런거지만 아쉬운 건 어쩔 수가 없었다. 다른 팀에선 1명이 하차해서 공중분해 되서 다 다른 팀으로 배정되었다는 얘기를 들었는데... 우리는 다행히 한명이 하차해도 백엔드 2명, 프론트엔드 2명으로 다른 팀과 인원차이가 안나기 때문에 그대로 진행할 수 있었다.

 

 

 

 

 

 

 

😜 프로젝트를 위한 Github 사용법 학습

 

오늘은 팀 프로젝트에서 GitHub를 어떻게 활용할 수 있는지 배웠고 사용법을 자세히 배웠다.

프로젝트 기간이지만 내일 낮까지는 프로젝트를 위한 학습이 진행된다.

Github를 개인 코드 저장소로만 이용해서 다른 사람과 같이 관리해본 적이 없어서 오늘 내용을 최대한 집중해서 익혔다.

 

 

🔎 칸반 보드?

 

오늘 배운것 중에 가장 생소한 단어였다.

영어 같진 않아서 찾아보니까 일본어이다. (看板, 칸반)

칸반 보드 생긴 걸 보니까 많이 봤던 거다.

할일과 진행 중인 프로세스, 그리고 끝난 프로세스를 한눈에 시각화 하는 가상 보드이다.

칸반 보드를 실무에서는 Jira(지라)같은 툴을 이용한다고 한다.

지금은 Github Project 탭이랑 노션을 잘 활용하면 충분할 것 같다.

 

 

🏃‍♂️ 운동은 꾸준히...

 

지금까지 나름 컨디션 관리를 잘 했다고 생각했다.

지금까지 밤에 적게 자고 학습이 가능했던건 전적으로 운동 덕분인 것 같다.

그런데 일주일 동안 프로젝트 전에 복습하겠다고 운동을 안했더니 몸이 많이 쳐졌다..

운동을 꾸준히 했을 때랑 쉬었을 때의 차이는 낮에 공부할 때 많이 느낀다. 🥱

체력이 떨어지면 오래 앉아서 작업하기가 힘들다.

계속 졸음이 쏟아지고 몸이 여기저기가 뻐근하다. 🫠

그래서 오늘부터 다시 저녁 운동을 시작했다.

이제 프로젝트 동안 최소 일주일에 3회 운동해서 체력을 보존해야 겠다.

 

 

 

🌱 주말동안 깃 프로필을 꾸며보았다.

 

 

저번 주말동안 그동안 미뤄왔던 Git 프로필 ReadMe.md 파일을 커스텀 해보았다.

인터넷에 검색해가면서 대충 했는데 나름 예쁘게 된 것 같다.

오늘 보니까 뱃지도 2개나 더 늘었다. pull shark랑 quickdraw 이다.

둘다 혼자 실습하다보니까 자동으로 생겼다. ㅋㅋㅋ

 

 

 

 

 

 

회고 카테고리를 만들고 처음으로 회고록을 작성한다.

프로젝트 들어가면서 아무래도 있었던 일이나 소프트 스킬 부분을 정리할 필요가 있겠다고 생각했다.

 

 

오늘은 드디어 학습을 마치고 Main-Project 전에 Pre-Project 를 시작했다.

첫날부터 코딩이나 설계같은 걸 하진 않았고 일단 오리엔테이션으로 하루가 지나갔다.

 

이제 팀으로 진행하기 때문에 커뮤니케이션에 대해서 하루종일 설명을 들었는데 오랜만에 쉬는 타임이라 편하고 즐거웠다.ㅋㅋㅋ

 

팀 매칭이 되서 드디어 2달의 대장정을 함께할 팀원이 발표되었다.

우리 팀은 나를 포함해서 총 5명인데 7팀이라서(행운의 7) 시작전부터 뭔가 느낌이 좋았다.

팀 매칭이 되고 팀원들과 첫 회의를 하는 시간을 가졌다.

다들 열정으로 가득하신 것 같아서 다행이었다.

지금은 프로젝트에 대한 걱정보단 기대가 많이 큰것 같다.

앞으로의 여정이 기대된다.

 

 

팀의 팀장을 맡게 되었다. 🥸

 

 

먼저는 팀장의 역할을 정하고 팀장을 정했다.

어쩌다보니 내가 팀장이 되었다.

일단 맡게 되었으니 운명이라 생각하고 최선을 다해서 최고의 결과물을 내야겠다,,,!

우리는 팀장의 역할을 이렇게 정했다.

  • 회의 주제를 미리 선정 및 준비 : 회의 10분 전에 미리 화상채팅방 준비하기
  • 커뮤니케이션 조율 : 의견 충돌 시 중재

 

그리고 앞으로 연락할 커뮤니케이션 툴과 화상회의를 할 툴에 대해서 의논했다.

slack 이라는 디스코드와 비슷한 툴이 있는데 커뮤니케이션 툴은 그걸로 결정했다.

아무도 슬랙을 써본적이 없었지만 현업에선 많이 사용한다고 해서 경험해볼겸 일단 써보기로 했다. (써보고 불편하면 디코로 옮기기로 했다.ㅋㅋㅋ)

그리고 게더타운을 화상회의 툴로 결정했는데 이것도 아무도 사용해본 적이 없었다.

모두들 새로운 기술에 적극적이라 감사했다.

 

 

팀의 룰의 대략적 뼈대를 만들었다.

 

코드스테이츠에서 여러 자료를 제공해주기도 했고 팀원분이 좋은 자료를 준비해주셔서 룰을 만들때 여러 의견들이 나왔다. 일반 규칙과 개발 관련 규칙으로 나눠서 정했다.

일반 규칙은 회의 시간, 회의할 때 순서대로 발언하기, 상시연락 가능 시간(책상앞에 있는 시간)을 정했다.

개발 관련규칙엔 "혼자 알지 않기" 와 "혼자 모르지 않기"를 추가했다. 

지금까지는 혼자 생각하면 됐지만 처음으로 팀으로 움직이는 거라 사소한것 하나까지도 공유해야 하고 오버커뮤니케이션이 필요하다.

 

회의 시간은 오전과 오후로 나눠서 작업 전후로 회의를 가지기로 했다.

오전에는 전날 작업했던 내용의 대략적 정리와 오늘 할 내용을 간단하게 공유하기로 했고

오후엔 그날 한 작업에 대한 리뷰와 정리, 회고를 하기로 했다.

우리는 회고를 KPT(Keep, Problem, Try) 형식으로 진행하기로 결정했다.

 

화상회의가 끝난 후에 감사하게도 적극적으로 의견과 피드백이 오가서 난 팀운이 굉장히 좋다고 생각했다. 사실 개인적으로 코딩 스킬보다 커뮤니케이션 스킬이 좋은 팀원을 만나고 싶었는데 참 다행이고 감사하다.

앞으로의 프로젝트 대장정을 위해 프로젝트 들어가기 전까지 준비를 많이 해야겠다.

 

 

 

1