Portfolio

회고 방식 - KPT 회고 + 피그잼(툴)

스타트업 개발팀의 애자일 회고 방법론 KPT - 실전편 | KPT 도입에 대해서 많은 관심을 받다. 지난주에 작성한 KPT하는 스타트업은 성장한다 글에 굉장히 많은 반응이 있었다. 실제로 비슷한 방법으로 팀 내 회고를 하고 있다는 분도 있었고, 자세히 듣고 싶다고 연락을 주시는 분들도 있었다. 지난 글에서는 KPT 도입과 효과에 대해서 작성하였다면 이번에는 실제로 팀 내 적용 방법에 대해서 작성할 예정이다.

https://brunch.co.kr/@fromjayden/8

Action Item (최종)

🌱

problem을 해결할 수 있는 action 뽑아내기

Type 통일

Issue에 할 일을 구체적으로 작성 (만약 Issue에 작성하지 않은 로직을 작성하면 롤백 시킨다.)

Issue 할 일에 적지 않은 부분은 hurryUp 브랜치 파세요 ← hurryUp 라벨도 붙여주세요

다른 사람 작업과 연결되는 부분은 그 분과 논의하기(공통 인터페이스 정의 후 작업)

Lazy Import & Suspense 적용

테스트 코드를 작성한다. → UI 컴포넌트와 비지니스 로직 분리 후 자동화 테스트를 진행해 본다.

관심사 분리하기

View ⇒ 컴포넌트

로직

utils : hooks 안쓰는 로직
custom hooks: hooks 쓰는 로직

🫂 최종회고

수화

Keep 💎

바쁘더라도 코드리뷰를 열심히 주고,받은 점!! (일정에 쫓겨서 반영 다 못한 부분도 있는데, 시간쪼개서 리뷰검토받고 머지해서 마음이 쪼금 편안했음)

프로젝트 회고하는 것! 플젝은 해봤어도, 회고는 해본 적이 없었는데..회고의 필요성을 느꼈음(다음 플젝에선 꼭꼭 회고의 시간을 넣을 듯)

Problem ⚠️

한 브랜치에 다른 여러작업이 섞이는 것. pr단위도 커지고,코드리뷰하기가 어려워짐. (자잘한 수정은 이슈만들고 브랜치파서 작업하는 게 비효율적인 거 같아서 하나씩 추가하다보니..이런 결과로 이어지는 거 같음)

본인이 하는 작업 중, 재사용할만한 로직, 컴포넌트를 미리 작업해서 올리고, 이후 작업을 하는 게 좋은 거 같음(안그러면 다른 팀원이 만들어놨지만 dev에 없어서 또 만들게 되거나 팀원들에게 만들었는지 물어봐야하니까 불필요한 커뮤니케이션 비용이 생기는 거 같음)

Try 🧪

본인이 하는 작업 중, 재사용할만한 로직, 컴포넌트를 미리 작업해서 올리기(재사용할 것을 미리 회의를 통해 정하고, 작업 분담하면 되지 않을까? 언제나..작업 분담하는 건 쉽지않은 듯 😢)

컴포넌트는 view만 담당하고, 다른 로직/비동기 분리하도록 작업하기 (hooks 안쓰는 로직은 utils, 쓰면 custom hooks로 나누는 건 어떨까?)

칭찬 💜 shot out

일정이 굉장히 타이트했는데, 모두 자기가 맡은 일을 주어진 시간 내에 해낸 점!! (코드는 리팩토링하면 되니까..시간 내 구현한 점을 칭찬합니다)

플젝 기간이 끝나도 다들 리팩토링 하겠다는 열정이 좋다!! 더 더 개선해봅시다 !!

별

Keep 💎

서로 모르는 부분이 있으면 같이 해결하려고 노력하는 모습이 좋았습니다.

프론트 5명이서 협업을 진행한 건 처음인데 분담을 적절히 해서 완성한 것 같습니다. 소통하는 과정이 시간이 오래 걸리더라도 정말 중요한 듯!

