지난 회고에서 무엇을 만들지에 대해 어떻게 정하게 되었으며, 기술과 환경적인 검증을 위해 프로토타이핑을 하여 세부적인 기획을 할 수 있었다는 것을 기술하였습니다.
이번 회고에서는 어떻게 팀원들과 의사소통을 하며 프로젝트를 진행하였는 지 기술해보겠습니다.
협업 도구
의사소통을 위한 도구를 선정하는 기준은
- 팀원 모두 손쉽게 사용할 수 있거나, 사용해봤으며
- 캘린더, 칸반보드, 메모장의 기능을 한 곳에서 관리할 수 있으면서
- 무료 플랜인 것
이였습니다.
많은 도구를 써보진 않아서 그럴 지 모르지만 이에 적합한 것은 Notion 밖에 없다고 의견이 통일되어
캘린더 기능을 통해 개인, 소프트웨어 마에스트로 및 팀 일정 관리, 날짜별로 나누어 회의록 작성, 개발 분야별로 나누어 사용 스택 및 환경을 공유하였습니다.
무적의 캘린더
프론트엔드 디렉토리 패턴 설계서
일정 관리
저는 소프트웨어 마에스트로 과정 전에는 에자일이란 단어를 들어본 적이 없습니다
협업 경험이 많으신 팀원분께서 에자일 방법론을 설명해주셨고, 다양한 멘토님들이 에자일 방법론에 대해 설명해주셨습니다.
제가 생각한 에자일 방법론의 가장 중요한 키워드는 비즈니스의 변화의 쫓아가기 위한 방법이였습니다.
소비자의 니즈는 정확히 예측할 수 없기에, 지속적으로 검증하는 방법으로 이해하였습니다.
하지만 저희의 상황은 다음과 같았습니다.
- 기술, 환경적 검증을 위한 프로토타이핑을 하였기 때문에 다소 촉박한 시간
- 중간 발표, 최종 발표, 멘토링 등 프로젝트 개발외에 투자할 시간 존재
- 새로 사용해보는 개발 스택 다수 존재
위 상황에서 빠르게 MVP를 개발하고, 사용자 경험을 추적한 후 업데이트하는 방식은 다소 리스크가 큰 방법이라고 판단하였습니다.
그렇기 때문에 일정 관리 측면에서만 에자일 방법론의 개념을 일부 도입하는 방식으로 일정을 관리하였습니다.
스프린트
가장 크게 도입한 것이 스프린트 개념입니다.
Sprint: 육상 경기·수영 경기·스피드 스케이트 등의 단거리 레이스. 또는, 단거리를 전력(全力)으로 행하는 질주(疾走)나 역영(力泳)
저희는 3주를 한 스프린트로 계획하였으며 스프린트 시작 시 해당 스프린트에 수행할 태스크들을 수립하고
스프린트가 종료될 시 멘토님과 함께 회고하는 시간을 가졌습니다.
아쉬운 점과 느낀 점
수 많은 프로젝트가 그렇듯이, 저희 프로젝트도 초반에는 잘지켜지다가 개발 기간이 촉박해진 후반에는 스프린트 태스크 등록, 회고를 소홀히 하였습니다.
그 이유가 무엇인지 생각해보았을 때, 제가 생각한 이유는 다음과 같습니다.
- 스프린트 외의 일정 관리가 존재
- 회고에 대해 멘토님에게 의존했던 경향
- 서로에 대한 믿음 ?
저희는 평일, 주말할 것 없이 일정을 공유해 매일 회의를 하였습니다.
그리고 매일 해야할 태스크를 노션 메인화면에 체크리스트로 기록해두어 하나씩 해쳐나갔습니다.
이 때문에 스프린트 태스크 등록 및 수행이 무의미하게 느껴졌던 것 같습니다.
해야할 일을 체크리스트로 기록해두는 것은 협업 경험이 좋아 앞으로도 사용하고 싶은 방법이지만, 개인적으로 개발해야되는 것은 스프린트에 위임하여 수행하면 더욱 좋지 않았을까 생각되었습니다.
회고를 진행할 시 항상 멘토님과 같이 하다보니, 멘토님 없이는 회고를 안하게 되었던 것 같습니다.
후반에는 강의 형태의 멘토링이 많아져 저희 팀의 회고를 맡아주실 시간이 부재되었고, 더불어 저희가 회고를 통해 얻는 협업의 경험이 체감되지 않아 진행하지 않았던 것 같습니다.
이는 회고의 방식을 수정하는 방법을 적용하면 좋을 것 같다고 생각되었으며, 그 방법으로는 KPT 방법론이 있다고 생각되었습니다.
KPT 방법론과 함께 회고에 대한 좋은 글은 다음 링크를 참고해보시면 좋을 것 같습니다.
앞써 기술했던 것처럼, 저희 팀은 거의 매일을 함께 하였습니다. 이 때문에 매일 서로가 작업중인 것, 지금 겪고 있는 문제를 공유할 수 있었고
이는 회고를 통해 얻는 이점이 상쇄되는 데 큰 역할을 하였다고 생각되었습니다.
공동으로 해결해야할 문제가 많은 과정을 함께 하다보니 거의 매일 의논하게 되었지만, 회사나 사이드 프로젝트처럼 개인의 일을 공유할 시간이 따로 존재하지 않는 과정이라면 회고의 이점을 다시 체감할 수 있다고 생각되었고 현재 진행하는 사이드 프로젝트에서는 체감하고 있습니다.
마치며
저는 한 프로젝트에서 Keep, Problem, Try가 있듯이 사람에게도 KPT를 적용할 수 있다고 느끼고 있습니다.
전 프로젝트에서 잘해서 유지하고 싶은 점, 문제가 되어서 수정하고 싶은 점, 더욱 좋다고 생각되어 시도해보고 싶은 점을 다음에 진행하게 되는 프로젝트에 적용하는 것 인데요.
당연한 말일 수도 있습니다 ..
Wavy는 이전에 진행했던 프로젝트에 비해 규모도 크며 체계적으로 일정관리를 했던 프로젝트여서 더욱 많은 점을 배우고 느꼈던 것 같습니다.
다음에는 개발적으로 어떻게 하였는 지, 겪었던 이슈와 해결했던 방법에 대해 기술하며 프로젝트 회고를 마칠 것 같습니다.
긴 글 읽어주셔서 감사합니다.
