week3 review

week3 팀 회고

중점을 둬야하는 부분

• 회고할 때 나는(혹은 다른 사람들은) 부정적 감정을 무시하지 않으면서 전반적으로 긍정적 감정을 많이 겪는가?
• 회고할 때 나는(혹은 다른 사람들은) 점차적으로 생각을 더 적극적으로 해서 새로운 이야기를 만들어 가는가?
• 회고할 때 나는(혹은 다른 사람들은) 시각의 전환을 자주 하게 되는가?
• 낙관적으로 회고하되 부정적인 사건을 인정해야 그 회고의 효과가 높다.

구체적인 프로세스

사전 준비하기 (개인)

1-1. (회고가 처음일 경우) 회고에 대한 이해 1-2. 어떤 방식으로 회고를 할 것인가에 대한 정리 (with 회고하는 인원) 1-3. 무엇을 회고할 것인가 (targeting) (with 회고하는 인원) 1-4. 자신을 회고 1-5. 프로젝트에 대한 회고 회고 (Check-In) 2-1. (정한 회고 방식에 따라 진행) 마무리 3-1. 감사인사 회고의 회고(의 회고의 회고의 ..)

KPT

K, P, T를 기준으로 action item을 도출한다.

Keep, Problem, Try 세 부분으로 나눈다.

• Keep: 좋았던 점을 기반으로 도출되며 앞으로 프로젝트를 진행할 때, 계속 유지해야할 사항
• Problem : 아쉬웠던 점을 기반으로 도출되며 앞으로 프로젝트를 진행할 때, 개선되어야 할 사항.일어난 사건 자체 뿐만 아니라 좋았거나 나빴던 일에 이르는 과정에 대해 쓰는 것이 좋다.
• Try : 도출된 problem의 원인을 파악하여 이를 기반으로 어떠한 시도들을 해볼 수 있는지에 대한 내용. Try을 고려할 때 포인트는 구체적인 액션에까지 구체화 시키는 것이 중요

주요 사건을 5F로 공유하기

• 5F란 다음을 의미한다.
  1. 사실(fact)
  2. 느낌(Feeling)
  3. 교훈(finding)
  4. 향후 행동(Future)
  5. 피드백(Feedback)

JFYI

불보듯 뻔한 회고는 안하느니만 못하다. 당연한 얘기보다 내면에 있는 솔직한 이야기가 수면 위로 드러났을 때, 비로소 제대로 된 회고가 될 수 있다. 진척 회의는 반드시 별도로 진행한다.

희선

자신의 회고

• keep : 이번주에 해야할 일을 다 끝내려고 노력했다.
• Problem : 다른 팀원들의 코드를 이해하는데 어려움이 있었다.
• Try : 기능이 끝날 때마다 진행하는 코드리뷰 시간에 코드를 이해할만큼 꼼꼼히 봐야할 것 같다.

팀 회고

• keep : backlog를 할 수 있는데까지 하려고 노력한 것.
• Problem : 각각이 맡은 backlog의 의존성이 있었고, 하나의 기능을 개발할 때 되어있지 않은 부분도 만들어야해서 중복적인 코딩을 하는 상황도 발생했었다.
• Try : 1. 이번주에 개발할 기능에 대해 의존성이 없도록 잘 나누어본다. 2. 테스트 코드를 작성한다.

주요 사건

1. 팀원들(나포함) 컨디션이 안좋을 때가 종종 있는 것 같다.
   • 몸 관리를 잘하자요!!! 힘들면 잠시 쉬고 열심히 하는게 더 좋아요!
2. 같은 기능을 여러 팀원이 따로 개발한 일이 발생하였다.
   • 본인이 맡은 기능에서 꼭 필요한 부분만 개발하도록 해요. 그리고 다른 사람도 같은 부분에서 개발을 하고 있다면 진행 상황을 꼭 공유하도록 합시다. 그리고 api 문서도 가능하면 쓰면서 명확하게 해두면 더 좋을 것 같습니다!

피드백

• 보현 : 중복되는 부분을 해결하는 방법을 생각해보는 것이 좋을 것 같다 / 테스트 코드도 꼭 해보자
• 영도 : 중복되는 부분을 나누기보단 서로 대화를 많이 해서, 해결을 하자. 이번주에 저만 한 번 더 쉰 것 같아서... 정말 힘들면 쉬셨으면 좋겠다.
• 형규 : 컨디션 공감한다. 중복기능의 경우.. 하지만 방향이 달랐고 그걸 인지하고 있었기 때문에 더 좋은 코드가 무엇인가 고민할 수 있었어서 난 좋았다.

보현

자신에 대한 회고

