개인 회고록
1차 프로젝트 회고록 -엄윤성
팀 회고록
😃 Keep
“1시간내에 해결이 안되면 도움을 청하는 문화”
문제가 발생했을 때 또는 이해가 안되는 부분들이 있을 때,
1시간 동안 혼자서 해결이 되지 않는다면
팀원들에게 물어보는 문화는 좋은 문화인 듯 하다.
알려주면서 더 배우고, 또 모르는 부분들은 다른 팀원에게 배우면서
실력이 향상되는 경험을 여러번 했다.
“문제 발생시 즉시 공유하는 문화”
사람은 누구나 실수 할 수 있다.
다만 우리는 모든 실수로부터 배울 수 있는데, 실수를 숨기거나 공유를 하지 않으면
팀원간의 오해를 불러 일으킬 수도 있고, 때론 프로젝트 안에서 더 큰 문제를 발생시킬 수도 있다.
해서 문제가 발생 할 시 즉시 슬랙에 공유하는 문화는
팀원 개개인에게도 프로젝트에게도 효율적인 방법이었다.
“이슈를 열고 해당 이슈기반으로 브랜치를 하여서 개발하는 로직”
먼저 이슈를 봄으로써 현재 어떤 것들이 필요한지 알 수 있었고
해당 이슈번호로 브랜치를 생성하기 때문에
특정 문제에 대한 코드를 보고 싶다면 해당 번호로 만들어진 브랜치를 찾으면 되기에 간편했다.
“오픈 및 종료 스크럼”
처음 스크럼을 통해서 어떤 것들을 개발할 지 정하고, 개발 후에는 스크럼을 통해 마무리 하는 것이
서로의 진행 상황을 알 수 있었기 때문에 다음날 프로젝트를 진행할 때 원활히 시작할 수 있어서
공유차원에서는 나쁘지 않았다고 생각한다.
🥲 Problem
“코드리뷰”
처음 브랜치 머지 룰을 정할 때, 최소 코드리뷰 2명 이상 받고 확인하는 룰이 있었다.
프로젝트 마감시간이 다가올수록 각 자 할일이 많아지고 코드리뷰가 더뎌졌다.
그래서 코드 리뷰를 제대로 하지 못하고 approve를 날리는 일들이 종종 생기게 되어서 아쉬웠다.
“공유”
이 역시 시간이 촉박해지면서 생긴 문제였다.
본인 할 일에 대해 문서화가 제대로 되지 않은 상태에서 개발하다 보니
다른 팀원이 뭐하는 지 잘모를 때가 있었다.
각자 한 일들이나 만난 문제들 그리고 해결법들이 서로 공유가 잘 되지 않아서
소통이 까다로워지는 부분이 있었다.
🤔 Try
“테크 문서를 작성해보기”
이슈기반으로 작업을 작성하고 진행을 하는 것은 나쁘지 않았지만,
후에 다른 분들이 작성한 해당코드를 분석 할 때
팀원분들이 어떤 사고방식으로 해당문제를 해결했고 그걸 어떤 코드로 풀어 냈는지에 대해서
자세히는 알지 못하는 아쉬움이 있었다.
그래서 테크 문서를 작성해서
해당 컴포넌트를 어떻게 쪼개고,
어떤식으로 풀어갈지를 서로 글로써 공유한다면
잘하는 팀원들의 암묵지를 습득함으로써 팀 자체가 더 성장 할수 있지 않을까 기대한다
“에러 및 문제 해결을 서로 발표하는 자리 마련”
이번 프로젝트는 2주라는 너무 촉박한 시간동안 진행되었기 때문에,
해당 부분을 서로 이야기 하는 시간이 부족했다고 든다.
이후에는 프로젝트를 하지 않더라도,
금요일 스크럼때나 한주 1번 또는 2주에 한번 정도는
자신이 공부하면서, 프로젝트를 하면서 겪었던 어려움,
그리고 그것을 어떻게 해결했는지 각자가 글로 적고 공유를 한다면
작성자 본인도 자신의 사고의 흐름이 어떻게 흘러가는지 알 수 있고
팀원들도 타 팀원들의 디버깅, 문제 해결의 사고를 익힐수 있지 않을까 기대해본다.