카카오톡의 새로운 기능
애자일(Agile)하게 개발하기
[코드스테이츠 PMB 10기] 애자일 방법론으로 프로덕트 문제점 개선하기
애자일(Agile)과 워터풀(Waterfall)
어떤 방법으로 프로덕트를 개발해야 할까요?
정답은 없다. 둘 중 무엇이 옳고, 무엇이 옳지 않은지 결정을 내릴 수 없다. 둘 다 프로젝트를 더 효과적으로 진행해 나가고 목표를 이루기 위한 하나의 도구, 프로세스 방법론이기 때문이다.
그렇다면 프로젝트를 시작하기 앞서 어떤 프로세스에 따를 건지는 어떻게 결정할까?
보통 회사, 조직의 유형과 상황에 의해 결정되고 회사 임원이나 팀장에 의해 결정되어 제시되는 경우가 많다.
따라서 스타트업이라고 무조건 애자일 방식이고, 규모가 큰 기업이라고 수직적인 의사결정인 워터풀 방법론을 적용하는 것이 아니라, 제품에 따라, 조직 문화, 특성에 따라 달라질 수 있다는 것이다. 두 가지 방법론은 어떤 특성과 차이점을 가지고 있는지 정리해 보았다.
워터풀(Waterfall)
워터풀 방법론은 앞 단계가 끝나야 다음 단계로 나아갈 수 있는 계단식 접근 방식이다. 한 단계가 끝나면 이전 단계로 돌아가기 어려운 특성 때문에 프로젝트를 시작할 때 기획자가 검토할 사항이 많고, 작성할 기획 산출물도 많다. 그래서 기획자는 초반부터 프로세스 각 단계별로 진행할 일들에 대해 구체적인 틀을 가지고 있어야 한다. 그렇지 않으면 개발 중 다양한 문제에 부딪히고 난항을 겪게 될 것이다.
워터풀 개발 방식은 요구사항 정의, 분석-> 디자인-> 개발-> 테스트-> 배포의 과정을 거친다.
이렇게 체계적인 단계를 적용 시 좋은 점은 문서로 요구사항에 대한 정리가 잘 되어있기 때문에 프로젝트 관리가 쉬워진다. 또 프로젝트 기간이 정해져 있기 때문에 배포 가능한 기능 위주로 범위를 줄일 수 있다.
하지만 전체 프로세스를 완료하기까지 시간이 상당히 걸리고, 개발 중이나 이후에 프로덕트를 수정하려면 많은 비용과 시간이 소모된다. 빠르게 변화하는 트렌드에 곧바로 맞춰 나가기에는 어려운 부분이 있다.
애자일(Agile)
애자일 Agile은 기민함, 민첩함의 의미로 짧은 주기 동안 최소의 기능을 개발하여 고객의 문제에 빠르게 대처하는 방법론을 말한다. 워터풀 방식과 다르게 기획 문서에 할애하는 시간을 줄이고 1주-3주 정도의 기간 동안 스프린트 단위로 프로젝트를 진행하는 효율적인 과정을 지향한다. 고객의 요구사항을 반영한 MVP를 반복적으로 개발하고 테스트하기 때문에 사용자가 원하는 기능을 개발하는데 매우 유용하다.
애자일은 도입만 하면 바로 적용되는 프로세스가 아니라 팀 전체가 애자일적인 문화를 만들고 참여해야 한다.
'애자일 문화'는 탑다운 형식의 의사결정 구조가 아닌 수평적인 체계를 유지하면서 각 구성원들에게 자율성을 주는 대신 제품에 대한 책임감을 갖게 하며 더 좋은 서비스를 위한 프로젝트 중심의 목표를 강조한다.
애자일은 다음과 같은 과정을 반복적으로 진행한다.
계획: 고객과 이해관계자들이 함께 브레인스토밍, 정의, 우선순위 설정, 필요 자원 등을 논의한다.
설계: UX 전문가, 스크럼 마스터, 클라이언트, 제품팀 그리고 기타 주요 이해관계자와 협력하여 제품과 개발 요소들을 결정한다.
개발: 개발팀은 ‘스프린트’라고 불리는 여러 반복 작업을 거치며 고객 요구사항에 맞는 제품을 개발한다.
테스트: 제품이 고객 요구사항을 충족하는지 확인하는 단계이며, 결함 발견 시 해당 제품을 개발 단계로 보내 수정하고 다시 테스트한다. 이 과정은 제품이 고객 요구사항이나 목표를 충족할 때까지 지속한다.
배포: 모든 단계가 완료되면 최종 제품을 고객에게 전달한다.
피드백: 팀이 전체 개발 프로세스를 회고하며 제품이나 팀의 성과를 개선하는 방법을 검토하고 논의한다.
애자일 방식으로 프로덕트 개발을 진행할 때 유의할 점은 빠른 사이클을 가진 만큼 버그가 많이 발생할 확률이 높으며, 완성도가 떨어질 수 있으니 기술적으로 중요한 부분은 개발 기간을 길게 잡고 꼼꼼하게 점검하며 진진 행하는 것이 좋겠다.
'카카오톡 카테고리 기능' Agile 하게 업데이트 하기
애자일 방법론에서 기획자는 '사용자 스토리(user story)'를 설정하고 개발에 필요한 백로그를 작성해 이용해 팀원들, 이해관계자들과 쉽고 효율적인 커뮤니케이션 한다. 사용자 스토리는 고객의 니즈를 중심으로 프로덕트가 갖춰야 할 핵심 기능을 작은 단위로 나눠 작성한 요구사항 리스트이며, 최대한 문장 형태로 누가, 무엇을, 왜, 어떻게를 생각하며 고객의 목적을 달성하려면 어떤 기능이 필요한지 보여줘야 한다.
우리의 생활에서 자주 사용되는 서비스인 '카카오톡 메시지'를 업데이트한다고 가정했을 때 개선할 문제점과 기능을 사용자 스토리로 작성해보고, 제품 백로그 중 우선순위를 정해 칸반 보드에 정리해 보았다.
고객 문제 정의
매일 보는 화면이라서 익숙해진 걸까? 왜 그동안 불편함을 인지하지 못했을까?
하나쯤은 있을 법한 그룹화, 카테고리 분류 기능이 카카오톡 메시지에는 없다. 현재 카톡 채팅방 리스트는 가장 최근에 메시지 별로 온 날짜, 시간 순으로 정렬되어 있고 자주 사용하는 채팅방을 즐겨찾기로 상단에 고정시킬 수 있다. 그런데 오래된 메시지, 광고 메시지, 알림 메시지 등 중요한 메시지가 아님에도 리스트에 노출되어 있어서 원하는 메시지를 보려면 스크롤을 올렸다, 내렸다 해야 하는 불편한 문제가 있었다.
하지만 카카오톡 채팅방 목록을 그룹 별로 나눌 수 있다면 어떨까?
사용자가 카테고리 태그를 이용해 '친한 친구' '회사 동료' '거래처' 등으로 채팅방을 그룹화시킨다면 중요한 대화 그룹은 상단에 배치 혹은 화면에 계속 노출시키고, 중요하지 않은 대화는 토글 숨기기 기능으로 잠시 가려 놓으면 효율적인 채팅방 관리가 가능해질 것이다.
사용자 스토리 (User Story)
[ 카카오톡 메시지 채팅방 카테고리 별 분류가 가능한 그룹화 기능]
카카오톡 메시지 사용자들은
더 편리한 채팅방 목록 관리 및 사용성을 위해서
채팅방 목록 카테고리 별 분류할 수 있는 그룹화 기능을 원한다.
카카오톡 메시지를 사용하는 유저들의 목적을 위해 필요한 기능을 정의하고, 유저 스토리 형식으로 작성했다. 사실 백로그 기능들을 바로 나열하고 우선순위를 정해도 되지만 이렇게 유저 스토리를 사용하는 이유는 개선안을 고객 관점에서 바라보고, 고객의 니즈가 반영된 핵심 기능을 계속 생각하며 개발을 진행할 수 있기 때문이다.
백로그, 칸반(Kanban) 보드
유저 스토리를 활용해서 개발할 기능을 작성하고, 고객 핵심 기능에 최소한으로 필요한 백로그의 우선순위를 정해 보았다. 그리고 칸반 형식으로 할 일 (to-do), 진행 중인 일 (In progress), 완료한 일 (done) 이렇게
3가지로 나누었다.
(Bold - 우선순위 높음)
1. 채팅방 목록에서 카테고리 그룹 폴더 생성
2. 채팅방 편집에서 원하는 채팅방 선택 후 분류 별 폴더에 담기
3. 원하는 카테고리 선택
4. 그룹에 담기 완료 알림
5. 전체 채팅방 목록에서 그룹별 보기 가능
6. 그룹별 보기 설정 시 채팅방 목록이 각 그룹별로 분류된 모습으로 보임
7. 사용 빈도가 낮은 그룹은 토글 기능으로 접어두기, 숨기기 가능
8. 카테고리 이름, 폴더 컬러 바꾸기
칸반보드프로젝트 스프린트 기간을 2주 정도로 예상하고 기능을 구현하는데 가장 기본적인 백로그들만 칸반 보드에 작성했다. 그리고 작업 진행 중인 경우 각 백로그마다 어떤 개발이 필요할지 생각해 보았다.
사용자에게 보이는 클라이언트와 그룹화에 필요한 DB 테이블 설계 및 생성 등 하나의 백로그를 구현하는데 몇 가지의 과정이 필요했다. 여기서 각 과정마다 자세하게 파고들면 최소한의 기능을 개발 후 테스트하는 것이 아닌 완전한 기능을 만드는 것으로 애자일 취지와 맞지 않는다.
In Progress에서는 WIP Limits을 잘 정해서 일의 범위를 조절해야겠다. 그리고 애자일은 항상 팀원과의
커뮤니케이션이 동반되기 때문에 좋은 퀄리티의 결과물을 위해 팀이 할 수 있는 일의 개수와 양을 유지하고 진행 정도를 잘 체크해야 한다는 것을 유의해야 한다.
Done (완료한 일)에서는 개발이 완료되고 기능 테스트까지 이어져야 고객에게 배포할 수준이 되며, 피드백을 얻어 새로운 고객 의견을 반영할 수 있게 된다. 혹은 테스트 과정을 따로 보드에 작성하여 고객에게 서비스해도 문제가 없는지 확인하는 작업이 필요할 것 같다.
