Skip to content

Week2. Day2 ‐ 23.11.14 팀회고

dongind edited this page Nov 15, 2023 · 1 revision

KPT(keep : 계속 하면 좋은 점, problem : 문제점, try : 문제 개선을 위해 다음에 해볼 만한 일) 기반으로 회고 방식을 변경

영우

  • keep
    • 활발한 소통문화를 만들어나가고 있는 것 같습니다. 의사결정이 빨라서 쓸데없는 오버헤드가 생기지 않아 행복합니다.
  • problem
    • 회의를 각자 방을 파서 허들로하니까, 중간에 참여하고 싶을때 메시지를 보지 않으면 참여를 할 수 없을것같아요.
  • try
    • 팀원이 모두 초대된 허들용 채널을 하나 더 판다

서정

  • keep
    • 코어 타임에 슬랙 허들에 계속 접속해있어서 필요할때 바로바로 (음성으로) 소통할 수 있는 점
    • 문제가 생기면 바로 해결방안에 대해 논의 후 결론까지 짓고 넘어가는 점
  • problem
    • Jira 이슈를 좀더 세분화했으면 좋았을 것 같다.
  • try
    • 다음 스프린트 회의때 Jira 이슈 생성시 반영하기

용현

  • keep
    • FE 멤버들과 컴포넌트 구조를 구성하는 과정을 수행한 덕분에, 전체적으로 코드를 어떻게 구성하면 좋을지에 대한 윤곽을 엿볼 수 있어서 좋았다.
    • 또한 컴포넌트 구조를 설계하면서, 우리가 놓쳤던 화면구성이 필요한 API를 미리 잡아낼 수 있었던 점이 있다.
  • problem
    • 다만, 컴포넌트 구조를 짜면서 조건부 렌더링을 과도하게 남발하고 있는 것이 아닌가에 대한 의문이 든다.
      • 특정 상황에서만 렌더링 하는 조건부 렌더링을 사용하지 않을 수는 없지만, 이것이 컴포넌트의 최소 책임 원칙을 잘 지키지 않는 코드가 아닐까하는 의문이 든다.
    • 디자인 샘플을 구성하면서, 계속해서 지라의 복제본이라는 느낌을 지울 수가 없다.
      • 특히 Lesser는 지라보다 쉬운, 그리고 지라보다 간편함을 모토로 내세운 프로젝트인데 디자인을 하면서 그러한 점을 담지 못하고 있다고 생각이 든다.
    • 회의를 하던 중 트러블 슈팅 과정에서는 문제 해결에만 너무 집중해서 이를 기록하지 못하고 있다.
      • 이러한 기록을 담지 않으면 똑같이 발생하는 문제에는 똑같이 시간을 낭비하게 될 것이다.
  • try
    • 컴포넌트의 조건부 렌더링의 활용방법, 그리고 이에 대한 올바른 설계 방식이 있는지 코드 설계를 들어가기 전에 학습할 필요가 있다. 이 부분은 주말 혹은 시간이 된다면 이번주 목요일날 학습해 볼 예정이다.
    • 디자인 샘플에 대한 많은 레퍼런스를 찾아보고 이를 기반으로 설계 해봐야 할 것 같다.
      • 지금 우리는 워낙 주제에 대한 많은 토의와 생각을 했기 때문에 그냥 보면 단순해 보이지만, 정말 처음 보는 사람(애자일 / 칸반 보드라는 것을 어떻게 관리하는지 모르는)의 입장에서는 또 다를 것이다. 철저하게 객관화하여 매우 단순하고, 간단한 형태의 레퍼런스를 많이 찾아보고 이를 기반을 설계해야 할 것이다.
    • 트러블 슈팅을 기록하기 위한 문서 포맷을 준비하고, 트러블 슈팅이 발생하면 이 문서에 바로 기록하는 습관을 만들 수 있도록 하자.
      • 이렇게 해서 조금이나마 트러블 슈팅을 기록하는 것을 쉽게 습관화 할 수 있도록 도와주면 좋지 않을까 싶다.

승민

  • keep
    • 열린 소통과 긍정적인 분위기
  • problem
    • 프로젝트 환경 설정 과정에서 예상치 못한 에러가 발생하여 이를 해결하는 데 상당한 시간이 소요되었습니다.
  • try
    • 프로젝트 환경 설정에 대한 문서를 작성하고 업데이트하기

수린

  • keep
    • 실시간 소통
  • problem
    • Jira에 일정 분배를 하지 않은 부분이 있었다. → 환경설정 하는 일. 그래서 git에 commit 할 때 이슈 번호를 작성하지 못했다. → 내가 한 작업을 트래킹 하는 데 문제가 있을 수도?
    • 일에 소요될 시간 예측이 잘못 되었다. → 환경 설정이 빨리 될 줄 알았는데 예상보다 오래 걸렸다.
    • 정해 놓은 git convention에 해당하지 않는 일이 발생했다. → 브랜치에 대한 컨벤션에는 feature 관련 이름 규칙만 존재 → 이를 다른 사람한테 공유하고 함께 정하려다보면 시간 소요가 커지는 것 같음
  • try
    • 조금 걸릴 것 같은 회의도 Jira에 이슈로 만들어 놓자.
    • 컨벤션으로 정해 놓지 않은 부분은 일단 임의로 하고 왜 그렇게 했는지를 정리해 두면 좋을 것 같다. → 이 부분은 의견이 갈릴 수도

🎯팀 규칙

💻프로젝트

📃문서

☀데일리 스크럼

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

🗨️회의록

  • 회의록
  • 📚팀 회고

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

    ✍️개인 회고

    1주차
    2주차
    3주차

    🧑‍🏫기술 공유

    Clone this wiki locally