提示：本文共有 3694 个字，阅读大概需要 8 分钟。
Sprint计划会议中，划分用户故事是一个很重要的活 动。划分用户故事时，一定要遵循用户故事的划分准则。 用户故事描述了对软件（或系统）用户或客户有价值的功能。用户故事包括三方面内容：书面描述（用于计划和备忘）， 交谈（细化故事细节），以及测试用例（验证故事实现）。 书面描述 包括故事的描述，为谁服务，唯一标识，提示信息，对迭代计划编制有所帮助。 交谈 和用户一起进行面对面的沟通，记录笔记，模型，文档交流。 测试用例 立验收测试的标准，这个标准是让用户来自:WWw.xlTkwj.com 小龙文 档网:用户故事,模板来如何 来确认这个故事已近完成的。 一个好的用户故事包含三个要素：角色、活动以及商业价值。角色即功能的使用者，活动描述需要完成怎样的功能， 商业价值描述功能的必要性以及功能带来的价值。 用户故事的格式为：作为一个 角色，我想要 活动，以便于 商业价值。 注意：用户故事不能够使用技术语言 来描述，要使用用户可以接受的业务语言来描述。 用户故事的作用是备忘功能，而不是文档。而用例需要详细的描述期操作步骤，以及每个异常路径。 用户故事是可见的商业价值，而不是功能描述。每个用户故事的粒度与工作量都相差不多。 优秀的故事具备六个特点，即：独立性、可协商性、对用户或者客户有价 独立性：尽可能避免故事之间存在依赖关系，故事间的依赖关系会产 可协商性：故事是可协商的，不是必须实现的书面合同或者需求。 对用户或者客户有价值。确保每个故事对客户或者用户有价值的最好 可预测性。开发者应该能够预测故事的规模，以及编码实现所需要的 短小精悍。故事规模对实现有影响，何种故事规模最合适，取决于开 由于调度系统功能点较多，操作也较多，个人认为可按照不同操作来划分用户故事。 随着用户故事粒度的增大，不定性（由于缺陷、人为因素、外部依赖等因素）会急剧提高。所以用户故事的划分要做到 以下几点： 很多人认为用户故事的大小跟完成时间是成正比的。但是研究表明，随着用户故事规模的增长，完成它所需要的时间 会成非线性增长。两倍大小的用户故事需要花五倍的时间来 完成。 在开发过程中，很多时候团队成员都在等待，开发人员等待需求，开发人员等待架构和代码审查，测试人员在等开发 人员完成开发工作等等。在稀缺资源面前会有一个长长的任 务队列。如果能够消除由于资源竞争产生的队列，团队开发 的效率就会大大提高。根据排队原理，用户故事的不确定性 是导致系统开发周期非线性膨胀的主要因素。不确定因素主 要有：不确定的迭代长度，不确定的用户故事集合，用户故 事大小差距很大，团队成员不固定发布时间，不固定新的需 求到达时间。解决的方案就是让一切变得确定，稳定。需要 把大的任务切成类似大小的小的用户故事。这样就大大减小 了不确定性，提高了效率。 1、减少等待：下游的成员不必要等待过长的时间，小用户故事在系统内的流传会很快，从宏观来说变成了一个并行 模式而不是串行模式。 2、加快反馈：每个小功能的完成都是一个反馈点，可以及时沟通信息。大块需求导致很多需求的缺陷往往在最终测 果不能及早完成，尽快测试，缺陷会越来越难以解决。软件很少一 次就做好，多次反馈以及不断演进才是一个真正能把功能做好的策 3、减少缺陷：沟通更加及时，有问题可以及时发现，立刻解决，而不需要过长时间的等待。 4、更好的衡量进度：可以工作的软件能够更好、更真实的反应项目进度状况。人天生只能关注很小的部分 精力和 智力所限。 5、较少的投入获得较早的回报：这样可以尽早的达到成本与收入的平衡点。 7、更容易分优先级：大块用户故事中难免还有优先级较低的小用户故事，通过细分，可以真正关注高优先级的用户 故事。 8、让每个人接触不同的用户故事：用户故事变小，也会更简单，一次很容易让不同人同时去完成。 验收测试指检验程序。来验证已完成的用户故事是按照现场客户期待的方式开发的。一旦迭代开始，开发人员开始编 写代码，现场客户开始详细测试。依靠技术熟练的现场客户成员，意味着测试将包括卡片上甚至背面的所有内容，都编 进测试，并且自动运行测试工具进行检验。 1、列举要点Bulletpoints 在一个用户故事卡片或者wiki 上，以列举要点的形式， 把对系统行为的期望结果和实际结果记录下来。这种技术适 用于较小的或者简单的用户故事。 把你测试需要用到的任何场景、数据都记录下来。比如，用正确的/错误的/空的密码来测试密码功能。跟之前的方法 一样，这种技术通常非常适用于小的或者简单的用户故事。 先进行一些测试，再洋洋洒洒把你需要验证的系统功能记录下来。这是一种比较易学的技术。这种方法适用于简单的 测试，也是其他方法不适用时的万能钥匙。 使用三段式：Given，When，Then。在Given 部分，罗 列出前提条件，测试环境，测试输入以及系统状态。在When 部分，则列出一些触发点或者状态转换事件。在Then 部分， 记录系统行为，期望的输出，或者下一个系统状态。这种技 Example ConceptualForm 编制一张表格，包含测试输入和期望输出。所谓概念形态，就是不以特定的值来描述数据。如果能比较容易地做出这张 表格，那么使用这种方法就很可能非常有效。 假定这个项目的客户是个饮料自动售货机的制造商。他们要求我们为他们的售货机开发一款软件。我们可以找他们的 市场经理了解这个软件的需求。 因此，我们的客户就是他们的市场经理。谈需求的时候，有一回他这样说：―用户往售货机每塞一个硬币，售货机都 要显示当前该客户已经投了多少钱。当用户投的钱够买某一 款饮料时，代表这款饮料的按钮的灯就会亮。如果那个用户 按了这个按钮，售货机就放一罐饮料到出口，然后找零钱给 上面的话描述的是一件事情，一件用户通过系统完成他一个有价值的目标（买一罐饮料）的事。客户所说的话，就是 在描述一个用户故事（user story）。 如果我们想要记下这 如果投入的钱足够买某种饮料，这种饮料对应的按钮的灯就会亮。 一个用户故事只是以客户能够明白的方式，描述了一个系统的外在行为，它完全忽略了系统的内部动作。比如，下面 标为红色那些文字，就属于不应该出现在 用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素： 商业价值：为什么需要这个功能，这个功能带来什么样的价值。 用户故事通常按照如下的格式来表达： 作为一个 角色,我想要 活动, 以便于 商业价 作为一个网站管理员‖，我想要统计每天有多少人访问了我的网站‖，以便于我的赞助商了解我的网站会给他 们带来什么收益。‖ 需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。 RonJeffries 关于用户故事，RonJeffries 来描述它：10 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。 交谈（Conversation） 用户故事背后的细节来源于和客 户或者产品负责人的交流沟通。 确认（Confirmation） 通过验收测试确认用户故事被正 确完成。 用户故事的六个特性 INVEST Independent,Negotiable, Valuable, Estimable, Small, Testable 一个好的用户故事应该遵循 INVEST 独立性（Independent）—要尽可能的让一个用户故事 独立于其他的用户故事。用户故事之间的依赖使得制定计 划，确定优先级，工作量估算都变得很困难。通常我们可以 通过组合用户故事和分解用户故事来减少依赖性。 可协商性（Negotiable）—一个用户故事的内容要是可 以协商的，用户故事不是合同。一个用户故事卡片上只是对 用户故事的一个简短的描述，不包括太多的细节。具体的细 节在沟通阶段产出。一个用户故事卡带有了太多的细节，实 际上限制了和用户的沟通。 有价值（Valuable）—每个故事必须对客户具有价值（无 论是用户还是购买方）。一个让用户故事有价值的好方法是 让客户来写下它们。一旦一个客户意识到这是一个用户故事 11 并不是一个契约而且可以进行协商的时候，他们将非常乐意 写下故事。 可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者 难以估计故事的问题来自：对于领域知识的缺乏（这种情况 下需要更多的沟通），或者故事太大了（这时需要把故事切 分成小些的）。 短小（Small）—一个好的故事在工作量上要尽量短小， 最好不要超过10 个理想人/天的工作量,至少要确保的是在一 个迭代或Sprint 中能够完成。用户故事越大，在安排计划， 工作量估算等方面的风险就会越大。 可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测 试，那么你就无法知道它什么时候可以完成。一个不可测试 的用户故事例子：软件应该是易于使用的。
看到此处说明本文对你还是有帮助的，关于“用户故事 模板”留言是大家的经验之谈相信也会对你有益，推荐继续阅读下面的相关内容，与本文相关度极高！
