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

[Shinsuan]

왜 회고를 해야 하나요?

바쁘고 치열하게, 또 잘 버티고 있는 스프린트 17기 여러분!
정신없이 프로젝트를 하다 보면 현재 우리 팀의 방향성과 목표를 잊어버리기 쉬워요.
매주 팀원들과 일주일을 회고하며 프로젝트를 위한 원동력이 되었으면 좋겠어요.

회고에 대한 궁금증

회고와 일기의 차이는 무엇인가요?

• 일기는 일상에서 있었던 일들을 의식의 흐름대로 편하게 적는 것이라면,
  회고는 함께 보고 듣고 경험한 사건과 현상들을 곱씹어 보고, 그중에 특히 되짚고 싶은 것들을 '왜' 와 '어떻게'에 집중해서 기록하는 것입니다.

회고 방법

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

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

참고글

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

[Shinsuan]

🍀 0팀 (예시)

Keep

• 미팅 시간 약속을 모두 잘 지켜준다.
• 프로젝트 과정에서 기술 고민을 함께 하는 것이 서로의 학습에 도움이 된다.
• 새로운 제안을 했을 때, 모두 개방적으로 의견을 들어주어서 고맙다.
• 위워크에 모여서 하다보니, 프로젝트 진행이 빠르게 잘 이루어진다.

Problem

• 커밋 메시지가 명시적이지 않아서, 서로 어떤 작업을 했는지 파악하기 힘들었다.
• 급하게 코드를 작성하느라, 폴더 구조가 이상하다.
• 서로를 너무 배려하느라, 의견을 더 많이 나누지 못한다.

Try

• 협업을 위해, 커밋 메시지를 더 구체적으로 작성한다. (커밋 메시지 규칙 정하기)
• 폴더 구조를 다시 논의하여 폴더 구조 규칙을 만들고, 규칙에 맞추어 파일을 배치한다.
• 각자 하루에 한 번 이상 의견을 낸다.

[Ospac]

👾 3팀

Keep

• 다들 맡은 개발을 너무 잘하고 있습니다 .. 금요일까지 화이팅 ..
• 깃허브에 이슈나 pr을 올리는 것이 각자 작업 진행 상황에 대해 알 수 있어 좋다.
• 깃 커밋이나 브랜치, 폴더구조 등을 명시적으로 정해서 진행함에 있어 효율이 좋았다.
• 공통 컴포넌트나 api를 만들어주신 덕분에 작업하고 있는 부분에 쉽게 가져다 쓸 수 있어서 작업 효율에 도움이 되었다.
• 모두 계획대로 진행을 잘 하고 있고, 깃허브에 올리면서 잘 공유가 되어 진행사항을 잘 알게 된 부분이 있고, 일단 기본틀이 잘 작성이 되어 서로 연결하기 좋은 환경이 되어 좋았습니다.
• 팀원들 모두 맡은 역할을 잘 수행해나가고 있으며, 데일리 스크럼에서 코드 리뷰 등을 진행할 수 있어서 많은 도움이 되었다.

Problem

• 일정이 있으면 미리 사전에 팀원들에게 설명하지 못한 부분들이 아쉽다.
• 디스코드 나갈때 인사했으면 좋겠다.
• 각자 알아서 하는 성격(?)이라 작업하는 부분이나 질문이나 그런 공유가 적다.
• css 만들때 px단위가 많다. (rem 사용하기)
• 이슈, PR을 깔끔하게 잘 작성하고 있지만 서로 작업하는 부분에 대한 이해도를 높이기 힘들다.

Try

• 각자 맡은 기능이나 컴포넌트 파일 하나 정도를 다른 팀원이 이해할 수 있도록 설명해보기 + 문제해결 했던 과정 공유 (데일리 스크럼)
• Zep에서 소통 더 원활하게 하기 (방이 나눠져있어서 필요한 사람은 해당된 방에서 통화해보는 형식으로) : 코어타임에 사용
• 코드 리뷰 활성화 하기 (데일리 스크럼할때 PR을 같이 보고 Merge) (자율적으로)
• 작업 기간내의 일정, 작업완료 할때 공유하기
• css 만들때 rem단위 통일하기