• keep : docker-mysql 한글 한글화와, 암호 암호화를 성공적으로 수행했다. / 문서화도 꾸준히 해서 기술공유할 때 미리 작성한 문서덕분에 좀 더 편했다. / 코드작성에서 열정을 느꼈음. 다만 몸이 힘들었음. / 페어프로그래밍 요청을 잘 한 것 같다. / 팀에게 코드리뷰를 받은게 좋았음
• problem : 구현은 내 속도대로 했는데 스스로 마음을 급하게 먹었다. / 구현 시 다른 부분들까지 지나치게 구현 욕심을 내다가 시간이 지나치게 많이 걸렸다. / 감정 관리에 실패 1회 해서 분위기를 좀 안좋게 했다. / 클라이언트 측 구현을 현재 socket이후에 1번도 안했다. 그래서 클라이언트 측 구현 방식과 리액트, 리덕스 구조에 대한 이해가 부족하다.
• try : 브레이크문을 설정해야 할 것 같다. / 최소한만 하도록 노력하고, 조금이라도 구현이 이상할때는 중간중간 팀원에게 체크를 받자. / 빠르게 코드를 작성하고 리뷰를 받는게 좋을 수도 있겠다. / 다음주에는 필수적으로 client쪽 기능 구현을 맡도록 하겠음 / 반대로 인프라는 나와 영도님이 많이 한 것 같아서 팀원이 할 수 있는 기회를 마련해줘도 좋을 듯 하다.

프로젝트에 대한 회고

• keep : 편해지고 있음(좋은 의미로) / 팀원들이 서로 이해를 잘 해주는 편인것 같다. / 밥을 여전히 맛있게 먹고 있다. / 구현을 잘 해나가고 있는 것 같다. / 의견 오가는 횟수가 많은 것 같음
• problem : 3주차 구현을 목표한대로 못했음 / 까먹고 있는 것들이 있다.(redis, project todo doing done, api문서, 테스트코드, git tag, 커밋으로 이슈 닫기또.. 까먹고 있으니까 뭔지도 모르겠지?) / 속도는 여전히 궁금함, 이 속도가 우리가 최선을 다했을 때 맞는 속도일까? / 최선의 답이란 무엇일지? / 서로 기능이나 구현에 대한 이해의 차이가 있는 것 같다.
• try : 구현을 목표한대로 못하는 이유에 대한 분석? 회고 타임 / 이슈를 많이 남기기 / 오늘 토론 / 지속적인 얘기가 필요하지만 시간이 너무 느려지지는 않을까?

사건에 대한 회고 (종합, 5F)

• 서브웨이 먹었을 때
  1. 사실(fact) : 내가 피곤해 보여서 집에 가는걸 제안했고 나는 기능 구현을 더 하고 싶었어서 거절했는데 그 과정에서 분위기가 좀 안좋아졌음
  2. 느낌(Feeling) : 미안함과 서운함이 있었다.
  3. 교훈(finding) : 욕심을 버려야 하나? 말을 잘들어야 하나?
  4. 향후 행동(Future) : break문을 설정 (3명 모두 동의)
  5. 피드백(Feedback)

피드백

• 영도: 서브웨이 먹었을 때, 기분 안좋았었나? 전혀 기억이 안난다;;; 이슈 무조건 남기는 것 좋다. 슬랙에 잊기 않을려고 올리는 것, 이슈에도 올리자. 오늘 기능 개발하면서 느낀점은 속도 느리지도 빠르지도 않다고 생각한다.
• 형규: 클라이언트 리덕스 이해안가면 유튜브 강의 추천. 타인의 말을 너무 깊게 생각하지 않아도 될 것 같다.
• 희선: 몸이 안좋으면 쉬어도 좋다는 얘기여서 보현님이 기분나빴는지. 분위기가 안좋았는지 그건 몰랐다. 그냥 밥먹을 땐 개발 얘기말고 편한 얘기하면서 지내고 싶다. github project 관리는 꾸준히 해야할 것 같다.

형규

자신

• Keep: 여전히 지각은 안하고 있다. 좋은 코드를 항상 염두하는 것.

• Problem: 여전히 하드코딩의 흔적이 있다. 정작 내 이슈는 많이 못한 것 같다.

• Try: 코드리뷰 결과를 받으면 그에 따라 구조를 얼른 잡고 기능을 조립하듯이 추가해보자.

• 5F: 서버의 컨트롤러와 모델 구조

  • fact: 완성이 안됐다.
  • Feeling: 안타깝다. 하지만 감은 잡혔다.
  • finding: 모델이 socket에 의존하지 않게 하는 것이 과연 정말 좋은 것인가? 생각해 볼 문제라는 걸 찾았다.
  • Future action: 코드리뷰를 보냈으니 답을 기다리고, 만족스럽지 않으면 help master를 이용한다.
  • Feedback: 이번엔 의존도가 아니라 복잡성을 개선하는 구조를 짜보면 어떨까

프로젝트

• Keep: 열심히 하는 것. 서로의 코드에 관심을 가지는 것. 서로 코드 리뷰해주는 것

• Problem: 너무 열심히 하려다보니 번아웃이 조금씩 되가는 것 같다. 컨디션이 안좋아지는 문제도 있다.

