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

[yunjeongcodeit]

왜 회고를 해야 하나요?

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

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

회고 방법

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

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

참고 글

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

[mxkxx1011]

4팀 롤링 2주차 회고입니다

[K777agent]

5팀 롤링 2주차 회고입니다.

[KingNono1030]

8팀 기초 프로젝트 팀 회고(KPT)입니다.

Keep: 현재 우리팀이 잘 하고 있어서 계속 유지하면 좋을 것 같은 부분을 
작성해주세요. 이시간을 빌려 한주간 프로젝트에서 잘 된 점들을 
서로 마구 칭찬해주는 시간을 가져도 좋겠네요.

• 정윤호: 컴포넌트 기반 개발의 장점을 여실히 느꼈다. 특히 초기 컴포넌트 위주의 구현과 컴포넌트 단위의 브랜치 분기는, 컨플릭트로부터 어느정도 자유로웠다. 코어 타임을 무리하게 길게 설정하지 않고 하루 중 2시간으로 설정해, 오히려 집중되게 소통할 수 있었다. 팀 분위기 좋은 점이 큰 장점이다.
• 김동규: 멘토님이 말씀하시길 프로젝트에서 제일 중요한 것은 팀 분위기이다. 우리 팀은 어떤 분쟁도 없었던 점에서 이미 성공하지 않았나 싶다. 이러한 면은 각자 맡고 싶은 역할, 분량 등에 대해 확실한 의사 표현이 있었기에 서로간에 이해가 잘 되었던 것 같다. 장점과 제한점을 공유한 점도 이에 기여했다고 믿는다. 각자 맡은 역할은 끝까지 착실히 수행했고, 작업을 떠넘기지 않았다. 팀장님이 팀의 구심점이 되어 잘 전두지휘했고, 분위기도 좋게 유지한 점을 칭찬하고 싶다.
• 정유승: 컴포넌트화 잘 되어 있는 만큼 작업이 겹치지 않고 세분화 되어 있었다. 내가 무엇을 해야 하는지 명쾌히 정해져 있어 일 진행이 잘 되었다. 해야 할 일의 리스트가 이미 있었기 때문에 특정 과제를 수행하면 바로 이어서 다음 과제로 이어서 작업한 것이 효율을 늘렸다. 역할 분담도 각자의 강점에 맞게 잘 배분되었다.
• 하유리: 정해진 역할이 주어진 것이 내가 선호하는 업무 방식이라 편하게 작업할 수 있었다. 팀장님이 팀원들에게 태스크를 줄 때, 모두가 해당 과제를 거부하지 않고 책임 있게 끝까지 수행한 점이 좋았다.
• 신지원: 역할 분배와 컴포넌트 기반 개발 방식이 좋았다. 팀원들도 이기적인 모습이나 포기하는 모습 없이 팀적으로 잘 행동했다. 에러가 발생하거나 수정사항이 생겨 팀채널에 이를 알릴 때, 소통이 빨랐고 해결도 빠르게 되었다.

Problem: 현재 우리팀이 가지고 있는 문제가 있다면 작성해주세요.
문제의 발견은 곧 우리 팀이 더 성장할 수 있다는 의미이니, 
문제 발견을 두려워하지말아요:)

• 정윤호: 프로젝트 초반에 컨벤션 규칙을 별도의 문서화하지 않고 구두로만 이야기 나눈 점이 아쉬웠다. 팀장으로서 이런 부분을 더 체계화했어야 하는데, 명시적으로 계속해서 확인할 수 있는 규칙이 게시되지 않았기 때문에, 커밋 메시지나 PR 작성 면에서 혼동과 팀에 불편을 끼쳤다. 구현 외적으로 신경써야 할 부분이 많았다는 사실을 깨달았는데, 너무 빠르게 구현 단계에 들어 선 부작용이 아닌가 싶다.
• 김동규: 기초 프로젝트는 구현에서의 도전보다도 협업 과정 중에서 겪을 고난과 도전을 기대하고 있었다. 그런데 역설적으로 팀 활동이 이상적인 방향으로 너무 잘 진행되었고, 협업 단계에서의 경험치를 얻을 기회가 적었던 것 같다.
• 정유승: 우리팀 팀활동에는 아무 문제 없었다. 대학 시절 팀플의 악몽 때문에 걱정이 많았었는데, 막상 해보니 너무 스무스하게 진행 되었다. 팀장님의 중요도가 높아서, 팀장 의존도가 높았던 점을 굳이 단점으로 얘기할 수 있을 것 같다.
• 하유리: 불편을 느끼지 못했는데, 굳이 찾아보면 프로젝트에서 다양한 기술을 시도해보지 못한 점이 아쉽다. 이미 알고 있는 기술로만 문제를 해결해서 지식의 확장 면에서 아쉬움이 있다.
• 신지원: 전반적으로 만족스러운 팀활동이었다. 그러나 초기에 팀 규칙이나 컨벤션을 공고히 결정하지 않았던 점에서 많은 부작용을 느꼈다. 작업 순서 상 리팩토링 단계가 후순위에 배치되어 있는데, 남이 작성한 코드를 읽고 수정할 때 애로사항이 발생했다.

Try: Problem에 적은 것을 해결하기 위해 우리 팀이 다음에 시도해볼만한 것 혹은 Keep 중에서도 더 개선하거나 시도해보고 싶은 것을 작성해보세요. 다음주에는 Try에 적은 것을 바탕으로 더 좋은 협업을 해요 :)

• 정윤호: 프로젝트 초기에 구현 외적인 요소들에 대해 팀의 협의를 구하고, 규칙을 공고히 정하는 것의 중요성을 여실히 느꼈다. 다음 프로젝트에서는 이런 부분을 개선해보고 싶다. 또한 우리 팀은 주어진 요구사항에 집중하여 작업을 했는데, 팀미팅에서 창의성이 드러날 만한 회의를 하지 못한 것이 아쉽다. 다음번에는 요구사항 외적으로도 서비스를 개선하고 강화할 만한 추가 기능이나 디자인에 대한 창의적 회의를 해보고 싶다.
• 김동규: 팀미팅에서의 이야기가 다함께 PR을 보고 구현이 잘 되는지 아닌지만 따지는 건설적인 이야기 위주로 이루어졌다. 그러나 각자 다른 관점과 접근 방법으로 코드를 짤 수 있는 만큼, 각자의 코딩 노하우나 코드 지향점 등에 대한 이야기도 나눠보고 싶다.
• 정유승: 나의 구현에 관련된 레퍼런스만 보았지 다른 사람의 코드에 대해서는 공부해보지 못했다. 지식의 습득의 관점에서 팀활동이라는 특수성에서 이점을 살리지 못했던 것 같다. 다음번에는 PR 참여도 왕성히 해보고, 남의 코드도 많이 읽어보고 싶다.
• 하유리: 특정 문제를 마주칠때 팀적으로 함께 솔루션을 찾고 공유하는 경험이 너무 좋았다. 이러한 경험을 더 많이 겪고 싶고, 각자의 꿀팀, 노하우에 대한 공유도 많으면 좋겠다. 구현에만 집중하느라 코드 리뷰에 많이 참여하지 못했는데, 다음에는 많이 해보고 싶다.
• 신지원: 프로젝트 시작 전에 정해야 할 규칙들을 확실히 다루면 협업 경험이 더 개선될 것 같다. 코드 리뷰도 모두 각자의 구현사항 다루는데 바빠, 많이 활성화되지 못했던 점이 아쉬웠고. 다음번에는 코드리뷰에 적극적으로 참여하고 싶다.

[yellowjang]