🔉 가상 뀨 MC : 안녕하세요 인터파뀨 여러분들! 2주동안 열쩡!열쩡!열쩡! 가득하신 모습으로 프로젝트에 임하신 모습이 인상깊었습니다! 공식 프로젝트 기간이 끝나서 프로젝트 회고를 가져보려고 하는데요, 회고를 시작하기 전에

이번 프로젝트를 짤로 표현해볼까요?

• 🔉 다희

  

• 🔉 상민

  

• 🔉 휘년

  

  리액트로 슥슥 할 수 있지 않을까? ¯\(ツ)/¯ 응 아니야~ (ಥ⌣ಥ)

어? 내려줘야 되는 데이터를 싹 바꿔야 되네? 어?? 어?????? 어어어어!?!?!?

다들 몸이 안좋아도 열불코딩 ㅠㅠ

🔉 가상 뀨 MC : 그러셨군요! 첫술에 배 부르랴, 라는 속담이 있듯이 모든게 완벽할 수는 없었을 것 같은데요. 이번 프로젝트를 진행하면서 개발 과정, 협업 프로세스, 개인적인 사정, 스프린트 분배 등등 포함해서

아쉬웠던 점이나 어려웠던 부분이 있었을까요?

• 🔉 다희
  • API 엔드포인트를 너무 크게 잡았던 부분을 조금 더 깊이 생각했으면 개발 전에 더 잘게 쪼갰을 수 있었을 것 같다.
  • 개발 초기 단계에서 필요한 공통 코드 작성 부분을 티켓으로 만들지못했고, 중복 작업이 발생한 부분이 조금 있었음.
  • 스토리 포인트 예측 너무 어려웠다.
  • 2주라는 기간동안 바닥부터 시작해서 협업 + 개발을 진행해야 했고 빌드업하는 시간이 당연히 길 수 밖에 없어서 욕심만큼 개발 기능을 많이 못만들었던점. 3주만 되었어도 욕심을 더 내볼 수 있었을 것 같음.
  • PR 디스크립션이 중구난방이었음.
  • 버그 있는 코드 그대로 머지했음.
  • 스프린트 시작할 때 티켓을 모두 만들고 분배하고 시작했음에도 불구하고 스프린트 도중에 생성된 티켓이 많았음.
• 🔉 상민
  • PR의 지체 : 나중에는 다소 유연하게 갔지만 처음에는 모두에게 리뷰를 받다보니 머지가 느렸다.
  • 스토리 포인트를 예측하기가 어렵다.
  • 프로젝트 보일러 플레이트의 부제가 아쉬웠다.
  • 동시성 문제 해결까지 해보지 못해 아쉽다.
• 🔉 휘년
  • 커뮤니케이션
    • 단어, 용어의 기준이 개인마다 차이가 있을 수 있다는 점을 간과했다.
    • 명확한 결론이 나지 않은 채 포괄적인 결정사항이 많았던 것 같다.
  • 티켓 만들기
    • 정확히 독립적으로 수행될 수 있는 작업단위로 나누어서 각자가 가져가야 하는데 종종 특정 티켓에 종속적인 티켓이 서로다른 사람에게 가게 된 것 같다.
      • 시작부터 종속적이지는 않았는데 도중에 이슈 내용 변경으로 종속적이 된 듯.
  • API 응답을 좀 더 체계적으로 생각했어야 했던 것 같다.
    • 시작도 하기 전에 결정하는것은 (아직 경험이 없어서) 무리이겠지만, 실상 처음에 생각했던 응답 데이터 형식을 지킨 API가 하나도 없었다. 모두 변경이 발생...
    • 좀 더 이 설계가 잘 이루어졌다면 하루이틀정도의 시간이 더 생겼을지도?
  • Jira Cloud에서 story point estimate밖에 지원해주지 않는다.
    • 설치형 서버에서는 [Todo] → [In Progress]에서 예상시간, [In Progress] → [Review] 단계에서 실제 작업시간을 적을 수 있어서, 예상치와 실제값을 비교해가며 바로잡아갈 수 있었는데 이부분이 없는게 아쉽다.

