📓 우리의 회고

2차 데모데이

Keep: 잘하고 있는 점. 계속 했으면 좋겠다 싶은 점

크루	의견
이리내	어쨌든 기간 안에 목표했던 구현 기능들을 다 구현한 점. 서버와 안드로이드 연동이 생각보다 순조로웠던 걸 보니 API 합의가 잘 이루어졌던 것 같다고 느껴짐. 매 아침 진행상황을 공유함으로써 각자 얼마나 작업했는지 잘 알 수 있었음.
하티	- 꾸준히 소통하고, 머뭇거리지 않고 의견을 제시하는 점! - 칸반 보드, 이슈 관리 컨벤션 등이 잘 맞춰지고 있는 것 같습니다. - (안드) 모르는 부분에 있어서 물어보았을 때 항상 친절하게 알려줘서 고맙습니다. :)
코비	리뷰를 상세히 한다는 점이 좋았고, 브랜치 전략, 이슈 등 데모데이가 급박헀던 일정이 아니면 잘 지켜져서 좋았습니다.
호이	의사소통 과정에서 힘들었던 부분 공유, 기간 내에 구현 기능을 잘 구현한점, 현재 구현하고 있는 목표에서 과하다 싶은 부분을 todo로 남겨두는 것
로피	깃 브랜치 전략에 잘 적응하고 있는 점, 일정 안에 기능들을 다 완성하지는 못했지만 버그 등을 제외하고는 우리의 목표구현을 많이 이루었던 점이 좋았다!
여우	협력해서 페어코딩으로도 구현해보고 역할을 나누어 따로 구현해보기도 하면서 팀 협동 과정에서 겪을 만한 다양한 이슈를 체험해본 거 엄청 좋았다! 2차 스프린트 때의 경험을 바탕으로 3차 스프린트 때에는 더 빠르고 원활한 개발이 가능할 듯
케로	깃 브랜치 전략을 다들 처음 해보는 것이였는데 잘 했던것 같다. 기능을 나눠서 구현하고 다시 합치는 과정에서 충돌이 잦았지만, 잘 문제없이 해결했던 것 같다. 얼레벌레였지만 목표한 것을 전부 다 구현해냈던것이 만족스럽다!! 초반에 4인 페어로 다같이 맞추면서 했던것도 좋았다.

Problem: 뭔가 문제가 있다 싶은 점. 변화가 필요한 점

크루	의견
이리내	(백엔드) 데모데이 전에 기능을 급하게 구현하다보니 모든 백엔드 팀원이 approve하지 않고도 merge가 급하게 이루어진 적이 많았던 것 같다. 리뷰도 급하게 남기다보니 다른 사람이 구현한 부분에 대해 이해도가 낮아서, 나중에 뒷북으로 모르면 물어봐야 한다는 문제점이 있는 것 같다..
하티	- (안드) 기능 분리가 되어있어서 서로의 코드 혹은 기술에 대해 이해가 부족할 수 있을 것 같고, 코드 리뷰도 더 어려웠습니다. 또 발표를 하며 느낀 점이, 서로 공유되지 않은 점들이 있었던 것 같아요. - 일정 추정 !! 졸려하는 여러분과 제 모습에 마음이 속상하네요. ㅠㅠ - 기능 구현이 바빠 발표 준비가 급박했던 것 같고, 요구사항 반영이 더뎌진 게 아쉽습니다. 일정 추정을 여유롭게 잡고, 발표 준비를 잘 해야할 것 같아요.
코비	일정 추정에 시간을 조금 들이면 좋을 것 같습니다. 마지막에는 저희가 만들었던 컨벤션이 조금 삐긋하는게 느껴졌어요 (+PPT 준비시간)
호이	(백엔드) 빠르게 기능을 구현하고 해당 기능을 사용해서 계속 진행해야 되기 때문에 코드 리뷰가 제대로 안된거 같다. 데모데이 이후, 구현한 기능에 대한 더 깊은 생각(파일 업로드가 오래 걸리는 경우, 서버 내에 로그를 어떻게 관리할지)가 부족했음을 느꼈다.
로피	- 데모데이에 발표를 하기 위해 급하게 리뷰하지 못한채 마지했던 점이 아쉬워서 일정을 잘 잡아야 할 것 같다는 생각이 들었습니다. 안드로이드와 서버 연동을 너무 늦게 시작해서 오류를 늦게 찾아 고칠 수 있는 시간이 없었던 점도 아쉬웠습니다! - 안드로이드에서도 뷰를 나누어서 프로그래밍을 진행하느라 서로의 필요한 기술이 뭔지 모른채 코드 리뷰를 해주어야할 때도 있어서, 이번에는 특히 시간이 촉박해서 서로의 기술을 공부하고 리뷰를 달아주는게 힘들었던 점이 있었던 것 같습니다.
여우	- 코드리뷰가 끝나고 머지된 dev 브랜치에서 코드를 그대로 끌어왔는데 테스트가 깨지는 건 분명한 이상상황인 것 같다. PR을 보내기 전 전체 테스트를 실행하도록 강제하는 기술을 도입하거나, 각자 컴퓨터 환경에 상관없이 개발 환경을 모두 통일하도록 도와주는 도커 등의 기술을 도입할 필요가 있다. - 안드로이드와 서버가 연동하는 작업이 맨 마지막에 이루어진 것이 아쉽다. 애자일 어쩌구에 의하면 자주 빠르게 하는 협력과 피드백이 중요하다고 하므로, 하나의 API가 완성될 때마다 두 파트가 연동 테스트를 하고 상호 피드백하는 프로세스를 추가하면 좋겠다. - (나한테 아쉬운 거) 백엔드 사람들이 모여서 해결하고 있는 이슈 주제를 혼자 모르거나 팀원이 하는 말의 뜻을 잘 못 알아듣는 것 ,, 대체로 팀원의 일에 좀 더 관심을 가질 필요가 있다
케로	1. 데모데이 발표자료를 준비하는 것이 너무 늦게 시작해서 아쉬웠다. 2. 목표의 설정이나, 각자의 진행 사항에 대해 서로 공유하기로 했는데, 그게 뭔가 잘 안된 것 같다. 3. 리뷰 요청을 신청하고, 리뷰를 받는 과정이 생각보다 오래 걸려서 다음 단계의 구현을 진행하기가 힘들었다. 4. 일정 추정을 정확하게 하기가 어려웠다. 5. 저의 발표와 질문 처리에 문제가 있었던 것 같아요… 6. 호이의 어그로가 참기 힘들어요

