Skip to content

week2 review

hyeonggyu ham edited this page Nov 15, 2019 · 1 revision

week2 팀 회고

중점을 둬야하는 부분

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

구체적인 프로세스

사전 준비하기 (개인)

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 : 해야할 일은 잊지 않도록 정리하고 issue로 등록하는 것.
  • Problem : 의견 조율에 있어서 좋은 방법을 정하는 것.
  • Try : 1. 매 주 팀의 리더를 정해서 일요일에 해야할 일을 정하고, 스크럼을 올리고 기타 여러가지 의견낼 때 팀을 리드하면 좋겠다. 2. 다른 팀의 진행 상황을 보면서 우리 팀이 어느정도 왔는지도 확인해봐야할 것 같다. 빨리 넘어갈 부분은 넘어가고 더 좋은 것이 있다면 도입하는 것이 좋겠다. 다른 팀에서 배울 점은 배웠으면 좋겠다. 3. 기술 공유 시간이 꼭 필요할 것 같다. 같이 진행하는 프로젝트에서 매 주 어떤 feature를 담당하게 될지 모르고, 개인의 학습을 위해서도 프로젝트에서 쓰인 기술은 꼭 알고 넘어가자.

주요 사건

  1. 사소한 부분에서 의견이 잘 조율되지 않을 때가 종종 있었다.
    1. 사실(fact) : 사소한 일에 의견이 조율되지 않아서 시간을 많이 보냈다.
    2. 느낌(Feeling) : 나를 포함한 팀원들의 기분이 좋지만은 않았을 것 같다.
    3. 교훈(finding) : 의견 조율하는 부분에 있어서 좋은 방법을 찾을 필요가 있겠다.

피드백

  • 기술 공유 그라운드룰, 의견 조율 할 때 : 서로 본인 의견의 중요도를 표시하자
  • 사소한 것이 진짜 사소한 것인지 판단 (미루지 못할 것은 사소한 것이 아니다. / 팀의 priority)
  • 팀 리더 재밌어보인다.

보현

자신에 대한 회고

  • keep : 전혀 모르는 분야였던 travis, docker, nginx 를 어느정도 구현했다. / 문서화를 잘하지는 못해도 하려고 노력했다. 나중에 다시 참고할 수 있도록 / 의견을 굽히려고 노력할 때가 있었다.
  • problem : 힘들 때 까칠해졌었다. / 구현의 속도가 느린 것 같다. / 이해하지 못한 부분을 나중에 하면 되지 하고 넘기는 경우가 많았다. (canvas, redux, socket.io) / 노는 것에집중됐던 때가 있다. / 다른 팀원이 맡은 일에는 주의를 아예 꺼버리게 됐다.
  • try : 사람이 먼저다. / 속도가 느리면 오랫동안 하면 되는데 체력이 딸릴 때가 있다. 그렇다면? 속도에 구애받지 말자. / 나보다 먼저 이해한 팀원에게 이해를 구하자. / 사람이 먼저다. / 내가 데모를 해서 질문을 받았다고 생각하자.

프로젝트에 대한 회고

  • keep : 재밌게 지내고 있다. / 팀원들끼리 이해를 잘 해주는 것 같다. / 밥을 맛있게 먹고 있다.
  • problem : 나는 재밌는데 팀원 모두가 재밌게 지내고 있을까 의문 / 재밌는건 중요하지만, 본분을 다하지 못하는건 더 재미가 없다. / 밥값이 많이 나가고 있다.
  • try : 모두가 재밌는 방법을 생각해보자 / 항상 서로 체크하자 본분을 다하고 있는지 / 가끔 싼 밥을 먹자.

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

  • Travis & Docker 어려움
    • fact : 점점 구현은 됐지만, 진도가 천천히 나갔다. 영도님에게 넘겼고 현재 CI / CD 가 된다. 하지만 추가해야하는 것들은 더 있다.
    • feeling : 시간이 더 넉넉했으면 좋겠다는 느낌이었다. 팀원들에게 셀프로 공격받는 상상을해서 힘들었다.(?) 물어보고 괜찮아졌다.
    • finding : 포기하며 편하다. 공식문서를 꼼꼼히 찾아보는 일을 좋았다.
    • future : 분업을 잘하면 좋을 것 같은데.. 속도가 더 빨라지는 건 욕심 낼 부분이 아닌 것 같기도 하다.