🔉 가상 뀨 MC : 각자 생각하는 회고의 정의가 조금씩 다를 것 같지만, 제가 생각하는 회고는 앞으로 개선점을 찾고 더 잘해보고자하는 프로세스라고 생각합니다. 그런 의미에서 이번 프로젝트에서 개발 과정, 협업 프로세스, 개인적인 사정, 스프린트 분배 등등 포함해서

개선하면 좋을 점이 무엇이 있을까요?

• 🔉 다희
  • PR 디스크립션 템플릿을 만들면 좋겠다.
  • 머지 전에 버그 체크할 수 있는 프로세스 도입하고 싶다.
  • 정말 어려운 일이지만 스토리 포인트 관리(예측 시간, 실 작업 시간 차이 측정)를 좀 더..잘하면 좋을 듯
• 🔉 상민
  • PR의 지체 : Ship / Show / Ask 전략으로 PR 해본다. 대신 먼저 테스트 자동화된 CI 파이프라인이 필요하다.
  • 보일러 플레이트의 필요성을 느꼈고, 개인적으로 하나 만들어야겠다.
• 🔉 휘년
  • 커뮤니케이션
    • 커뮤니케이션을 할 때 무언가 새로운 결정 사항이 생기는 경우에는 정말 바닥부터 구체적으로 따지고 올라가며 결정사항들을 명시적으로 기록 해 두어야 할 것 같다.
    • 포괄적인 결정사항들은 개인이 작업하기에는 유연성이 생겨서 좋지만, 여럿이서 같이 작업을 할 때에는 커뮤니케이션 비용을 늘릴 수도 있는 양날의 검인 것 같다.
  • 새로운 티켓은 정말 급한 사항이 아니라면 당일의 워킹타임 도중에 생성 및 시작하지 않는다.
    • 보통 스크럼 시에 현재 나와있는 티켓들을 같이 확인하고 + 각자의 작업 티켓들을 확인하게 되는데 도중에 티켓이 추가 및 작업이 시작되면 그 변경사항을 따라가지 못할 수도 있다.
    • 새로 생성된 티켓의 변경사항이 다른 사람의 작업에 영향을 주는 내용이라면 다음 스크럼 등에서 이런 티켓을 생성했고, 작업할 예정이라는걸 명확하게 공지하는 시간이 있었으면?

🔉 가상 뀨 MC : 오~ 그러셨군요! ~~~~ 그렇다면 분명 잘하셨다고 생각하신 점도 있었을텐데요. 아~ 우리팀 이거 하나는 끝장나게 잘했지~, 우리 팀원 분들 이런거 정말 잘했지, 아 나 그래도 이건 진짜 잘했지~ 싶은 것도 있겠죠?? (없다구요? 잠깐 면담 한번 하시죠~~)

잘한 점을 마음껏 뽐! 내볼까요?

• 🔉 다희
  • 팀 : 프로젝트에 투자하는 시간과 노력과 열정이 모두 다 비슷했던 점! 단합 짱 잘되었음! 팀에 필요한 정보나, 문서같은거 서로 조사해오기로하면 다들 최선을 다해서 조사해오셨음!
  • 휘년 : 초기 프로젝트 빌드업할때, 추가적으로 인터파크 api 분석, 프론트 페이지 구상해주셔서 빠르게 진행할 수 있었음. 비동기 커뮤니케이션 활발하게 잘 해주셨음! 변경사항이나 문제가 있으면 바로바로 알려주심!
  • 상민 : 코드 작성시에 개선점, 고민 포인트를 빠르게 공유하고 적극적으로 코드 개선해주심. 백신맞고 골골거리는 상태임에도 불구하고 맡은 바 최선을 다해주심! 개발 열정 뿜뿜! 습득 속도 빠름! 개발 멋쟁이~
  • 본인 : 인터파뀨 노션 문서화 너무 잘했음! (뿌듯), 분위기 잘 이끌었음! (뿌듯), 프로젝트 개선사항 빠르게 공유하고 개선시킴! (뿌듯).