2차 프로젝트 회고록

2차 프로젝트 📽️

프로젝트 기간: 22.08.29 ~ 22.09.08(9일)
버그 수정 및 리팩토링 계획 : 22.09. 10 ~ 22. 09.13
개발은 초기 세팅부터 직접 구현하였고 이번 프로젝트는 다양한 라이브러리와 API를 최대한 활용하는 것을 목표로 진행하였습니다.

목차

Good
- 규칙적인 stand-up meeting 실천 및 내부적인 규칙 설정
- 정확하고 빨랐던 API 명세서(postMan)
- 성실한 팀원을 만나 감사

Problem
- plan failure
- mis-communication
- documentation
- advance preparations
- Leave completed tickets alone
- A time constraint
- different naming convetion

good

• 스탠드업 미팅을 정확한 시간에 매일 실천한 것과 자신의 할 일과 블로커를 잘 공유한 것뿐 아니라 전반적인 팀의 문화를 올바른 방향으로 이끌었습니다. 반드시 지켜야 하는 규칙들을 같이 정하고 그 이후 밝은 분위기와 위로와 격려하는 동시에 부족한 부분이 있다면 정확히 알려주고 성장 마인드 셋을 지니도록 서로 도와주는 팀이었습니다.
• API 명세서를 post man을 통해 프로젝트 중반 정도에 깔끔히 마칠 수 있어서 프론드엔드 입장에서 Sprint의 티켓을 진행하는데 있어서 일이 막힘없이 진행될 수 있다는 점에서 만족스러웠습니다.
• 지각, 결근이 일체 없고 프로젝트 초기에 정한 규칙들을 모두 성실히 이행하고 더 나은 프로젝트 방식에 대한 열정들을 가진 팀원을 만날 수 있어서 너무 감사했습니다.

problem

• plan failure: 계획했던 당일 할 일을 미팅 때 공유한대로 이행하지 못하는 경우가 너무 잦았던 것같습니다. 비록 바쁘고 할 일이 많았었지만 그럴 경우, 팀원들에게 바쁜 이유와 상황을 공유했더라면 원활한 상황 공유로 기한을 맞추기 수월했을 것 같습니다. 또한 "코드를 리팩토링할 수 있는 시간적 여유로 확보할 수 있지 않았을까?" 하는 아쉬움이 있습니다.
  
  

• mis-communication: 오프라인이고 온종일 같이 있기 때문에 소통이 원활하게 이루어진 것 같이 보인다고 생각합니다. 만약 온라인 혹은 재택근무라고 가정해본다면 소통에 문제가 분명히 있었을것 같습니다. 우리가 프로젝트를 어떻게 진행하였는지 정확히 다시 바라보고 온라인이라고 가정하여 생겼을 문제들을 재정의하고 다음 프로젝트에는 어떻게 action point를 잡고 나아가질지 정리해보려고 합니다.

• documentation : 무엇을 문서화할지 정확히 정하지 않고 시작하다 보니 프로젝트를 진행하다가 불편함을 느낀 적이 많습니다. 또한 자신이 한 일을 한눈에 파악할 수 있도록 문서화하는 능력을 더욱 길러야겠다는 것을 알게 되었습니다.

  action point 👇

  • 프로젝트 프로세스에 대한 문서화하기

  1. 기본적인 규칙 (변수명,함수명, commit 규칙 등등)들을 문서화로 정리하지 않아서 서로 다른 방식으로 중구난방으로 코드를 작성한 점.
  2. 노션을 활용하여 공유문서를 만들고 우리만의 프로세스 규칙들을 프로젝트 시작하면서 정리해놓으면 좋을 것 같습니다. 혹시 문제를 발견하거나 바뀌기 이전 프로세스가 적혀있다면 확인을 한 인원이 즉시 고쳐 다른 사람들에게 동일한 혼란이 가는 것을 방지하면 좋겠습니다.

