Good
- 프로젝트 기간에 좋았던 것들을 적어주세요.
- 우리가 만든 사이트, 프로젝트에 큰 애정이 생긴것같다. 이것 하나만으로도 성공적인 팀 프로젝트였다고 할수 있을것 같다. 왜 이런 애정이 생긴걸까에 대해서 생각해보면.. 팀원들간의 소통이라고 생각한다. 짤이몽땅이라는 하나의 사이트를 주제로 정말 수많은 이야기를 해가며, 짤이몽땅이라는 사이트를 만들어갔다.
- 기한의 코앞에서는 제대로 이루어지지 않았지만, 전체적으로 코드리뷰가 잘 이루어진 편인것같다. 스크럼 진행후에 1시간씩 코드리뷰를 하는 시간을 가졌고, 이로인해 코드의 오류를 다수 줄일수있었고, 프로젝트의 진척도를 인지해가며 진행이 가능했다.
- 100%라고 할수는 없지만 이슈작성과 커밋의 세분화가 잘 이루어진 편인것같다.
Bad
- 프로젝트 기간에 아쉬웠던 것들을 적어주세요!
- 프로젝트가 진행되는 동안의 스크럼은 아직도 부족한점이 많았다. 스크럼 룰이 확립되기전에는 정돈되지않아 어수선한 느낌이 들어 많은 얘기는 했지만 정리된게 없었고, 룰이 확립되어지고 나서도 각자가 읽어보아도 확인 할수 있는 내용을 확인하는 그런 상투적인 스크럼이 되지않았나라는 생각도 든다.
- 중간 회고에서도 적었지만 미흡한 문서화는 크게 개선되지 못했던것같다. 최소한 회의록만큼은 꾸준히 작성했어야하지 않았을까라는 아쉬움이 든다.
- 어쩔수없는 부분이라고도 생각하지만, 기한의 막바지에 이르러서는 코드리뷰나 이슈작성이 전처럼 이루어지진 못했다. 막바지까지도 팀원들과 계속해서 디스코드에서 상주하며 진행해서 코드 추가사항이나 수정사항에 대해서 자연스레 파악하고 있지만, 그렇지 못한 상황이었다면 자칫 프로젝트의 흐름을 놓칠수도 있는 문제가 발생할거라 생각한다. 현업에서는 이러한 다급한 상황속에서 어떻게 대처할까??
[KPT 회고란]
Keep
- 좋았던 점 중에서 다음에도 유지하고 싶은 것들을 적어주세요.
- 이번 팀 프로젝트의 가장 큰 장점은 바로 모든 팀원들의 적극적인 대화, 의견 제시였다고 생각한다. 적극적인 참여도와 의견제시는 프로젝트의 완성도를 높여줄수있을뿐만 아니라, 각 팀원들이 프로젝트의 흐름, 진행사항을 파악할수 있게 해주고, 이는 곧 효율적인 작업으로 이어진다고 생각한다.
- 코드리뷰를 병행한 PR또한 프로젝트의 완성도와 follow up에 큰 효과를 주었던것같다.
Problem
- 아쉬웠던 점에서 실제로 문제로 발생했던 것들을 적어주세요.
- 기획에서 개발로 넘어가는 부분이 매끄럽지 않았던것같다. 조금 더 지체되지 않고 개발을 시작할수 있는 방법이 있지 않을까..? ( 기획시에 개발 프로세스에 대한 틀 정립 등)
- 다운탑 방식의 컴포넌트 제작은 초반 개발진척에 어려움을 주었다. 프로젝트의 기획기간이 부족하여 상세한 부분까지의 기획이 이루어지지않은 상황속에서 다운탑 방식으로 개발을 진행하는것은 효과적인 방식이 아니었다. base 컴포넌트에서 고려하지 못한 부분이 너무나 많았고, 불완전한 base 컴포넌트나 hook를 무리하게 사용하려하며 허비한 시간이 많았다.
- 3주간 온전히 프로젝트에만 시간을 쏟았다. 이는 곧 체력저하로 이어질것이고, 장기전이 되었을때는 되려 비효율적인 시간소요가 많아질수있다. 조금더 시간적으로 체계적인 프로젝트 진행계획을 짤 필요성이 느껴진다.
Try
- Keep 사항 중에서 한단계 더 발전하기 위해 시도해볼 것들을 적어주세요.
- Problem 사항 중에서 문제를 예방하기위해 시도해 볼 것들을 적어주세요.
- 코드리뷰를 병행한 PR또한 프로젝트의 완성도와 follow up에 큰 효과를 주었던것같다.
→ 리뷰없이 merge를 진행할때도, comment를 통해 변경사항을 명확히 기록해둔다.
- 고정된 스크럼시간을 정한다. 팀원들간의 약속시간을 좀 더 명확하게 잡아야 체계적인 진행이 가능할것이다.
- 세부적인 기획이 수립되지 않은 상황에서는, 다운톱방식이 아닌 톱다운 방식으로 개발을 진행해본다.
- 코드리뷰에 대한 조금더 상세한 룰 정립이 필요하다
- 내용적인 부분에서는 상투적일수 있지만, 충분히 개선되어졌던 쓰레드였다