첫 프로젝트 회고를 이제야 작성하다니..
전에는 회고글은 기록하는 용도라고 생각했었는데 막상 다른 팀 프로젝트를 해보니 같은 문제점이 보이는 걸로 보아 전체적인 팀 프로젝트에 대한 객관적인 시선으로 회고를 꼭 작성하는 시간을 가져야겠다고 생각이 들었다.
1. 내가 선택한 회고 방식
- 내배캠에서 알려준 KPT 회고 방식이다.
KPT 회고란?
Keep, Problem, Try
지속할 것, 문제가 될 것, 다음에 시도할 것
각 시간에 맞춰 다음 목록을 진행하며 회고하는 방식이다.
시간은 50분 정도로 진행되며 만약의 상황에 대비해 10분 정도 여유를 가지자. 진행 순서는 아래와 같다.
- KPT에 대해서 설명 : 5분
- Keep, Problem 작성 : 5분
- 각자 작성한 Keep, Problem 공유 : 10분
- Try 작성 : 7분
- 각자 작성한 Try 공유 : 8분
- 팀 및 프로젝트에 활용할 Try & Action 선정 : 15분
참고 자료: https://www.designsori.com/zero/1157702
혼자서 하는 게 아닌 팀끼리 하는 것이나 팀끼리는 이미 한 번 진행했었고 이제는 혼자서 팀 프로젝트를 되돌아보며 KPT를 작성하는 방식으로 회고글을 이어 나갈 생각이다.
2. KPT
1) Keep, 지속해야 할 것
- 레퍼런스 공유, 팀원과의 소통(에러사항, 아이디어 등)
먹고하조 팀에서 제일 많이 했던 것 중 하나가 (기능 관련 제외) 팀원끼리 모르는 것에 대해 공유하고 같이 방법을 찾아가며 관련 레퍼런스를 서로 주고 받는 것 그리고 팀 프로젝트가 끝난 것과는 별개로 우리의 프로젝트를 개선할 수 있는 방법에 대해 소통한 것이다.
나는 아이디어가 참 부족한 사람인걸 알고는 있었지만, 팀 프로젝트를 진행 하면서도 꽤 느꼈다..ㅎ
아이디어가 넘치는 사람은 본받아야해!
2) Problem, 문제가 될 것
- 협업 방식, 규칙 관련
처음으로 팀 프로젝트를 했던 것도 있지만 개발 직종은 어떤 식으로 협업하는지 알 수 없었고 (그래도 깃헙 관한 협업은 성공적으로 했다ㅎㅎ) 설령 안다고 해도 우리는 프론트와 백으로도 나눌 수 없고 기능별로 크게 분업할 수 없는 상황이니 정확히 어떤식으로 역할 분담을 해야하는지에 대해 몰라서 답답했다.
그리고 맨 처음에 여러 규칙들을 정하고 한다던대(예를 들어 변수명, 깃헙 커밋, 통일된 css - 폰트, 색상 등) 알 수가 없었으니 서로서로 기능 구현에만 달려들어서 내가 짠 코드도 못알아봤다 ㅋㅋㅋ
튜터님에게 달려가서 기능 구현에 대해 질문했을때 튜터님이 대충 치신 코드만 봐도 우리의 코드는 꽤 지저분했고, 코드를 뒤엎고 싶다는 생각까지도 들었다 ㅎㅎ 존경스러워요 튜터님
쓰다보니 이건 경험의 차이도 큰 것, 열심히 배운 만큼 코드의 질에서도 티가 나겠지?
3) Try, 다음에 시도할 것
- '문제가 될 것'에서 서술한 것들을 고쳐나가는 것
- 많은 아이디어를 찾아볼 것
- 레퍼런스 공유
- 팀원들에게 에러 사항 바로 바로 공유
- 규칙 정하기
