-Today's Learning Content-

• KPT 회고

---

1. 프로젝트를 마치며...

내용 정리

오늘은 프로젝트의 최종 마감일로, 프로젝트를 마무리하고 발표까지 마쳤다.
지난 일주일을 회상해보며 아쉬운 점, 좋은 점 등에 대해 KPT를 작성해 보았다.

1) Keep

• 유지했으면 하는 점: GitHub Issues 활용, 마일스톤 체크 및 준수, 정기적인 팀 스크럼, 적극적인 소통
• 잘한 점: 프로젝트를 시작하기 전에 대략적인 설계와 와이어프레임 설계를 통해 앱의 전반적인 내용을 구축한 점

이번 프로젝트를 진행하며 팀원을 너무 잘 만났다고 생각했고,
다들 열심히 열정적으로 프로젝트에 임해주신 덕분에 나도 더 열정을 내서 할 수 있었던 것 같다.
활발히 소통하며 마일스톤 등을 통해 서로의 진행상황, 어려운 점 등을 공유하며 작업을 진행하니 프로젝트의 전체적인 흐름도 파악할 수 있었고, 배워가는 점도 많았다고 생각한다.

지금까지 몇 번의 프로젝트를 겪은 덕에 점점 협업에서의 내 역할, 팀워크를 위해 중요한 점 등 어떻게 하면 팀 활동에 기여할 수 있고 영향력을 행사할 수 있는지 알아가고 성장을 하게 된 것 같다.

2) Problum

• 문제점: 코드 리뷰의 부족함, 소통 이슈, 스케줄 조절 실패
• 해결방안:
  • 마일스톤을 적극 활용하여 각 팀원별 스케줄과 프로젝트의 전체 스케줄을 파악할 수 있도록 하고, 상시 체크하여 데드라인에 문제가 되지 않을지 검토.
  • 시간이 없다는 핑계로 PR을 대충 넘기지 않고 부족한 시간도 사용해서 적극적이고 유의미한 코드 리뷰를 작성.
  • 팀원과 이야기한 내용이 서로 다르게 이해하지는 않았는지 재확인

제일 아쉬웠던 부분은 코드 리뷰이다.
이번에 프로젝트에서 MapKit이라는 라이브러리도 이용하고 API도 사용하며 다양한 기술 스택을 사용했는데, 내가 맡은 영역이 아니다보니 접할 수 있는 기회는 팀원들의 PR 밖에 없었다.
그런데도 프로젝트의 구현 때문에 시간이 없다는 핑계로 코드를 제대로 읽지 않고 넘긴 것이 후회가 된다.
조금 벅차고 힘들더라도 팀원들의 코드를 보며 배우고, 프로젝트를 더욱 잘 이해할 수 있는 기회였는데 스스로 그 기회를 져버린 것이다.

이번 후회를 경험으로 삼고 다음 프로젝트에서는 아무리 시간이 없고 바빠도 의미 있는 코드 리뷰를 할 수 있도록 노력해 보자고 생각했다.
이를 위해 하루에 시간을 정해서 그 시간 동안은 PR에 대한 리뷰만 하는 식으로 스케줄을 조정해 보자고 생각했다.

3) Try

• 아쉬운 점: 하고 싶은 것이 많았던 것에 비해 스케줄 조절에 실패하여 필수 기능을 구현하는 데에도 급급하여 깔끔한 코드를 작성하지 못하고, 서로의 코드를 적극적으로 리뷰하지 못한 점

위의 의견과 겹치는 부분이 많다. 역시 코드 리뷰가 제일 아쉽고, 구현하고자 했던 기능들, 구현 하고 싶었던 기능들을 다 구현하지 못한 것에 대해 아쉬움이 남는다.
내가 좀 더 잘 했다면, 좀 더 빨랐다면, 실수하지 않았다면 이라는 생각이 드는 것 같다.
그러나 한 편으로는 내가 하고싶은 기술이라고 해서 무작정 시도하고 다 해보는 것은 팀 프로젝트의 의의와 멀어지는 일이라고 생각한다.
당연히 하고싶은 기능이 있어도 팀원들과 협의를 거쳐야 한다고 생각하고, 팀 목표가 프로젝트의 필수 기능 구현이 우선시 된다면 이를 따르는 것이 옳다고 본다.
그런 면에서 생각해보면 이번 프로젝트는 적어도 목표는 달성했기에 성공적으로 끝냈다고 말하고 싶다.

이번에 아쉬웠던 점들은 어떻게 하면 해소할 수 있을지 계속 고민해보며 다음 프로젝트에서는 아쉬움이 남지 않도록 노력해야겠다고 생각했다.

4) 결론

이번 프로젝트를 진행하며 초반에는 문제가 없었지만, 중반-후반으로 갈 수록 문제가 튀어나왔다.
중간에 데이터 모델이 바뀌거나 구조가 바뀌는 등 많은 변화가 있었기 때문이다.

변화가 많았다는 것은 초기 설계가 불안정 했다고 생각한다. 완벽한 설계는 없겠지만, 적어도 최선의 설계를 해야 불필요한 로스를 줄일 수 있고 프로젝트를 더욱 효율적으로 진행할 수 있을 것 같다는 생각을 하였다.

결국 중요한 것은 팀원들과 충분히 협업하며 초반 설계를 탄탄히 하고, 적극적인 코드 리뷰와 소통을 통해 문제점이 없는지 진행은 잘 되는지 확인하며 정해둔 마일스톤을 준수할 수 있도록 노력한다면, 아쉬움이 덜 남는 프로젝트를 진행할 수 있다고 생각한다.

-Today's Lesson Review-

블로그의 소개글도 그렇고, 지금까지는 '의미 있는 코드'를 작성하자고 생각했다.
그러나 팀 프로젝트를 여러번 겪으며 생각하는 것은
좋은 개발자는 코드를 잘 쓰는 개발자가 아니라는 것이다.
1인 개발이 아니라면 결국 협업을 하게 될 것이고, 이 때 필요한 능력은
의미있는 코드를 작성하는 능력이 아니라
'활동에 의미를 만드는 능력'이라고 생각한다.
그래서 앞으로는 의미 있는 코드를 쓰는 것이 목표가 아닌
내가 하는 모든 행동과 말에 '의미를 만드는 사람'이 되는 것이다.