Problem ⚠️

이슈와 관련 없는 부분까지 구현해서 올리는 것. 이 때문에 pr 머지 하는 과정에서도 충돌이 많이 발생한 것 같습니다.

코드 리뷰 하면서도 이 부분이 왜 이 브랜치에..? 했던 순간이 종종 있었습니다.

급하니까 우선 머지하고 보는 것 → 코드 리뷰의 의미가 사라지는 느낌..

Try 🧪

이슈에 적힌 기능만 구현하기! 추가할 부분이 생기면 다른 이슈 파서 진행하기.

조금 비효율적이라 생각되더라도 협업의 일환이라 생각하고 감수하는 게 좋을 것 같습니다.

이제 시간이 넉넉하니까 코드 리뷰 꼼꼼히 진행하고 반영하는 과정 거치면 좋을 것 같습니다~

칭찬 💜

맡은 부분을 완성도 있게 해오려고 했던 팀원들 모두 칭찬합니다 👍 바빠도 항상 꼼꼼하게 코드 리뷰해 준 수화 언니가 일등 공신..👍

누구 하나 빠짐없이 열심히 참여한 덕분에 프로젝트 기한 안에 성공적으로 마무리할 수 있었던 것 같습니다!

이제 리팩토링 꾸준히 하면서 코드 퀄리티 높이고 자랑할 만한 프로젝트가 되었으면 좋겠습니다✨

천욱

Keep 💎

더 나은 코드를 위해 고민하고 팀원들과 서로 코드리뷰를 주고받은 것이 많은 도움이 되었다.

또 프로젝트 기획할 때 욕심내지 않고 완성도 있는 프로젝트를 목표로 잡았기 때문에 기간안에 완성된 프로젝트를 제출했다는 것에 큰 만족을 느꼈다.

Problem ⚠️

한 브랜치를 만들어서 작업하는 범위가 좀 애매한 부분이 있었던 것 같다.

예를 들어서 로그인 상태를 확인한 후에 네비게이션 바에 “로그인” or “로그아웃” 표시를 해주는 작업은 큰 기능이 아니기 때문에 다른 기능을 하다가 하는 김에 한번에 해버리는 경우가 있었다.

이런게 쌓이다 보면 하나의 브랜치에 작업물이 많아지고 코드리뷰도 길어지는 현상이 발생한다.

Try 🧪

Problem에서 말한 문제 해결은…

우선 어떤 (사소한)부분들을 보완해야하는지 기록을 해놓고 5개 정도씩 묶어서 작업하는 방법도 좋을 것 같다.

물론 이슈에도 어떤 작업들을 할 것인지 적고 pr을 보낼때도 자신이 한 작업들을 잘 정리해서 보내면 코드리뷰의 시간을 좀 더 줄일 수 있을 것 같다.

칭찬 💜

소피아님 말씀처럼 기간안에 제출하는 것이 아주아주 중요하다고 말씀해주셨는데 나영팀 모두 기간안에 제출하기 위해 노력한 모습 너무 칭찬합니다~ 👍

건오

Keep 💎

프로젝트 기획도 꼼꼼히 하고 그에 따라 프로젝트 진행을 하면서 초반에 시간을 많이 들인 것이 좋았다고 느꼈다.

새로운 기술도 적용해보면서 프로젝트가 잘 돌아가는 것을 보고 만족했습니다.

Problem ⚠️

한 브랜치에 너무 많은 코드를 작성하고 다른 팀원들의 코드도 pull 받아서 하니 코드 리뷰할 때 팀원들이 너무 고생했다😂 또한 기능만 돌아가도록 코드를 짜서 리팩토링할 게 너무 많아졌다.

Try 🧪

코드를 작성할 때, 먼저 공통된 부분이나 자주 쓰일 것 같은 코드는 따로 빼서 작성해야겠다고 느꼈다.

프로젝트 기한을 지키려고 몇가지 지나친 기능들도 채워나가며 더 완성도 있는 프로젝트를 만들어 나가야겠다.

