어쩌다 보니 스프린트 2번째 회고 내용을 한 달 가량이 지나서야 작성하게 됐다..;;
그 동안 논 것은 아니고, 사실 일주일 기간동안 진행된 스프린트가 종료된 후에 팀원끼리 더 디벨롭 시켜서 만들고자 얘기가 됐었다.
그래서 현재 작성 시점까지 열심히 추가 개발을 이어왔다.
(사실 핑계지 뭐.. 이거 쓸 틈이 없었겠는가.. 자아성찰, 자아비판)
늦어지긴 했지만 안하는 기록보단 의미가 있는 법. 자아성찰을 품고 시작.
짧은 개발 기간
일주일의 스프린트 기간인데다가, 개인적인 경험상 팀업과 스프린트 그 자체를 겪어보는 것에 주된 의의가 있다고 느꼈다.
스프린트 미팅을 진행하는 모습
그리고 데모시연까지 품고 있다보니 제대로 시연을 하려면 제대로된 결과물이 있어야 하고, 그러려면 당연히 기획 단계에 힘을 쏟을 수 밖에 없다(실제 실무에서도 마찬가지고).
그래서 일주일 중 개발 기간은 단 2일이다.
주말 이틀 포함 일주일인데 이 주말간 개발이 진행된다.
개발 준비
앞서 스프린트 18기 회고(1)에서 말했듯이 개발에 들어가기 전 개발 스택과 컨벤션은 정해졌었다.
추가적으로 form과 관련해 react-form-hook을 기반으로 한다. 여기에 zod를 얹는 것.
그리고 업무 할당은 PL과 각자 공수 체크를 해서 분담하게 되었다.
분담 기준은 화면 > 유저 플로우를 기반.
이때 도움이 되는게 이 직전까지 진행한 스프린트 과정이었다. 이미 BDD를 통해 정해둔 유저 플로우들이 있었기 때문에 이를 통해 추론되는 기능들을 기반으로 하였기 때문.
개발 진행
준비는 이미 되었었다고 보면 되고, 주말이 시작됨과 동시에 개발도 시작.
각 유저플로우에 따라 나온 기능들에 티켓 넘버링을 하고, 진행 상황은 아래 카테고리에 대해 피그잼을 통해 체크하며 공유하였다.
- FE
- 화면 UI
- 기능 연결
- BE
앞서 말했듯이 스프린트 중 개발은 이틀이었기에 순식간이다. 게다가 급박하게 돌아가다 보니 생각만큼 각 화면과 기능의 연결이 매끄럽지 못하단 느낌을 받았다ㅠ
그리고 스프린트에서 구하지 못한 디자이너를 따로 구해 합류시키게 되었는데, 우리 일정과 디자인 일정이 맞지 않아 데모 시연은 내가 만든 와이어 프레임 수준으로 진행하기로 하였다.
다들 계속 발전시킬 마음이 있었으니 일단은 데모를 진행하고, 나중에 디자인을 얹어 발전시키자 얘기를 했다.
그렇게 짧았던 이틀은 순식간에 지나가고 월요일까지 진행된 개발은 데모 직전까지도 진행되었다.
그리고 결국 데모날..
데모 시연
최종 데모때 못 온 팀들도 있었다. 이걸 보면 우리팀은 다행이다 싶긴하다. 탈주하는 사람도 없었고, 공중 분해되지 않았으니 말이다.
다같이 모인 데모날 각 조의 서비스 컨셉에 대한 설명과 발표를 짤막하게 하고, 1:1 팀매팅을 하여 데모를 진행하게 됐다.
서로가 서로의 서비스 결과물을 경험해보며 아쉬운 점에 대해 피드백 하는 것.
우린 그럼 어디까지 완성을 했을까?
스케이트 보드 설계는 됐는데..
위 내용은 테오의 스프린트 진행과 관련된 메일 중 일부를 발췌한 것이다.
이 중 임팩크가 가장 크게 오는 것이 "바퀴를 보여주는 것 보다는 스케이트 보드를 보여주는 것이 더 임팩트가 클 것"이라는 부분이다.
이전 직장에선 거의 워터폴 방식으로 했기에 바퀴->하부->상부->자동차 같은 방식으로 진행했는데 이번 스프린트를 겪으며 스프린트의 핵심을 짚는 말이지 않을까 싶었다.(아닌가?ㅎ)
여하튼.. 그래도 저럴 수 있도록 스케이트 보드까진 만들었다고 생각했는데, 우린 문제가 있었다..
중요한 것은 배포.. 그리고 배포
애초 스프린트 시작 OT때 계속 강조한 것이 있었다.
꼬옥 배포를 신경쓸 것..! 데모를 하려면 시연할 결과물이 있어야하니 꼭 배포를 먼저 신경써서 체크할 것이었다.
우리도 분명 인지하고 있었다. 그러나 배포 과정에서 문제가 있을 것이라곤 생각지 못한 것이었다.
우린 배포를 데모날 오전에 진행했다.
vercel을 이용해 배포를 하기로 했고, 이럴 때 못해본 분이 경험해보면 좋으니 해보고 싶어했던 분이 진행을 하게 됐다.
그런데 우리끼리 합이 맞지 않아서 인지 배포 단계에서 계속 오류가 발생했다..ㅠ
애초에 작업 공간이 organization이었던 것도 초반엔 문제가 됐고, 이걸 해결하는 과정에서 시간이 걸렸다.
결국 우린 데모 때 배포를 마무리하지 못했다.
그래서 1:1 팀 매칭 후 상대 팀에게 양해를 구하고 우리만 다른 팀의 결과물을 시연하고 피드백을 주게 되었다.
1:1 이후엔 자유롭게 돌아다니며 다른 팀과의 피드백을 진행하면 됐는데, 우린 배포된 것이 없으니 붕~ 떴다.
그저 아쉬울 따름.. 왜 초반에 그렇게 배포가 강조 됐는지 알 것 같은 대목이다..
그래도 피드백은 받아야지!
하지만 이대로 이 시간을 허비할 순 없었다.
공유할 배포 링크가 없어도 내 화면을 공유해서라도 보여드리고 아이디어를 받으면 좋지 않겠는가?
처음 매칭됐던 팀의 피드백을 드린 후 괜찮다면 화면을 공유드리고 서비스 진행과 컨셉에 대해 설명드리고자 했다.
상대 분들도 흔쾌히 받아주셨고, 내 화면을 공유드린 뒤 진행 방식에 대해 설명드렸다.
그 결과 몇가지 피드백을 받을 수 있었다.
우리가 이미 알고 있던 것도 있지만, 모르던 것, 혹은 아이디어들이 있었다.
만약 최소한의 노력도 안했다면 이런 피드백조차 받을 수 없었겠지?
회고 진행
각 데모와 피드백 시간이 끝난 후 다시 팀시간으로 돌아갔다.
이제 진짜 스프린트의 마무리 시간, 각 팀별로 회고를 해보는 것이다.
회고 또한 피그잼에서 진행~ 이번에 처음 써본 피그잼이지만 꽤 쏠쏠한 거 같다. 기능적으로도 재미적으로도.
여하튼 회고는 3개의 주제에 4가지를 돌아보게 되었다.
주제
- 우리의 결과물
- 협업과 우리팀
- 스프린트와 나
4가지 섹션
- 좋았던 점
- 새롭게 배운 점
- 할 수 있었는데 아쉬운 점
- 개선해야 할 점
각자 위 부분들에 대해 생각을 적고, 서로 얘기하며 공유와 위로(?)의 시간을 가졌다.
난 다시금 회고를 하고 있으니, 이 시기 기준으로 회고를 개인 회고를 다시 정리해보자.
다시 하는 회고
이번 스프린트에서 난 무엇을 경험하고 얻었는가?
좋았던 점
1. UIUX 담당과 기획의 경험
일단 UIUX 담당자로써 서비스 컨셉과 기획을 할 수 있는 기회를 가졌던 것, 그리고 다행히도 그 결과물이 팀원들의 공감을 이끌어 냈다는 것은 스스로 뿌듯하고 잘한 점이라고 생각한다.
2. 기술적 경험
또한 기술적으로도 새로운 것을 접할 수 있었던 것이 좋았다. pnpm은 다른 것과 무엇이 다른 패키지 매니져인가?
다시 경험해보는 tailwind는 어떠할 것인가?
실제로 pnpm은 꽤 나쁘지 않았고, tailwind는 여전히 내 취향은 아니지만 지금 디벨롭 과정까지 쭉 진행하며 사용하면서 이전 같은 불편함은 덜게 되었다.
3. 스프린트 그 자체
또 스프린트를 경험한 것 그 자체가 나에겐 좋았던 점이다.
기존 중소 규모의 회사에선 절대 경험해보지 못했을 것이었다,, 매일 빠르게 치는 것이 우선이고, 이전 직장의 작업 방식은 개인적으론 어느 방법론이라 할게 없었다.
그런데 이번 18기를 통해선 BDD, SDD 등 새로운 방법론도 알게 되고, 스프린트 과정의 협업 또한 경험할 수 있어 매우 좋았다.
+) 그리고 비록 배포까지 마치진 못했지만 팀원들의 이탈없이 마무리했다는 것도 좋은 점이라고 생각한다.
아쉬운 점
1. 배포를 놓친 것
팀원 전체의 패착으로, 분명 OT에서도 강조되었지만 너무 안일하게 생각했던 점이다.
애초에 CICD를 먼저 잡고 갔어야 했다.
그래서 merge되는 대로 결과물이 반영되어 눈으로 확인될 수 있게 했어야 했다.
그랬다면 이번 데모 직전 배포 이슈를 미리미리 잡을 수 있었으리라ㅠ
왜냐하면 어느시기 무엇이 원인인지 트러블 슈팅이 보다 쉬웠을 테니까.
2. 디테일한 문서화
이건 내 스스로 아쉬운 점이면서 새롭게 배운 점이다.
내가 컨셉과 기획을 잡다보니 UI 배치나 플로우에 각 의미가 있었다. 근데 내 기본 컨셉에 다른 팀원들의 좋은 의견들을 흡수 합병시키는 과정에서 약간씩 혼선이 생기는 것 같았다.
물론 한번 짚고 넘어가서 다들 이해를 했었다.
그런데 아무래도 모두가 다 한번에 기억을 하고 있는 것은 아니었고, 나중에 다시 봤을 때 헷갈려 하는 경우도 있었다.
이때 든 생각이 "한 번 정리해서 이해시켰다고 끝날 것이 아니라 좀 더 투자해서 문서화를 해둘껄"하는 생각이었다.
그랬다면 작업 간에 계속 나를 불러 다시 물어보는 일도 줄고, 다시 꺼내 봤을 때 헷갈리는 일도 줄지 않았을까?
짧은 시간에 치여 놓친 아쉬운 부분 중 하나였다.
3. 짧은 코드리뷰 시간
개발이 단 이틀동안 진행되었고, 빨리 결과물을 내야하는 상황 속에 PR이 계속 쌓이니 오랜 시간 코드리뷰를 가질 수 없었다.
여유롭게 시간을 가지기엔 계속해서 작업물 PR이 쌓이고, 늦은 merging은 어떤 conflict를 또 낼지 모르기에 모두의 컨펌이 아닌 한 명 이상의 컨펌이 나면 머지시키도록 약속을 하고 진행하게 됐다.
그래서 나중에 머지된 PR을 보고 뒤늦은 질문과 수정 요청사항이 생겨도 PR상에는 이미 늦은 상태였다.
하는 수 없이 별도 협업 도구인 디스코드를 이용해 추가적인 피드백을 주고 이후 PR에 반영되도록 할 수 밖에 없었다.
물론 데모 직전까지 MVP 플로우를 만들어야 하니 어쩔 수 없는 선택이었긴 하다.
그래서 스프린트의 개발 시간이 하루 이틀만 더 있어서 좀 만 더 여유있는 코드 리뷰 시간을 확보할 수 있다면 좋을 것 같다는 후기이다.
여기까지가 스프린트 자체의 회고는 끝이다.
일주일 스프린트로 보면 어쩌면 알맞는 시간, 처음 경험하는 나에겐 짧은 시간.
무엇이 되었건 다시 몸을 바쁘게 움직이게 만들고 여러가지 경험을 쌓을 수 있던 시간이었고,
여러가지를 배울 수 있었다.
이후엔 한달여가 지난 지금 시점(1월 초)까지 제대로된 하나의 서비스를 만들기 위해 팀원들과 추가 개발을 진행하였고 현재 홍보 직전까지 왔다.
이젠 이후 디벨롭 과정에 대한 회고를 할 예정. To be continued..
