애자일 방법론 중 하나인 사용자 스토리를 학습 중입니다.

보다 효과적인 학습을 위해 챕터마다 정리하여 블로그에 포스팅 하려 합니다. 

지인들에게 알리지 않고 기록의 용도로 사용하는 블로그인 만큼, 많은 사람이 볼리는 없겠지만 혹여나 애자일 공부하신 분께서 보신다면 코멘트로 첨삭? 부탁드립니다. 

열심히 배우겠습니다.

User Story Applied 1.개요

배경

소프트웨어 개발 프로젝트가 어떻게 진행 될 것인지 완벽하게 예측하는 것은 불가능 하고, 따라서 프로젝트 전 기간에 걸쳐 의사를 결정해야 한다. 이를 위해 보다 빈번하고 신속한 정보공유 프로세스가 필요하다.

프로세스

waterfall - 한 주기 : 요구사항 작성, 요구사항 분석, 설계, 구현, 테스트  

이에 비해, 사용자 스토리는 고개과 사용자의 참여가 프로젝트 하는 내내 계속 됨.

1. 스토리 작성 워크숍에서 처음 작성.

(프로젝트 진행 중에도 아무 때나 추가 작성 가능.)

* 고객이 스토리를 작성

1. 고객팀에서 어느 이터레이션이나 릴리즈에 포함시킬지 우선순위를 결정하기위해.
기술용어가 아닌 비즈니스 용어로 작성 되어야함.

2. 제품의 주된 기획 주체로서 고객팀은 제품의 동작을 가장 잘 설명할 수 있다.

* 사용자 역할 모델링을 활용 (3장 참고)

2. 개발자는 스토리 크기를 추정.

3. 이터레이션 길이 iteration length 선택. 

4. 속도 velocity (한 이터레이션 동안의 작업량) 추정.

5. 스토리 포인트 추청. 

6. 이터레이션 배정.

7. 이를 바탕으로 release plan을 세운다.

* 각 이터레이션을 시작하기 전에 고객팀은 진행중인 릴리즈 계획을 수정할 수 있다.

스토리 크기와 스토리 포인트가 서로 다른 개념인지 궁금.

이해하기로는, 스토리 크기는 에픽 Epic을 세부 스토리로 나눌 때 처럼 기능적으로 접근

스토리 포인트는 구현할 때 드는 시간적 비용 차원으로 접근했는데.. 

인수 테스트 Acceptance test

: 스토리 개발 후 고객이 기대하는 대로 정확히 동작하는지 입증하는 과정.

이터레이션이 시작되면 개발자는 코드를 작성, 고객팀은 테스트를 작성

테스트는 초기에 작성할 수록 좋음. 

for 고객이 기대하고, 가정하는 것을 보다 빠르고 정확하게 개발자에게 전달 할 수 있음.

Why User Story?

사용자스토리는 고객, 개발자 모두이해가능

반복적 개발  iterative development에 효과적

iterative process 반복적 프로세스는 refinement 연속적인 정련을 통해 발전해 간다.

그 밖에..

각 카드의 뒤에 기대사항을 표현. 

이는 Acceptance test 인수테스트를 작성하는 단서reminder 가 된다.

고객팀 customer team

: 사용자의 요구를 만족하는지 보증해줄 사람이 필요하다.

예를들어 테스터, product manager, 실 사용자, interaction designer

사용자 스토리가 큰 것 보다는 많은 것이 낫다. 

1장은 사용자 스토리를 전반적으로 흘끗 훑어보는 느낌이다.

다시읽길 잘했다는 생각이 드는 한편 일독하는 사람들에게는 적합하지 않은 구성 같다.

아무튼 조각조각 따로 놀던 이해의 조각들이 완성되가는 기분이다.

그리고. ㅇ ㅏ. 개발팀은 그 동안 나랑 일하느라 힘들었을것 같다. 미안할 따름이다.

나는 어느정도 해결되고 있는 문제를 더 멋지게 해결하는 서비스를 준비중이다.

적어도 내가 생각하기에 그 문제를 해결하는 기존의 솔루션이 그지 같아서 인데,

1. 정말 그지같을까.

2. 해결되지 않았던 문제를 해결하고 싶다.

라는 두가지 생각 때문에 다소 괴로운 요즘이었다. 

뭐 첫번째 생각이야. 내가 함부로 내릴 판단이 아니라 타겟유저들의 판단에 다만 순응하면 된다. 지금 하고있는 고객인터뷰를 열심히 하는 수 밖에. (지금까지의 결과로는 그지같다.)

문제는 두번째 생각인데. 이에 대해 CTO분께 조언을 구했다.

"해결되지 않았던 문제가 해결 된 사례가 있나요?"

그 단순한 물음에. 생각해보니.

사례가 아주 없진 않지만. 머리속에 스쳐가는 대부분의 product들이 해결하고 있는 문제들은, 그 프로덕이 나오기 전부터 어느정도, 그지 같게 해결되고 있어왔다. 정도의 문제인 것 같다. 현재 얼마나 그지 같은지. 그리고 새 솔루션이 얼마나 왕자같이 해결하는지. 의 정도.

나는 예비 창업가다. 

팀도 있고 사무실도 있고 휴학하고 full-time 일 하면서 나는 내가 창업가인 줄 알았는데, 내가 믿고 따르는 Y선배가 네트워킹 파티에서 지인들에게 나를 소개할 때. 예비 창업가라고 소개했다. 그 때 살짝 기분이 나빴는데 곰곰히 생각해보니. 내가무슨!

덕분에 창업가의 정의를 내리게 되었다.

세상에 놓인 문제를 발견, 그리고 해결한 사람들은 창업가.

문제를 발견하고 있거나, 발견했지만 아직 마땅한 해결방안을 찾지 못한 사람은 예비창업가.

나는 중요한 문제를 발견했다. 그리고 마땅한 해결방안을 찾았다고 생각한다. 

하지만 그건 내생각이고 실제로 user들이 내가 만든 서비스를 통해서 해당 문제를 해결할 때까지,

나는 예비창업가.

새삼, 수식어를 떼어내는게 쉽지 않을거라는 생각이 든다.

하지만 그 때가 만드시 올거라 믿는데, 떠올리면 벌써부터 행복하다.