Skip to content

Week3. Day2 ‐ 23.11.22 팀회고

surin edited this page Dec 12, 2023 · 1 revision

KPT 기준

  • Keep : 계속 하면 좋은 점
  • Problem : 문제점
  • Try : 문제 개선을 위해 다음에 해볼 만한 일

서정

  • keep
    • 공유가 필요한 내용에 대해서 학습하면서 문서화를 열심히 했다. 회의를 구두로만 하는 것보다 효과적인듯!
  • problem
    • 데모 완성에 큰 영향은 없으나 나중에 처리해야할 일들이 생겼을 때 어떻게 관리할지 고민이었다. 당장 쳐내기에는 데모 완성을 위해 우선적으로 해야할 일들이 있어서 미뤄둬야 하는데, 생각날때마다 기록을 안해두면 나중에 까먹을 것 같다.
    • 반복되는 문제이긴 한데 지라 스토리 단위를 크게 만들어놔서 완성으로 옮길 수가 없다..
  • try
    • 바로 해결하기에는 시간이 없지만 나중에 시간이 생겼을 때 처리할 일들을 보관하는 를 만들었다.
    • 스토리 더 작게 나누기 + 스프린트 회의에 더 신경을 써야할 것 같다

영우

  • keep
    • 아는것에 대해서 설명을하고, 모르는것에 대해서 질문을 하는게 당연한거지만 지키기 어려운건데 우리팀은 잘 지키고 있다.
  • problem
    • 오늘 스크럼이 좀 길었다.
    • 프리티어 설정을 두시간했다. 너무너무 힘들었는데, 내가 예상한 상황이나 원하는 상황이 아닌것을 못견뎌한다.
  • try
    • 스크럼때는 현황공유위주로 빠르게 진행하고, 전체가 공유해야할 내용이 있으면 이후에 말해보자.
    • 어려운 상황이 닥쳤을때 범용적으로 사용할 수 있는 스스로의 해결프로세스를 강구해보자.

용현

  • keep
    • 코드 리뷰를 서로 봐주는 과정 덕분에 코드를 짤 때, 더 깔끔한 방식과 재사용성이 높은 방식을 의식해서 작성할 수 있는 것 같다.
  • problem
    • task 인수 조건을 정할 때, 현실적이지 못한 조건을 설정해 두었던 탓에 task를 마무리 할 수 가 없었다.
    • 또한, test 코드를 작성하기 위한 환경 설정이 되어 있지 않은 것도 인수 조건 달성에 불편함을 야기했다.
  • try
    • jest 환경 설정 마무리를 통해, 인수 조건을 위한 테스트를 수행할 수 있는 환경을 마련
    • 내일 테스트 코드를 작성해보면서, 각각의 task 타입(스타일 구성, hook 코드 작성, 화면 구성)에 따른 인수 조건의 기준을 작성한다.

승민

  • keep
    • 코드 리뷰를 통해 작성한 코드를 다시 되돌아볼 수 있어서 좋습니다.

수린

  • keep
    • 코드 리뷰 꼼꼼히 해줘서 좋았다.
    • 공유해야 될 내용을 정리해서 공유해줘서 이해하기 쉬웠다.
  • problem
    • 데모 때 정확히 어떤 동작을 가능하게 할 것인지 논의가 필요할 것 같았다.
    • 지라 태스크에 실제로 하지 않아도 되는 일이 올라가 있었다.
      • 회원 가입 페이지 생성과 로그인 페이지 생성 두 개가 올라가 있었는데, 사실 회원 가입 페이지가 따로 있지 않아서 이는 필요하지 않은 부분이었음
    • 자동배포가 막히는 부분을 이제서야 수정
  • try
    • 스프린트 계획 회의 때 목표를 더 확실하게 정하거나, 목표가 변경될 것 같다면 다시 간단하게라도 이야기 한다.
    • 태스크를 더 신중하게 생성한다.
      • 근데 갑자기 변경된 거라면…?
    • 배포에 관심을 가지고 젠킨스 들어가서 확인하자.

🎯팀 규칙

💻프로젝트

📃문서

☀데일리 스크럼

1주차
2주차
3주차
4주차
5주차
6주차

🗨️회의록

  • 회의록
  • 📚팀 회고

    1주차
    2주차
    3주차
    4주차

    ✍️개인 회고

    1주차
    2주차
    3주차

    🧑‍🏫기술 공유

    Clone this wiki locally