用户故事规范资料.doc

优秀用户故事的准则用户故事描述了对软件（或系统）用户或客户有价值的功能。用户故事包括三方面内容：书面描述（用于计划和备忘），交谈（细化故事细节），以及测试用例（验证故事实现）。书面描述包括故事的描述，为谁服务，唯一标识，提示信息，对迭代计划编制有所帮助交谈和用户一起进行面对面的沟通，记录笔记，模型，文档交流测试用例立验收测试的标准，这个标准是让用户来如何来确认这个故事已近完成的—添加、删除、修改、浏览等。 按照数据—可以浏览产品和介绍、可以浏览产品价格 按照特性—易用性、性能、兼容性、并发性等等 按照角色—从不同的用户角度 等等 由于调度系统功能点较多，操作也较多，个人认为可按照不同操作来划分用户故事。 划分用户故事的原则： 随着用户故事粒度的增大，不定性（由于缺陷、人为因素、外部依赖等因素）会急剧提高。所以用户故事的划分要做到以下几点： 缩短完成用户故事的时间。 很多人认为用户故事的大小跟完成时间是成正比的。但是研究表明，随着用户故事规模的增长，完成它所需要的时间会成非线性增长。两倍大小的用户故事需要花五倍的时间来完成。 减少用户故事大小的差异性 在开发过程中，很多时候团队成员都在等待，开发人员等待需求，开发人员等待架构和代码审查，测试人员在等开发人员完成开发工作等等。在稀缺资源面前会有一个长长的任务队列。如果能够消除由于资源竞争产生的队列，团队开发的效率就会大大提高。根据排队原理，用户故事的不确定性是导致系统开发周期非线性膨胀的主要因素。不确定因素主要有：不确定的迭代长度，不确定的用户故事集合，用户故事大小差距很大，团队成员不固定发布时间，不固定新的需求到达时间。解决的方案就是让一切变得确定，稳定。需要把大的任务切成类似大小的小的用户故事。这样就大大减小了不确定性，提高了效率。 将大的用户故事分割成小块的好处： 减少等待：下游的成员不必要等待过长的时间，小用户故事在系统内的流传会很快，从宏观来说变成了一个并行模式而不是串行模式。 加快反馈：每个小功能的完成都是一个反馈点，可以及时沟通信息。大块需求导致很多需求的缺陷往往在最终测试的时候才发现的，如果不能及早完成，尽快测试，缺陷会越来越难以解决。软件很少一次就做好，多次反馈以及不断演进才是一个真正能把功能做好的策略。 减少缺陷：沟通更加及时，有问题可以及时发现，立刻解决，而不需要过长时间的等待。 更好的衡量进度：可以工作的软件能够更好、更真实的反应项目进度状况。人天生只能关注很小的部分--精力和智力所限。 较少的投入获得较早的回报：这样可以尽早的达到成本与收入的平衡点。 风险小：小的功能投入的资源较少。 更容易分优先级：大块用户故事中难免还有优先级较低的小用户故事，通过细分，可以真正关注高优先级的用户故事。 让每个人接触不同的用户故事：用户故事变小，也会更简单，一次很容易让不同人同时去完成。 用户故事的验收测试的技术验收测试指检验程序。来验证已完成的用户故事是按照现场客户期待的方式开发的。一旦迭代开始，开发人员开始编写代码，现场客户开始详细测试。依靠技术熟练的现场客户成员，意味着测试将包括卡片上甚至背面的所有内容，都编进测试，并且自动运行测试工具进行检验。进行用户故事的验收测试的技术，以及测试整个主题的方法： 列举要点(Bullet points) 在一个用户故事卡片或者wiki上，以列举要点的形式，把对系统行为的期望结果和实际结果记录下来。这种技术适用于较小的或者简单的用户故事。 测试场景/数据…… 把你测试需要用到的任何场景、数据都记录下来。比如，用正确的/错误的/空的密码来测试密码功能。跟之前的方法一样，这种技术通常非常适用于小的或者简单的用户故事。 先测起来 先进行一些测试，再洋洋洒洒把你需要验证的系统功能记录下来。这是一种比较易学的技术。这种方法适用于简单的测试，也是其他方法不适用时的万能钥匙。 Given/When/Then 使用三段式：Given，When，Then。在Given部分，罗列出前提条件，测试环境，测试输入以及系统状态。在When部分，则列出一些触发点或者状态转换事件。在Then部分，记录系统行为，期望的输出，或者下一个系统状态。这种技术对于有着很多前提条件或者有特定触发点的测试非常适用。 概念形态上的，带有实例的规格说明书(Specification By Example-Conceptual Form) 编制一张表格，包含测试输入和期望输出。所谓概念形态，就是不以特定的值来描述数据。如果能比较容易地做出这张表格，那么使用这种方法就很可能非常有效。 互相搭配 选择多种不同的方法应对不同的测试角度。 假定这个项目的客户是个饮料自动售货机的制造商。他们要求我们为他们的售货机开发一款软件。我们可以找他们的市场经理了解这个软件的需求。 因此，我们的客户