KPT 회고
앙골라 팀 회고
K : 현재 만족하고 있는 부분, 앞으로도 유지하고자 하는 부분
- 작업 내용 문서화 및 활발한 공유
- 이슈 공유 규칙과 같은 소통 규칙 설정 및 활용
- 적극적이고 배려하는 의사소통, 긍정적인 분위기
- 개발 및 코드 컨벤션 명확히 정하기
- 팀 문화 형성 및 적극적인 교류
- 팀 안에서의 역할 지속적으로 생각해보기
P : 불편하거나 아쉽게 느끼는 부분, 앞으로 개선이 필요한 부분
트러블 슈팅 문서화 부족
- 팀원들과 공유할 수 있는 문서화 툴에 트러블 슈팅 문서를 만들어두고 이슈가 발생했을 때의 과정과 해결 방법을 문서화해두어 동일한 트러블을 직면했을 때 보다 빠르게 대응할 수 있도록 하기
- 문제 상 발생 시, 문제 상황, 진행 과정, 해결 방법 등 자세하게 기록
코드 리뷰, QA에 시간을 충분히 할애하지 못함
- QA를 진행할 때, 예상되는 예외 상황을 리스트업 한 후 하나씩 실험하며 진행하기
- 전체적인 일정을 설정할 때, 버퍼를 두고 딜레이되는 상황에 대비하기
- QA에 시간과 인풋을 더 투자하기
멘토님 중간 피드백 반영 미흡
- 반영하지 못한 멘토님의 피드백을 기준으로 지속적으로 리팩토링하여 새로운 지식들을 학습하고 프로젝트의 품질을 향상시키는 데 노력하기
- 다음 프로젝트 때 적극적으로 팀원과 이야기해 보는 시간을 가져서 피드백 받은 부분을 반영하기
모바일 대응에 미흡
- 모바일 대응을 가장 우선으로 고려하여 웹 페이지 제작
기능 구현에 급급해 코드의 완성도를 높이지 못함
- 리팩토링하며 코드의 완성도 높이기
- 코드의 구조를 충분히 생각하고 개발 시작하기
핵심 기능 문서 (PR) 에 대한 정리 및 리마인드가 필요함
- 중요 문서가 업데이트 되면 다시 리마인드 하기
- 중요한 PR 문서와 코어 역할을 하는 문서들은 책갈피 페이지를 만들어 링크하기
- 특정 기능을 만들 때, 봐두어야 하는 문서들 기능 별로 분류하기
T : 잘하고 있는 것을 더 잘하기 위해, 당장 시도해 볼 부분
- 팀 스프린트를 나눈 후 개인적인 업무를 한 번 더 체계적으로 나누기
- 문서화를 적극적으로 활용하여 팀원에게 공유하기 (트러블 이슈, 코드 개선 등)
- 다른 팀원이 담당한 부분도 “자신의 일”이라고 생각하기
- 프로젝트 코드 다시 훑어보며 이해하지 못한 부분 이해하고, 정리하기
- 어떻게 해야 팀원들이 편하게 개발할 수 있을까를 생각해보기
- 문서화 체계적으로 진행하기 (기능 별로 문서 분류)
- 중요 슬랙은 링크하거나 캡처해서 같은 문서 내에 정리하기
앙골라 개인 회고
K
김영준
Keep
- 적절한 개발 컨벤션을 정한 것이 서로가 무엇을 개발하고 있는지 쉽게 파악할 수 있게 되어 중복되는 코드를 작성하지 않는 데에 도움이 된 것 같다.
- 일정 시간이 지체되면 팀원들에게 즉시 이슈를 공유하는 점이 개발 시간을 빠르게 단축할 수 있었던 것 같다. 또한 자신이 담당한 역할이 아닌 부분에서 발생하는 이슈도 함께 고민하고 해결하는 과정에서 좀 더 성장하는 계기가 되었던 것 같다.
- 이렇게 항상 즐거운 분위기 속에서 협업을 진행했다는 점이 놀라웠다. 물론 훌륭한 팀원분들을 만난 덕분일 것이지만, 적극적인 소통, 타인에 대한 배려, 그리고 긍정적인 분위기를 유지하는 것이 큰 역할을 한 것 같다. 이러한 성향을 갖춘 사람에 가까워질 수 있도록 노력하여 앞으로의 협업도 이런 유쾌하고 즐거운 분위기 속에서 개발을 하고 싶은 마음이다.
Remind
- 전체 팀원이 프로젝트를 시작하기 전에 커밋 형식, 브랜치 전략, 개발 및 코드 컨벤션들을 명확하게 정하기
- 슬랙을 통해 이슈 공유에 대한 규칙을 만들고 적극적으로 활용하기
- 적극적인 소통, 타인에 대한 배려, 긍정적인 분위기가 중요하다는 것을 항상 인지하고 이러한 사람에 가까워질 수 있도록 노력하기
김주하
Keep
- 팀 문화를 잘 형성함으로서 팀에 대한 소속감과 프로젝트에 대한 애정을 증대할 수 있었다. 팀원들의 앙골라 캐릭터를 만든다거나 코어타임에 지각 할 시, 커피를 사는 것 등 약간의 오락적인 요소들도 한 번 더 팀원들과 소통을 하게끔 만들어 팀 분위기를 잘 조성시켜주었다.
- 팀원 간 원활한 의사소통은 사소한 마찰도 방지시켜주었다. 자신의 의견은 적극적으로 어필하되 돌아오는 피드백을 적극 검토하고, 상대를 배려하며 의사소통이 진행되었던 것이 너무 좋았다. 이는 내가 팀 내에서 적절히 의견을 표출할 수 있게끔 만들었고, 화기애애한 팀 분위기를 이끌어낼 수 있었다.
- 팀 개발 문화와 문서화 작업은 프로젝트 작업에 큰 도움을 주었다. 개발 문화를 정함으로서 헤메이지 않고, 빠르게 개발을 진행할 수 있었고, 통일성을 가질 수 있었다. 또한 논의된 것들을 문서화함으로서 놓치는 부분을 바로 잡을 수 있었고, 이전에 진행했던 내용들도 계속 참고할 수 있어 개발에 큰 도움을 주었다.
Remind
- 적절한 팀 문화를 형성하여 소속감을 가지고, 팀원들과 많이 교류하기
- 타인에 대한 배려와 원활한 의사소통을 할 수 있도록 노력하기
- 팀의 개발 문화와 컨벤션을 정하고, 문서화에 최선을 다하기
박민우
Keep
- 팀원들 모두 최대한 상대방의 기분을 상하지 않게 하고 팀 분위기를 해치지 않도록 서로를 배려하며 의사소통하려는 것이 느껴져 좋았다. 무엇보다 팀원들에게 고맙거나, 미안한 일이 있다면 평소보다 더 적극적으로 고맙거나 미안한 마음을 나누었고, 이는 더욱 평화롭고 즐거운 팀 분위기를 만들었던 것 같다.
- 팀 안에서 팀원들 모두 자신이 할 수 있는 일을 적극적으로 찾아서 해주었다. 누구 하나 시키지 않았는데도 자신의 능력에 맞게 디자인 담당을 자원해준 팀원, 문서화를 담당해준 팀원, 자신의 태스크가 일찍 끝나 공통적인 부분을 구현해주는 팀원들이 있어서, 프로젝트의 진행 속도가 더욱 빨라질 수 있었다.
- 자세한 PR 내용 공유 및 적극적인 코드 리뷰를 통해 팀원들 모두 프로젝트에 대한 전반적인 이해도가 높았고, 이를 바탕으로 특정 팀원에게 이슈가 발생하면 다함께 이슈에 대해 고민하고 비교적 빠르게 해결할 수 있었다.
Remind
- 말하기 전 한 번 더 생각하며, 서로를 배려하는 의사소통 하기
- 팀 안에서 자신이 할 수 있는 역할 지속적으로 생각해보기
- 자세한 PR 내용 공유 및 적극적인 코드 리뷰
이지윤
Keep
지난 중간 회고에 이어서 프로젝트가 마무리될 때까지 잘 지켜지고 있는 부분들이어서 다음 프로젝트 때도 유지하고 싶은 부분들이다.
우리는 모두 하나라는 인식과 Problem 대처 규칙을 세워 문제상황이나 궁금한 점을 바로바로 공유할 수 있는 환경을 만든 점이다. 혼자 끙끙 고민하고 있으면 해결되는 것은 없고, 시간만 지체되기 때문에 바로바로 팀원들과 의사소통하는 것이 효율적이었다. 같이 이슈에 대해 상의하다 보면 새롭게 알게 되는 내용도 많았다.
또한 데일리 스크럼 규칙을 세워서 팀원들의 진행 상황을 파악하고 이슈 등을 공유할 수 있는 환경을 만든 점이다. 이 또한 팀원들이 현재 어떤 업무를 진행하고 있고, 공유하고 싶은 이슈들은 무엇인지 한눈에 파악할 수 있어서 좋았다.
Remind
팀 프로젝트 시작 전에 팀 문화를 정하고 시작하여 팀원 간의 원활한 의사소통이 잘 되었던 것 같다. 또한 팀원들 모두 서로의 의견을 존중해 주는 분위기도 한몫했다. 다음 프로젝트에서도 이번 경험을 바탕으로 좋은 팀 문화를 만들어 가고 싶다.차세진
Keep
모두 머릿속으로 같은 그림을 그리면서 기능을 구현하였고, 작은 것부터 하나씩 꾸준히 공유해왔기 때문에 문제가 발생했을 때 자신이 맡은 일이 아니더라도 각자의 솔루션을 제시할 수 있었다. 즉, 함께 하려는 꾸준한 노력들 덕분에 문제나 이슈가 발생해도 다섯명이 머리를 맞대어 효율적으로 해결할 수 있었다.
이렇게 되기 까지는 활발한 문서화와 슬랙 커뮤니케이션도 크게 작용했다.
프로젝트 개발 과정들을 스크럼 문서나 개별 문서에 꼼꼼히 기록해왔고, 대부분의 이슈 공유가 슬랙에서 이루어져 이전 과정들을 팔로우업해서 현재 문제를 해결하는 것이 수월했다.
추가적으로, ‘팀’ 이라는 소속감을 주는 장치들도 팀 문화의 하나라고 생각한다. 예를 들면 다같이 앙골라 아이콘을 프로필 사진으로 한다던 지.. 재미로 했던 일이지만, 이런 장치들 덕분에 ‘팀의 일이 나의 일’ 이라는 책임감을 더 많이 가질 수 있었다.
Remind
- 꾸준한 공유를 통한 효율적인 문제 해결
- 작업 과정 문서화
- 이슈 공유는 기록에 남도록 슬랙에서 소통
- 팀 정체성, 소속감을 주는 장치 마련
P
김영준
Fact
기능 구현에 급급해서 팀원들의 코드 리뷰를 꼼꼼히 하지 못했다.
Problem
추후 발생하는 문제에 대해 예상하지 못했고 최종 발표 전 날에 급히 코드를 수정하는 일이 발생했다.
Solution(Action Item)
- 코드 리뷰를 보다 꼼꼼하게 진행
- 다른 사람의 코드를 많이 접하기
Fact
반복되는 이슈들에 대해서 매끄럽게 대처하지 못했다.
Problem
동일한 이슈임에도 불구하고 이슈를 해결하는 데 시간을 많이 소요했다.
Solution(Action Item)
- 팀원들과 공유할 수 있는 문서화 툴에 트러블 슈팅 문서를 만들어두고 이슈가 발생했을 때의 과정과 해결 방법을 문서화해두어 동일한 트러블을 직면했을 때 보다 빠르게 대응할 수 있도록 하기
Fact
중간 회고 때 멘토님의 피드백을 받았지만 모든 피드백을 반영하진 못했다.
Problem
앙골라 프로젝트에서 React-Query를 도입하여 사용하는 중이었고, 해당 라이브러리에서 제공하는 useInfiniteQuery를 활용하여 무한 스크롤을 구현하여 보다 여러 인터페이스를 추가적으로 따로 구현할 필요가 없음에도 일단 기능을 구현하는 데 초점을 두어 기존의 Intersection Observer를 사용한 무한 스크롤 코드를 수정하지 않았다. 또한 React 18에서 도입된 Suspense를 로딩 처리에 적용해 보라는 멘토님의 피드백도 실제 코드에 반영하지 못했다.
Solution(Action Item)
- 반영하지 못한 멘토님의 피드백을 기준으로 지속적으로 리팩토링하여 새로운 지식들을 학습하고 프로젝트의 품질을 향상시키는 데 노력하기
김주하
Fact
모바일 대응에 미흡하였다.
Problem
데스크탑 위주의 개발을 진행하였다. 반응형을 구현하긴 했지만 우선순위에서 벗어나 있었다. 그러다보니 모바일에서 UI가 깨지는 현상이 꽤 많이 있었다. 배포 후, 홍보를 위해 지인들에게 URL 주소를 뿌리면 95%는 모바일로 접속하여 볼 것이다.
Solution(Action Item)
모바일 대응을 가장 우선으로 고려하여 웹 페이지 제작
Fact
QA 기간이 짧아서, 예상치 못한 버그에 대처가 늦었다.
Problem
프로젝트 마지막 날에 다 함께 최종 테스트 중, 예상치 못한 버그를 발견하였다. 이 버그를 해결하느라 예정된 일정이 늦춰졌다. PR리뷰가 꼼꼼하지 못했다고 생각할 수도 있지만, 팀원 모두가 PR리뷰를 100% 완벽하게 할 수는 없다고 생각된다. 우리는 1차 QA만 진행하였지만, 조금 더 QA 기간과 횟수를 늘리고 꼼꼼하게 진행한다면 충분히 사전에 문제를 발견할 수 있을 것 같다고 생각된다.
Solution(Action Item)
QA에 시간과 인풋을 더 투자하자.
Fact
트러블 슈팅을 정리하지 않아 반복되는 문제에 추가적인 시간을 소요함
Problem
프로젝트 진행 중 많은 문제들과 마주하였는데, 개발하는데 조급하여 이러한 문제들을 문서화해두지 않았다. 이는 반복되는 문제가 생겼을 때, 기억이 나지 않아 다시 해결해야하는 상황이 종종 발생되었다.
Solution(Action Item)
마주한 오류들에 대한 트러블 슈팅을 문서화해두자
박민우
Fact
반복되는 문제 상황에 대한 트러블 슈팅 문서화를 하지 못한 것
Problem
각자 개발하며 문제 상황을 마주했을 때, 눈 앞의 문제를 해결하는 것에 조급하고 급급했기 때문에 이를 자세한 기록으로 남기지 못했다. 문제 상황을 해결했다는 것도 중요하지만, 막상 해결하고나니 이를 기록으로 남기지 못한 것이 아쉬웠다. 프로젝트가 모두 끝나고 트러블 슈팅 문서를 작성하려고 하니, 기억도 가물가물하고 자세한 과정이 기억나지 않았다.
Solution(Action Item)
문제 상황이 발생 시, 이를 캡처하거나 녹화해 문제 상황, 진행 과정, 해결 방법 등을 자세하게 기록
Fact
기능 구현에 급급해 코드의 완성도를 높이지 못한 것
Problem
기간이 정해져있는 프로젝트였기에, 최우선순위는 정해진 기간안에 주어진 요구사항을 모두 구현하는 것이었다. 그래서 특정 기능들은 처음부터 구조나 효율성을 생각하고 설계하기보다는 요구사항대로 동작하도록 구현하는 데 초점을 맞추게되었다. 하지만 이는 추후 컴포넌트의 비즈니스 로직을 분리하거나 부가 기능을 추가하는데도 어려움을 주었다. 덕분에 오히려 시간을 더 많이 잡아먹는 일이 발생했다. 처음부터 코드의 구조를 좀 더 생각하고 개발을 진행했다면 추후 개발이 많이 수월해지지 않았을까 하는 아쉬움이 남는다.
Solution(Action Item)
코드의 구조를 충분히 생각하고 개발 시작하기
리팩토링하며 코드의 완성도 높이기
이지윤
Fact
트러블 슈팅 문서화를 하지 않았다.
Problem
동일한 문제 상황이 발생했을 때, 문서화를 해두지 않아 기억에만 의존하여 빠르게 해결하지 못했다.
Solution(Action Item)
다음 프로젝트 진행 시에는 미리 트러블 슈팅 양식을 만들어 놓아서 동일한 문제 상황이 발생했을 때, 빠르고 효율적으로 대응할 수 있도록 해야겠다.
Fact
기능 구현에 앞서서, 멘토님의 피드백(중간 회고, 기획서)을 적극적으로 반영하지 못했다.
그래도 프로젝트 구조나 비즈니스 로직 hook으로 추상화, page 레벨에서는 조합하는 형태로 피드백을 반영해 본 것은 좋았다.
Problem
피드백을 주고받음으로써 배우는 점이 큰데 놓친 것 같아 아쉬웠다.
Suspense 활용이나 유틸 함수 jsDoc 주석 등 활용해 보지 못했다.
Solution(Action Item)
앙골라 프로젝트 리팩토링을 해보면서 반영해 보거나 다음 프로젝트 때는 적극적으로 팀원과 이야기해 보는 시간을 가져서 피드백 받은 부분을 반영해 보고 싶다.
차세진
Fact
코드 리뷰, QA 등의 과정을 거쳤음에도 불구하고 찾아내지 못했던 버그가 있었다.
Problem
마지막 배포 일정 중에 버그를 발견했고, 예상했던 것 보다 일정이 딜레이 되었다. 코드 리뷰나 QA를 통해서 내가 충분히 발견할 수 있었음에도 불구하고, 늦게 알아차린 점에서 반성했다. QA 에 다른 과정을 추가해볼까 하는 생각이 들었다.
Solution(Action Item)
- QA 를 진행할 때, 예상되는 예외 상황을 리스트업 한 후 하나씩 실험하며 진행하기
- 전체적인 일정을 설정할 때, 버퍼를 두고 딜레이되는 상황에 대비하기
Fact
이거 저도 저번에 이랬는데.. 이거 제가 저번에 작성했었는데.. 하는 내용들이 많았다.
Problem
공유와 소통을 상당히 많이 하더라도, 일정에 맞추어 기능 개발에 집중해야하기 때문에 누군가 리마인드를 해주거나 보이는 곳에 문서를 만들지 않는 이상 모든 것을 기억하기는 어려웠다.
따라서 지난 내용들을 다시 공유하거나, 문제를 다시 해결해야하는 경우가 종종 있었다.
Solution(Action Item)
- 중요한 PR 문서와 코어 역할을 하는 문서들은 책갈피 페이지를 만들어 링크하기
- 특정 기능을 만들 때, 봐두어야 하는 문서들 기능 별로 분류하기
- 중요 문서가 업데이트 되면 다시 리마인드 하기
T
김영준
Fact
코드 리뷰, 이슈 대처, 그리고 피드백 미반영과 같은 문제들은 결국 기능 구현에 너무 집중하여 시간에 대한 관리가 미흡했던 탓에 발생했던 것 같다. 3차 팀에서는 기능 구현 이외의 작업에 대해 충분한 시간을 할애하기 위해 일정을 잘 분리하는 데에 신경을 써서 프로젝트의 완성도를 높일 수 있도록 임해야겠다.
프로젝트를 진행하면서 팀원들로부터 좋은 영향을 많이 받았다. 이러한 긍정적인 영향을 3차 팀에 그대로 반영하여, 팀 내에서 원활한 협력과 소통이 이뤄질 수 있도록 의견을 적극적으로 제시하고, 팀의 이슈에 대해 적극적으로 해결하는 모습으로 임하여 프로젝트에 많은 도움을 주는 팀원이 되도록 노력해야겠다.
Solution(Action Item)
- 팀 스프린트를 나눈 후 개인적인 업무를 한 번 더 체계적으로 나누기
- 문서화를 적극적으로 활용하여 팀원에게 공유하기 (트러블 이슈, 코드 개선 등)
- 의견을 적극적으로 제시하기
김주하
Fact
- 하나의 문제 상황이 발생하였을 때, 팀원 모두가 자신의 일처럼 생각하며 해결하려고 노력하였다. 이는 문제 상황을 매우 빠르게 해결해주었고, 효율성을 높여주었다. 나는 다른 팀원들에 비해 이러한 부분이 조금 더 부족한 것 같다. 분배되어진 업무여도 모두 자기 일처럼 관심을 가지는 노력이 더 필요하다고 느꼈다.
- commit을 최대한 자주 하려고 노력했다. 하지만, 막상 개발하게되면 commit을 잊어버리거나 여러 코드를 건들여서 commit을 분리하기 애매한 상황이 자주 있었다. 조금 더 세분화해서 commit을 진행해야된다고 생각되었다.
Solution(Action Item)
- 팀 내에 생기는 모든 이슈에 관심을 가지고, 해결하려고 노력하기
- commit을 세분화하여 자주 하기
박민우
Fact
어떤 프로젝트를 하던, 내가 담당한 부분뿐만 아니라 다른 팀원들이 담당한 부분도 모두 “팀의 일”이라고 생각하며 적극적으로 이해하려고 노력하는 자세가 필요함을 느꼈다. 프로젝트 후반으로 갈 수록 담당하는 태스크의 양이 많아지면서 다른 팀원들의 코드를 이해하지 못한 부분도 생겼다. 다른 팀원의 코드를 보면서 성장할 수 있다는 것을 온몸으로 느꼈던 프로젝트이기에, 아직 살펴보지 못한 부분들도 꼭 이해하고 좋은 패턴이나 다음 프로젝트에도 적용할 수 있을 만한 부분들이 보인다면, 이를 온전히 내 것으로 만들어보려고 노력해야겠다.
Solution(Action Item)
- 다른 팀원이 담당한 부분도 “팀의 일”이라고 생각하기
- 프로젝트 코드 다시 훑어보며 이해하지 못한 부분 이해하고, 정리하기
이지윤
Fact
더욱 더 적극적인 자세를 가져야겠다. 이번 프로젝트를 하면서 팀원분들의 열정적인 자세를 보고 깨우친 바가 많았다. 다음 프로젝트에서는 과도한 걱정보다는 열린 자세로 프로젝트에 임해야겠다. 많이 배우고 부딪혀 봐야 하는 시기이다!
Solution(Action Item)
다음 프로젝트 진행하기 전에 3차 팀원들과 간단한 토이 프로젝트를 일주일간 진행하기로 했다.
일주일 동안 새로운 기술이나 코드들을 쉬지 않고 부딪혀 보면서 익숙해지도록 연습하자!
차세진
Fact
현재 진행 상황과 문제 상황 공유에 적극적으로 임해야 겠다. 처음부터 하나의 일을 같이 한다는 생각으로 진행하는 것이 좋았기 때문에, 3차 팀에서도 같은 자세로 임하고 싶다.
팀원들이 개발할 때 드는 리소스들을 어떻게 해야 줄일 수 있는 지 고민해봐야겠다. (예를 들면 문서화, 리마인드 등등)
Solution(Action Item)
- 협업은 적극적으로 임하기 (내 일이라고 생각하면 자동으로 적극적)
- ‘도와준다’라는 느낌이 아니라, ‘같이한다’라는 느낌이 들게 소통하기 (내 일이기도 하니까!)
- 어떻게 해야 팀원들이 편하게 개발할까 도 생각해보기
- 문서화 체계적으로 진행하기 (기능 별로 문서 분류)
- 중요 슬랙은 링크하거나 캡처해서 같은 문서 내에 정리하기
- 코드 스니펫… 생각해보니 gitignore 에 막힘 ⇒ 다음엔 이러지 말자!