기초 프로젝트 2주차 팀회고

[Tony-Codeit]

왜 회고를 해야 하나요?

• 짧은 프로젝트 기간에 팀 회고는 개인의 성장뿐 아니라, 원활한 팀 프로젝트를 위한 발판이 되어줄 거예요.
  매주 팀 단위로 회고를 하며 어떤 점이 좋았고, 어떤 점이 아쉬웠고, 아쉬웠던 부분은 어떻게 개선해볼지 함께 이야기해보면
  그 다음주에는 더 나은 프로젝트를 진행할 수 있을거예요. 회고를 통해 함께 성장해보아요 🔥

• 회고 시간만큼은 솔직한 생각, 마음을 터놓기
  솔직한 회고를 통해 다음주는 더 즐겁게 프로젝트를 진행할 수 있을거예요.

회고 방법

회고는 “KPT 회고” 방식으로 진행해볼거예요. 아래 방법대로 회고해주시면 됩니다.

• 팀원들과 모여 그 주의 팀 프로젝트 활동을 돌아보며, '좋았던 점(Keep) / 아쉬웠던 점(Problem) / 시도해볼 것(Try)'으로 항목을 나누어 회고해주세요.
  • Keep: 현재 우리팀이 잘 하고 있어서 계속 유지하면 좋을 것 같은 부분
  • Problem: 현재 우리팀이 가지고 있는 문제
  • Try: Problem에 적은 것을 해결하기 위해 우리 팀이 다음에 시도해볼만한 것 (혹은 Keep 중에서도 더 개선하거나 시도해보고 싶은 것)
• KPT 회고 피그마 템플릿을 활용해서, 팀 회고를 진행하셔도 됩니다. 단 템플릿 사용시, 팀별로 복제해서 사용해주세요. 꼭 템플릿을 사용하지 않아도 되니, 팀별로 편한 방식으로 회고를 진행해주세요.
• 이번주 일요일까지, 팀 회고한 내용을 정리하여 댓글로 올려주세요.
  (댓글에 예시 회고를 올려드릴테니, 참고해주세요. 피그마 템플릿으로 진행하셨다면 캡처본을 올려주셔도 돼요.)

참고 글

• KPT 회고란 무엇인가?
• 팀문화의 탄생

[SeungHyunOK]

2팀

• 좋았던 점(Keep): 현재 우리팀이 잘 하고 있어서 계속 유지하면 좋을 것 같은 부분
  • 코어타임 말고도 저녁시간에 개발을 하는것을 보고 열심히 하는것 같아서 좋았습니다.
  • 질문이나 모르는게 있어도 통화로 직접 도와주는것이 좋았습니다.
  • 온라인으로 의견 을 모으는게 힘들다고 생각했는데 잘되어서 좋았습니다.
  • 피드백사항이 빨리 처리되는게 좋았습니다.
  • 뒤쳐지는 사람이 있어도 싫은티 안내고 잘 도와줘서 좋았습니다.
• 아쉬웠던 점(Problem): 현재 우리팀이 가지고 있는 문제
  • pull request가 좀 더 빨리 처리 되었으면 좋겠습니다.
    • PR올린게 잘 변경이 되었는지 확인 불가 ⇒ ChangeRequest 를 통해서 확인
    • 해결이 되지 않았는데 리뷰를 올리면 안되기 때문에 해결을 하려고 하다 보니 시간이 지체되었습니다.(옥승현) ⇒ 아래 방법을 적용
  • 모르거나 막히는 부분이 있으면 바로바로 물어보고 해결하는게 좋겠습니다.
  • 코드 리뷰를 하는 사람들이 정해저 있는 것 같아서 다같이 리뷰를 진행 했으면 좋겠습니다.
• 시도해볼 것(Try): Problem에 적은 것을 해결하기 위해 우리 팀이 다음에 시도해볼만한 것 (혹은 Keep 중에서도 더 개선하거나 시도해보고 싶은 것)
  • PR 리뷰 시 코멘트한 부분이 변경되었는지 몰라서 승인 및 머지해야될 지 모르겠는 부분에 대해서 change request 상태로 변경 되었는지 물어보고 리뷰 올린 사람이 답변하는 방법 사용. 다른 리뷰어도 change request 가 있으면 해결 되었는지 확인 후 머지.
  • 요구사항(피그마)과 코드를 비교해서 모르더라도 보이는 점들을 피드백을 해보자.

