기동 1팀 중간 점검 회고록 (제출용)의 사본

🎉 프로젝트의 절반이 지났습니다!

🖊️우리 회고 합시다!

🤷‍♂️회고 때 무엇을 하나요??

☝️ 우선 모든 것을 털어내 봅시다.

Good

• 기획
• 요구사항을 상세히 정리하고나니 기능별로 필요한 사항이나 예외처리가 필요한 부분들을 미리 정리할 수 있었기에 개발 단계에서 모든 팀원이 각 기능에 대한 공통적인 이해를 갖게되었다.
• 기획부터 디자인까지 전반적으로 참여하다보니 대략적으로 알기만 했던 부분들을 더 깊게 이해하는 계기가 되었다.
 

• 개발 환경 설정
• 코딩컨벤션, 노드버전관리, 커밋 컨밴션, 이슈, 브랜치 전략 중 어느 하나 대충하는것 없이 정말 말 그대로 협업으로 함께 토론하고 결정하여 내용을 맞춰나가는것이 프로젝트 진행 흐름과 개발 환경을 익히는데 큰 도움이 되었다.
• 막연히 기존에 제안되는 룰을 그대로 따라하는것만이 아니라, 가이드라인을 따라가되, 각자의 추가적인 의견들을 반영하여 커스텀화된 룰을 만들며 프로젝트 세팅을 진행하였다.
• 단순히 추천하는 lint rule을 가져다 쓰거나 하지않고 각자의 코딩스타일에 대한 협의를 통해 lint룰을 정했기에 각자의 코딩스타일을 돌아볼 뿐만 아니라 우리 팀만의 코딩컨벤션을 구축할 수 있었다.
 

• 프로젝트 관리
• 이슈 템플릿이나 PR템플릿을 통해 서로의 이슈나 PR에 대해서 공통된 양식과 표현방법을 만들었기에 이슈나 PR에 대해 빠른 파악이 가능해진다. 조금 더 적극적이어도 좋을 것 같다.
• 발생한 에러나 버그에 대해 이슈로 등록하고 발생원인과 해결과정을 기록해두었기에 팀원과의 빠른 공유가 가능해지고 추후 동일한 이슈가 발생했을 때에 대한 참고자료가 되는 것 같다.
• git-project로 이슈나 PR을 칸반보드 형식으로 연결하여 진행하였기에 팀원별로 진행상황을 명확히 알 수 있었다.
 

• 개발
• 스토리 북을 이용하여 테스트 스토리를 작성했기에 비록 시간을 좀 걸릴지라도 확실하게 동작하는 기능 개발이 가능해졌다.
• base 컴포넌트를 우선 개발해두었기에 나중에 어떤 기능을 하는 컴포넌트를 만들때는 핵심기능을에 집중하고 그외 로직들은 base컴포넌트에 위임해서 처리할수 있어 코드가 좀 더 명료해진다.
• atomic design 기반으로 base컴포넌트의 기능을 어디까지 해야하는지 고민을 하면서 구성에 대하여 고민해볼 수 있었다. base컴포넌트에 css 디자인을 어느정도 해야할지도 고민해보면서 변경이 많은 base는 더 많은 props를 받을 수 있도록 아닌경우에는 좀 더 custom할 수 있도록하는 과정을 재사용성과 편리성을 갖춘 컴포넌트 개발이 가능했다.
 

• 팀 문화
• 누구 한명이 프로젝트를 이끌어가고 나머지는 무임승차하는 것이 아닌 모두가 의견을 적극적으로 제시하며, conflict 되는 의견들을 원만히, 그리고 적절하게 서로 맞추어가며 타협하고 있다.
• 팀원 모두가 프로젝트에 대한 주인의식을 가지고있고 긍정적인 방향으로 모두가 함께 프로젝트를 이끌어가고 있는 것 같다. 그렇기에 시간이 갈수록 팀원들간의 결속력을 높여주고, 좀 더 프로젝트에 몰입하게 해주는 좋은 영향을 끼치고 있다고 생각한다.
• 3주라는 시간의 절반이 지났음에도 진행과정에서 루즈하거나 해이해지는 부분없이 잘 달려온 것 같다.
• 팀원이 작업한 코드와, 내가 작업한 코드를 하나로 맞추어가는 작업은 어렵고 괴롭지만, 그만큼 큰 쾌감을 주는것 같다. 마치 각자 맞추던 퍼즐 블록들이 모여서 나 혼자서는 못 만들 커다란 그림이 되는것을 보는 느낌인것 같다. 이렇게 내가 작성하지 않은 코드를 적용하고, 반대로 내가 작성한 코드를 팀원이 사용하며 생기는 다양한 시행착오들을 통하여, 개인 프로젝트와는 다른 부분에서 크게 성장하고 있는 느낌이 든다.
 

