[도르] 개인 회고

기획

• 프로젝트 초반에 목표했던 프로젝트 기능을 모두 구현함 3주라는 짧은 기간, 백엔드와의 첫 협업등으로 모든 기능을 구현할 수 있을까하는 걱정이 있었는데 정말 다들 열심히해서 모든 기능을 구현하고 좋은 결과를 냈다 생각함

• 디자인 단계에서의 시간절약 디자인에 익숙한 코비와 젠의 활약으로 디자인 단계에서 많은 시간을 절약했다 생각함 그러면서도 퀄리티 높은 디자인이 나왔기에 이부분에서 인적자원을 팀적으로 잘 활용했다 생각

• 서비스 브랜딩 과정 기획단계에서 자칫 비효율적이기만하고 대충 브랜딩한 결과가 나오기 쉽다 생각했는데 서비스를 브랜딩하고 서비스명, 색상, 로고등을 정하는 과정이 조금은 체계적이였다고 생각

• 기획단계에서의 효울성 정말 중요한 단계이지만 많은 시간을 투자하기에는 부담스러운 단계가 기획이라 효율성이 중요하다 생각이 들었는데 효율적으로 시간을 배분했다 생각함. 명확한 레퍼런스와 기획의도가 있어서 가능했다고 봄

프로젝트 관리

• 비동기적 의사소통 이전 프로젝트에서는 동기적인 의사소통을 주로했고 그러다보니 아침 부터 새벽까지 같이 있게되는 상황이 펼쳐졌었다. 이번 프로젝트에서는 비동기적으로 의사소통에 대해 어느정도 이해하고 실천한 것 같아 보다 효율적인 개발이 가능했다 생각

• 스프린트 기간의 설정 프로젝트의 기간을 스프린트로 쪼개고 스프린트의 목표를 설정하다보니 지금단계에서 해야할 일과 집중해야할 일을 명확하게 알수 있어서 자칫 딴길로 새거나 하는 문제를 미연에 방지했다 생각

개발

• MUI의 사용 사실 일장일단이 있는부분이라 생각이 들지만 짧은 프로젝트에서는 장점이 더 극대화 된다고 생각한다. 또한 MUI의 theme를 커스텀해 사용하였기에 mui특유의 느낌에서 벗어나 조금의 우리 프로젝트만의 느낌을 잘 살렸다고 생각

• 리액트랑 조금 더 친해짐 저번 프로젝트떄 리액트랑 안면을 텄는데 이제는 통성명정도한 사이는 된 것 같다.

기획

• 브랜딩과 기능과의 일관성 상실 제공하는 서비스에 대해 연상되는 친숙함, 편함등의 키워드를 바탕으로 브랜딩을 했으나 이부분을 서비스 어느부분에서 느낄 수 있는가 하는 의구심이 남음

프로젝트 관리

• 코드리뷰 코드리뷰를 충실하게 진행하지 못했다고 생각함. 프로젝트에 치이다보니 코드리뷰를 소홀하게되었고 어쩔수 없는 측면도 있지만 결과적으로는 좋지못한 코드를 남겨두게 된 모양이라 아쉬운부분이라고 생각

• 문서화 부족 프로젝트를 진행하면서 발생한 이슈나 문제점들을 기록해두는 것이 부족했다고 생각함. 기타 회의록이나 다른 문서작업은 나쁘지 않았으나 프로젝트 전반적인 이슈나 기술적인 부분을 기록하는 부분에서 소홀했던것 같다.

• 지라 활용의 미숙함 지라라는 프로젝트 관리 도구가 좋은 이유는 어느정도 알겠으나 지원하는 기능에 비해 사용하는 기능이 적다는 느낌이 많이 들었다.

개발

• 타입스크립트 미사용 러닝커브나 숙련도로 인해 장점보다 단점이 많다고 생각해서 타입스크립트를 사용하지 않았는데 개인적으로는 많이 아쉬운 부분이라 생각함.

• 스토리북의 미사용 스토리북이 없으니 각 UI컴포넌트를 테스트하는 부분이 많이 어려웠고 오히려 MUI를 사용해서 디자인시스템이 어느정도 있는상황이라 스토리북을 사용했을떄 보다 시너지가 좋았을수도 있을수 있겠다는 생각이 들었음

• 상태관리 툴의 미사용 context api의 한계가 명확하다고 생각이 들었음. 변경주기가 비교적 긴(인증, 테마, 언어)등을 이용할때는 충분히 좋으나 그 이외의 상태관리에서는 생가보다 불편할 수 있겠다는 생각이 들어서 다른 상태관리 도구를 이용해보지 못한 것에 대한 아쉬움을 느낌

• 서비스 브랜딩과정을 좀 더 체계적으로 가져가고 싶다. 서비스 브랜딩 과정에서 타겟층의 명확한 pain point를 바탕으로 그에 대한 솔루션을 먼저 생각한 후 그것을 바탕으로 브랜딩을 가져간다면 더욱 명료해질것이라 생각이 들어서 다음 프로젝트에서는 명확한 타겟층과 pain point, needs 그에 대한 솔루션 명확히하고 브랜딩과정에서도 이번에 해본 서비스 MBTI과정에 대한 좀 더 체계적인 과정과 색상 선택과정을 거치고 싶다.

• 비동기적 의사소통 성공적인 비동기적 의사소통이 성공적인 동기적 의사소통보다 충분조건이 좀 더 까다로운편이지만 팀적으로 명확한 비전과 스프린트 목표설정, 업무 분담이 된다면 효율성을 끌어 올릴수 있어서 비동기적 의사소통을 중점으로 진행해볼것 같다. 다만 기획단계에서는 어쩔 수없이 동기적 의사소통이 필요한 경우가 많은 것 같다.

• 코드 리뷰의 부재 코드 리뷰의 부재로 좋지 못한 코드를 프로젝트에 남겨두게되었고 부채로서 존재함. 추후에 결국엔 리팩토링이 필요할 코드를 계속해서 작성하는 문제점이 발생.

• 문서화 부족 프로젝트를 진행하면서 발생한 이슈와 이벤트들을 정리하지 않다보니 프로젝트 마무리단계에서 프로젝트의 흔적이 많이 옅어지는 느낌이 있고 실제로 최종프로젝트 평가 문서화 부분에서 다른 팀에 비해 높은 점수를 받지 못했다고 생각함

• 원활한 비동기적 의사소통을 위해 명확한 비젼과 업무분담을 설정하고 스크럼시간의 효율성과 효과성을 높인다.(어떻게??)

• 최소 approve 개수를 설정한다. 반드시 받아야할 approve를 설정해서 코드리뷰를 의무화한다.

• 무의미한 LGTM은 자제한다.

• github wiki를 통해 프로젝트 이슈관리를 진행한다.