[sseung30]

1팀

[Still-Mare]

👻 4팀

Keep

• 팀원들이 각자 맡은 역할을 책임감 있게 충실히 수행
• 정기적인 팀 미팅으로 진행 상황 공유
• 적극적인 피드백과 중간 점검으로 문제 예방
• 모르는 부분에 대한 적극적인 도움으로 문제 해결

Problem

• 개별 작업으로 인한 상호 작업 이해도 부족
• 페이지 간 연동 기능으로 개발 속도 저하
• 코드 리뷰 시간 부족 및 작업 진행사항 분석 미흡
• 프로젝트에 대한 적극적인 의견 표현과 토론 부족
• 결정 과정의 지연과 빠듯한 일정 관리

Try

• 정기적인 코드 리뷰 시간 도입 및 팀 미팅 빈도 증가
• 작업 중 어려움과 완료 사항의 수시 공유
• 자유로운 의견 교환 분위기 조성
• 데일리 스탠드업 회의 도입
• 문제 해결 경험 공유를 통한 학습 효과 증대

[kevin123753]

5팀

Keep
역할 분담이 잘 되어 있어 각자 맡은 파트를 일정에 맞춰 책임감 있게 수행하고 있다.

기능 개발 전, 사전 논의와 기획 공유를 통해 불필요한 충돌 없이 작업할 수 있었다.

질문이 생기면 디스코드나 Zep으로 바로바로 소통하며 빠르게 해결하는 구조가 잘 작동하고 있다.

컴포넌트/모듈 재사용을 염두에 두고 개발해 전체적인 코드 품질이 유지되고 있다.

깃 브랜치 전략과 폴더 구조가 명확해져서 병합 과정에서 큰 혼란이 없다.

Problem
가끔 PR 설명이 간단하게 끝나서 어떤 작업인지 전체 맥락을 파악하기 어려운 경우가 있었다.

중간 중간 기능 병합 이후 일부 스타일 깨짐이나 예상치 못한 버그가 생겼지만 바로 공유되진 못했다.

팀원 간 스타일/네이밍 기준이 다소 달라 일관성 유지에 약간의 어려움이 있었다.

각 기능이 의도한 대로 작동하는지 테스트하는 시간이 부족해 QA 단계에서 놓친 부분이 발생했다.

Try
PR 작성 시 작업 요약 및 주요 변경점을 한눈에 파악할 수 있게 정리해 올리기

데일리 스크럼 시 병합 이후 변경된 부분이나 이슈를 짧게라도 브리핑하기

코드 컨벤션 관련 가이드 정리 후, 중복되는 논의 줄이고 개발 집중하기

QA 체크리스트를 간단히 정리해두고 기능 완료 후 빠르게 자가 검토할 수 있게 하기

[annmmww]

2팀

1주차 KPT 회고

Keep

• 질문에 대해 모두 성심성의껏 답해주어서 학습에 많은 도움이 된다.
• 의견이 잘 맞고, 다른 부분이 있으면 충분히 의견을 듣고 조율하는게 빠르게 이루어져서 효율적이다.
• 힘들어도 맡은 바에 책임을 다하고, 다른 사람을 돕고자 하는 사람들이 모여 너무 감사하다.
• 자신만의 역할을 찾고 그 자리에서 최선을 다하고 있는 모습이 보인다.
• 개개인의 능력들도 뛰어나지만, 합심해서 프로젝트를 해나가려는 점이 강점인 것 같다.

Problem

• to-do list 활용이 미비하다.
• 함께 모여 작업하고 맞춰보는 시간이 없어 소통이 조금 더 필요할 것 같다.
• 고민거리가 있다면 같이 공유해보는 것도 좋을 것 같다.

Try

• 공용 To-do list 툴
• 정기적인 짧은 동기화 미팅
  • 월요일 오전까지 각자 배포
  • 정기 팀미팅에서 기능 & 코드 발표 및 문제점 파악
    • 팀원 의견 존중
  • 애자일 방식
• 함께 모여 작업하는 시간’을 시범적으로 운영