Bad

• 기획
• 기획단계에서 개발단계로 넘어가는 과정에서 기획을 어느정도로 마무리할지에 대한 협의과정이 매끄럽지는 않았던것 같다. 기획에 많은 시간을 쏟다보니 기획에 지쳐서 개발단계로 넘어간 느낌이 있다.
 

• 개발 환경 설정
• 디렉토리 구조와 네이밍에 생각보다 많은 시간을 쓴 것 같다. 추후 변경해도 되는 부분이라는 점에서 초기에 많은 시간을 쓰는 것은 지양할 필요성을 느꼈다.

• UI/UX 디자인
• figma를 처음 사용해보았는데 와이어프레임과 UI 명세서를 함께 작업하려다보니 시간과 노력이 많이 들어가게 되었다. 결과적으로 구현해야할 결과물이 명확해져서 개발 단계에서 추가적으로 논의할 부분이 최소화될 것이라는 점은 확실하지만, 짧은 프로젝트 기간에서 어느정도 까지 협의를 했어야 하는지에 대해서는 여전히 의문이 든다.
• 페이지 레이아웃과 디자인 시스템을 미리 정해두지 않아 기초적인 골격이 없는 것 같다는 아쉬움이 들었다.
 

• 팀문화
• 회의 시간에 제한을 두지 않고 진행하다보니 다른 길로 새는 경우나, 우선순위가 떨어지는 주제에 대해 오랫동안 붙잡고 있는 경우가 종종 있었다. 무엇에 집중하고 무엇에 집중하지 않아야 할지 모호하다.
• 스크럼 진행이 정리되지 않는 것 같다. 팀원 별로 오늘 할일이 무엇인지, 무엇이 급한지, 무엇이 얼마나 남았는지, 앞으로 무엇을 할것 인지가 명확하지 않다. 흘러가는대로 일하는 느낌이다. 현재 우리가 어느 단계에 있고 다음 단계가 얼마나 남았는지 그러기 위해서는 무엇을 해야하는지에 대한 명확하게 알수 있는 시스템이 필요할 것 같다.
• 프로젝트 진행에 대한 문서화가 부족하다. 같이 있던 시간에 비해 문서로 정리되고 만들어진 부분은 적다고 생각한다.
• 초반에 이슈 배분 및 작업 할당에 어려움을 겪었다. 프로젝트에 익숙하지 않다보니 모든 것을 협의해서 정하려했고 같이 있는 시간 대비 효율이 떨어졌다.
 

• 코드리뷰
• 모든 PR에 대해 코드리뷰를 할수 있다면 좋겠지만 소요 시간을 고려했을 때에도 정말 '모든' PR에 대해 리뷰를 진행해야하는지가 의문이다.
• 코드리뷰를 제대로 하고싶은 마음에 계속해서 미루다보니 쌓아졌고 리뷰가 없기에 merge되지 않은 PR들이 많아졌다.

✌️ KPT(Keep, Problem, Try) 회고

• 기획
• 초기에 많은 부분에 대해 의견 합의를 하고 프로젝트를 시작하니 의견 충돌이 적음
• 요구사항을 세부적으로 작성한 덕분에 기획서 문서화에 도움
 

• 프로젝트 관리
• 이슈기반의 프로젝트를 통해 각자 할 일이 명확해짐, 기능 구현 및 버그에 관한 기록 관리 가능
 

• 개발
• 스토리북을 통해 PR에서 해당 작업물의 결과를 눈으로 확인할 수 있음
 

