경미
Keep
- 팀 프로젝트에 대해 경험해 볼 수 있어서 좋았다. 문제 아닌 문제 상황을 겪고 도움도 요청해 보면서 오히려 더욱 많이 배울 수 있었던 프로젝트가 아니었나 싶다.
- 협업태도에 대해 서로 이야기 나누고 어떤 시간을 공유하고 어떻게 앞으로 프로젝트를 해나갈지에 대해 정한 것이 좋았다. 이미 정해진 규칙이 있었기에 고민하는 시간을 줄일 수 있었다고 생각한다.
- 브랜치전략, PR양식, 커밋컨벤션, eslint, stylelint 같이 협업을 위한 컨벤션과 툴들에 대해 많이 알게되고 경험해 볼 수 있어서 좋았다.
- 피그마를 활용한 와이어프레임 제작 및 프로토 타입 제작으로 서로 화면에 대한 이해를 높일 수 있었고 회의를 할때도 이야기하는 바를 바로 보여줄 수 있었기 때문에 소통하는데 있어서 편리했다.
- 리액트를 이해하고 익히는 것을 목표로 PR을 통해 코드를 리뷰하고 merge하는 협업 방식이 좋았다. 후반에가서는 일정에 쫓겨 제대로 리뷰 하지 못했지만 그래도 서로의 코드를 리뷰하고 이해 하려고 노력했다.
Problem
- 각 기능이 어떤 API가 필요한지 파악 하고, 주어진 API가 어떤 데이터를 주고 받는지에 대한 분석이 부족해 개발 중 해메는 시간이 있었다.
- 기능의 우선순위를 보다 bottom-up 방식을 적용해 UI 먼저 구현하자는 방법으로 계획보다 일정이 지연되어 진행 되었지만 멘토링을 통해 우선순위를 설정하고 작업을 진행하면서 많이 개선 되었다고 생각 한다.
- 규칙이나 만들어야 하는것에 대한 내용은 정리가 되어 있었지만 작업 단위 분배나 진행도를 파악할 수 있는 문서화가 되어있지 않아 전체적인 프로젝트 진행도를 파악 하거나 각자의 상황을 파악하기 힘들었다.
Try
- 협업을 위해 사용한 컨벤션, 전략, 툴에대한 이해가 부족해 제대로 적용하지 못한 부분이 많았다. 더 공부해서 팀과 상황에 맞는 전략이나 방법을 도입해보고싶다.
- 기획 단계에서 프로젝트의 기능들을 정의하면서 우선순위를 설정해서 그것에 맞춰 작업 순서와 단위를 나누는 방법을 생각해 봐야 겠다.
- 상세기능을 정의할 때 필요한 API 요청과 응답을 같이 문서에 정리해 두면 개발 중 문제파악이 더 쉬워질 것 같다.
- 주기적인 진행상황 공유 이번 프로젝트를 통해 진행상황나 문제상황을 공유하는 것에 대한 중요성을 깊이 느꼈다. 회의나 스크럼의 주기를 명확히 해서 서로 상황을 공유하는 것이 필요 할것같다.
- 작업을 분담할때는 역할 목표를 명확히 하여 공유하고 진행도를 파악할수있게 문서화를 하려고 한다.
사휘
K
- 최초 세웠던 계획에 차질이 생겨 계획을 중간에 수정해야 했는데, 수정한 계획에 대해서는 대부분 수행했다.
- 개인적으로도, 팀적으로도 프로젝트 진행에 있어 어려움을 겪을 때 늦지 않게 도움을 요청하여 적절하게 대처할 수 있었다.
P
- 프로젝트를 통해 성취하려고 했던 최우선 목표를 항상 최우선 순위로 간주하지 못하여 중간 중간 진행 순서를 결정할 때 확신을 갖지 못했다.
- 팀적으로 최고의 효율을 낼 수 있는 팀원 역할 분담이 이루어지지 않았다고 생각한다.
- 코드에 오류가 너무 많았다는 것을 알고 있었음에도 시간적 여유가 없어서 해당 오류를 수정하며 진행하지 못했다.
- Issue로 생성해놓은 task의 진행 상황에 대해서 follow up이 꼼꼼하게 이루어지지 않았다.
- PR한 코드에 대해서 리뷰가 꼼꼼하게 이루어지지 않았다. 따라서 merge 이후에도 빈번하게 내용 수정이 이루어졌다.
- 겪었던 문제 상황 및 해결 방안에 대해 체계적으로 정리해두지 않았다.
T
- 프로젝트 진행과 관련된 여러가지 방법론을 설정하는 데에 있어서 사전에 조사 기간을 충분하게 갖는다. 최대한 다양한 방식을 알아보고 각각의 장단점을 구체적으로 파악하고 나서 프로젝트에 도입한다.
- 프로젝트 진행을 시작하기 이전에, 프로젝트에 대한 팀원 각자의 이해도와 수행 능력, 환경 등을 보다 세밀하게 파악하여 프로젝트 진행에 있어서 개인에게 특화된 task를 부여한다. 이로써 프로젝트의 전체 진행 상황에 차질이 발생하는 것을 최소화 한다.
- 스크럼 시간에 나눌 이야기에 대해서 구체적인 목록을 사전에 마련해둔다. 따라서 특정 내용을 빠트려 뒤늦게 해당 내용에 대해서 추가적인 회의를 하는 상황이 발생하는 것을 방지한다.
- 자신의 작업 수행 상황을 표시하는 칸반보드에서 task를 최대한 구체적으로 작개 쪼개고, 진행 상황을 철저하게 최신화하여 프로젝트의 진척도를 명확하게 확인할 수 있도록 한다. 매 회의 시간에 이 부분을 확인하는 절차를 추가한다.
정민
Keep
- 서툴렀지만 그래도 팀프로젝트를 통해서 하나의 웹을 만들어보니 내가 이 프로젝트에서 목표하던 바를 어느정도는 이뤘다고 생각한다. 웹을 만들기 위한 전체적인 과정을 직접 겪고, 또 겪으면서 나에게 부족한 점(hook사용, context등)들을 알 수 있었다. 질문을 하는 것도 처음엔 어려웠지만 그래도 조금씩 해보니까 익숙해지는 것 같다. 더 많이 팀원들과 공유하고 소통할 수 있도록 노력해야겠다.
- git issues를 사용한 점이 좋았다. 우선순위를 정해서 issue에 등록해 놓으니까 프로젝트의 진행도와 다음에 어떤 일을 해야할지 파악하기 쉬웠다. 이전의 방식보다 훨씬 가시적이어서 파악에 용이했다.
- 멘토님께 피드백 받은 후로 기능 우선 개발로 바꾼 후 단기간에 주요 기능 사항을 구현하는 데에 성공했다.
- 코드 짜면서 막힐 때가 많았는데 경미님과 사휘님이 도와주셔서 많은 부분 해결할 수 있었다. (문제 상황 공유 및 서로 도와주기)
- eslint, stylelint, prettier, commitizen으로 프로젝트 초기에 코드 컨벤션을 맞춰서 코드를 통일성 있게 작성할 수 있었다.
Problem
- PR을 자세히 작성하지 못했다. 사휘님께서도 지적해주셨는데 구현이 되면 올리기 바쁘다보니 PR을 보다 자세히 적는데에 소홀했던 것 같다.
- 기본적으로 나의 개발역량이 많이 부족했다고 생각한다. 리액트 강의라도 많이 듣고 시작했다면 좀 더 나았을 것 같은데 코드 리뷰, 코드 이해나 작성에 있어서 시간이 더 걸리고 좋은 코드로 짜지 못했다.
- Git을 다루는 것에 아직 서투르다. 가끔 develop에서 pull받은 후 브랜치에서 pull받다보면 충돌이 나는 경우라던가 다른 경우에 충돌이 날 때가 종종 있었는데 어떻게 해결해야하는지 잘 몰라서 팀원들의 도움을 많이 받았다.
- 질문할 때 더 정리해서 질문하기. 종종 급하게 생각치 못하게 질문할 때가 있었는데 그 때 스스로도 정리가 안돼서 소통이 원할하게 되지 않을 때가 있었다.
- 구현 자체가 급하다보니 hook 사용이라던지 보다 좋은 로직으로 짜지 못한 점이 아쉽다.
- 역할을 분담하긴 했지만 난이도가 한사람에게 편향되는 부분이 있었던 것 같다.
Try
- 앞으로 PR 작성할 때는 이 코드를 처음 보는 사람이 쉽게 파악할 수 있도록 로직을 간략하게라도 적도록 해야겠다.
- 리액트를 전반적으로 복습해서 정리해야겠다. 최종 프로젝트 전까지 남은 시간동안 최대한 지식을 채워야겠다.
- Git에 대한 전반적인 학습도 필요한 것 같다. 전체적인 흐름과 사용법들을 다시 한 번 익혀야겠다.
- 급하게, 말하고 있다고 질문하지 말고 스스로 질문을 정리하는 시간을 꼭 가져서 명확하게 질문해야겠다.
- 이해하지 못하고 지나간 부분이나, 문제 부분 적어두기!