[Node.js_4기] 팀 프로젝트 회고 : KPT + 프로젝트 회고 (24/03/25)

목차

 

1. 문제

2. 시도

3. 결과

4. 배운점

 

1. 문제 

 

자세한 내용은 보충 TIL로 배운 내용을 정리할 생각입니다.

이번주, 최종 프로젝트가 시작되기 때문에...

SA가 통과되고, 업무 분담까지 끝날 때 까지는 이번 프로젝트로 TIL을 작성하게 될 것 같습니다.

 

2. 시도 

 

Nest.js를 사용하여 

Trello(칸반보드 툴) 클론 코딩을 하였습니다.

ERD

이전의 프로젝트들과 비교하면 스키마의 수가 확실히 많이 늘어났습니다.

그만큼 기능들도 많아졌고, 스키마간의 연결도 늘어나 기능 개발에 어려움이 있었습니다.

 

3. 결과 

• 사용자 관리 기능 ( - 기능에 영향을 주는 Entity: [&: 강한 연결, (&): 약한 연결])
  • 로그인 / 회원가입 기능 - User(o)
  • 사용자 정보 수정 및 삭제 기능 - User(o )
• 보드 관리 기능
  • 보드 생성 - Board(o)
  • 보드 수정
    • 보드 이름 - Board(o)
    • 배경 색상 - Board(o)
    • 설명 - Board(o)
  • 보드 삭제 - Board (&) User
    • 생성한 사용자만 삭제를 할 수 있습니다.(o)
  • 보드 초대 - Board & Invite & User
    • 특정 사용자들을 해당 보드에 초대시켜 협업을 할 수 있어야 합니다. (o)
• 컬럼 관리 기능
  • 컬럼 생성
    • 보드 내부에 컬럼을 생성할 수 있어야 합니다.
    • Column (&) Board (o)
    • 컬럼이란 위 사진에서 Backlog, In Progress와 같은 것을 의미해요. (o)
  • 컬럼 이름 수정 - Column (o)
  • 컬럼 삭제 - Column (o)
  • 컬럼 순서 이동 - Column & Board
    • 컬럼 순서는 자유롭게 변경될 수 있어야 합니다.(o)
      • e.g. Backlog, In Progress, Done → Backlog, Done, In Progress
• 카드 관리 기능
  • 카드 생성 - Card (&) User
    • 컬럼 내부에 카드를 생성할 수 있어야 합니다. (o)
  • 카드 수정
    • 카드 이름 - Card (o)
    • 카드 설명 - Card (o)
    • 카드 색상 - Card (o)
    • 작업자 할당 - Card (o)
    • 작업자 변경 - Card (o)
  • 카드 삭제 - Card(o)
  • 카드 이동
    • 같은 컬럼 내에서 카드의 위치를 변경할 수 있어야 합니다. - Card & Column(o)
    • 카드를 다른 컬럼으로 이동할 수 있어야 합니다. -Card & Column (o)
• 카드 상세 기능(김동원)
  • 댓글 달기 - Comment & Card & User
    • 협업하는 사람들끼리 카드에 대한 토론이 이루어질 수 있어야 합니다.(o)
  • 날짜 지정 Card
    • 카드에 마감일을 설정하고 관리할 수 있어야 합니다. (o)

팀원들과 

위의 기본 기능들을 모두 구현했고,

redis를 사용해여 캐싱을 구현했으며,

s3에 image파일을 올려 서버로 가져오는것,

테스트코드 작성(은 실패) 시도,

git action을 사용하여 ci까지는 완료(테스트코드 제외)

아쉽게도 

 

4. 배운점 

 

KPT 회고

 

팀장
K - 빠른 업무 프로세스
P - 전반적으로 에러 등 예외에 발목잡히는 시간이 너무 길었음, 이로 인해 불필요하게 소모된 시간이 상당히 존재함
T - 에러 등의 예외 상황에 대한 구체적인 대응 메뉴얼을 만들고 이를 팀원들이 지킬 수 있도록 할 필요가 있어 보임

팀원1
Keep: 어디까지 했는지 현황 체크했던 부분이 일정 관리면에서도 좋았던 것 같다.
Problem: 최종 api 테스트 하는 것을 한분이서 하셨는데 생각해보면 너무 한 사람한테만 과중한 업무를 부담시킨 것 같다는 생각이 들었다.
Try: 테스트 하는 건 여러명이서 분담하는 식으로 하던가, 아니면 화면공유해서 테스트 돌려보면서 문제 생기면 바로바로 해당 api 부분 작성한 팀원이 피드백 주는 식으로 하면 좀 더 수월하지 않을까란 생각을 해봤다.

나
keep
깔끔하게 나뉘어서 충돌이 없었던 업무 분배와 진척 사항 체크
problem
서로의 코드에 대한 설명은 부족했던 것 같다. 필요할 때 질문하는 방식이 아니라, 주기적으로 서로의 코드에 대해 설명하는 시간이 필요했던 것 같다.
try
테스트 코드를 완성해서 ci/cd 과정까지 진행해보기

팀원2
KEEP
새로운 기술을 사용해본 점
작업 시간이 늦어졌는데 팀원 분들이 배려해주신 점 (감사합니다...)
PROBLEM
고칠 수 없는 에러라는 판단 하에 해결보단 작업을 이어나간 점, 결과적으로 작업이 지연됨
TRY
개발 환경이 달라 리팩토링이 필요했는데,
어떤 기술을 적용할 때, 동일한 환경에서 개발이 진행될 수 있도록 설치 및 세팅 방식을 문서화하는 방법도 좋을 것 같다는 생각이 들었다.