用户故事与敏捷方法

第一章 概览

»什么是用户故事？

用户故事描述了对用户、系统或者软件购买者有价值的功能。核心是有价值的。

用户故事包括以下三方面：

 »细节在哪里？

用户故事分大小，很大不行，史诗级的用户故事，可以进一步拆分成小故事，特别小也不行，故事细节不如大家一起讨论。用户故事不用像需求文档一样扩充。

»必须多少时间完成？

记录用户期望，然后用测试验收的方式检查，是否已经完成。测试描述可以不完整，可以简短，可以随时添加，目的是让开发人员知道什么时候是结束。

有点类似老师在练习册上留作业，告诉你做到哪里，什么时间完成。

»客户团队

指所有的关系人。开发、测试、交互、产品经理、实际用户、客户等等。解决了这些人的所有问题，基本上，软件系统的问题就解决了。

»使用用户故事的过程是怎样的?

»规划发布和迭代

发布规划应该是项目时间和预计功能集合之间的平衡。

迭代规划应该是。。。？？？

计划需要考虑成本。迭代需要考虑研发速率，结合优先级进行迭代计划的安排。

»什么是验收测试？

测试也可以捕获项目预期，提前写好测试例子，进行测试，是可以跟开发同时进行的。

»为什么要变？

用户故事将重点从文档转移到了对话。

 

»小结

 

第二章 编写故事

好故事应该是独立的、可讨论的、对客户有价值的、可测试的、小的、可估计的，六点特征。invest

»独立的

好故事应该是减少依赖的，当遇到依赖性强的故事时，可以采取以下三种方法：

1.两个依赖的故事合并成一个独立的稍微大点的故事

2.用不同的方式切割

3.可以进行估计。当a比b先做的时候，估计一个a的工作天数，当a比b先做的时候，估计一个a的工作天数。

»可讨论的

故事是可以讨论的，故事是功能的简短描述，它不是具体的需求本身，会记录一些重要的需求细节，但是不是全部的。如何恰如其分的描述需求细节很重要。

把细节加入到故事是一条原则。

但是在需求讨论阶段，考虑太多细节问题，会导致一种错觉：故事卡反映了所有问题，不需要跟客户进一步讨论了

 

？？？？有疑问，再细化研究吧

»对用户或者用户有价值的

用户vs客户

注意：隐含测试细节的用例要和用户故事本身分开。尽量避免用户故事中出现用户界面、技术方面的定义。

用户故事不是承诺，是。。。

»可估计的

是对开发人员说的，估计一下故事的大小。

以下是会影响估计的

1.开发人员缺少领域知识：应该参与故事的讨论，对故事有大概的了解，不用对故事的细节了解很深。

2.开发人员缺少技术知识：可以实施极限编程里面的探针实验。

3.故事太大：需要继续分解；或者可以标记成占位符，有待讨论的大功能。

»小的

史诗级故事分为两种：复合故事、复杂故事。故事的大小取决于具体的团队。

复合故事：多个小故事凑在一起。分解这类故事可以采取多种方法。比如根据动作来区分，增删改查；也可以根据数据边界进行分解。

复杂故事：一般是不可以分割的。对于一些，因为 未知性导致的复杂故事，可以多次迭代进行分解。调研类的故事可以先放第一，不跟其他故事一起进行。

对于太小的故事，需要合并。比如缺陷类故事、调整界面颜色。。。

»可测试的

对于大多数故事都是可以测试的，不能测试的一般是非功能性需求；998%可测试的都在追求自动化测试。

»小结

 

 

 

第三章  用户角色建模

»用户角色

»角色建模的步骤

★通过头脑风暴，创建初始的用户角色集合

★整理最初的用户角色集合

★整合角色

★提炼角色

——--------------------------------------------------------------------------------------------------

»通过头脑风暴，创建初始的用户角色集合

注意：一个用户角色是一个用户

»整理最初的用户角色集合