[ojm51]

3팀 KPT 회고록 (2주차)

[wiZArd3233]

7팀 주간 회고록

K

전주현: 항상 개선할 점을 찾으려고 하는 것이 좋았다고 생각 합니다.
염성진: 기간 안에 잘 마무리할 수 있을 거 같아 다행인 것 같다.
김세환: 각자의 기능을 본인의 개발 스타일과 장점을 살릴 수 있는 환경을 구현하였다
김우성: 처음 우려와 다르게 프로젝트가 잘 진행되고 있는 것 같습니다.

P

전주현: 별다른 문제점은 없었다고 생각 합니다.
염성진: 크게 문제가 없어 잘 취합하여 마무리했으면 좋겠다.
김세환: 협업하는데 있어서 개발 환경과 디자인 패턴을 어디까지 맞춰야하고 어디까지 자유롭게 할 수 있는지 알기 어려웠습니다.
김우성: 서로 간의 의사소통도 원할합니다. 프로젝트 막바지인데 무리 없습니다.

T

전주현: 지금 이대로 쭉 해서 좋은 마무리 했으면 좋겠습니다.
염성진: 개인적인 회고록을 기록해야 좋을 거 같다.
김세환: 각종 블로그나 프로젝트를 참고하여 자유롭게 개발하는 환경을 해치지 않는 선에서 디자인 패턴을 맞추려 해보았습니다.
김우성: 프로젝트를 처음부터 다시 시작해 보고 있습니다. 완성도 있게 !

[kjw0412c]

6팀 주간 회고록

• 임귀태
  • K
    • 하나의 문제를 여럿이 토론하며 좋은 방향성을 찾는 것은 좋았던 것 같습니다!
    • 코어 타임 역시 어느정도는 잘 지켜졌다고 생각합니다.
  • P
    • 아쉬운 것은 코어 타임은 '코어'로 굴러가야 한다고 생각했으나, 저도 그렇고 코어 타임 외의 개발에 대한 시간 투자에 대해서 적극적인 투자가 제대로 일어나지 못한 것 같아 아쉬움이 있습니다.
    • 큰 틀로서의 계획을 제대로 세우지 못한 것에 대한 아쉬움이 있습니다.
  • T
    • 이에 대해서 좋은 방향으로 개선하려면 명확한 목표를 세우고 그에 대한 조금은 세부적인 목표로 잘라내어 계획을 수립하고 이에 대한 개인의 적극적인 투자가 일어나야 더 좋은 방향성을 띌 수 있을 것 같습니다.
• 김준완
  • K
    • 상호간의 존중이 많이 지켜졌던 것 같습니다. 서로 부족한 점이 눈에 많이 보였을 텐데, 지적보다는 배려와 제시의 형태로 의사결정이 이루어져서 마음이 편했습니다.
    • 각자가 맡은 부분이나 내용에 대한 불만이나 비난없이 진행된 것 자체가 좋았고, 구체적인 지시나 오더가 없이도 해야할 일을 찾아서 해나가는 모습이 좋았습니다.
  • P
    • 데드라인이 처음 생각보다 촉박했고, 이에 대한 대처가 미흡했던 부분이 있는 것 같습니다.
    • R&R분배나 규칙 및 정책 설정을 미비하게 하여 프로젝트 진행 중간에 새로운 내용들이 필요해지고, 때로는 오해가 생기기도 했던 것 같습니다.
    • 멘토님이나 주강사님을 많이 활용하지 못한 것 같고, 서로의 코드를 이해하는 시간이 부족했던 것 같습니다.
  • T
    • 일정이 틀어질 위기라는 생각이 들면, 자신 및 팀원이 아니라 주강사님이나 멘토님의 좀 더 적극적으로 받아봤어도 좋았을 것 같습니다.
    • 코딩에 할애하는 시간이 좀 적어지더라도 정책 설정이나 규칙을 정하는 데에 처음에 좀 더 적극적으로 임했다면 시간이 아껴졌을 것 같습니다.
