Posts [에센셜 스크럼] Chapter5 - 요구 사항과 사용자 스토리
Post
Cancel

[에센셜 스크럼] Chapter5 - 요구 사항과 사용자 스토리

개요

대화 사용

점진적인 개선

사용자 스토리란 무엇인가?

카드

대화

확인

세부 사항 수준

좋은 스토리의 기준, INVEST

독립성(Independent)

독립성 기준을 적용하라 때, 목표는 모든 의존성을 없애는 것이 아니라 의존성을 최소화하는 방향으로 스토리를 작성하는 것!

협상 가능성(Negotiable)

협상 가능한 스토리를 작성하는 것은 대화가 필요하다는 것을 명확히해 미리 상세한 요구 문서를 만드는 것과 연관된 문제를 방지힌다!!! (즉, 기획팀과 개발팀 사이의 대화를 통한 협상으로 인해 서로 옳은 가치를 만들어내기 위해)

협상 가능성이 지켜지지 않는 대표적인 예는 제품 책임자가 팀에게 어떻게 스토리를 구현할 것인지 말하는 것!!!

스토리는 어떻게가 아니고 무엇이나 왜에 관한 것이어야 한다

가치(Valuable)

모든 스토리는 ‘고객’ 이나 ‘실사용자’ 에게 가치 있는 것들로만 이뤄져야 한다.

만일 스토리가 개발자들에게는 가치가 있지만 이것이 고객이나 사용자에겐 분명하지 않다면 기술적인 스토리 가 있어도 괜찮을까? => 기술적인 스토리의 근본적인 문제는 제품 책임자가 그 안에서 어떤 가치도 인지하지 못할 수 있다는 것이다. 이는 사업 가치가 있는 스토리기술적인 스토리 의 우선순위를 정하는 것을 어렵게 만든다.

하지만 기술적인 스토리 가 존재하려면 제품 책임자는 왜 이를 위해 비용을 지불해야 하며, 따라서 무슨 가치를 최종적으로 전달하려는지 이해할 수 있어야한다.(개발팀이 PO에게 오라클 최신 DB로 이전해야하는 것에 대해 설명 후 PO가 가치를 이해 후 제품 백로그에 포함시키는 예시를 기억하자.)

하지만 이는 또한 완료의 정의를 통해 기술적 스토리의 특정 영역을 해소할 수 있다.

추정(Estimatable)

스토리에 필요한 노력과 비용을 가늠할 수 있도록 스토리를 만들어야 한다. 만일 팀이 스토리의 크기를 정할 수 없다면 그 스토리는 크기를 정하기엔 너무 크거나 모호한 경우기ㅓ나 혹은 팀이 크기를 추정하기에는 지식이 부족한 것이다.

(작은) 사이즈 적합성(Small)

스토리는 작업을 하려고 계획한 때를 위해 알맞은 크기(sized appropriately) 가 되어야 한다.

반드시 언제(when) 스토리를 작업할 것인지를 생각하여 에픽의 사이즈를 나누는 기준을 적용해야 한다.

테스트(Testable)

스토리는 관련된 테스트를 통과 또는 실패하는 2진법 형식으로 테스트 가능(testable) 해야 한다.

비기능적 요구 사항

비기능적 요구 사항 은 시스템 수준의 제약을 나타낸다. ex. 시스템이 IE8, 파이어폭스6, 파이어폭스7, 사파리, 크롬15 를 지원해야한다.

필자는 팀이 가능한 많은 비기능적 요구 사항을 완료의 정의에 포함시키는 것을 추천한다. 비기능적 요구 사항을 개발 막바지에 테스트하는 것은 결정적인 시스템 성능 특성에 대한 빠른 피드백을 얻는 것을 방해한다.

지식 습득 스토리

지식 습득을 하기 위한 제품 백로그 항목을 만들어야 한다.

어떤 경우에는 일을 진행하기에 제품에 관한 지식이 불충분할 수 도 있으므로 이러한 지식 습득 스토리를 통해 탐구를 해야한다.

하지만 지식 습득 스토리도 충분히 이를 수행할만한 합리적이고 경제적인 가치가 있는지를 따져봐야 한다.(동전을 던지며 A, B 두 설계에 대한 가치를 판단하는 예시)

빨리 실패 하기 전략: 무언가를 시도해보고 금방 피드백을 받고 빠르게 점검하며 적응하는 전략.

스토리 수집

스토리를 수집하기 위해 사용자에게 질문하는 것보다 더 나은 접근법은 사용자를 팀의 일부로 포함시켜 무엇을 만들지 경정하고 만들어진 것을 계속해서 검토해 나가게 하는 것이다.

사용자 스토리 작성 워크숍

사용자 스토리 작성 워크숍(user-story-writing workshop) 의 목적은 함께 바람직한 비즈니스 가치를 브레인스토밍하고 제품이나 서비스가 무엇을 해야 하는지를 위한 사용자 스토리를 만드는 역할을 하는데 있다.

스토리 매핑

스토리 매핑은 사용자 중심적 설계의 개념과 스토리 분해를 결합하여 하나로 만든다. 좋은 스토리 맵은 사용자 관점에서 활동의 흐름을 보여 주고 개별 스토리와 더 큰 사용자 가치의 연관성을 이해하기 위한 맥락(context)을 제공한다. 에어비앤비의 사례와 유사하다고 볼 수 있다.

Note: 스토리 작성 워크숍은 워크숍 기간 동안 스토리를 우선순위대로 정리하는 것이 아닌 스토리를 작성하는데 초점을 맞춘다. 그래서 우리는 스토리 매핑을 우선순위 정렬을 시각화하는데 도움을 주는 기술로서 워크숍을 보완하는데 사용할 수 있다.

마무리

This post is licensed under CC BY 4.0 by the author.

[React] setState의 비동기성

[에센셜 스크럼] Chapter6 - 제품 백로그