用户故事-软件工程.pptVIP

用户故事贯穿于整个开发流程 产品负责人根据收集来的需求编写用户故事,放入产品Backlog中 在Sprint计划会议中,团队成员讨论其中的一些用户故事,细化故事细节,确定验收标准,使用Planning Poker(计划扑克)估算故事点,然后把故事分成一些小的任务,并估算时间 最后,把故事放入Sprint Backlog中,按优先级排序 Sprint开始时,故事卡片和任务卡片都放在白板的TO DO栏,团队成员按故事的优先级挑选任务,把任务卡片挪到Doing栏.团队尽可能完成优先级高的故事. 在故事开发的初始阶段,测试人员和产品负责人一起确认测试用例 故事的任务完成后,产品负责人验收并确认故事已完成 把故事卡片挪到Done栏中.如此完成Sprint的所有任务 Sprint结束时,团队将完成的故事演示给涉众,其它产品负责人和团队,通过用户故事向客户输出商业价值 什么是用户故事 描述了对用户、系统或软件购买者有价值的功能。用户故事由以下三方面组成： 卡片：一份书面的故事描述 交流：有关故事的对话，用于具体化故事细节 确认：测试，用于表达和编写故事细节且可用于确定故事何时完成 例子： 用户可以在网站上发布简历 用户可以搜索职位 公司可以发布新职位 用户可以限制浏览其简历的人 优秀的故事特点 独立的 可讨论的 对用户或客户有价值的 可估计的 小的 可测试的 用户故事验收测试 写验收测试的好处 很多客户和开发人员讨论的很多细节可以通过验收测试记录下来 测试是一个两步流程 1)测试要点写在故事卡上 2)测试要点变成全面的测试,这些测试可以用来演示故事已正确,完整地实现 用户故事验收测试 故事卡背面的测试要点的例子:公司可以用信用卡支付发布工作的费用 测试要点 用VISA信用卡,万事达信用卡和美国运痛卡测试(通过) 用大来卡测试(失败) 用正确的,错误的和空的卡号测试 用过期的信用卡测试 测试不同的交易金额(包括超过信用卡额度限制) 测试要点记录了客户提出的一些假设 验收测试也提供了确认故事是否被完整实现的基本标准 有了标准,我们就知道什么时候某件事情算是做完了 为程序员提供大量有用的信息 例如想想不同的交易金额(包括超过信用卡额度限制),如果在写代码前写了这一测试,会提醒程序员处理因额度不够导致交易失败的情况 客户团队由哪些人组成 包括确保软件满足用户需求的所有人 测试人员 产品经理 真实用户 交互设计人员 规划发布和迭代 一个发布由一个或多轮迭代组成 发布规划指的是确定项目时间表和预期功能集合之间达到平衡 迭代规划涉及选择迭代包含的故事 客户团队和开发人员在发布和迭代规划中都要参与 规划发布和迭代 发布规划时 客户团队首先从排列故事优先级开始 排优先级考虑: 大部分用户和客户对特定特性的渴望程度 小部分重要用户和客户对特定特性的渴望程度 故事之间的关系 例如缩小故事的优先级不高,但它可能被看做是高优先级的,它与高优先级的另一个故事放大互补 当开发人员与客户团队意见冲突时,应坚持客户利益最大化 什么是验收测试 用来验证实现的用户故事是否符合团队的期望 当一轮迭代开始时 开发人员开始编码 客户团队开始测试 测试工作包括 从故事卡背面写下的测试描述开始 到把测试放入自动化测试工具中的所有工作 定义速率 速率是一个团队在一轮迭代中完成的故事点数 为何在故事卡背面写测试描述？ 在卡片的背面写测试对于客户是沟通故事的期望和假设的非常好的方法 哪些不是好的用户故事 1用户可以在Windows XP 和Liunx上运行系统 2所有绘图和图表将用第三方类库完成 3用户可以最多撤销50步操作 4软件将在不久的将在6月30日发布 5软件将用JAVA编写 6用户可以从下拉列表框里选择他的国籍 7系统将使用LOG4J把所有错误信息记录到一个文件中 8如果用户15分钟内没有保存文档，系统将提示用户进行保存 9用户可以选择导出到XML特性 10用户可以导出数据到XML文件 答案 1 OK 2 用户不关心图表是怎样实现的 3 OK 4 需要在发布计划中考虑的限制条件 5 依赖于产品，如果产品是一个面向JAVA程序员的类库，那些用户会比较关心使用的语言 6，小了点 7 它不应该指定使用LOG4J实现日志功能 8 OK 9 OK 10 OK 估算用户故事 在估算会议上，三个程序员在估算一个故事 分别估算故事为2，4，5个故事点，他们应该用哪个估算？ 他们应该继续讨论这个故事，直到他们的估算更加接近 团队A在上2个星期的迭代中完成了43个故事点。团队B在作另一个项目而且有两倍的开发人员。他们同样在上2个星期的迭代中也完成了43个故事点，为什么会这样？ 一个团队的故事点数和任何其它团队的故事点数没有可比性 在该问题中，不能认为团队A的效率是团队B的效率的两倍 估算团