• UI / UX
• Good → 와이어 프레임을 통해 프로젝트 결과를 예측할 수 있고, 실제 style 작업을 할 때 참고 가능
 

• 코드리뷰
• Good → 내 코드 뿐만 아니라 다른 사람의 코드도 한 번씩은 볼 기회가 생김, 미처 발견하지 못한 에러에 대한 초기 대응 가능
 

• 팀 문화
• 다같이 논의하는 시간을 갖는 것은 중요하다 생각. 각자 진행되는 프로젝트의 진행사항이나 의견에 대해서 모두 하나로 동기화되는 시간을 통해 하나의 프로젝트를 그려나갈 수 있음
• 프로젝트 과정을 빨리 대충하는것이 아니라 팀원들과 토론하고 결정이 되면 진행 중 함께성장하는데 유익
 

• 기획
• 중요성 대비 협의 시간을 길게 가졌던 안건에 대한 아쉬움
• 협의 기간의 장기화 (프로젝트 진행 지연)
• 기획에서 개발로 넘어가는 부분이 매끄럽지 않았음. 조금 더 지체되지 않고 개발을 시작할수 있는 방법 탐색 필요
 

• 프로젝트 관리
• 이슈를 생성하는 단위에 대한 모호함 (컴포넌트 단위, 페이지 단위, ...)
 

• 개발
• 스토리북으로 작성하는 과정에서의 시간 소요
• 스토리북의 제한된 기능만을 사용
 

• UI / UX
• 데스크톱 사이즈 layout없이 개발하다보니 진행이 어느정도 된 이후에 수정하기에는 오히려 애매해짐
• 레이아웃을 짜는 것에 익숙하지 않은 점 때문에 시간이 많이 소요됨
 

• 코드리뷰
• 코드리뷰를 미루다보니 PR이 쌓이게되고 필요한 기능을 이용하지 못하는 문제가 발생
• 기능 구현을 하느라 코드리뷰가 부담으로 느껴질 때가 있다. 코드리뷰를 상세하게 하려면 개발 속도가 지체되고, 그렇다고 무분별하게 approve를 할 경우 예상치 못한 충돌이 날 수 도 있는 딜레마가 존재
 

• 팀 문화
• 개발하면서 어떤 고민을 하여서 문제를 해결하였는지를 개발이 지나고 나면 잊어버리기 쉬움

• 스크럼 진행 방식 논의 → 1. 잘 되었는가 2. 발전 보완사항
• Github projects를 적극적으로 활용하기
• in Progress의 이슈에 대해 각자의 진행상황이나 일정을 공유
• Done의 이슈를 함께 보면서 정리된 이슈에 대해 공유. 모두가 확인한 사항은 Archive
• 자연스럽게 스크럼 후 코드리뷰로 이어질 수 있도록
 
홍중: 4 - 적용을 하긴했지만 상투적인 느낌이 다소있었다. → 무엇을 하고있느냐보다 현재 디테일한 진행상황, 고민사항등을 공유
 
가영: 5 - why? : 각자가 개발한 부분에 대해서 우선순위를 정하고 시작하다보니 자연스럽게 코드리뷰로 이어지고, 개발에 대한 순서도 명확해지는 효과가 있었다.
무호: 4 - 행동적인 부분은 수행 but, 스크럼이 주는 플러스 알파가 있었는가는 의문
예를 들면 이슈적인 공유, 고민사항 등의 공유를 할수 있는 시스템의 필요
doing이 너무 짧다 → 디테일한 공유
 
현석: 3 - 행동적인 부분은 수행 but, 스크럼이 주는 플러스 알파가 있었는가는 의문
 
 

• 리액트에 대한 기본적인 이해가 부족한 상황에서 프로젝트를 진행하다보니 아쉬운 부분이 있다.
• 리액트 스터디(완벽하게 이해하고 있지 못한 코드에 대한 의견 공유 시간)
• 오히려 코드를 완벽히 이해하면서 프로젝트를 진행한다면 오류를 수정하는 시간도 단축될 수 있고, 팀원들 간의 진행 속도 및 기술 스택에 대한 지식 수준을 상향평준화할 수 있을 것으로 기대된다.
• 언제?? 코어타임 → 스크럼 후에 관련된 이야기를 나누고 싶은 팀원끼리 자유롭게 진행하는 방식
• 의논 후 결론이 안나거나 애매한 부분은 멘토님께 정리해서 질문드려보기
 