칭찬 💜

처음으로 issue, pr도 꼼꼼히 적어보고 코드리뷰도 하면서 팀원들에게 많은 도움을 받았다.

서로 비밀없이 다 얘기해주고 개선할 점도 바로 말해줘서 프로젝트가 원활하게 진행되었던 것 같습니다

앞으로 꾸준히 리팩토링하면서 프로젝트 개선도 하며 lighthouse 점수도 올려 나중에 포트폴리오에 개선했던 경험도 채워나갑시다 🏃

명재

Keep 💎

코드 리뷰를 통해 궁금한 점, 개선할 점에 대한 소통을 원활하게 한 부분이 추후 리팩토링 과정에서도 지속되면 좋겠다. (물론 마감 기간에 다다르면서 리뷰를 소홀히 했지만…)

github Issue로 작업 단위를 관리하면서 놓치는 부분을 최대한으로 줄일 수 있어서 리팩토링 과정에서 조금 귀찮을 수 있는 부분이지만 쭉 진행하면 좋겠다.

Problem ⚠️

하나의 공통 Type 파일에서 모든 Type을 관리하다 보니 불필요하거나 중복되는 Type이 많이 존재한다.

컴포넌트의 UI 로직과 비지니스 로직이 분리되지 않아서 가독성도 떨어지고 중복되는 로직이 많이 보인다.

Try 🧪

리팩토링전에 테스트 코드를 작성하고 리팩토링하는 과정을 가졌으면 좋겠다.

불필요한 컴포넌트까지 렌더링하는 문제를 해결하면 좋겠다. (lazy import)

칭찬 💜

팀원 모두가 잠을 줄이면서까지 목표로 정한 기능을 구현한 점 칭찬합니다!!

팀원 대부분이 리팩토링하겠다는 의지를 보이면서 HIT 프로젝트에 대한 애정이 보여서 감동이었습니다. 리팩토링하면서 더 발전해보자구

Action Item

🌱

problem을 해결할 수 있는 action 뽑아내기

도움되는 자료 슬랙에 자료 공유하기 - 어떤 자료인지도 설명

관련되는 자료 댓글 많이 활용

react-query 도입하기 - 리팩토링 기간

2개 이상 중복되면 공통 컴포넌트로

ex) CategoryList → CategoryListSection / profileSection

각자 네이밍하도록ㅋㅋㅋ - 눈치껏 통일

플랭크와 함께하는 회의 시간

utils 폴더에서 constants.ts 분리하기

Api 폴더 이름 바꾸기(Api → api)

❣️ 중간회고

수화

Keep 💎

pr단위랑 코드리뷰 정도(?)가 딱 적절한 거 같다. 이전에 첫 팀플할 땐, pr단위도 너무 컸고, 코드리뷰도 엄청 빡빡하게 해서 구현속도가 늦었는데..현재는 pr단위도 UI, 기능별로 쪼개서 올려서 코드리뷰하기 좋다!

Problem ⚠️

코드리뷰할 때 어디에 집중할지 정하면 좋을 거 같다. 현재 데모버전에선 성공로직만 보기로 했는데..어쩔 수 없이 디자인도 보게되고..다른 것도 보다보니 리뷰시간이 길어진다.

디스코드에서 채팅을 많이하는데, 디코보단 슬랙에 자료 공유하기! 공유할 땐, 어떤 자료인지 간략히 적어두기! 또, 슬랙의 스레드 - 댓글 구조를 잘 이용하면 좋을 거 같다

매번 고민하는 문제, 코드 퀄리티 vs 시간 → 시간이 정해진 플젝인만큼, 퀄리티의 욕심을 버리자! (RegisterInput으로 만드느라 은근 시간씀..ㅠ)

Try 🧪

recoil 써보고 싶었는데, 지금까지 써보질 않았다. 써볼 일이 생겼으니 공부해서 적용해보자!

