收藏
用户故事与敏捷方法 - Mike Cohn

用户故事与敏捷方法

Mike Cohn

出版社

清华大学出版社

出版时间

2010-03-31

ISBN

9787302223405

评分

★★★★★

标签

敏捷开发需求分析敏捷项目管理

书籍介绍

《用户故事与敏捷方法》详细介绍了用户故事与敏捷开发方法的结合，诠释了用户故事的重要价值，用户故事的实践过程，良好用户故事编写准则，如何搜集和整理用户故事，如何排列用户故事的优先级，进而澄清真正适合用户需求的、有价值的功能需求。

《用户故事与敏捷方法》对于软件开发人员、测试人员、需求分析师和管理者，具有实际的指导意义和重要的参考价值。

AI导读
核心看点
  • 详解用户故事编写准则与搜集技巧
  • 阐述敏捷开发中需求优先级排列方法
  • 提供估算、迭代计划及验收测试实战
适合谁读
  • 寻求敏捷转型的软件开发人员
  • 负责需求分析与产品管理的PM
  • 希望提升团队协作效率的管理者
读前提醒
  • 需结合团队实际场景灵活应用方法
  • 重视书中强调的面对面沟通与对话
  • 注意区分用户故事与传统需求文档
读者共识
  • 理论体系完整，是敏捷入门经典之作
  • 落地实施需克服组织沟通障碍与阻力
  • 部分读者认为缺乏UI交互设计环节

本导读基于书籍简介、目录、原文摘录、短评和书评生成，不等同于全文精读。

精彩摘录
  • "第1章 概览 什么是用户故事 用户故事描述了对用户、系统或软件购买者有价值的功能。其包括： 1.一份书面的故事描述，用来做计划和作为提示。 2.有关故事的对话，用于具体化故事细节。 3.测试，用于表达和编档故事细节且可用于确定故事何时完成。 使用故事的过程是怎么样的？ 编写用户故事的过程最好从考虑系统的用户类别开始。 应由客户团队而不是开发人员来编写用户故事，尽量不要出现技术术语。 排列优先级时需要考虑下面几点： 1.大部分用户和客户对特定特性的渴望程度。 2.小部分重要用户和客户对特定特性的渴望程度。 3.故事之间的互补或依赖关系。 规划发布和迭代 在许多故事的优先级上，开发人员可能与客户团"
  • "Tom Poppendieck(2003) 评论说：“如果总是需要写满小卡片，那下一次就用一个更小一点儿的卡片。”"
  • "第6章 用户故事验收测试 验收测试可以记录客户提出的一些假设，也提供了确认故事是否被完整实现的基本原则。 在写代码之前写测试 考虑每个故事，然后问类似下面的一些问题： 1.关于这个故事，程序员还需要知道什么？ 2.对怎么实现这个故事，我的想法是什么？ 3.有没有一些特殊情况会使这个故事有不一样的行为？ 4.这个故事在什么情况会出错？ 客户定义测试 客户可以和程序员与测试人员合作创建测试，但不要完全依赖程序员与测试人员，客户至少应该详细的指出一些测试，用以验证故事的实现是正确的。 测试是过程的一部分 一般情况下，产品经理和测试人员共同负责列出详细的测试。产品经理带来驱动项目的公司目标的知识；测试"
  • "第7章 优秀用户故事准则 从目标故事开始 切蛋糕 技术人员习惯将大故事按照技术路线分割，这种做法的缺陷是，没有一个故事是单独对用户很有用的。而应该保证每个小故事都提供某种程度的完整的功能。 编写封闭的故事 一个封闭的故事是指那种随着一个有意义的目标的实现而结束的故事，能让用户使用后觉得她完成了某个任务。 卡片约束 对于任何必须要遵守而不需要直接实现的故事，在其故事卡上标注“约束”（constraint） 比如 系统必须支持最大50个并发用户的峰值。 尽管约束卡不需要做估算，也不会像普通卡那样被安排到迭代中，但可以有验收测试。 根据实现时间来确定故事规模 不要过早涉及用户界面 有些需求并不是故事"
  • "第8章 估算用户故事 故事点 可以用户理想日作为故事点的单位：相较于用连续时间估算，它更简单；相较于用完全模糊单位，它可使我们的估算拥有更好的依据。 以团队估算 客户和产品经理可以参加，但他不能提出他个人的估算或者在听到自己不赞成的估算时发表意见。 估算 Wideband Delphi方法，与采用迭代方式进行开发软件的极限编程类似。 目的是要为故事得到一个统一的估算值。这个迭代过程很少超过3轮。 三角测量 帮助团队验证他们没有逐渐改变一个故事点含义的有效方法，不过可以不是特别精确。 使用故事点 我们用“速率”（velocity）来代表一个团队在一轮迭代中完成（或期望完成）的故事点数。因此，务必"
  • "第10章 迭代计划 迭代计划概览 1.讨论故事。 2.从故事中分解出任务。 3.开发人员承担每个任务的职责。 4.讨论过所有故事，并且接受所有任务后，开发人员单独估计他们承担的任务，以确保他们不会做出过于乐观的承诺。 讨论故事 过分地深入每个故事的细节会让会议变得冗长、低效，因为会议中不是每个人都需要聆听所有故事的所有细节。 分解任务 1. 尽管故事的确可以小到作为工作单位，但将他们分解出更小的任务，一般更符合项目协作的需要。 2. 故事是对用户或客户有价值的功能的描述，它们并不是开发人员的待办事项。分解任务有助于发现那些可能会被遗忘的任务。 3. 一个故事点任务分解其实是即时设计中的一次短脉"
  • "用户故事强调对话交流而不是书面沟通。 用户故事可以同时被你和开发人员理解。 用户故事用的大小适合于做计划。 用户故事适用于迭代开发。 用户故事鼓励推迟考虑细节，直到你非常清楚地了解自己的真正需求。"
  • "独立的(Independent) 可讨论的(Negotiable) 对用户或客户有价值的(Valuable to Purchasers or Users) 可估计的(Estimatable) 小的(Small) 可测试的(Testable)"