Try: 잘하고 있는 것을 더 잘하기 위해서, 문제가 있는 점을 해결하기 위해서 우리가 시도해 볼 것들

크루	의견
이리내	모든 팀원이 코드를 다 보고, approve해야 merge를 하는게 좋을 것 같다. 그리고 자신이 구현하지 않은 부분에 대해서도 잘 이해하고 있어야 다른 기능을 구현할 때 수월할 것 같아서, 코드리뷰를 하는것만으로도 코드를 이해할 수 있는 적당한 정도로 기능을 작게 쪼게거나, 2인 페어프로그래밍을 하고 나머지 둘이 리뷰를 남기는 것도 좋을것 같다.
하티	- 서로 적용한 기술이나 반영한 코드들에 대해 기술 블로그 등을 통해 공유해주면 좋을 것 같습니다. (시간이 될런지는…. 모르겠긴 하네요 😢) - 일정 추정을 여유롭게 잡아보면 좋을 것 같아요. - 완벽하게 디테일에 집착하지 않고, 포르쉐보단 스케이트 보드를 먼저 만들어요 우리!
코비	코드에 대해서 모두 오너쉽을 가질 수 있는 분위기가 만들어졌으면 좋겠습니다. 모두가 모두의 코드를 이해하고 있을 수 있게 할 수 있는 방안이 필요한 것 같습니다. 잘 만들어진 바퀴보다 자전거를 만드는 것이 낫다고 합니다. 저희 앱에서는 잘 지켜지는 걸까요?
호이	기능 구현하면서 간단한 기능 설명, 어려웠던 점, todo 등을 PR이나 문서에 기록해두면 코드 리뷰하기도 편하고 todo의 경우 기능 구현한 사람만 알고 있다가 까먹으면 안되니까 공유가 조금 더 잘 될거 같다. 코드 리뷰의 경우도 같이 회의를 진행해서 어떻게 진행할 지 다시 한번 상의하면 좋을 듯.. +) 마지할 때, 생각보다 컨쁠릭트가 나오는데 같이 있을 때, 마지를 하는게 어떨지.. 이 부분은 201팀처럼 이슈단위를 크게 만들고 세분화해서 가져가도 괜찮을듯요..
로피	서로 사용한 기술을 잘 정리해서 문서화하면 좋을 것 같습니다! 아니면 이 기술에 대해서 학습한 링크 등을 첨부하면 리뷰하는데 좀 더 도움이 될 것 같습니다! 이번엔 개발을 너무 늦게 시작해서 정해놓은 기능들에 비해 시간이 촉박했는데 일정 추정을 잘 해서 밀도있게 일했으면 좋겠습니다!
여우	- 이미지 관련 테스트를 원활하게 수행하기 위해서라도 도커 도입은 필수인 것 같다! 근데 나는 도커를 모르므로 주말동안 공부해보자 - velog로 임시 기술 블로그를 만들었으니, 주제와 담당자를 정해서 강제로 작성하게 하자 - 우리가 구현한 기능에서 의문이나 개선점이 있는 지 상대 파트 팀원으로부터 피드백을 받자!
케로	1. 데모데이 전날 데모데이 준비 시간을 fix해 놓고 다른일이 있더라도 그거 먼저 했으면 좋겠다. 2. 퇴근 전에도 진행사항을 공유하고, 서로의 목표치도 계속 맞춰가는 것이 좋겠다. 3. 나 자신의 능력치 알아가는 시간이 필요한 것 같다. 구현과정에서 코드를 너무 완벽하게 짜려고 하지 않는 것도 좋겠다.(코딩 스타일 보다 구현에 있어서 오류 처리같은 부분을 위주로 보는 것이 좋지 않을까요)

1차 데모데이

Keep: 잘하고 있는 점. 계속 했으면 좋겠다 싶은 점

크루	의견
이리내
하티
코비
호이
로피
여우
케로

Problem: 뭔가 문제가 있다 싶은 점. 변화가 필요한 점

크루	의견
이리내
하티
코비
호이
로피
여우
케로

Try: 잘하고 있는 것을 더 잘하기 위해서, 문제가 있는 점을 해결하기 위해서 우리가 시도해 볼 것들

크루	의견
이리내
하티
코비
호이
로피
여우
케로