속도

  • 왜 느린지?
  • 분업을 잘하면 좋다. 어떻게? 분업과 협업의 효율

형규

자신

  • Keep: 코어 타임을 잘 지켰다. 디자인 잘했다. redux에 대해 재미를 붙이고 공부했다.

  • Problem: git flow와 환경설정에 상대적으로 무관심했다. 너무 졸렸다.

  • Try: 커피를 자주 마시겠다. 일요일을 활용해 무관심했던 부분에 대해 배워보겠다. 이후 주차에서는 팀내 코드리뷰시간을 활용해 내가 맡지 않은 기능의 구현에 대해 알아가겠다.

  • 5F: Redux 공부

    • fact: 가장 많은 시간을 할애했다.
    • Feeling: 기분이 좋다.
    • finding: flux와 redux에 대한 전반적인 내용을 이해했다.
    • Future action: redux와 리액트 훅을 같이 쓰는 것에 대해 공부하고 redux를 실제 코드에 적용해 본다.
    • Feedback: 잘했다.

프로젝트

  • Keep: 밝은 분위기를 유지했다. 각자 맡은 바 성실히 한 듯.

  • Problem: 너무 조급해하지 않았으면 좋겠다.

  • Try: 우리 설계에 대한 자신감을 가지고, 묻고 더블로 밀고 나갔으면 좋겠다.

  • 5F: CI와 docker 설정

    • fact: 모두 처음 해본다. 가장 초점을 맞췄다.
    • Feeling: 어렵다.
    • finding: CI와 docker의 기초. 적용법
    • Future action: 이제 나에게 그것을 알려주세요.
    • Feedback: 자랑스럽습니다.

영도

자신에 대한 회고

  • keep: 지각 안했다. 맡은 이슈 열심히 했다. 커피 안먹고도 집중 잘하고 있다. (역시 팀에 주치의가 있어서 인가..)
  • problem: 문서화 잘 못하겠다. 해도 너무 난잡하게 이 파일 저 파일에 해둬서 어디에 있던 내용이었는지 까먹는다...
  • try: 맡은 일을 할 때마다, 문서화를 필수로 해야겠다. 지각 계속 안하도록 노력해야겠다.

프로젝트에 대한 회고

  • keep: 설계 중심적인 프로젝트 진행 좋다.
  • problem: 협업과 분업 그 사이에서 프로젝트가 진행된 것 아닐까. 그래서 조금은 효율성이 떨어졌던 것은 아닐까 싶다. 예를 들어, 설계가 단계적으로 진행되는게 가장 올바르다고 할 수 있을 때, 다 같이 고민하여 결정하는 것이 좋겠지만, 이 경우는 시간적으로 낭비될 수 있다고 판단해서, 다른 일로 나누어서 했지만, 이 부분은 다 같이 생각해보는 것이 어땠을까 싶다.
  • try: 중요도가 높고, 단계적으로 진행되어야하는 task에 대해서는 다 같이 의견 합의를 하는 것은 어떨까 싶다.

주요 사건에 대한 5F

  • 주요 사건: task 진행 시 시간적으로 부담을 느꼈던 것
    1. 사실(fact): 실제로 시간은 한정적이다.
    2. 느낌(Feeling): 부담스럽지만, 이 단계를 깔끔하게 마무리해야 다음 단계가 수월할 것 같은 느낌이 들었다.
    3. 교훈(finding): 하지만, 시간적으로 부담을 느끼고 분업해서 진행했던게 더 많은 것을 할 수 있지 않았을까?
    4. 향후 행동(Future): 시간적으로 부담을 느낄 때, 다시 돌아보고 고민하기?
    5. 피드백(Feedback): 우리 팀 화이팅

노트

  • 문서화하는 방법 공유 받을 예정 (이것만 하면 기술 공유왕!!)
  • 협업 분업 판단 방법 : 카드
Clone this wiki locally