用户故事与敏捷方法之六—编写用户故事

编写用户故事

敏捷模式下，需求的特点：不断变化，细节模糊

人的认知倾向于用固定不变的思维定式去看待一个事物。

举例，现在看着你身边的一棵植物，没有任何外力在施加作用力的情况下，你认为它是在动的吗？

举例，给你一杯水，请你不要以任何形式触碰它的情况下，让一杯水变成空杯。

（答案在篇末）

世界的真相是，一切事物都是发展变化的。敏捷方法就是既承认和接受这个事实的情况下，又要最大限度地满足人希望事物是暂时固定不变可预测的。

这就是用户故事推迟细节的原因。

用户故事粒度由粗到细

上图所代表的意思，从下到上越来越小，其主要意义并非是说用户故事从Size大逐渐被拆分为Size小。而更重要的是随着临近开发，对细节的沟通和确认，用户故事的内容越来越详细。

拆分任务只是为了团队更好的合作，任务量更好被估计，以及能够塞进一个迭代的有限任务。

究竟用户故事写到什么程度就基本成型了呢？

为了构造好的故事，关注六个特征，一个优秀的用户故事应该具备以下特点：

INVEST原则：

I：独立的 Independent

N：可讨论的 Negotiable

V：对用户或客户有价值的 Valuable

E：可估计的 Estimatable

S：小的 Small

T：可测试的 Testable

独立的

如果出现相互依赖的故事，对于排优先级和迭代计划的时候，都会出问题。

解决办法：

将多个相互依赖的故事进行合并

重新对这些相互依赖的故事进行拆分，横切和竖切法

实在没有办法合并和重新拆分，A故事依赖B故事，用两个估计：

估计一：当A故事在B故事之前完成，A故事最大估计为多少理想天。

估计二：当A故事在B故事之后完成，A故事最小估计为多少理想天。

例如：

B故事已经确定为2点~=2个理想天

A故事为3~5个理想天

A故事的估计一：5个理想天

A故事的估计二：3个理想天

因此这样的估计方法所得到的结论是，B故事至少要等待3个理想天才能开始工作，而如果AB都完成的情况下，至少需要3+2~2+5，5~7个理想天。

如果这时候老板要你预估完成AB用户故事的风险，你可以用5~7个理想天作为预测判断的依据。

可讨论的

用户故事的描述是功能的简短描述，细节将在客户团队和开发团队的讨论中产生。

在这个阶段用户故事用来提醒开发人员和客户进行关于需求的讨论。以及记录讨论过程中确定的关键点，和需要进一步确认的关键点。

讨论的细节直接转化为测试点。

过多的关注于本不应该关注的细节，只会带来更多的工作量；

过多的细节，增加了故事理解的难度；

过多的细节，造成了开发人员无需再与客户团队进行讨论的错觉；

小的

Small有两层意思

第一层意思：

只做最小量。只做最重要的，最有价值的事情，不做完美，不过早的制定太多的细节。

第二层意思：

太大的故事，不利于计划。超出一个迭代可以完成的量，就太大了，需要拆分。太大的故事，属于史诗级故事，因此在用户故事梳理会上，可以进行故事拆分。

史诗故事可以分为两种：

复合故事：分解复合故事可以按照动作进行，“创建”、“编辑”、“删除”、“查询”；

复杂故事：故事存在不确定性，难以分解。一般是分解成两个故事， 第一个故事是调研故事，第二个故事是开发故事。两个故事放在不同的迭代完成。调研任务完成才能够确定开发任务到底需要多少工作量。

比如开发新的算法，这类故事一般多发生在人工智能算法相关的用户故事。因为需要研究算法的可行性，不知道到底要多久才能够完成调研，因此难以分割。因此分为调研故事和开发故事是通常的做法。

（文中答案）

现在看着你身边的一棵植物，没有任何外力在施加作用力的情况下，你认为它是在动的吗？

答案是它的确是在动的，每一分每一秒都有植物细胞在我们肉眼无法觉察的情况下在分裂和死亡。如果等待足够长时间，这棵植物将变成今天完全不同的样子。

给你一杯水，请你不要以任何形式触碰它的情况下，让一杯水变成空杯。

答案是等待水分蒸发。每一分每一秒都有水分子从杯子中升腾到空气中。

编写用户故事就记录到这里。