用户故事

在读这本书之前,自己觉得有点好奇,用户故事指的是什么呢,读完之后,有了体会:用户故事描述了对用户.系统或者软件购买者有价值的功能.它由3方面组成:1>一份书面的故事描述,用来做计划和作为提示:2>有关故事的对话,用于具体化故事细节:3>测试,用于表达和编档故事细节且可用于确定故事何时完整. 它总共分为了五大部分来介绍: 第一部分是一些简单的概念或者使用故事的细节方面,比如如何编制用户故事,有哪些细节要求:在故事中找出用户角色模拟使用情节:怎样搜集到用户故事,通过各种途径:如何找到用户代理

计划 .估计项目总用时:7天 开发 .需求分析:作为一名现场计分员,我希望详细记录比赛现场比分增长情况,以便观众及运动员.教练员即及时掌握                                     比赛状况(每次比分形成一条记录) .生成设计文档:活动图 .设计复审:通过 .代码规范:Visual Studio 2010 .具体设计: .具体编码: using System;using System.Collections.Generic;using System.Linq;usi

第13章 用户故事的优势 从上一章我们得知,处理需求的方法多种多样,但是我们为什么要选择用户故事?因为它会带来多种好处: ①用户故事强调口头沟通:自古以来,口头表达是十分重要的.而且相比于书面书写的易产生歧义,口头表述更见简单明了,需求文档也是如此. ②人人都可以理解用户故事:相比于一些墨守成规的软件需求里的技术术语,用户故事使用的语言更容易使用户理解,简洁明了,同时更能增强用户对故事的记忆. ③用户故事的大小适合做计划:其他类型的需求分析关联性太强,并且还比较笼统,大小不能称得上是易实现的适合

软件需求是一个软件项目成功的关键因素,许多软件项目失败都是因为软件需求的“不完整.不准确.不一致”.而软件需求是从业务需求经用户需求最终得到系统需求的,所以业务需求是软件需求的源头,而业务需求又是从客户业务中来的,客户有问题且需要解决的业务才是业务需求.所以准确.完整的根据用户的描述获取用户的业务需求至关重要.从软件开发的角度入手,使用用户故事,从用户角度描述功能,让我们可以从用户角度出发思考问题,避免程序员的自以为是,使得业务需求更加的准确.完整. 用户故事描述了对用户.系统.或软件购买者有价

敏捷开发对需求规划的要求是很高的,首先需求是打散的,一个大的项目需求会拆分成很多小的功能完整的需求,以便排定优先级去逐个实现,敏捷开发提升了开发效率,但是对需求规划的要求更高了,就是对产品的需求规划能力提出了更高的要求,必须有清晰的思路,很强的需求规划能力才行,这样才能保证敏捷开发可以按照既定的设想去一步一步实现产品的设计. 敏捷开发是通过“用户故事”这个东东来实现传统软件开发所说的需求的. 一.什么是用户故事? 用户故事就是定义用户所需功能的文字描述,简单说就是用户的需求.一个好的用户故事包括

第八章 估算用户故事 故事点有一个很好的特性是团队可以定义自己认为合适的故事点,一个团队可能定义一个故事点为一个理想日的工作,也可能定义为一个理想周的工作.故事点有很多意义,所以故事点代表时间的模糊单位. 故事估算应该由整个团队集体来完成.故事估算属于团队集体有两个原因,第一个,还不确定团队中谁负责完成这个故事,第二个,团队决定的估算可能比个人估算更有用.在估算时,作者介绍了他所用的方法迭代的方式进行估算.在初步估算好后,成员进行讨论,然后进行下一轮的讨论,最终达成一致. 三角测量.估算一个故事

用户故事得到这么多人的肯定,是因为它自身的优势有很多:1.用户故事强调口头沟通,因为传统的通过各种文档进行表达,每个人对于文字的含义的理解都不同,所以在阅读文档的过程中可能会因为理解的不同对项目的完成造成影响:2.人人都可以理解用户故事,并且用户故事可以增强人们对各种事件的记忆:3.用户故事的大小适合做发布规划以及进行编程和测试:4.用户故事适合于迭代开发,项目过程中可以写出一部分故事然后就进行编码和测试5.用户故事鼓励延迟细节:6.用户故事支持随机应变的开发,因为用户故事注重口头交流,而且很容

因为需要将每个用户故事按重要性分配到相应的迭代过程,所以每个迭代过程的时间就可以根据用户故事大致估算出来,所以要学会估算用户故事所需的时间.估算用户故事可以采用故事点估算的方法,这种方法的优点就是团队可以定义自己认为合适的故事点,可以根据自己团队的情况具体定义,比较灵活.正因为这个原因,有的团队倾向于用理想时间,有的团队则倾向于使用模糊时间.估算的主要目的之一是知道整个项目的工作量,通常将估算量换算成时间,而模糊时间需要考虑项目过程中可能出现的情况,所以采用理想时间更为简单. 进行估算时尽可能整

开发软件可以通过编写用户故事来确立开发的目标和方向.而在编写故事前首先要对所有用户进行分类,根据角色的不同属性进行分类.步骤为:1.通过头脑风暴,列出初始的用户角色集合:(要坚持‘已确认的角色代表的是单一用户’的原则)2.整理最初的角色集合:(确认角色之间的关系:用户角色定义的是人而不是外部系统)3.整合角色:(对于完全重叠的用户进行重新定义,舍弃对系统成功作用不大的角色)4.提炼角色(根据角色特征来建立角色的模型). 编写故事之前需要搜集故事,通过与用户沟通来发现故事.可以像用渔网捕鱼一样获取

在我们编写用户故事或者拆分用户故事的时候,写封闭式的用户故事至关重要.一个封闭式的用户故事意味着这个故事完成后,用户可以达成一个明确的.有意义的目标.我喜欢打这样的一个比方,完成了一个用户故事,用户就可以停下来休息一会儿,喝杯咖啡了. 下面给一个不是封闭式的用户故事的示例:以一个在线求职网站为例:“作为一个招聘人员,我可以管理我发布的工作.” 这个故事太大了,以至于没有太多意义.“管理”这个活动很难被完成.比如,你们公司有一个经理,他肯定不会说,“OK,我的管理完成了,是时候干点儿实事儿了”.