앱 개발 프로젝트 서비스 기획, Agile 애자일 방법론— Linkerbell №1 기획편 — 2
코드스테이츠 4주 프로젝트
코드스테이츠 4주 앱개발 프로젝트 회고 시리즈 목차
- №1 기획편 — 프로젝트 기획 과정과, 프로젝트 관리 과정
- №2 전반부 — 첫 2 주동안 개발 과정에서 겪었던 시행착오과 고민들
- №3 후반부 — 마지막 2주동안 겪었던 일들과 QA
- №4 출시 — 실제 플레이스토어에 출시 과정
프로젝트 전체 기획 — continued
링커벨 프로젝트는 이런 과정을 거쳤고, 저번 글에서 아이디어를 내는 과정에서 고려했던 점들에 대해서 정리를 했다.
이번에는 팀이 편성된 이후 다같이 서비스 기능들을 구성하고, 우선순위를 정하고, Sprint를 계획하고, UI, API, DB Schema 를 구성했던 얘기 까지 해보려고 한다. 애자일 방법론이 어떤 식으로 적용되었는지도 얘기해보겠다.
2. 서비스 기능 구성 — 백로그(BackLog) 작성
2명의 프론트엔드와 2명의 백엔드로 팀이 꾸려졌다. 별도의 기획자는 없다! 그래서 나는 초기 아이디어 제안자일 뿐, 그 이후 실제 프로젝트를 만들어갈 팀 모두의 의견을 반영하여 프로젝트의 방향성을 정확히 하는 작업이 필수적이었다.
내가 먼저 나의 아이디어와 의도는 어떤 거였는지 얘기를 하고, 자유롭게 각자 의견을 나누면서 우리가 만들 서비스의 정확한 그림을 그리는 과정을 거쳤다.
우리는
- 링크를 쉽게 저장할 수 있어야 한다.
- 카테고리 자동 분류는 우리의 정체성이다.
- 저장한 링크를 편리하게 커스터마이징해서 사용할 수 있어야 한다.
- 심플한 디자인도 우리의 아이덴티티이다.
- 프로젝트 완성도가 우리에게 중요하다.
정도로 의견을 방향성과 주 아이덴티티를 확립하고 있으면 좋을 유용한 기능들에 대해 자유롭게 의견을 내놓았다.
태그 기능, 정렬, 필터링기능, 카테고리 수동 추가, 크롬 익스텐션 버전, 데스크탑 버전, 취향을 파악해서 비슷한 글 추천해주는 기능, 데이터를 시각화하여 트렌딩 글/카테고리나 성별/나이대 별로 무언가를 보여주는 것 등등 다양한 아이디어들이 쏟아져나왔고
- 꼭 필요한 최소 기능 즉 MVP 모델에 꼭 필요한 기능들은 Bare minimum
- 우선순위는 밀려나지만 있으면 확실히 유용한 기능은 Advanced
- 없어도 상관없지만 있어도 좋거나, 학습 목적으로 해보고 싶은 것들은 Nightmare
이렇게 세가지 단계로 백로그를 구성했다.
제품 백로그 Product Backlog= 제품을 만들 때 구현해야하는 것들이다.
To Do List를 생각해도 무방할 것 같다. 보통 우선순위와 예상 소요시간을 같이 명시한다.
이 단계에서 중요한 것은 해당 사항들은 추가, 삭제, 수정이 가능하다는 점이다.
아이디어를 자유롭게 내다보면 더 좋은 기능이나 세부적으로 구현해야할 것들에 대해서도 생각할 수 있기 때문에 나는 우리팀이 실제 할 수 있냐의 여부 보다도 이 서비스를 만드는 제품팀의 입장으로서 최대한 다양한 의견들이 부담없이 쏟아져나올 수 있도록 의도했다. (ㅎ 그렇게 해야 기획이 더 재밌어지는 것 같기도하다)
아래는 실제 백로그는 아니고 좀 더 심플한 버전이다.
3. 우선순위, 개발 순서 설정 — Sprint 계획 및 백로그 작성
위 제품 백로그들을 바탕으로 우선순위들을 좀 더 자세하게 분리하고 프론트/백엔드 각 팀에서 먼저 해줘야하는 것들을 고려해서 스프린트 백로그를 작성했다.
애자일 방법론 중 Scrum 방식을 따랐다. (정확히 뭔지 알지 못한채 따랐었다ㅎ)
처음에 스프린트를 어떻게 나눌까 고민했는데 우리는 큰 기능 단위로 나누고 각 팀 안에서는 화면 단위로 역할을 분리했다.
예를 들어, 링커벨에서 주요 개발해야하는 기능 중 로그인/회원가입 같은 인증기능이 있고 본격 링크를 저장해서 카테고리를 분류해주는 기능이 있다. 그리고 마지막으로 저장된 링크들을 커스터마이징할 수 있게 해주는 기능이 있다.
그럼 첫번째 스프린트는 인증기능을 프론트/백엔드 둘 다 개발을 하고 두번째 스프린트에서는 카테고리 분류를 해주는 식이었다.
4주 프로젝트인 만큼 시간이 길지 않아서 보통은 스프린트 기간을 2주로 가져가지만 우리는 평균1주일, 짧은 스프린트는 3-4일 정도로 가져가서 계획을 세웠다.
구현해야하는 것들을 목록화 하고 우선순위를 정하는 작업이 여기서 진행되었다.
프론트와 백엔드의 워크플로우 합을 맞추는 것도 중요한 작업이었다.
프론트가 UI 디자인까지 맡아서 해야하는 상황이었기 때문에 디자인 작업을 하고 본격 database가 구축되기 전까지 사용할 fake data를 만들고 있으면 그동안 백엔드는 프론트가 우선적으로 사용해야 하는 API를 만들어줘야 하기 때문에 그 타임라인을 맞추는 것이 중요했다.
프론트가 본격 작업을 시작하기 전에 Database 구조를 설계하고, 그를 바탕으로 API 문서를 미리 작성해 주는 것도 작업 효율성 측면에서 도움이 많이 됐던 것 같다.
4. 각자 task 작성 및 얼라인먼트 확인
구현해야하는 것들을 목록화 하고, 우선순위를 정했으면 이제 각 포지션 안에서 역할 분담을 하고 자신이 맡은 기능에 대해서 task를 작성했다. Backlog에 있는 것을 끌어와 자신의 task카드를 만들었다고 생각하면 된다.
이 때 진행 상태, 예상 소요시간, 실제 소요시간, 우선순위, 포지션, 담당자, 진행 날짜를 추가적으로 적었다.
진행 상태는 Not started, In Progress, Completed, Moving on to Next Sprint 이렇게 구성되어 있었다.
이 과정에서 중요한 포인트는 두가지 였다.
- 자신이 맡은 task는 자신이 직접 작성할 것.
자신이 해야할 작업에 대해 예상 소요시간을 정하고 좀 더 세부적으로 쪼개는 과정을 거치면서 자기가 해야할 일이 정확히 뭔지 더 명확하게 파악이 가능하다.
이 과정 중 헷갈리는 것이 있거나 다른사람과 겹치거나 남는 것이 있다면 제대로 소통이 되지 않은 부분이 있다는 것임으로 얼라인먼트를 확인하는 과정도 같이 가져가게 된다.
2. 예상 소요시간 —실제 소요 시간을 트랙킹하는 것은 개인의 역량을 파악하기 위함이 아니다.
애초에 애자일 방식은 제품팀 전체를 위해 도입된 방식으로, 제품팀 전체가 더 효율적으로 일을 잘 할 수 있게 하기 위해 만들어 진 것이다. (꼭 그런건 아니지만 그 또한 목적 중 하나)
예상 시간과 실제 소요 시간을 트랙킹하는 목적도 누가 잘하고 누가 못하고를 판단하기 위함이 아니고, 실제 어떤 기능을 구현하는데 어느정도 시간이 소모되고, 예상 시간보다 더 많이 걸린다면 어떤 이유에서인지 파악해서 다음 스프린트 계획때는 더 효율적인 계획을 세울 수 있게 하기 위함이다.
즉 각 스프린트를 통해 제품팀은 더 정확한 인사이트를 얻고 매 스프린트마다 발전할 수 있게끔 하는 것이 목적인 것이다.
5. UI design, API 문서 작성, DB Schema 작성
앞서 우선순위 정할 때 언급했듯이 이 세가지 과정은 스프린트 1 가장 처음에 진행되었고 상당 많은 부분 팀워크를 통해 다같이 합을 맞춰 진행하였다.
우리 팀에는 디자인 전공자가 있어서 (THANK GOD) 그 분이 전반적인 디자인을 도맡아주셨고, 세부적인 부분에 대해서 의견을 서로 나누며 모두가 이상적으로 생각하는 방향으로 초점을 맞춰 디자인을 진행했다.
그리고 각 기능을 구현할 때 사용될 데이터들에 대해 얘기를 나누면서 어떤 데이터가 필요하고 어떻게 관계를 구성할 것인지 의견을 나누며 DB 스키마를 작성했고
그것을 토대로 API 문서를 대략적으로 먼저 백엔드에서 작성해주셨다.
이 부분을 특별히 따로 언급하는 이유는, 이 세 부분에서 모두가 충분의 합의를 하고의견을 나누는 시간을 가지면 서비스 전반적인 방향성과 목표가 뚜렷해지는 것 같다고 생각했기 때문이다.
우리가 다 초보라서 그런지 몰라도 이 과정에서 상당한 시간을 투자했고 수정도 아주 여러번 거쳤다. 하지만 그 과정을 통해서 해야하는 것과 하지 말아야할 것 들이 더 명확해졌다.
6. Sprint 본격 시작 — Sprint 마무리
이제 기본적인 틀이 갖춰졌으니 Sprint가 본격 시작된다.
큰 기능으로 Sprint를 4까지 구성했지만 각 Sprint가 끝날 때 마다 회고하고 테스트를 진행하고 배포하고 변경되어야 할 사항들은 즉각 반영해서 다음 Sprint에 반영하고 진행하는 식으로 운영되었다.
실제로 Agile 방법론에서 가장 중요한 부분이 Sprint가 마무리되고 또 다음 Sprint가 시작되는 이 Review 구간이다.
+Agile vs Waterfall 방법론
기존에 많이 쓰이던 폭포수 방식(Waterfall)에서는 요구사항을 발견하고, 계획하고, 개발하고, 테스트하고 그 뒤에는 유지, 보수 과정만 남게 된다.
하지만 이 방식은 고객이 실제 사용하기까지 오래걸리기 때문에 고객이 실제 원하는 것, 고객의 진짜 니즈를 계속 계속 파악하고 반영할 수가 없다.
하지만 애자일 방식을 이용하면 고객의 입장에서 우리 서비스로부터 필요로 하는것이 뭔지 계속 집중할 수 있게 되고 그에 맞는 플랜을 그때 그때 적용해 보다 빨리 니즈를 충족시켜줄 수 있는 장점이 있다.
또한 문제가 생겼을 때 바로바로 유연하게 대처해나가면서 차선이지만 동시에 최선을 선택하며 개발할 수 있다는 장점도 있다.
우리도 커스터마이징 기능을 거의 마무리해놓고 크롬 익스텐션을 만들러 넘어가려고 했었지만 스프린트 리뷰과정을 거치면서 기능단위로 쪼개서 분업했던 것들이 합쳐지면서 파생된 버그들이 아주 많다는 것을 발견하고 크롭 익스텐션을 전면 취소하고 백로그를 새로 만들어 버그를 수정하며 완성도를 높이는 과정을 겪었다.
폭포수 방식대로 진행했다면 다 만들고 나서야 버그 투성이인 완성도 낮은 제품을 발견하고 고치는데 시간이 배로 더 들었을 것이다.
(그 외에도 애자일 방법론의 이점은 너무 많지만 여기서 다 언급하는 것은 어려울 것 같다! 다양한 좋은 책들과 블로그 포스트들이 있으니 찾아보는 것을 추천한다. )
이렇게 기획편을 마쳐보려고한다.
원래 계획대로라면 개발 과정 중 겪었던 시행착오들을 상세히 다음 편에 기록하려 했었는데 출시 후 취업준비로 바쁘게 살다보니 ... ㅎ 많이 까먹었다.
기록의 중요성을 새삼 다시 느끼는 바다.
