지은팀 최종 결과

최종 회고록

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

• 기획
• 처음 기획한 기능의 대부분을 구현했다.
• 기획하며 필요한 사항들 기획을 하면서 기능 구현에도 목표를 두었지만 정말 이것이 하나의 플랫폼이라 생각하고 근본적으로 무엇을 위해 이 주제를 정하고 어떤 사용자를 위해 만드는 건지에 대해 확실한 목표성을 가지게 되었다.
 

• 프로젝트 관리
• 각자의 진행 상황 공유와 이슈 기반 개발이 잘 이루어졌다.
• 프로젝트 계획, 세부 사항, 파일, 피드백을 일원화하여 관리가 되었다.
• 스프린트를 2일 주기로 짧게 잡아 진행을 하면서 프로젝트 진행을 더욱 원활하게 하였다.
• 노션을 이용해서 회의록을 작성하고 여러 안건들을 문서화했다.

• 코드리뷰
• 당연하지만 버그를 조기 발견할 수 있었고 컨벤션을 준수할 수 있었다.
• 중복 코드 방지와 일관된 스타일을 유지할 수 있도록 되었다.
• 다른 사람의 코드를 보게 됨으로써 프로젝트의 구조와 다른 사람의 코드 로직에 대해 더 잘 알게 되었다.
 

• 팀 문화
• 배려하는 모습
서로 의견이 겹치거나 그런 모습이 있을 때 초반에는 서로의 주장이 강해 이해를 못해주는 모습이 간간히 보였으나 프로젝트가 진행하면서 서로 존중하고 어떤 안건이 있을 때 자신의 생각보다 프로젝트를 위해, 팀을 위해 먼저 다른 사람의 말을 들어주려 하는 문화가 자연스럽게 생기게 되었다.
• 스크럼의 중요성
프로젝트를 진행하면서 놓치지 말자고 서로 다짐했던 것 중 하나는 스크럼을 활성화 하는 것이다. 코어타임이 시작하기 전 시작 스크럼, 끝나기 전 종료 스크럼을 진행 해서 어제 진행 상황과 문제 해결, 의견 제시를 할 수 있는 시간이 항상 생겼고 끝나기 전 스크럼으로 오늘 무엇을 했고 기한 내 진행 상황에 차질이 생길 시 다른 팀원들도 바로 알고 진행이 원활하게 되었다
 

• 커뮤니케이션
• 소통의 원활화
팀의 의사결정 부분을 회의를 통하여 계속해서 결정하였고 각자의 생각을 공유하고 같이 해결을 해나가는 경우가 많았기에 프로젝트를 하면서 나 혼자만 하는게 아니라 다른 사람과 함께 진행 할때의 차이점을 배웠다. 서로의 코드를 확인하며 개인이 아닌 우리의 코드를 만들게 되었다.
• 슬랙
만약 빠르게 공유되거나 처리되어야 할 문제가 있다면 슬랙을 통해서 신속하게 공유했다.
• 노션
• 노션의 ‘칸반보드’를 이용해서 현재 태스크, 앞으로 할 태스크를 모두가 공유했다.
• 안건 페이지를 따로 만들어 급한 문제 처리, 이슈 등에 대한 원활한 소통이 이루어졌습니다.

• 기획
• 디테일의 부족
기획을 할 때, 세세한 기능을 생각하지 못했다는 점이 아쉽다. 특히나 기획만으로 기능을 구체화 할 때는 그 기능을 위한 숨은 의존성에 대해서 통찰하지 못했다는 점이 아쉬웠고 따라서, 기능을 구현하면서도 그 기능을 구현하기 위하여 다른 부분을 다시 회의하고, 다시 이야기하는 과정에서 시간을 많이 소요하게 되었다.
 

• 개발
• 개발 기능의 분리
개발에 있어서, 의존성이 있는 부분을 한 사람이 맡아서 개발하는게 더 좋을 것 같은데 이러한 역할 분리가 미숙하여서 의존성이 있는 부분을 여러 사람이 맡는 일이 생겼고, 따라서 개발해야할 기능이 모호해지고, 개발 시 혼란스러워지는 점이 있었다.
• 코드에 대한 고민
• 처음 시작 할 당시에는 코드의 재사용, 가독성, 함수명, 변수명 등에 대해 리뷰를 달며 진행하였지만 마감 기한이 다가올수록 동작에 대한 구현에만 초점을 두게 되었다.
• 구현하지 못한 요구사항
• 구현 내용이 복잡하기 때문에 기본 요구사항 중 알림 에 대한 부분을 충족시키지 못하였다.
 