• advance preparations : 미팅 시작하기 전 자신이 어제 한 일과 오늘 할 일을 정리해보는 시간을 갖는 것이 이상적이며 당연하였으나 종종 아무것도 적혀있지 않을때가 많았습니다. 그로 인해 자신이 마주한 블로커나 오늘 할일에 대한 구체적인 계획이 공유되지 않아 일이 밀리고 기한을 지키지 못하는 경우가 생긴 것 같습니다.

  action point :

  • 최소 10 - 20분 정도는 차분히 정리해보는 시간 권고

  1. 스탠드업 미팅의 의미와 역할을 팀원과 같이 생각해보는 시간을 가지면서 어떤 자세로 준비할지 이야기를 통해 방향성을 잡고 프로젝트에 임한다면 더 나은 프로젝트의 결과와 함께 좋은 팀이 꾸려질 수 있을 것 같다.

• Leave completed tickets alone : Notion을 이용하여 티켓을 관리하였습니다. 총 5단계로 backlog -> This sprint -> In progress -> In review -> Done으로 나누어 팀 안에서 규칙을 정해 관리하였습니다. PR작성 후 merge가 완료된 티켓임에도 불구하고 in progress에 있었고 이미 진행 중인 업무인데 This sprint에 붙어있는 경우가 잦았습니다. 티켓 관리를 제대로 이루어지지 않다는 것은 한주의 Sprint 전체 계획이 잘 이행되고 있지 않다는 증거이기도 할 것이고 또한 소통이 원활하게 이루어지지 않았다는것을 보여주는 하나의 현상이라고 생각합니다.

  action point :

  • 티켓으로 업무 진척도를 파악하기
    아직 우리가 기획 단계 이후 개발 초기 단계에 만들어놓은 티켓들을 활용하지 못한 것 같습니다. 한주의 Sprint 미팅 시간에도 티켓을 활용하여 객관적인 수치를 가지고 진행한 것이 아닌 자신의 감정과 주관을 드러내어 아쉬운 미팅이었습니다. 아직 티켓에 대한 중요성을 인지하지 못한 것이 아닌지에 대해 생각해보았습니다.

• A time constraint : 8일이라는 짧은 기간 안에 꽤 완성도 있는 웹사이트를 만든다는 것이 쉽지는 않았습니다. 시간적이 제약이 있어서 프로젝트의 보이는 웹사이트는 잘 만들었다고 할지라도 코드의 완성도를 높이지 못한 게 너무 아쉽습니다. 프로젝트 기간이 끝났지만 컴포넌트 구조를 다시 생각해보고 어떻게 컴포넌트의 재사용성을 높여 만드는지에 대한 고민을 시작하려고 합니다. 또한 실제 배포까지 해보면서 전반적인 경험을 하려고 계획하고 있습니다.

  action point :

  • 추석 연휴 중 월 화 수 목 프로젝트 회고 및 리팩토링 진행 예정

  1. 기본적인 변수명, 함수명에서부터 시작해서 컴포넌트의 구조와 재활용이 가능한 컴포넌트로 바꿔보려고 합니다.

• different naming convetion
  왜 변수명을 잘 지이어야하는지... 왜 함수명을 잘 지어야하는지에 대해 정확히 깨달은 프로젝트였습니다. 프로젝트 중 후반에 돌입하면서 점차 바빠지고 할 일이 많은 가운데 상향 평준화를 위해 코드 리뷰를 진행하였습니다. 너무 바쁘기 때문에 코드 리뷰에 사용할 수 있는 시간은 30분 남짓이었습니다. 동료의 코드를 살펴보는데 한줄 한줄 마다 계속 그 변수의 의미를 물어보고 함수의 역할을 다시 물어보면서 불필요한 소통이 늘어나는 것을 보았습니다. 그러다 보니 시간이 부족하게 되고 점점 동료 리뷰하는데 시간을 쓸 수 없을 정도로 우선순위가 낮아지는 현상을 보았습니다.

  action point :

  • 프로젝트 시작 전에 변수명 함수명 규칙을 정확히 세웁니다.
  • 스스로 변수명 함수명을 짓는 데 있어 정확한 규칙을 세워 좋은 습관을 형성하는데 시간을 투자해야겠다는 것을 알게 됐습니다.