홍중: 4 - 형식적으로라도 얘기 자체를 많이 나눴고 많은 도움이 되었다.
가영: 3.5 - 초기의도보다 의견을 나눌만한 소스가 부족했다. 동일한 이슈가 반복되기도 했고 프로젝트 마무리 단계이다보니 코드 퀄리티에 대해서 의논하기는 시간적인 여유가 없었던 것 같다.
무호: 3.5 - 구체적행동으로 이루어지지는 않았으나 목표로했던 상향 평준화가 되었다 생각. 그러나 구체적인 화두가 없다보니 스터디를 하고있다는 체감이 되지 않았다.
현석: 3.8 - 구체적인 스터디라고까지는 아니지만 의견공유는 어느정도 이루어졌다고 생각
 

• 프로젝트 진행 중에 남겨야 할 것 → 따로 정리하는 것이 어렵다면, 자신의 PR에서 해당 코드에 코멘트로 달아두는 형식으로 기록해보자
• 고민했던 부분
• 이슈가 발생해서 해결했던 부분
• 팀원들과 의견을 나눴던 부분
 
현석: 3.5 - 프로젝트에 대한 기록을 남기자 고민의 흔적을 남기자라는 의도 였으나 충분치 않았다.
무호: 4 - 기능, 이슈, 이슈해결등을 나름 조금은 남겼다. 그러나 시스템적으로 정착되어있다는 느낌은 아니였다.
가영: 4 - 하나라도 했다? 사소하게 pr에도 신경써서 남겼다. 커밋도 꼼꼼하게 남겼다.
홍중: 4 - 커밋 브랜치 이슈 pr 잘 정리해서 작성했다. 그래도 나름 문서화 잘했다 생각, 회의록만 덜 쓴것 같아 아쉽다.

• 스토리북
• 스토리북을 이용하는데 있어 불필요한 prop를 전달하는데 에너지를 낭비하지 말자
• 스토리북에 작성하는 컴포넌트 단위에 대한 기준을 세우자. → 우선은 폴더단위로
 
무호: 5 - 에너지소모 안함
나머지: 관심없음
 

• UI / UX
• 데스크톱 UI에 대해 추후논의
무호: 4.5 - 초기 기획단계에서 결정되지 않았던것 치고는 높은 완성도
홍중: 4 - 애자일하게 하면서 많은부분을 빠르게 수정할 수 있었다. 그래도 논의가 약간은 부족했다.
현석: 4 - 어쩔수 없었던 측면이 강했고, 괜찮은 완성도. 짤 리스트파트에서 많은 수정이 일어나게됨
가영: 5 - 어쩔수 없었던 측면이 강했다. 재밌었다. 미운 정들었다.

• 코드리뷰
• 하루에 1시간 의무적으로 모여서 코드리뷰 진행 (13시~14시)
가영: 5 - 흠잡을데 없었다. 매끄러웠다.
현석: 4 - 그 때만 하게되는 부분을 보완하면 더욱 완벽
무호: 5 - 가장 잘 지켜진 룰, 효과도 컸다.
홍중: 5 - 마지막에 잘지켜지지 않았지만, 어쩔수 없이 너무 바쁜상황
룰을 잘지켜왔고 단기 프로젝트에서 코드리뷰를 진행했다는 자체가 대단하다 생각
 

• 문서화
• 회의록을 의식의 흐름대로 작성하되
• 자주 나오는 사안들은 폼을 만들어 주자
 
무호: 2 - 아무리 생각해도 나눈 이야기 치고는 노션에 문서로 기록한 게 적었다.
홍중: 3.5 - 짤막하게 적어둔게 아예 없지는 않다. 회의록이 부족하지만 다른 개발 관련 문서들은 충분히 있다 생각한다.
현석: 3.5 - 회의록은 명백히 좀 부족하다 생각, 그외의 문서들은 잘되어 있다고는 생각
가영: 4 - 대외용 - 완벽, 대내용 - 부족, 그래도 메모정도는 했다.