비동기로직을 어떻게 처리하는 게 깔끔할지 아직도 고민된다. react-query를 도입하기로 했으니, 이용법을 찾아봐야겠다.

각자 작업하다가 알게 된 것들 공유하는 시간/공간이 있으면 좋을 거 같아요!!

칭찬 💜

나 자신

알고있는 정보를 슬랙에 문서화해서 공유한 점! (git/github, postman)

건오님의 부지런함

목요일 마무리했을 때부터, 내일 뭐해야할지, 회의록까지 적어두는 부지런함)

명재님의 꼼꼼함

center태그가 쓸 수 없는 태그인지 처음 알았음..(사실 center태그의 존재도 처음 알았단 건..비밀)

천욱님의 든든함(?)

빠른 작업 + 새벽까지 디코에 있어서 새벽작업할 때 든든합니다!

별님의 센스

회의하다 기록해둘 부분이 있으면, 누구보다 빠르게 노션에 기록해주시는 점 (센스최고👍)

별

Keep 💎

코드 리뷰나 issue를 관리하면서 체계적으로 프로젝트를 진행하는 건 처음인데 처음엔 좀 헤맸지만 나름 적응해서 잘 진행하고 있는 것 같습니다!

팀원들끼리 코드 리뷰를 하면서 진행하니 각자의 진행 상황과 코드 로직 등을 이해하고 넘어갈 수 있고, 서로의 코드를 보면서 배울 수 있어서 좋은 것 같습니다.

Problem ⚠️

기능 구현에 집중해서 코드를 깔끔하게 작성하고 있지 못하다는 점입니다. 현재 코드에서 공통 컴포넌트로 뺄 수 있는 등 리팩토링 해야할 부분이 많이 보이는 것 같습니다.

배포에서 많이 헤매고 있는데 다시 집중해서 해결해 보는 과정이 필요할 것 같습니다. → 지금 맡은 부분들 마무리하고 화요일이나 수요일에 deploy 브랜치로 재시도?

Try 🧪

앞으로 작성하는 코드부터라도 분리할 수 있는 부분은 분리하고 깔끔하게 작성하도록 노력해야겠습니다..

수요일까지는 기능 구현을 마무리하고 리팩토링을 하는 시간을 가지면 좋을 것 같습니다!

칭찬 💜

팀원 모두 너무 열심히 참여해 주고 있고, 각자의 성향이 다른 부분 덕분에 더 시너지가 나고 있는 것 같습니다.

또 처음에는 회의 시간도 길고 의견이 통일되지 않는 느낌이 있었는데 요즘은 회의나 개발에 있어서도 속도가 많이 빨라져서 각자가 모두 성장했다는 생각이 듭니다!

열심히 참여하는 팀원들을 보면서 많이 배우고 있습니다. 다들 조금만 더 힘내서 프로젝트 잘 마무리합시다!

건오

Keep 💎

완벽하지는 않지만 전에 사용해보지 않았던 새로운 기술들을 두려워하지 않고 시도해보는 용기가 생겼고 issue, pr 템플릿도 만들어 보며 github와 조금 더 친해지고 있는 느낌을 받아 조금씩 성장하고 있다고 생각이 듭니다.

Problem ⚠️

팀원들과 함께 짠 규칙을 더 잘 지키고 좋은 코드가 무엇인지 많이 생각해보는 시간을 가지면 좋겠다고 생각합니다. 또한 끝까지 포기하지 않고 문제를 해결하는 끈기를 가져가야 겠다고 느꼈습니다. 마지막으로 리팩토링은 나중에 라는 안일한 생각을 버리면 좋겠습니다.

Try 🧪

문제가 당장 해결되지 않아도 계속해서 해결책을 찾고 여러 시도를 해야겠습니다. 상태 관리에 대해 깊이 이해하고 recoil을 사용해 봐야겠습니다. 지금 당장 전역으로 사용되는 상태가 없다고 생각하지만 다시 한번 코드를 쭉 훑어보며 상태 관리가 필요한 부분도 찾고 더 나은 코드로 개선할 수 있도록 시도해야겠습니다.