• Try: 홍삼..? 수액..? 몸 생각하면서 하자!

• 5F: socket

  • fact: socket을 사용해서 실시간 통신이 된다.
  • Feeling: 기쁘다.
  • finding: 하지만 관련 버그가 많다는 걸 알았다. 새로고침, 다른 탭에서 창 열기, 가만히 있다보면의 상황들에서 소켓이 재연결되는 현상.
  • Future action: 일단 핵심 기능을 먼저 구현할지 아니면 버그를 고칠지 고민해봐야 할 듯 하다.
  • Feedback: 분명히 다른 사람들도 같은 이슈를 겪었을테니 구글링을 해보고, 소켓쓰는 다른 팀에도 물어보고 마스터에게도 물어보자. 아니면 세션, 쿠키 관리를 고려해야 할 수도 있다.

피드백

• 영도: 저는 삼 필요없어요 아직;; socket은 바로 쓰지말고 하나의 객체로 감싸야할 것 같아요... 근데 어려워서 아직 잘모릅니다 ㅎ.ㅎ
• 보현: 태도가 좋다. 홍삼 대체 가능성이 높은 한약을 갖고 오겠다.
• 희선: 소켓과 관련한 이슈는 공감합니다. 많이 개선하고 예외처리가 필요할 것 같아요. 지각안하는거.. 본받아야한다.! (하지만 버스가 막히면 답이 없다.)

영도

자신에 대한 회고

• keep: 이슈는 열심히 하는 중이다. 커피 한모금도 안먹었다. 👍
• problem: 문서화 또 못했다. 잘 까먹는게 문제...
• try: 이번 주말에 했던 일 문서화 해놔야겠다. 지각 계속 안하도록 노력해야겠다.

프로젝트에 대한 회고

• keep: 서로 겹치는 일을 하면서도 잘 협의하면서 진행하고 있는 것이 보기 좋다.
• problem: 그래도 겹치는 일을 따로 하다보니 일이 병렬적으로 진행되는 현상이 일어나긴 한다. 그리고 서로 한 일을 아예 모르게 되는 경우도 생기지 않나 싶다. (예를 들어, 보현님이 현재 프론트 어떻게 구현되어있는지 모르는 것과 제가 travis 암호화 어떻게 했는지 모르는 것처럼)
• try: 병렬적으로 진행되서 커밋 충돌나는 경우는 이번주에 했던 것처럼 회의실을 빌려서 함께 논의하며 진행하면 좋을 것 같다. 그리고 서로 모르는 일이 생기는 현상 방지는 일요일에 서로 이번주에 한 것에 대해 공유하는 시간을 가지면 좋을 것 같다.

주요 사건에 대한 5F

• 주요 사건: task 가 가끔 병렬적으로 진행되는 현상
  1. 사실(fact): task가 순차적으로 구성되어 있다. 사람은 4명이고 시간은 널널하진 않다.
  2. 느낌(Feeling): 비효율적일 수도 있지만 긍정적인 부분이 있지 않을까? 서로 같은 문제를 보고 풀이가 다를 수 있는 것처럼
  3. 교훈(finding): 그래도 서로 간의 현재 진행 task와 겹치는 부분이 생길 것 같으면 빠르게 공유하는 것을 지속해야한다고 생각한다.
  4. 향후 행동(Future): 오버 커뮤니케이션 ㄱㄱ
  5. 피드백(Feedback): 우리 팀 화이팅!!!

피드백

• 보현 : 👍 드리구요, 문서화 팁: 본인을 의심하는게 좋을 것 같습니다., 한 문제 여러 시각에 대한 feeling이 아주 좋다.
• 형규 : 오버 커뮤니케이션 팁: 상대방을 의심하면 된다. 저사람 뭐하는거지? 지금 어디하고 계세요? 이러면 자연스럽게 서로의 진행상황을 공유할 수 있다. 깃헙 프로젝트의 doing도 적극 이용하자.
• 희선 : 문서화는 어렵게 생각하지마시고 내가 공부한 것을 다른 사람에게 쉽게 이해할 목적으로 작성해보세요.

이번주 일요일 할 일

• UI 디자인 완성
• test code 작성 (어떤 단위로 테스트 할 것인지)
• 보드게임 (우리 서비스 기획 향상을 위하여.) - 필수

회고의 회고

• 중복된 코드가 왜 발생했나?
• api문서 (깃북, yaml?, JSDoc은?)
• 까먹고 있는 것
  • redis
  • project todo doing done
  • api문서
  • 테스트코드
  • git tag
  • 커밋으로 이슈 닫기
  • 해결방안 : 포스트잇 가져와야겠다.
• GDD, 홍삼대체품
• 지각 안하는 노하우
• 한 일 공유
• 기술적인 회고 위주였다.(규)
• 홍삼에 대한 대한민국 사람들의 의식이 안타깝다😢 (현)