搜索
优秀用户故事的准则在Sprint计划会议中，划分用户故事是一个很重要的活动。划分用户故事时，一定要遵循用户故事的划分准则。一、用户故事的概念：用户故事描述了对软件（或系统）用户或客户有价值的功能。用户故事包括三方面内容：书面描述（用于计划和备忘），交谈（细化故事细节），以及测试用例（验证故事实现）。书面描述--包括故事的描述，为谁服务，唯一标识，提示信息，对迭代计划编制有所帮助。交谈--和用户一起进行面对面的沟通，记录笔记，模型，文档交流。测试用例--立验收测试的标准，这个标准是让用户来如何来确认这个故事已近完成的。一个好的用户故事包含三个要素：角色、活动以及商业价值。角色即功能的使用者，活动描述需要完成怎样的功能，商业价值描述功能的必要性以及功能带来的价值。用户故事的格式为：作为一个角色，我想要活动，以便于商业价值。注意：用户故事不能够使用技术语言来描述，要使用用户可以接受的业务语言来描述。二、用户故事与用例的区别：用户故事的作用是备忘功能，而不是文档。而用例需要详细的描述期操作步骤，以及每个异常路径。用户故事是可见的商业价值，而不是功能描述。每个用户故事的粒度与工作量都相差不多。用户故事是小粒度的，可测试的，可见的，并且是有价值的。三、优秀用户故事的特性：优秀的故事具备六个特点，即：独立性、可协商性、对用户或者客户有价值、可预测性、短小精悍以及测试性。1、独立性：尽可能避免故事之间存在依赖关系，故事间的依赖关系会产生优先级和规划问题。2、可协商性：故事是可协商的，不是必须实现的书面合同或者需求。3、对用户或者客户有价值。确保每个故事对客户或者用户有价值的最好方式是让用户编写故事。4、可预测性。开发者应该能够预测故事的规模，以及编码实现所需要的时间。5、短小精悍。故事规模对实现有影响，何种故事规模最合适，取决于开发规模、开发组的能力，以及技术实现等方面。6、测试性。所编写的故事必须是可测试的。四、用户故事的划分用户故事主要是从客户角度划分，可以按照以下原则划分：1、按照不同操作—添加、删除、修改、浏览等。2、按照数据—可以浏览产品和介绍、可以浏览产品价格3、按照特性—易用性、性能、兼容性、并发性等等4、按照角色—从不同的用户角度等等由于调度系统功能点较多，操作也较多，个人认为可按照不同操作来划分用户故事。五、划分用户故事的原则：随着用户故事粒度的增大，不定性（由于缺陷、人为因素、外部依赖等因素）会急剧提高。所以用户故事的划分要做到以下几点：1、缩短完成用户故事的时间。很多人认为用户故事的大小跟完成时间是成正比的。但是研究表明，随着用户故事规模的增长，完成它所需要的时间会成非线性增长。两倍大小的用户故事需要花五倍的时间来完成。2、减少用户故事大小的差异性在开发过程中，很多时候团队成员都在等待，开发人员等待需求，开发人员等待架构和代码审查，测试人员在等开发人员完成开发工作等等。在稀缺资源面前会有一个长长的任务队列。如果能够消除由于资源竞争产生的队列，团队开发的效率就会大大提高。根据排队原理，用户故事的不确定性是导致系统开发周期非线性膨胀的主要因素。不确定因素主要有：不确定的迭代长度，不确定的用户故事集合，用户故事大小差距很大，团队成员不固定发布时间，不固定新的需求到达时间。解决的方案就是让一切变得确定，稳定。需要把大的任务切成类似大小的小的用户故事。这样就大大减小了不确定性，提高了效率。将大的用户故事分割成小块的好处：1、减少等待：下游的成员不必要等待过长的时间，小用户故事在系统内的流传会很快，从宏观来说变成了一个并行模式而不是串行模式。2、加快反馈：每个小功能的完成都是一个反馈点，可以及时沟通信息。大块需求导致很多需求的缺陷往往在最终测试的时候才发现的，如果不能及早完成，尽快测试，缺陷会越来越难以解决。软件很少一次就做好，多次反馈以及不断演进才是一个真正能把功能做好的策略。3、减少缺陷：沟通更加及时，有问题可以及时发现，立刻解决，而不需要过长时间的等待。4、更好的衡量进度：可以工作的软件能够更好、更真实的反应项目进度状况。人天生只能关注很小的部分--精力和智力所限。5、较少的投入获得较早的回报：这样可以尽早的达到成本与收入的平衡点。6、风险小：小的功能投入的资源较少。7、更容易分优先级：大块用户故事中难免还有优先级较低的小用户故事，通过细分，可以真正关注高优先级的用户故事。8、让每个人接触不同的用户故事：用户故事变小，也会更简单，一次很容易让不同人同时去完成。六、用户故事的验收测试的技术验收测试指检验程序。来验证已完成的用户故事是按照现场客户期待的方式开发的。一旦迭代开始，开发人员开始编写代码，现场客户开始详细测试。依靠技术熟练的现场客户成员，意味着测试将包括卡片上甚至背面的所有内容，都编进测试，并且自动运行测试工具进行检验。进行用户故事的验收测试的技术，以及测试整个主题的方法：1、列举要点(Bulletpoints)在一个用户故事卡片或者wiki上，以列举要点的形式，把对系统行为的期望结果和实际结果记录下来。这种技术适用于较小的或者简单的用户故事。2、测试场景/数据……把你测试需要用到的任何场景、数据都记录下来。比如，用正确的/错误的/空的密码来测试密码功能。跟之前的方法一样，这种技术通常非常适用于小的或者简单的用户故事。3、先测起来先进行一些测试，再洋洋洒洒把你需要验证的系统功能记录下来。这是一种比较易学的技术。这种方法适用于简单的测试，也是其他方法不适用时的万能钥匙。4、Given/When/Then使用三段式：Given，When，Then。在Given部分，罗列出前提条件，测试环境，测试输入以及系统状态。在When部分，则列出一些触发点或者状态转换事件。在Then部分，记录系统行为，期望的输出，或者下一个系统状态。这种技术对于有着很多前提条件或者有特定触发点的测试非常适用。5、概念形态上的，带有实例的规格说明书(SpecificationByExample-ConceptualForm)编制一张表格，包含测试输入和期望输出。所谓概念形态，就是不以特定的值来描述数据。如果能比较容易地做出这张表格，那么使用这种方法就很可能非常有效。6、互相搭配选择多种不同的方法应对不同的测试角度。典型用户故事的例子：假定这个项目的客户是个饮料自动售货机的制造商。他们要求我们为他们的售货机开发一款软件。我们可以找他们的市场经理了解这个软件的需求。因此，我们的客户就是他们的市场经理。谈需求的时候，有一回他这样说：“用户往售货机每塞一个硬币，售货机都要显示当前该客户已经投了多少钱。当用户投的钱够买某一款饮料时，代表这款饮料的按钮的灯就会亮。如果那个用户按了这个按钮，售货机就放一罐饮料到出口，然后找零钱给他。”上面的话描述的是一件事情，一件用户通过系统完成他一个有价值的目标（买一罐饮料）的事。客户所说的话，就是在描述一个用户故事（userstory）。如果我们想要记下这段用户故事，我们可能会用这样的格式：名称：卖饮料事件：1.用户投入一些钱。2.售货机显示用户已经投了多少钱。3.如果投入的钱足够买某种饮料，这种饮料对应的按钮的灯就会亮。4.用户按了某个亮了的按钮。5.售货机卖出一罐饮料给他。6.售货机找零钱给他。注意到，一个用户故事里面的事件可以这样描述：1.用户做XX。2.系统做YY。3.用户做ZZ。4.系统做TT。5....用户故事只是描述系统的外在行为一个用户故事只是以客户能够明白的方式，描述了一个系统的外在行为，它完全忽略了系统的内部动作。比如，下面标为红色那些文字，就属于不应该出现在用户故事中的系统内部动作：1.用户投入一些钱。2.售货机将塞进来的钱存在钱箱里，然后发送一条命令给屏幕，屏幕显示目前已经投入的金额。3.售货机查询数据库里面所有饮料的价格，判定钱足够买哪些饮料，对于钱足够买的那些饮料，对应的按钮的灯就会亮起来。4.用户按下一个亮起来的按钮。5.售货机卖出一罐饮料给用户，然后将数据库里面该饮料的存货数量减1。6.售货机找零钱给用户。不管是口头描述的，还是书面形式，这样的内容是描述用户故事时一个很常见的错误。特别的，千万不要提及任何有关数据库，记录，字段之类的对客户一点意义都没有的东西。注：用户故事只是跟用户交流的开始，而不是全部假想已经从客户那边得到足够详细的需求了，我们可以开始实现了。不用把所有用户提供的细节都记录下来。假设你有点忘记用户故事，而客户又在你旁边，你直接问客户。客户可以提示更准确，更完整的需求给你。特别要注意的是，只要完成一个用户故事，就要让客户看一下，或者实际的操作一下，因为客户对已经做的的东西了解得越多，那他就可以提供越准确越完整的需求。用户挑选完用户故事以后，我们就要将这些用户故事逐个完成。每个用户故事我们都会设计结构，编码，测试等等。每做完一个用户故事，我们都要让客户验证一下系统是不是他所想的那样。