유저스토리를 활용한 프로젝트 진행의 장단점
by chanju · 81 things on NewTwos
- 복잡도가 높을 때, 프로젝트 실행의 문제
- 여전히 가장 보편적인 폭포수 방법론의 프로젝트 진행
- 요구사항 정의 > 화면설계서 > 메이커 리뷰 > 디자인 > 개발 > 테스트 > 오픈
- 폭포수 프로젝트에서 프로젝트 지연되는 상황
- 기획문서 작업 지연
- 이해관계자 협의와 서비스 기획으로 다시 돌아감
- 기획에서 지연이 되면 개발이 늦어짐
- 개발 과정에서도 커뮤니케이션 누락될 경우 추가 지연
- 최초에 프로젝트가 화면설계나 디스크립션 정의를 기획자가 시작할 수 있었던 이유
- 초기에 서비스는 단순했기 때문,
- 정보나 페이지 정의만 해도 개발이 가능
- 외주 기반의 국내 온라인 산업의 성장
- 모바일 서비스가 도래되면서 압도적으로 늘어난 기획량
- 수많은 기능이 모이면서 복잡도가 증가
- 결제수단, 배송수단 등등
- 복잡도 높은 서비스의 경우 화면설계와 정책설계 기간 증가
- 화면으로 소화하기 어려운 기획들이 등장
- AI를 활용한 추천 플랫폼
- 기획자는 화면만 기획할 수 있고,
- 실제 기능 구현은 개발자가 진행
- 여기에서 더 많은 커뮤니케이션 필요
- API로만 이루어진 서비스
- 애자일 사상과 목적조직으로서의 크로스펑셔널팀
- 아찔한 상처들로 남아있는 K-애자일 (feat. Tool만 도입)
- Jira 도입, Slack 사용, 2주 단위 스프린트
- 툴은 바뀌었지만 업무스타일은 그대로일 때 문제점
- 애자일은 사상이다: 구체적인 조직형태나 방법론, 툴이 처음부터 제시된 것이 아니라 애자일 사상을 실현할 수 있도록 제안됨
- 속도보다는 '모든 협업자의 적극적인 참여와 지속적인 변화'가 핵심
- 가장 적합한 조직은 크로스펑셔널팀
- 기존의 기능 조직의 문제점
- "내가 하는 일이 정말 우리 회사에 도움이 되는 일인가, 성과를 측정할 수 있는가?"
- 애자일과 함께 이야기되는 개발조직의 구조 : 목적 조직
- 특정 프로덕트 혹은 목표를 위해서 필요한 포지션의 사람들이 하나의 팀을 이룬다.
- 크로스펑셔닐팀의 장점을 극대화하는 PRD와 Userstory
- User story를 이론대로 사용해보자!
- 요구사항 정의를 할 때 What을 중심으로 하기 보다는 Why를 중심으로 정의
- UI 설계 디자인과 개발 설계 개발을 병렬로 진행
- PRD는 왜 만들어야 하는지 기획에서 고려해야하는 사용자와 비즈니스에 대한 목표를 제시
- Userstory는 디자인과 개발에 있어서 자유도를 주고, 구현되는 형태는 메이커의 더 적극적으로 참여하는 형태로 지원한다.
- PRD(Product Requirement Document)
- 엔드유저에게 어떤 가치를 제공하기 위해서 무엇을 만드는지 적는 문서
- 디자인이나 개발에 대한 구체적인 내용은 적지 않고 비지니스에 대한 정리
- 필요하다면 메이커와 논의하면서 정할 수도 있다.
- Guide Principle은 프로젝트의 자유도로 인해서 지나치게 방대해지거나 생각이 벗어나는 걸 방지하기 위해서 작성하는 항목,
- 중요도/우선순위/일정 등
- Userstory != 백로그, Use case, 페르소나
- 좋은 Userstory
- 기본구조: (사용자)는 (OO을) 위해서 (ㅁㅁ을) 할 수 있다.
- 확언적이지 않게 개발하는 산출물의 기능과 역할을 알려주는 문장
- 유저 스토리는 '완료조건'을 함께 명시한다.
- 유저스토리의 예: 구매자가 상품을 더 자세하게 보고 싶어할 때 특정 상품의 상세정보를 볼 수 있다.
- 여기에서 특정 상품의 상세정보는 '상품상세페이지'가 아닐 수 있다.
- 기존의 멘탈모델에서 벗어나서 자유도를 가질 수 있다.
- User Story 적용에서 겪은 문제점과 개선
- Userstory를 정책서, 화면 설계서와 같이 쓰면 안 된다.
- Userstory가 있어도 이해도의 차이로 바로 작업이 시작되지 않았음
- 사내 PO들의 자료와 팀내 회고와 학습을 진행
- 완료 조건의 중요성에 대해서 깨달음
- ATDD (완료조건 기반 개발방법론)
- 사용자에게 전달되는 최종 가치를 계속 떠올리게 하며
- 적극적으로 개발에 참여할 수 있도록 하는 개발 방법론
- Userstory에 대해서 같이 이해해야
- 화면설계서를 쓰지 않고 디자인과 개발 설계를 시작
- PO는 본인만 알고 있는 배경 지식이나 목표 등을 메이커에게 계속 공유헤야 함
- Userstory는 완료 조건을 가지고 테스트 가능
- 여전히 남은 문제점들
- 작업 시기 중첩의 문제
- 백엔드와 디자인이 끝난 이후에 프론트엔드가 진행되는 건 어쩔 수 없음
- 디자인을 특정 흐름별로 나눠서 진행하고 프론트엔드에 전달
- 어떤 단위로 나눠야 서로 작업이 중첩되지 않는지 고민해야 함
- QA시 Test Case 작성에 대한 문제
- 기존과 같은 화면설계나 스펙에 대한 정리가 없음
- QA에게 유저스토리 리뷰를 진행하고,
- 메이커들의 늘어난 업무적 범주와 관성의 문제
- 기획이나 의사 결정의 범주가 메이커에게 많이 넘어가게 됨
- 프로젝트 종료 후에 일반적인 회고가 아니라 유저스토리를 읽으면서 사용자 동선과 완료 조건이 제대로 포함되었는지 확인하는 리뷰 워크샵 진행
- 마무리
- 기술적으로 점점 더 복잡해져가는 프로덕트의 형태에서
- 기획자가 모든 것을 이해하고 프로젝트를 발의하는 것은 불가능
- 메이커들의 전문성을 더 많이 발휘할 수 있도록 PRD와 User Story
- (하나 못 썼음...)