짤이 몽땅 최종 회고

🤷‍♂️회고를 하기전에!

📝중간 회고때 작성한 Try 사항은 잘 지켜졌나요??

팀 공통 회고

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

Good

• 기획
• 최초 기획한 기능의 대부분을 구현했다. 처음하는 프로젝트다 보니 기획단계에서 너무 시간을 쏟은 것이 아닐까하는 걱정이 프로젝트 기간내내 있었으나 다행히도 프로젝트 기획단계에서 계획한 기능을 대부분 구현했다.
• 두 번의 발표를 통해 기획단계에서 들어가야할 사항들에 대해 알게되었다. 중간발표와 최종발표를 통해 우리가 제작한 서비스를 선보이는 과정에서 이 서비스가 필요한 이유, 즉 사용자의 니즈가 어떤것인지를 파악하고 서비스화하는 것이 기획단계에서 가장 중요하다고 느꼈다.
 

• 프로젝트 관리
• 이슈기반 개발과 커밋 세분화가 잘이루어졌다 100%라고 할수는 없지만 이슈작성과 커밋의 세분화가 잘 이루어진 편인 것같다. 커밋의 수가 절대적인 지표가 될수는 없지만 다른팀에 비해 꽤나 많은 커밋의 수가 우리팀의 노력과 커밋 관리를 살펴볼수있다생각한다.
 

• 리액트 숙련도
• 리액트랑 안면을 텄다. 리액트 강의를 다 듣지는 못하고 시작했기에 초반에 emotion와 storybook 사용법이나 리액트의 기본적인 사항에 대해 어려움을 겪었던 적이 많았으나 프로젝트가 진행될수록 리액트와 안면을 트게되었다.
• 실전 리액트 학습 리액트 강의를 듣기도 전에 리액트로 코딩을 해야하는 프로젝트를 시작해버렸다. 당장 코드를 짜야하니 리액트 공부를 하게 되고, 공부한 것을 바로바로 활용해서 코드를 짜면 그에 대한 리뷰를 받을 수 있는 상황이었다. 강의 커리큘럼대로 강사님의 코드를 보면서 이해하기 급급했던 때에는 느낄 수 없었던 짜릿함이 있었다.

• 팀 문화
• 자유로운 소통 팀의 의사결정부분을 대부분 협의후 결정하였기에 처음 배우는 입장에서 학습에 도움이 되었으며 서로가 고민하고 있는 부분을 공유하고 같이 생각했기에 나만의 코드가 아닌 우리의 코드가 될수 있었다. 또한 그로 인해 모두가 프로젝트의 주인의식을 갖게되어 프로젝트의 애정도 큰 것 같다.
• 상호간의 동기부여 막히는 부분, 모르는 부분을 공유하고 해결하는것을 더 연습하고 있었는데 프로젝트 기간동안 정말 많은 연습이 되었고 그러한 과정이 자연스러워졌을뿐만아니라 많은 동기부여가 되었다. 너무 재밌어서 잠자는 시간도 미루게 되고 눈뜨고 자기 전까지 다른 생각은 전혀 없이 한 가지 생각만 해왔다는 사실조차 프로젝트가 끝나고 나서야 자각하게 된 것 같다. 정말 몰두해있는 순간에는 내가 지금 몰두하고 있다는 사실조차도 잊게되는 경험을 할 수 있었던 프로젝트였다.
 

• 코드리뷰
• 기한의 코앞에서는 제대로 이루어지지 않았지만, 전체적으로 코드리뷰가 잘 이루어진 편인것같다. 스크럼 진행후에 1시간씩 코드리뷰를 하는 시간을 가졌고, 이로인해 코드의 오류를 다수 줄일수있었고, 프로젝트의 진척도를 인지해가며 진행이 가능했다.

Bad