作者简介
Mike Cohn是敏捷联盟的发起成员之一，并担任其文章项目的总监。他1984年开始编程，1988年开始管理软件项目，客户包括富达投资、维亚康姆、宝洁、NBC和花旗银行。Mike写本书时是Fast401k的软件工程副总裁。这家行业领先公司提供基于互联网的401(k)档案保存和管理解决方案。Fast401k向金融服务行业客户提供自主品牌的e401k软件产品，作为外包服务供应商，利用专有技术实现规模经济效应。在本书之前，Mike著有或合写了4本编程方面的书籍
目录
第I部分 起步
第1章 概览 3
什么是用户故事？ 4
细节在哪里？ 5
“必须多长时间完成？” 6

显示全部
用户评论
看看就行了，其实很多时候对第一线的用处不是特别大。但是引起的思考和进一步研究是很好的
敏捷开发中需求分析的基础 很有用 实践中 要用好还得努力啊
: TP311.5/2963
为什么总加班？为什么那么努力却看不到进步的优质成果。想到一位大大说的话，大部分人都在靠本能工作，而不是方法。不到7人的敏捷团队在10个月可以完成100多人瀑布团队9个月的开发任务，这就是敏捷开发的魅力吧，越来越多的开发团队也在引入敏捷方法。之前学PMP的时候就对敏捷很感兴趣，但老师也只是浅浅讲了下，看这本书扫盲了，很细节，也有案例。终于知道了用户故事该怎么操作，也终于明白了什么是“测试驱动开发”。太爱这种又高效又聪明的工作方式了！
这的确是一套不错的方法，但放到产品开发里来，就会发现少了一个很重要的环节——UI和交互设计。指望开发、PM们口头沟通就能开发出优秀的产品是不可能的。
很好的敏捷项目指导书籍
产品经理必读
感觉咨询行业更适用
与瀑布式开发相比，这种延迟细节、拆分任务、保证高频率沟通的开发模式，是可能通过完善的规则来降低对项目成员的要求，提高开发效率的。但我觉得这种工作模式更适合能短期交付的项目而非十分庞大的项目，通过规范的流程保证项目的底线，至于上限就另说。
敏捷方法的入门级教材，还是有些收获的
清华大学出版社的其他书籍查看全部

下载
收藏