칭찬 💜

우리 월수화목금 팀원들이 함께 아이디어를 말해보고 기획부터 개발까지 모든 과정을 함께 하면서 협업이 얼마나 중요한지 깨닫게 해주었습니다. 어려움을 겪고 있을 때마다 적극적으로 해결해주고 작은거 하나라도 공유하는 점을 꼭 칭찬하고 싶습니다~ 마지막 스퍼트 가자~ 🏃

천욱

Keep 💎

리액트+Typescript, TailWind, Vite등 새로운 기술들을 많이 접할 수 있어서 좋았고, Git에 대해 더 많이 알게 되어서 이 부분이 가장 만족스럽습니다. Git flow를 직접 경험해보면서 Git사용에 대한 자신감이 생긴 것 같습니다.

서로 코드리뷰를 해주면서 더 나은 코드를 작성하는 환경을 꾸준히 이어갔으면 좋겠습니다. 미쳐 생각하지 못했던 부분들을 짚어주고, 상대방의 코드를 보고 배울 수 있는 점이 좋은 것 같습니다.

Problem ⚠️

선택과 집중이 지금보다 더 개선되었으면 좋겠습니다. 팀원 모두가 의욕적이다보니 회의시간이 생각보다 길어진 경우가 많았습니다. 회의시간을 정해서 꼭 필요한 얘기들만 하고 비동기 소통을 많이 활용하면 좋겠습니다.

Try 🧪

useHook을 사용해보고 싶습니다. 리액트의 큰 장점이라고 생각하는데 이번 프로젝트도 익숙한 hook들만 사용했던 아쉬움이 있습니다. 남은 기간동안 useHook을 만들어서 현재 코드에 적용해보고 싶습니다.

칭찬 💜

프로젝트 기획하고 코딩컨벤션, 기술스택 결정할때 시간이 많이 소모되고 ~~거기서 살짝 시작도 전에 지쳤었지만~~ 초반에 많이 얘기하고 정했던 덕분에 개발속도는 빠르게 진행 될 수 있었던 것 같아요~ 협업 처음해보는 Git린이한테 많이 알려주셔서 팀원분들 너무 고맙습니다! 최종 배포까지 열심히 달려봅시당 월수화목금 화이팅! 🤩

명재

Keep 💎

팀원들 서로 코드를 공유하면서 코드 컨벤션을 지키기 위해 노력하면서 코드의 가독성이 올라가고 코드 리뷰를 통해 지키지 못했던 규칙을 서로가 보완하는 점이 남은 프로젝트 기간 동안 지속해서 유지되면 좋겠다.

Problem ⚠️

기능 구현과 질 높은 코드라는 두 가지 선택지를 항상 고민하면서도 기간의 제한이 있다는 점에서 기능 구현에만 더욱 집중하게 되고 있다. 두 가지 모두를 가져갈 수 있는 방법에 대해 고민해보고 지속해서 균형를 유지해야 한다고 생각한다.(이게 근데 너무 어려움… 🥹)

Try 🧪

비지니스 로직과 UI 로직, util 함수 로직을 역할에 맞게 분리하기

module을 가져오는 순서를 정하기

utils 폴더에서 constants.ts 분리하기, Api 폴더 이름 바꾸기(Api → api)

칭찬 💜

팀원들 모두 맡은 역할에 책임을 다해 프로젝트를 진행하고 있다. (그래서 나도 잠자는 시간을 줄였다…🥹) 또한 소통을 통해 오해를 만들지 않고 팀원들 모두가 원하는 최종 기획가 구현이 일치 선상에서 이어져 가고 있다. 당연히 지켜야 할 부분이라는 생각이 들 수 있지만 꾸준히 소통하지 않았으면 분명 기획가 다른 모습이었다고 나는 생각한다. 우리 팀 수다쟁이들~😜 물론 나 포함…