The Fact of User Story

1. Preface

很多时候,当做事迷失于细节,就会忘记了当时做这件事情的本来目的,做项目也是一样。

2. What’s User Story

用户故事描述的是用户想要在某一场景下达到的目标,即业务价值,用来作为需求的提示和制订计划。

3. Why User Story

当用户看到或使用软件后,通常会产生新想法

经验告诉我们,软件需求是易变的,不确定的,我们不可能很好的预测到将来需求的变化。用户在看到或使用软件后通常会产生新的想法。这种需求的不可控是软件项目中最大的风险与痛点,也正是这种不确定性的存在使得我们必须关注用户需求的核心目标,并且频繁的,以最快的速度将已工作的软件与用户进行沟通,及时捕获用户的新想法或新需求。

用户故事就是在这样一种大的环境下随着迭代式轻量级开发方法的出现而出现。

4. The Fact of User Story

It is about the Intent

在多变的需求中,通常用户完成需求的目标和业务价值是不变的,所以用户故事更多的是关注用户所要达到的目标,而非具体的解决方案或某一个细节。这也是它与传统的需求规格说明书最大的不同。

为什么不一开始就讨论细节呢?

第一,软件需求是多变的,过早的涉及细节往往是一种浪费。到真正开发的时候这些细节通常会发生新的变化。
第二,开发中开发人员对需求存在不同的解读,不可能一次性作对。
第三,过早的涉及细节,会使得开发人员陷入实现的过程中,只是为了实现而实现,而忘记了需求的目的,从而可能丧失了选择其它更加有效的解决方案的机会;另外,这样的用户故事也会变得不可协商,等同于传统的软件需求规格说明书,在敏捷开发中应该尽量避免。

It is a PlaceHolder

用户故事代表着用户的需求而不是记录用户的需求,用来制订计划和需求提示。

It is about Conversation

用户故事强调的是口头的交流,”听我来讲故事”,阐述着用户故事背后的真正目的。需求的细节需随着开发的进行而在频繁的“对话“中获得,从而能够一定程度上应对多变的需求。

Ron Jeffries用3个C来描述用户故事,卡片(Card)、交谈(Conversation)和确认(Confirmation)。卡片一般是一张小纸片,写着用户的故事描述。如果故事卡上面已经无法继续书写了,那么需要使用更小的故事卡,这迫使我们更好的关注目标而非细节。

5. How User Story Plays its Role

用户故事是随着项目的进展逐渐演进的。

在业务分析阶段(Inception),捕获用户的业务流,提取用户故事。业务流节点上的任何有效一步都可以作为一个用户故事或者多个用户故事。这个时候得到的是粗粒度的用户故事,通常称为master story。

当项目进入开发阶段时,用户故事需要进一步拆分,使其大小适合于开发与计划;同时增加一些开发假设或相关的约定使之能够被开发。进入开发中,开发团队实现用户故事,与业务分析员和用户协商其中的解决方案与实现,在协商沟通的方式中可工作的软件胜于详尽的文档。

开发完成后,测试人员基于完成的用户故事进行测试,完成部署,最后由用户对已交付的用户故事进行验收,验收通过,也意味着该用户故事就此结束。

用户故事驱动着整个项目的开发过程,需求由不确定到确定,直至最终完结。

6. What’s a Good User Story

6.1 Reflect its intent

用户故事通常按照如下的格式来表达:  

story
1
2
3
4

As a <Persona>,
I'd like to/want to <Action>,
so that I achieve <Goal/Benefit>.

或者

story
1
2
3

In order to achieve <Goal/Benefit>,
<Persona> want to <Action>…

举例:

story
1
2
3
4
5

作为工作单处理人员,
我希望能够查询待处理的工作单,
以便了解当前需要处理的订单,及时完成订单的处理。

这样来表达的好处是显而易见的,它是从用户角度关注业务目标,是采用用户和开发团队都可以理解的业务语言去编写,而不是技术语言。开发人员在理解了业务价值后会有助于技术方案的决策,帮助更快速地开发,而这样的用户故事也会鼓励用户的参与,从而帮助项目。

比如<<用户故事与敏捷方法>>一书中提到的”该产品应该有4个轮子”描述,这时候我们往往会联想到汽车,然而其实用户想要的是一个割草机,所以这个用户故事应该表达割草的目标,而非4个轮子的细节或解决方案。

story
1
2
3
4

As Lisa,
I want to have a tool
so that I can quickly weed my lawn.

6.2 Follow INVEST Principle

用户故事的INVEST原则可以指导我们写一个好的用户故事。

6.2.1 Independent

用户故事应该是端到端的,可独立开发,独立部署、独立交付的功能点。在整个业务流中, 应尽量避免故事之间的相互依赖,这种依赖会使得制订计划与开发都变得更加困难。

6.2.2. Negotiable

用户故事代表的是用户的目标,不是Specification,所以一切能够达到用户故事目标的解决方案与实现细节都是可以协商的。故事卡本身的简单描述,也是在提示用户与开发团队,这不是具体的需求,也不是最终的解决方案。开发团队应发挥主动能动性参与到这些解决方案与细节的商谈中,从而帮助用户更好的更有效的达到目标。

6.2.3 Valuable

每个故事必须给用户带来价值,从业务角度而非实现角度。

6.2.4 Estimatable

可估算的,帮助制定项目计划,故事之间不能相差太多, 整个项目开发周期中一致性胜于准确性。

6.2.5 Small/Size Appropriate

用户故事的大小需要合适,过大过小都不利于制定计划。一般它的大小取决于迭代长度。如果一个用户故事不能够在一个迭代内完成,那么就会影计划,也意味着不能够对它进行部署,不能尽快拿到反馈,用户故事的不确定性就会增加。

我们一般会对过大的用户故事进行拆分或重新组合。拆分用户故事不管什么方法,最重要的是保证用户故事是端到端的,可独立交付,而如创建用户API,创建用户UI这样的用户故事是不好的。

6.2.6 Testable

每个用户故事都是可独立测试的.

7. Summary

综上所述,用户故事描述的是用户的目标和业务价值,而不是解决方案;用户故事不是传统的需求规格说明书,不是用例,不是既定的合同或契约,它是可协商的;用户故事代表了用户的需求,而不是记录用户的需求。它时时提醒我们需要以可工作的软件与客户进行有效的沟通,快速反馈,及时捕捉新的需求。

用户故事是面向用户的,强调口头沟通;鼓励延迟细节的处理;用户故事的大小适合制定作计划;用户故事必须是可估计的,以便帮助计划。用户故事必须是独立可开发可交付的;用户故事之间如果存在依赖,将会影响我们制订计划。

It is all about the intent.“,以我们的核心技术能力,帮助用户达成目标实现业务价值是敏捷开发团队的关键目标。

Share Comments