• 장혁수
  • K
    • 다들 맡은 역할에 최선을 다하는 모습이 보기 좋습니다. 불철주야 고생이 많으십니다.
  • P
    • 의사소통을 할 때 상대방이 얘기한 것에 대해 잘못 이해를 해서 대화의 방향이 산으로 갈 때가 있습니다.
  • T
    • 상대방이 얘기한 것을 들어보고 자신이 이해한 것이 맞는지 한 번 되물어보는 것도 좋은 방법인 것 같습니다.
• 염정훈
  • K
    • 각자 코드를 작성하다가 모르는 부분이 있을때 본인만의 해결방안을 제시해주면서 도움을 주려는 모습이 좋았습니다.
  • P
    • 본인이 편한 방식으로 코드를 작성했을때 해당 코드가 다른 사람과 공유 해야 하는 코드이면 서로 편하게 쓰기위해 수정이 거의 필수적인것 같습니다.
  • T
    • 서로 공유되는 코드부분들을 이야기 하면서 어떤식으로 작성하면 좋을지 정하고 작성하는것도 좋은 방법인것 같습니다.

[SealBros]

장난 없는 1팀 주간 회고록

[itscold96]

4팀 기초 팀프로젝트 주간 회고록

Keep (현재 우리팀이 잘 하고 있어서 계속 유지하면 좋을 것 같은 부분)

• 디스코드 화면공유를 적극적으로 활용: 프로젝트를 완성하면서 함께 의논해야 할 부분이 있을 때마다 디스코드 음성채널의 화면공유 기능을 활용하여 팀원 모두가 힘을 보태서 해결할 수 있어서 좋았습니다. 덕분에 각자 맡은 부분을 구현하는 데 어려움이 있거나 코드에 문제가 발생했을 때 효율적으로 대처할 수 있었습니다.
• 멘토링 시간 전 질문 리스트 작성: 멘토링 시간 전에 미리 멘토님께 여쭤볼 질문 내용을 취합하여 미리 전해드렸기 때문에, 더 자세한 답변을 들을 수 있었고, 이를 통해 프로젝트의 중간점검을 받고, 현업에서 프로젝트를 진행하는 노하우에 대해서도 많이 배울 수 있었습니다.
• PR 리뷰: PR을 통해 서로 리뷰도 하고 부족한 점을 많이 채울 수 있어서 좋았습니다.
• 컨벤션과 브랜치 규칙 준수: 컨벤션과 브랜치 구조를 잘 지켜서 작업한 점이 좋았습니다.
• 문제 공유 후 함께 해결: 문제가 생기면 다 같이 해결하는 문화가 좋았습니다.
• 소통: 소통(피드백)이 원활하고 약속을 잘 지키는 팀원들이 좋았습니다.

Problem (현재 우리팀이 가지고 있는 문제)

• 개인 구현 시간에 너무 많은 시간이 들어간 것: 상대적으로 어려운 기능을 맡은 분들은, 개인적으로 맡은 부분을 구현하는 데 시간을 너무 많이 소비하여 다른 팀원분들의 코드 리뷰에 적극적으로 참여 하지 못한 것이 아쉽다고 하셨습니다.
• 도움 요청 부족: 어려움이 지속되면 도움을 청해야 하는데 그러지 않고 혼자 해보려고 하다가 너무 많은 시간을 사용해버린 것이 아쉽습니다.
• 코드 스터디 흐지부지: 생각보다 개발 기간이 오래 걸려, 코드 스터디가 흐지부지되는 경향이 있었습니다.

Try (문제 해결을 위해 시도해볼만한 것)

• PR 코드리뷰: 다음 프로젝트에서라도 다른 팀원분들의 PR에 코드리뷰를 남기면서 프로젝트에 더 많이 기여할 수 있게 노력하기.
• 문제 공유: 문제가 생기면 혼자 앓지 말고 공유하기.
• 코드 스터디 시간: 프로젝트 중에 코드 스터디하는 시간을 가지기.
• R&R 분할: R&R을 한 번에 하지 말고 공통 부분을 먼저 개발할 수 있도록 R&R을 나누어서 해보기.

[kjh9852]

8팀 회고록

[hvrain]

Keep

Problem & Try