• 프로젝트 문서화
• 프로젝트 기록을 남기는 것에 소홀했다. 정말 많은 얘기와 의견을 나누었는데 그런 것들을 한줄씩이나마 적어두었더라면 꾸준함의 지표가 되었을텐데 그런 기록을 남기지 못헀다는 것이 아쉬움이 남는다. 또한 팀원들과 소통을 정말 많이 했다. 나누었던 주제가 정말 많고 다양했는데 그것들을 기록으로 다 남기지 못했던 것 같아서 아쉬운 부분이다.
 

• 개발
• 개발 우선순위 시간적인 압박이 심한 프로젝트에서 하나의 기능(grid...tab....)에 매몰되어있어서 다른 기능을 구현이 미뤄지면 팀 전체적으로 정체 구간이 생기고 일정에 차질이 생길수 있다. 우선적으로 기능을 하게 해두고 리팩토링을 하더라도 어느정도 리듬감있는 개발이 필요한것 같다.
• 코드에 대한 고민 맡은 기능을 구현함에 있어서 중간 점검 이후로는 동작하게 하는 것에 더 초점을 두게되었다. 코드리뷰를 꼼꼼히 진행하다보니 제출 기한 내에 프로젝트가 완성되기 어렵다는 판단을 했고, 우선을 동작하게만 만들다보니 코드들끼리 서로 엉켜있거나 중복되는 부분도 많이 생겼다. 그리고 가장 중요한 '이 코드가 최선일까'에 대한 고민을 하지 않았다. 생각은 들었지만 당시에는 외면하려고 했던 것 같다. 기록이라도 해둘 걸 하는 아쉬움이 있다.

• 코드리뷰 및 프로젝트 관리
• 어쩔수없는 부분이라고도 생각하지만, 기한의 막바지에 이르러서는 코드리뷰나 이슈작성이 전처럼 이루어지진 못했다. 막바지까지도 팀원들과 계속해서 디스코드에서 상주하며 진행해서 코드 추가사항이나 수정사항에 대해서 자연스레 파악하고 있지만, 그렇지 못한 상황이었다면 자칫 프로젝트의 흐름을 놓칠수도 있는 문제가 발생할거라 생각한다. 현업에서는 이러한 다급한 상황속에서 어떻게 대처할까??
💡
Try - Keep 사항 중에서 한단계 더 발전하기 위해 시도해볼 것들을 적어주세요. - Problem 사항 중에서 문제를 예방하기위해 시도해 볼 것들을 적어주세요.

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

• 프로젝트 관리
• 이슈기반으로 브랜치를 만들어서 기능개발하는 것이 명확한 단계와 현재 개발 단계를 알수 있었기에 좋았다.
 

• 코드리뷰
• 고정적인 코드리뷰 시간을 두는 것은 생각보다 더 많은 도움이 되었다. 코드리뷰를 병행해서 PR에 대해 판단하다보니 프로젝트의 완성도와 follow up에 큰 효과를 주었던것같다
 

• 팀 문화
• 비대면상황에서는 웬만하면 캠을 켜고있는 것이 좋은 것 같다. 바로바로 질문이나 의논을 할수 있고 팀원간의 유대감과 결합력도 높아지는 것 같다. 또한 상주하면서 서로 이슈를 공유하고 해결하는 과정이 성장에 도움이 되었다.
• 이번 팀 프로젝트의 가장 큰 장점은 바로 모든 팀원들의 적극적인 대화, 의견 제시였다고 생각한다. 적극적인 참여도와 의견제시는 프로젝트의 완성도를 높여줄수있을뿐만 아니라, 각 팀원들이 프로젝트의 흐름, 진행사항을 파악할수 있게 해주고, 이는 곧 효율적인 작업으로 이어진다고 생각한다.
 

