(用户故事规.docVIP

优秀用户故事的准则 在Sprint计划会议中，划分用户故事是一个很重要的活动。划分用户故事时，一定要遵循用户故事的划分准则。 用户故事的概念： 用户故事描述了对软件（或系统）用户或客户有价值的功能。用户故事包括三方面内容：书面描述（用于计划和备忘），交谈（细化故事细节），以及测试用例（验证故事实现）。 书面描述--包括故事的描述，为谁服务，唯一标识，提示信息，对迭代计划编制有所帮助。 交谈--和用户一起进行面对面的沟通，记录笔记，模型，文档交流。 测试用例--立验收测试的标准，这个标准是让用户来如何来确认这个故事已近完成的。 一个好的用户故事包含三个要素：角色、活动以及商业价值。角色即功能的使用者，活动描述需要完成怎样的功能，商业价值描述功能的必要性以及功能带来的价值。 用户故事的格式为：作为一个角色，我想要活动，以便于商业价值。 注意：用户故事不能够使用技术语言来描述，要使用用户可以接受的业务语言来描述。 用户故事与用例的区别： 用户故事的作用是备忘功能，而不是文档。而用例需要详细的描述期操作步骤，以及每个异常路径。 用户故事是可见的商业价值，而不是功能描述。每个用户故事的粒度与工作量都相差不多。 用户故事是小粒度的，可测试的，可见的，并且是有价值的。 优秀用户故事的特性： 优秀的故事具备六个特点，即：独立性、可协商性、对用户或者客户有价值、可预测性、短小精悍以及测试性。 独立性：尽可能避免故事之间存在依赖关系，故事间的依赖关系会产生优先级和规划问题。 可协商性：故事是可协商的，不是必须实现的书面合同或者需求。 对用户或者客户有价值。确保每个故事对客户或者用户有价值的最好方式是让用户编写故事。 可预测性。开发者应该能够预测故事的规模，以及编码实现所需要的时间。 短小精悍。故事规模对实现有影响，何种故事规模最合适，取决于开发规模、开发组的能力，以及技术实现等方面。 测试性。所编写的故事必须是可测试的。 用户故事的划分 用户故事主要是从客户角度划分，可以按照以下原则划分： 按照不同操作—添加、删除、修改、浏览等。 按照数据—可以浏览产品和介绍、可以浏览产品价格 按照特性—易用性、性能、兼容性、并发性等等 按照角色—从不同的用户角度 等等 由于调度系统功能点较多，操作也较多，个人认为可按照不同操作来划分用户故事。 划分用户故事的原则： 随着用户故事粒度的增大，不定性（由于缺陷、人为因素、外部依赖等因素）会急剧提高。所以用户故事的划分要做到以下几点： 缩短完成用户故事的时间。 很多人认为用户故事的大小跟完成时间是成正比的。但是研究表明，随着用户故事规模的增长，完成它所需要的时间会成非线性增长。两倍大小的用户故事需要花五倍的时间来完成。 减少用户故事大小的差异性 在开发过程中，很多时候团队成员都在等待，开发人员等待需求，开发人员等待架构和代码审查，测试人员在等开发人员完成开发工作等等。在稀缺资源面前会有一个长长的任务队列。如果能够消除由于资源竞争产生的队列，团队开发的效率就会大大提高。根据排队原理，用户故事的不确定性是导致系统开发周期非线性膨胀的主要因素。不确定因素主要有：不确定的迭代长度，不确定的用户故事集合，用户故事大小差距很大，团队成员不固定发布时间，不固定新的需求到达时间。解决的方案就是让一切变得确定，稳定。需要把大的任务切成类似大小的小的用户故事。这样就大大减小了不确定性，提高了效率。 将大的用户故事分割成小块的好处： 减少等待：下游的成员不必要等待过长的时间，小用户故事在系统内的流传会很快，从宏观来说变成了一个并行模式而不是串行模式。 加快反馈：每个小功能的完成都是一个反馈点，可以及时沟通信息。大块需求导致很多需求的缺陷往往在最终测试的时候才发现的，如果不能及早完成，尽快测试，缺陷会越来越难以解决。软件很少一次就做好，多次反馈以及不断演进才是一个真正能把功能做好的策略。 减少缺陷：沟通更加及时，有问题可以及时发现，立刻解决，而不需要过长时间的等待。 更好的衡量进度：可以工作的软件能够更好、更真实的反应项目进度状况。人天生只能关注很小的部分--精力和智力所限。 较少的投入获得较早的回报：这样可以尽早的达到成本与收入的平衡点。 风险小：小的功能投入的资源较少。 更容易分优先级：大块用户故事中难免还有优先级较低的小用户故事，通过细分，可以真正关注高优先级的用户故事。 让每个人接触不同的用户故事：用户故事变小，也会更简单，一次很容易让不同人同时去完成。 用户故事的验收测试的技术 验收测试指检验程序。来验证已完成的用户故事是按照现场客户期待的方式开发的。一旦迭代开始，开发人员开始编写代码，现场客户开始详细测试。依靠技术熟练的现场客户成员，意味着测试将包括卡片上甚至背面的所有内容，都编进测试，并且自动运行测