• Table Of Contents

회고 템플릿

<aside> <img src="https://noticon-static.tammolo.com/dgggcrkxq/image/upload/v1606889875/noticon/c2ggzek1iwfd0yccf62r.gif" alt="https://noticon-static.tammolo.com/dgggcrkxq/image/upload/v1606889875/noticon/c2ggzek1iwfd0yccf62r.gif" width="40px" /> 4L(4Ls)

4L은 특정 활동에 대해 느낀 생각과 경험을 중심으로 회고를 진행하는 방식입니다.

• Liked (좋았던 점)
• Lacked (아쉬웠던 점)
• Learned (배운 점)
• Longed for (앞으로 바라는 점)

4L 역시 여러 상황과 여건에 적용해볼 수 있지만, 협업 프로젝트 진행 과정의 특정 지점(마일스톤)에서 구성원들과 중간 점검을 할 때 더욱 편리하게 쓸 수 있을 것 같아요.

참고 자료 : 개발자의 공유 문화 이모저모 (2) 회고 문화

</aside>

선정 배경

• 이 프로젝트의 성격은 서비스를 만들어나가는 것 보다 주니어 개발자가 모여 여러 가지 기술 스택을 적용시켜가며 프로젝트를 완성 하는 것에 가까움.
• 따라서, 프로젝트를 발전시키는 과정 내에서 배운 것에 대해 초점이 맞춰져 있음.
• 4L 방법론에는 Lacked, Learned, Longed for 이 명시되어 아쉬웠던 점, 배운 점에서 Longed For을 이끌어나갈 수 있는 방향. 특히나 배운 점이 따로 명시되어 있으므로, 학습에 큰 비중을 둔 프로젝트와 어울린다고 생각하였음.
  • 또한 지금의 프로젝트는 끝난 것이 아니고, 앞으로의 리팩터링이 있으므로 프로젝트를 1차 완성한 지금 마일스톤으로 활용하기 좋음.

4L

Liked (좋았던 점)

• 팀원들 열정은 있었음 ; 도망을 안감
• 제가 말하는거 앵간하면 피드백 줄려고 노력하는거 괜찮았음
• 프론트엔드 팀 자체는 좋았음
  • 스프린트 일 단위로 정기적으로 했던 것.
  • 코드 리뷰도 끝까지 열심히 함
  • 기술 스택 많이써서 좋았음. 전 리액트 쿼리써서 좋았다.
  • 팀 자체가 코드 퀄리티를 놓지 않으려고 했음.
  • 포기 안한 거
  • 디자이너가 제시한거 안된다고 안하고 다 만듬
• DND 동아리 자체에서 제공하는 가이드라인이 좋았음
  • 하나하나 마일스톤이 좋았음. 특히 데모 (중간 포인트), 자료 많이 첨부해주셨고, 기획 쪽이 체계적이였음
  • 기획쪽은 현직 안가면 배우기 힘들고, 개발쪽은 더 그럼.
    • 자료나 레퍼런스 자체를 찾기가 어려웠는데 가이드라인을 통해서 확실히 볼 수 있었다.

Lacked (아쉬웠던 점)

• 솔직하지 못한 태도
  • 저희쪽에서 조금 더 열린 마인드로 다가갔으면, 아이스 브레이킹을 잘했으면 더 잘 공유해주지 않았을까?
  • 분위기가 되게 중요한 듯, 팀 분위기에 따라서 할 수 있는 말과 없는 말이 있다.
  • 아이스 브레이킹에 소홀 했음.
  • **우리가 실행해 본 팀원 모두 함께 할 수 있는 팀 빌딩 게임 3가지 (마켓컬리 기술블로그)**
  • 소통이 잘되는 분위기를 미리 만들어두는게 나중에 소통 때문에 발생하는 비효율성을 완화할 수 있다. 특히 마지막 쯤엔 감정이 상하기 때문에
• 팀원 들이 말이 별로 없었다. 열정이 없는건 아니였는데…… 내가 말하는게 맞을까? 라는 의구심
• 전체 kpt를 1주일 마다 했었으면 어땠을까? kpt를 일찍했으면… 팀 분위기의 문제
  • 프론트엔드도 kpt 도입했으면 더 깔끔했을 듯?
• 전체 팀 분위기가 화기애애 했다면 완성이 안되더라도 여유롭게 가져갔으면 어땠을까라는 생각이.