• 기획
• 기획에서 개발로 넘어가는 부분이 매끄럽지 않았던것같다. 조금 더 지체되지 않고 개발을 시작할수 있는 방법이 있지 않을까..? ( 기획시에 개발 프로세스에 대한 틀 정립 등)
• 일정산출의 어려움 아직 프로젝트 경험이 많지 않고, 실력적인 부분에 대해서도 미지수라는 점에서 기능 구현 이슈를 생성하고 이 이슈를 resolve하기까지의 일정을 산출하는 것이 어려웠다. 그러다보니 체계적인 개발이 이루어지지는 못했다는 점이 다음 프로젝트에서는 개선해야할 부분이라고 생각한다

• UI / UX
• UI 흐름도의 부재 UI흐름도를 미리 그리고 시작하려하였으나 오히려 복잡한 흐름도가 나와서 다시 봐도 파악하기 힘들것이라고 파악하여 따로 진행하지 않았다. 하지만 그러다보니 세세하게 페이지 이동을 해야하는 부분을 놓치거나 모달을 띄울때 어떤식으로 할지 등 더 구체적으로 정하지 못하고 개발에 착수하게 되었다. 또한 UI흐름도가 있었을 때 생기는 많은 장점들이 있다고 생각하는데 그러한 이득을 보지 못해 아쉬웠다.
 

• 개발
• 다운탑방식 개발의 어려움 다운탑 방식의 컴포넌트 제작은 초반 개발진척에 어려움을 주었다. 프로젝트의 기획기간이 부족하여 상세한 부분까지의 기획이 이루어지지않은 상황속에서 다운탑 방식으로 개발을 진행하는것은 효과적인 방식이 아니었다. base 컴포넌트에서 고려하지 못한 부분이 너무나 많았고, 불완전한 base 컴포넌트나 hook를 무리하게 사용하려하며 허비한 시간이 많았다.
 

• 팀 문화
• 미흡한 기록화 프로젝트를 위해 쓴 시간에 비해서 기록물이 그 만큼 남아있지 않아서 아쉬운 부분이 있다. 물론 커밋을 하면서 그 결과물을 코드로서 남겨두긴 했지만, 코드에는 전부 담지 못했던 고민들도 많았기 때문에 그런 것들을 꼭 정제된 언어가 아니더라도 기록해두었으면 좋았을 것 같다.

• 기획단계에서 명확한 세부 프로세스를 설정하자. 명확한 타켓층과 니즈를 바탕으로한 프로젝트 주제가 결정되면 그것을 바탕으로 주요기능, 기술스택, 디자인, 색상, 로고와 와이어프레임이 명확하게 나오기에 그러한 세부스텝을 정해두면 좋을 것 같다.

• 고정적인 코드리뷰 시간을 가지되 그때만 코드리뷰가 일어나는 현상을 최소해야한다.
고정적인 코드리뷰시간은 코드리뷰가 가장우선시되는 시간으로 매우 도움이 되었으나 그외의 시간에 대해서는 코드리뷰를 하지 않는 현상도 나타났다고 생각한다. 이 부분을 팀원 모두가 인지해야만 한다고 생각한다.
 

• 다운탑 방식의 문제점을 해결하기위해 대략적인 디자인 시스템이 필요하다 디자인시스템이 어느정도 있어야 그것을 바탕으로 명확한 기준이 있는 base 컴포넌트 개발이 가능해진다고 생각한다. 따라서 스케치 수준일 지라도 디자인 시스템이 있으면 좋을 것 같다. 다만 단기 프로젝트에서 그것이 가능한지는 의문이다.

• 탑다운방식을 고려해보자 다운탑 방식이 여러가지 고충이있다는 것을 알았으니 크게 레이아웃을 먼저 짜두고 개발하는 탑다운 방식으로 개발을 진행하는 것도 고려해보면 좋을것 같다.

개인별 회고

짤이 몽땅의 향후계획

단기적 목표(최종 프로젝트 전까지)

1. 타입스크립트의 연습에 도움이된다.

2. 장기적으로 보았을 때 API를 직접 만들어서 대체할 계획이기에 그부분에 데이터의 타입체크를 위해서도 필요할것 같다.

중기적 목표(최종 프로젝트 이후)