• UI/UX 디자인
• 구체화의 중요성
와이어 프레임으로 진행을 하면서 세세하게 페이지 이동을 해야하는 부분을 놓치거나 모달이나 흐름을 구체적으로 정하지 못하여 진행을 하면서 임의로 정해야 하는 부분들이 꽤 있었기에 개발을 하면서 이 부분에 대해 또 정해야 할 시간이 필요하게 되었다.
 

• 코드리뷰(PR)
• 짧은 시간의 아쉬움
시간이 지날 수록 코드 리뷰에 들이는 시간을 짧게 할 수 밖에 없어서 코드를 꼼꼼하게 볼 수 없었다. 그래서 코드를 대강 확인하고 approve 해버리는 바람에, 이 후에 머지된 코드에서 바뀐 부분을 파악하지 못해서 시간을 들일 때도 있었다.

• 기획
• 명확한 세부 프로세스를 설정하고 시작해야 한다.
명확한 타겟층과 사용자의 필요성을 바탕으로 주요 기능들과, 로고, 색상, 그림자 그리고 와이어 프레임이 나오며 그러한 세부 스텝을 설정하여 시작을 하면 개발이 더욱 원활히 이루어질거라 생각한다.

• 협업(개발)
• 이슈를 다른 툴로 연동하여 다른 사람의 히스토리를 파악하자
PR과 이슈가 연동되지 않아 한번 더 수정을 해줘야 하는 경우가 있었는데 이 부분은 나중에지라나 다른 툴로서 이슈마다 git commit을 연동하여 다른 누군가가 히스토리를 더 빨리 파악할 수 있도록 하면 좋겠다.
• 디자인에 사용되는 색상 등은 미리 상수화를 하고 시작하자.
색상을 미리 상수화하고 시작하였기 때문에, 마지막까지 모든 파일에 색상에 대한 상수화가 적용되지 않았다. 따라서 다음부터는 대략 정해진 것이라도 미리 상수화를 한 후, css에 적용을 목표로 하자.
 
 

• UI/UX 디자인
• 사용자의 다양한 접근성을 위해서 반응형이 필요하다. 구현을 하면서 반응형을 놓쳤기 때문에 이 부분을 리팩토링하여 페이지의 크기가 달라지더라도 그에 따라 변경되는 안정적인 서비스를 보여주고 싶다.
• 사용자 액션에 따른 디테일한 view를 보여주자.
당장 눈에 보이는 컴포넌트 뿐 아니라 사용자 행동에 따른 view도 디자인 기획단계에서 신경을 써야했다. 예를 들어 글을 삭제할 때 ‘글을 삭제할까요’ 라는 한번 더 confirm을 하는 컴포넌트도 개발 중간에 발견하게 되었다. 이 부분을 급히 추가하기에는 시간이나 기술적 어려움이 있어 web API로 대체하였는데, 직접 컴포넌트를 구현하여 이 부분을 보완을 시켜야 한다.
 

• 코드리뷰
• 시간을 정해서 리뷰하는 시간을 가지자. 시간에 쫒겨서 기능에 크게 문제가 없다면(50~70% 정도 만족한다면) 승인하고 넘어갔는데, 조금 더 리뷰를 빡빡하게 (70% 이상) 하고 코어타임을 시작하기 전에 리뷰를 하는 시간을 고정 시켜서 온전히 리뷰에 집중할 수 있도록 만들어야 겠다.
 
 

<러북>의 향후 계획

리팩토링 목표

추가 기능 구현 사항

6/22 최종 발표 날 마지막 스크럼

6/22 최종 발표 날 새벽 1시

6/22 최종 발표 날 새벽 3시

6/22 자정 마지막 사진

6/21 온라인 스크럼

6/17 새벽 어느날

6/15 온라인 스크럼

6/14 온라인 스크럼

6/13 온라인 스크럼

6/13 새벽 4시 🔥 

6/10 온라인 스크럼

6/9 온라인 스크럼

6/8 온라인 회의

6/7 오프라인

6/6 온라인 회의