안녕하세요😊 넥스트 유니콘에서 개발팀 리딩을 맡고 있는 Mark 입니다. 오늘은 넥스트 유니콘 개발팀이 어떻게 일하고 있는지를 공유해볼까해요! 글로 표현하는데에 한계가 있지만, 저희의 경험이 조금이나마 도움이 되었으면 합니다.
저희 팀은 넥스트 유니콘 개발 초창기부터 스크럼 방법론을 사용하여 프로젝트를 진행해왔습니다. 완벽한 스크럼 방법론을 도입하기에는 현실적인 어려움이 있어, 조금씩 저희와 맞게 프로세스를 수정하여 저희 만의 프로세스를 정립하였습니다.
넥스트 유니콘 팀의 제품 생명 주기는 스프린트 단위로 구성 됩니다. 하나의 스프린트는 약 3~4주의 주기로 이뤄집니다.
스프린트 기획
개발팀의 스프린트는 Growth팀이 기획과 디자인을 어느정도 완료한 시점부터 시작됩니다. Growth 팀은 6~10개의 아이디어를 하나의 스프린트로 준비합니다. 각 아이디어는 목표와 목표에 따른 디자인, 검증 방법을 포함합니다. 또한, 스프린트 진행에 필요한 User Story가 준비됩니다. 보통 아이디어 하나당 2~6개의 User Story가 준비됩니다.
사내 컨플루언스에 정리되어 있는 스프린트의 아이디어들 및 User Story들
기획 리뷰
기획이 완료되면 개발팀은 Growth팀과 함께, 기획 및 디자인에 대한 리뷰를 진행합니다. 리뷰는 개발팀 전체가 참여합니다. 개발팀은 리뷰 진행 동안 기획 단계에서 놓친 사항들에 대한 코맨트나 기획의 의도 등 궁금한 점을 물어보며, 이번 스프린트의 목표를 이해합니다.
Task 정립
다음은 기획 단계에서 준비된 User Story를 개발팀의 작업 단위(Sub-Task)로 나누는 작업을 수행합니다. 필요에 따라서 공통된 작업들은 별도의 Task로 생성하여 둡니다. (Ex, 유저 관리 시스템 같은 경우는 여러 Story에 걸쳐서 사용됩니다. 따라서 유저 관리 시스템 구축 같은 Task를 하나 만들어 둡니다.) Task 정립 과정은 보통 제가 맡아서 진행하고 있습니다. 연구과제도 필요하다면 Task로 넣습니다.
실제 구성된 User Story 및 할당된 Story Point
스프린트 미팅
이렇게 구성된 User Story 및 Task, 그리고 그에 따른 Sub-Task 들은 아직 예측되지 않은 상황입니다. 따라서, 개발팀은 스프린트 미팅이라는 회의를 통해 각 Task 들에 Point를 할당합니다. Point는 난이도를 산정하는 추상적인 개념입니다. 현재는 저희 팀이 하루 24 point를 소화 할 수 있다 가정하고, 난이도를 산정하고 있습니다. 난이도 산정에는 플래닝 포커 기법을 사용합니다. Sub-Task를 포함한 모든 Task들에 point를 산정하는 작업을 합니다. (Sub-Task에 포인트를 줬다면 부모 Task는 합산된 point를 가집니다.)
저희 팀의 플래닝 포커 기법
특정 작업에 대해 팀원 각각 예측되는 Point를 산정하여 비교한다.
Point가 크게 차이나는 경우 이유를 듣고 이유가 합당하면, 다시 Point 산정을 진행한다.
특정 팀원이 알고 있는 지식에 의해 Point 산정에 영향이 있다면, 해당 지식을 공유하고, 해당 Task의 내용이나 댓글에 Reference를 참조해놓는다. 역시, 다시 Point를 산정한다.
비교적 작은 차이일 경우, 미팅 주관자(바로 저️!🙋♂️)의 직권으로 적당히 조절해 넣는다 (…)
초창기 플래닝 포커를 위한 화투패들 (…)
아마존에서 구매한 플래닝 카드 (링크 포함)
초창기에는 다이소에서 구매한 화투에 유성매직으로 칠해 진행하였으나, 최근에는 아마존에서 구매한 플래닝 카드를 사용하여 스프린트 미팅을 진행 하고 있습니다.
저희가 쓰는 카드는 0, 1, 2, 3, 5, 8, 13, 21, ?,☕로 구성되어 있는데, Point의 차이가 애매하게 남으로써 인한 논쟁을 줄이고자 보통 피보나치 수열을 선호한다고합니다 :)
스프린트 미팅을 통해 구성된 대시보드 (예측 실패로 Burn-down Chart가 좋지않네요 … )
개발 진행
스프린트 미팅 후 비로소 개발팀은 개발할 준비가 되었습니다👏👏👏 저희 개발팀은 자신이 할 만한 Task들을 직접 할당하여, To Do — In Progress — Under Review 단계로 작업을 진행합니다. 작업 진행 정도에 따라서 Burn-down Chart도 그려집니다. 개발은 보통 2주에서 2주 반 정도 기간이 소요됩니다.
예측보다 빠르게 진행된 스프린트의 Burn-down Chart. 이 경우 작업이 루즈해지는 경향이 있습니다(…)
지난 스프린트의 Burn-down Chart. 원격근무로 인해 예측 못한 부분으로 일정이 늘어났네요.
Daily Scrum
스프린트 기간동안 개발팀의 진행상황 및 궁금증은 수시로 공유합니다. 하지만, 하지 않아도 될 낭비를 줄일 수 있다면 더 없이 좋을 것 같습니다. 따라서, 개발팀은 매일 아침 10시 50분에 Daily Scrum을 통해서 서로 진행중인 작업을 공유하고, 혹시 놓치는 부분은 없는지 피드백을 줍니다. 더불어, 개발 리드로서 일정 예측에도 큰 도움이 됩니다.
Burn-down Chart
할당된 포인트를 기반으로 Burn-down Chart가 그려집니다. 해당 차트는 목표한 일정이 제대로 지켜질지 예측 할 수 있는 지표입니다. 저는 해당 차트를 보고 일정이 더 필요 한지, 혹은 더 일찍 끝낼수 있는지를 판단합니다. (지난 스프린트의 경우, 리모트 근무로 인해 예측치 못한 부분이 스프린트 일정에 영향을 미쳤습니다 …)
Quality Assurance
개발을 어느정도 마무리하면, QA 작업에 들어갑니다. API 같은 경우에는 BDD를 통해 어느정도 테스트 자동화가 가능하나, 수많은 UI / UX 요소가 포함된 Web-app의 경우, 직접 QA를 할 필요가 있습니다. QA작업이 진행함에 따라, Bug라는 특수한 Task가 생깁니다. 이런 Bug들은 릴리즈 영향도에 따라서 Highest, High, Medium, Low, Lowest 등의 Priority를 가집니다. 보통은 Medium 이상의 Bug들만 존재하나, 릴리즈 시기가 가까워짐에 따라 PM과 함게 Bug들의 중요도를 조정하는 작업을 거칩니다.
Release
이제 릴리즈입니다. 이렇게 저희가 개발한 것이 세상에 나왔습니다 👍
그리고 나서는 … ?
개발팀은 릴리즈 후 다음 스프린트 미팅까지 보통 4~5일을 갖습니다. (안그런적이 있습니다ㅠㅠ 후유증이 생길수 있어요!) 이 기간동안 개발팀은 중요한 일을 해결해야합니다.
Hotfix 대응 — 릴리즈 시에 챙기지 못한 것들에 대한 수정이 필요합니다.
개발부채 관리 — 릴리즈를 위해 수행했던 수많은 악행(?)들을 회개할 시간입니다😢 리팩토링을 열심히합니다. 다만, 조심해야합니다. 리팩토링한 코드들은 Test가 필요하거든요.
회고 — 우리가 잘한 점은 무엇인가, 개선할 점은 무엇인가, 다음은 어떻게 할 것인가!
다음 스프린트 준비
이렇게 하나의 스프린트가 끝났습니다. 수많은 단계들을 자연스럽게 연결지으며 나아가는 저희 팀원들에게 항상 감사드리고, 자랑스럽습니다 👏👏👏
사실 금요일에 있는 다음 스프린트 미팅이 걱정되긴 합니다. 코로나로 인해 대중교통을 타야하는 팀원들이 리모트로 함께하고 있죠. 스프린트 미팅은 많은 의사소통이 필요하고, 같이 User-Story를 이해하며 업데이트 해나가는 회의인 만큼 원격으로 진행하는 것 또한 저희 팀에게는 챌린지겠네요! 😊
개발팀 뒷모습
No Silver Bullet. 은 탄환은 없다.
개발 리드로서 가장 좋아하는 문구입니다. 늑대 인간은 쉽게 죽지 않지만, 은 탄환 한방에 죽습니다. 마법같은 은 탄환이 소프트웨어 개발에도 존재할까요?
저희 프로세스는 시행착오가 많았던 것 같습니다. 그리고 지금도 회고를 통해 조금씩 개선시켜나가는 중인 것 같습니다. 완벽하지는 않지만, 그리고 완벽할 수도 없겠지만, (수정된) 스크럼 프로세스를 통해 저희 팀이 조금은 더 서로 이끌며 나아갈 수 있는 것 같습니다.
은 탄환은 못 찾았지만, 납 탄환을 찾았네요!
여러분들도 같이, 스프린트 한 번 어떠세요?
가입하기
