实例化需求
2012-9
人民邮电出版社
Gojko Adzic
190
307000
张昌贵,张博超,石永超
无
你手里正拿着或正在屏幕上翻看的这本书，是一系列研究的成果。我们调查了世界各地的多个团队如何在很短的周期内说明需求、开发软件，并交付正确的、无缺陷的产品。本书呈现的是集体智慧，从公共网站到内部支持系统，涉及大大小小约50个项目。这些项目包含了各种各样的团队，有在一个办公室里办公的小团队，也有跨越大洲的集团公司，他们使用了众多过程，包括极限编程（XP）、Scrum、看板（Kanban）以及一些类似的方法（通常附带有敏捷或精益的字眼）。这些项目有个共同点——项目需求说明和测试能够良好配合，项目组从中获益良多。实例化需求说明如何处理需求说明与测试，不同的团队使用不同的名称，但它们都有一套共同的核心原则与思想，而我认为它们在本质上是一致的。很多团队使用以下这些名称来命名这类实践：敏捷验收测试验收测试驱动开发实例驱动开发故事测试行为驱动开发实例化需求说明相同的做法却有如此多的名字，这事实上也反映了当前在这一领域内有着大量的创新。同时它还反映了一个事实，本书描述的这些做法，影响了团队的需求描述、开发和测试等方面。为保持一致，必须选择一个名字。本书将采用实例化需求说明（Specification by Example）这个名称。至于为何选它，稍后的“谈谈术语”一节将详细解释。实践出真知本书通过案例研究和访谈来呈现这个话题。之所以选择这种方式，是为了让读者能看到目前真的有团队正在这么做，并且从中获益良多。实例化需求不是一门神秘艺术，虽然有些主流媒体会使人这么觉得。书中的一切几乎都是来自于现实世界、真实的团队以及切实的经验。有一小部分实践是作为建议提出的，并没有真实案例研究的支持。我认为这些思想对将来会很重要，也正是因为如此，我才明确地提出它们。我很确定，我所主导的研究以及我得出的结论，虽然促成了本书的编写，但由于这并不是一项严肃的科学研究，将会被那些号称敏捷开发不可用、业界应该回到“真正的软件工程” 的怀疑论者所排斥。那也没关系。相比一项严肃的科学研究所需的资源，编写本书时我接触到的资源是十分有限的。但即使我拥有那些资源，我也不是一个科学家，而且我也不用伪装我自己。我是一名实践者。本书读者对象如果你像我一样，是一名实践者，并且靠软件谋生，那么这本书可以提供很多帮助。有些团队已经尝试去实施敏捷过程，并且碰到了低质量、返工以及未达客户预期等问题，本书主要就是写给这些团队的。（没错，这些都是问题。简单地迭代只是权宜之计，并非解决方案。）实例化需求说明、敏捷验收测试、行为驱动开发，以及其他不同叫法所指的这个实践，都能解决这些问题。无论你是测试人员、开发人员、业务分析师，还是产品负责人，这本书都可以帮助你开始实施这些实践，并学习如何用它们在团队中做出更多贡献。几年前，我在大会上碰到的大多数人都没听说过这些思想。而现在，我碰到的大部分人都或多或少知道这些实践，但是很多人都未能妥善落实。在实施敏捷开发的过程中，团队碰到的问题通常都很少有文字记载，所以每一个受挫的团队都认为，自己遇到的问题比较特殊，而这些理念无法在他们的“现实世界”里发挥作用。只需听他们述说短短五分钟，我就能猜中三四个他们碰到的最大问题，这让他们觉得惊讶。而当他们得知其他团队也有同样的问题时，他们更是完全惊呆了。如果你也在这样的团队当中，那么本书为你做的第一件事情，将是告诉你“你并不孤单”。本书中我所采访的那些团队并不完美——他们也曾遇到数不清的问题。但他们在碰壁之后，并没有放弃，而是决定围绕这些问题继续努力并解决问题。了解这一点通常能鼓舞人们换一种眼光去看待自己的问题。我希望你在读罢本书后也有同样的感受。如果你正在实施实例化需求说明，本书将就如何解决你当前的问题提供非常有用的建议，同时也能让你了解未来会发生什么事情。我希望你可以从别人的错误中汲取经验，并且完全避免发生同样的问题。本书也写给有经验的实践者，以及那些在实施实例化需求说明的过程中相对成功的人们。在采访开始之初，我本以为这些事情都已胸有成竹，只是在求证而已。结果我发现，人们在实施过程中居然有如此之多的想法，这是我始料未及的。我从这些案例中学到了很多，希望你也如此。这里所描述的实践和想法，应该会激发你的灵感，促使你对自己的问题尝试变通方案，或者让你在见过类似的故事之后，意识到可以如何改善团队的过程。本书内容在第一部分，我会介绍实例化需求说明。我不会说服你为什么应该遵循本书描述的原则，而是向你展示——用实例化需求说明的方式——团队从这个过程中获益的例子。如果你在考虑购买这本书，请浏览一下第1章，看看有哪些好处可以带到你的项目中。第2章介绍了关键的过程模式和实例化需求说明的关键工件（artifact）。在第3章，我会更详细地解释活文档的概念。第4章会展示一些改变过程和团队文化的最常见的切入点，也会就开始过程实施时需要注意的地方给出一些建议。本书写作的一个目的是为团队在实施实例化需求说明时使用的这些模式、想法和工件创建一致的语言。整个实践在业界有许多名称，里面各种要素的名称更是多出一倍。不同的人分别将同一个东西叫作功能文档、故事测试、BDD文档、验收测试等。正因为如此，在第2章中我会对所有的关键要素介绍一些我感觉不错的名字。即使你非常有经验了，我还是建议阅读这1章，以确保我们对本书中的关键名字、用词和模式的理解是一样的。在第二部分，我会展示案例中的团队用来实现实例化需求说明原则的关键性实践。不同环境中的团队会做非常不同的事，有时甚至为了达到相同效果采取相反或冲突的措施。除了实践外，我还记录了团队贯彻基本原则的环境。第二部分差不多按照过程区域分成7章。在软件领域没有最佳实践，但是确实有一些好的想法我们可以尝试在不同的环境中去使用。在第二部分中，有些小节标题旁边会有拇指向上或向下的图标，代表的是调查中一些团队觉得有用的做法，或者是他们经常遇到的问题。请根据建议做适当的尝试或回避，但不要完全照搬套用。箭头图标出现的地方代表的是各种做法的精髓。软件开发不是静态的——团队和环境都在改变，过程也必须随着改变。在第三部分中，案例分析展示了一些团队的实施历程。我记录了他们的过程、约束条件和环境，并分析了这些过程是如何演化的。这些故事有助于你迈开第一步或让你更进一步，并发现新的想法与做事方式。本书的最后一章，我总结了我从促成本书的案例分析中学到的关键要素。更上一层楼在传统的学习模型守破离（Shu-ha-ri） 中，本书处于破的层次。破是说要打破陈旧的规则，并证明成功的模型有很多。在我的Bridging the Communication Gap一书中，我展示了我的模型及经验。本书中，我尽量不带进以前的背景。只有当我觉得有重要观点需要证明，并且本书中提到的其他任何团队都没有类似情况的时候，我才会展示那些我自己参与过的项目。从这个意义上讲，本书在Bridging the Communication Gap的基础上更进了一步。我会在第2章简单介绍一些基本的原则。即使你以前从未听说过这些想法，第2章的简介也应该可以给你足够的信息去理解本书的其余部分，但我不会过多地深入基础的内容。有关实例化需求说明的基础内容在Bridging the Communication Gap一书中有详细的描述，我不想在本书中重复。如果你想更详尽地重温那些基础内容，请访问http：//specificationbyexample.com，登记你购买了本书，就可免费获得Bridging the Communication Gap的PDF版本。我想今后我不会就这一主题续写“离”这个层次的书籍——因为该层次是超越书籍的。另一方面，我相信本书可以帮助你到达“离”这一层次。一旦你开始觉得选择什么工具已经无关紧要，那么你就已经达到了这个层次。本书没有源代码，也不介绍任何工具本书没有源代码，也没有特定工具的使用说明。我觉得必须事先说明这一点，因为在出版过程中，我就曾多次向别人解释这一点（典型的问题有“什么意思？一本没有源代码的软件开发书？这怎么可能！”）。实例化需求说明的原则和实践主要影响软件交付团队中的人员沟通，以及他们如何同使用者和项目干系人进行协作。我确信许多工具供应商会试图卖给你一套技术方案。如果有工具可以立即消除遇到的问题，许多经理会乐于为此买单。不幸的是，他们遇到的主要是人的问题，而不是技术问题。比尔·盖茨说过：“在企业中应用任何一项技术时，首要的法则是，在有效率的系统中导入自动化，将使效率倍增。第二条法则是，在缺乏效率的系统中导入自动化，会使效率更低下。”很多团队在使用实例化需求说明的时候失败了，他们使用自动化工具反而导致他们的过程更加低效。我不想把注意力放在特定的工具上，相反，我想侧重分析团队努力实现这些想法的真实原因。一旦你们能正确地沟通和协作，你们就可以选择适合的工具去使用。在阅读本书后，如果你想知道更多支持实例化需求说明的工具，请访问网站并查看资源部分。
《实例化需求：团队如何交付正确的软件》是在世界各地调查了多个团队软件交付过程后的经验总结。书中介绍了这些团队如何在很短的周期内说明需求、开发软件，并交付正确的、无缺陷的产品；为团队在实施实例化需求说明时使用的模式、想法和工件创建了一致的语言；展示了案例中的团队用来实现实例化需求说明原则的关键性实践；并在案例分析部分展示了一些团队实施实例化需求说明的历程。
《实例化需求：团队如何交付正确的软件》适合与项目管理、开发、测试、交付有关的人员阅读。
Gojko Adzic
战略软件交付顾问，专注于敏捷和精益开发，尤其擅长敏捷测试、实例化需求和行为驱动开发。Gojko经常在国际上重要的软件开发和测试会议上发言，并运营着英国的敏捷测试用户小组。最近这十多年来，他一直在财务和能源交易平台、移动定位、电子商务、在线游戏和复杂配置管理系统等行业项目中，从事程序员、架构师、技术指导和顾问等工作。除本书外，他还著有Bridging the Communication Gap、Test Driven.Net Development with FitNesse和The Secret Ninja Cucumber Scrolls等书。
目 录
第一部分 开始
第1章 主要优点 2
1.1 更有效地实施变更 4
1.2 更高的产品质量 5
1.3 减少返工 8
1.4 更好的协作 10
1.5 铭记 11
第2章 关键过程模式 12
2.1 从目标中获取范围 13
2.2 协作制定需求说明 14
2.3 举例说明 14
2.4 提炼需求说明 15
2.5 自动化验证时不修改需求说明 15
2.6 频繁验证 17
2.7 演化出一个文档系统 17
2.8 实际的例子 18
2.8.1 商业目标 18
2.8.2 范围 18
2.8.3 关键实例 18
2.8.4 带实例的需求说明 19
2.8.5 可执行的需求说明 20
2.8.6 活文档 20
2.9 铭记 20
第3章 活文档 21
3.1 为什么我们需要权威的文档 22
3.2 测试可以是好文档 22
3.3 根据可执行的需求说明创建文档 23
3.4 以文档为中心的模型所具有的好处 25
3.5 铭记 25
第4章 开始改变 26
4.1 如何开始改变过程 27
4.1.1 把实施实例化需求说明当作更广阔的过程变更的一部分 27
4.1.2 专注于提高质量 27
4.1.3 从功能测试自动化开始 28
4.1.4 引入一个可执行需求说明的工具 29
4.1.5 使用测试驱动开发作为踏脚石 30
4.2 如何开始改变团队文化 31
4.2.1 避免使用“敏捷”术语 31
4.2.2 确保你得到管理层的支持 32
4.2.3 把实例化需求说明当作是比执行验收测试更好的方式来推销 33
4.2.4 不要让测试自动化成为最终的目标 34
4.2.5 不要太关注工具 34
4.2.6 在迁移过程中，遗留脚本也要有人维护 35
4.2.7 跟踪哪些人在运行(以及没有运行)测试自动检查程序 35
4.3 团队如何在流程和迭代中集成协作 36
4.3.1 Ultimate软件公司的Global Talent Management团队 37
4.3.2 BNP Paribas银行的Sierra团队 38
4.3.3 天空网络服务部门 39
4.4 处理签收和可追溯性 40
4.4.1 在版本控制系统中保存可执行需求说明 41
4.4.2 通过导出的活文档来签收 41
4.4.3 签收的是范围，而非需求说明 41
4.4.4 在“精简的用例”上签收 42
4.4.5 引入用例实现 42
4.5 警告信号 43
4.5.1 注意频繁改动的测试 43
4.5.2 当心回退 44
4.5.3 注意组织级的失调 44
4.5.4 当心“以防万一”的代码 44
4.5.5 注意霰弹式修改 45
4.6 铭记 45
第二部分 关键过程模式
第5章 从目标中获取范围 48
5.1 构建正确的范围 49
5.1.1 理解“为什么”和“谁” 50
5.1.2 理解价值从何而来 51
5.1.3 了解商业用户预期的输出是什么 52
5.1.4 让开发人员提供用户故事的“我想要”部分 53
5.2 在没有高层次控制权的情况下，协作确定范围 53
5.2.1 询问“为什么这些东西有用？” 54
5.2.2 询问替代方案 54
5.2.3 不要只顾最低层次的需求 55
5.2.4 确保团队交付完整的功能 55
5.3 更多信息 56
5.4 铭记 56
第6章 通过协作制定需求说明 58
6.1 为什么需要协作制定需求说明 58
6.2 最热门的协作模型 59
6.2.1 尝试大型的全体工作坊 59
6.2.2 尝试小型工作坊(“神勇三剑客”) 61
6.2.3 结对编写 62
6.2.4 让开发人员在迭代开始前频繁地审查测试 63
6.2.5 尝试非正式交谈 64
6.3 准备协作 65
6.3.1 举办介绍会 65
6.3.2 邀请项目干系人 66
6.3.3 进行具体的准备工作并事先审查 67
6.3.4 让团队成员尽早审查故事 68
6.3.5 只准备初始的实例 69
6.3.6 不要让过度的准备阻碍了讨论 69
6.4 选择协作模型 70
6.5 铭记 71
第7章 举例说明 72
7.1 举例说明：一个例子 74
7.2 例子必须精确到位 75
7.2.1 不要在例子中出现“是/否”的回答 75
7.2.2 避免使用等价抽象类 75
7.3 例子必须完整 76
7.3.1 用数据作试验 76
7.3.2 使用替代方法来检验功能 76
7.4 例子必须要真实 77
7.4.1 避免虚构自己的数据 77
7.4.2 直接从客户那里获得基本的例子 78
7.5 例子应该易于理解 79
7.5.1 避免探讨所有可能的组合 80
7.5.2 寻找隐含的概念 80
7.6 描述非功能性需求 81
7.6.1 取得精确的性能需求 82
7.6.2 为UI使用低保真度的原型 82
7.6.3 试用QUPER模型 83
7.6.4 讨论时使用核查清单 84
7.6.5 建立一个参照的例子 84
7.7 铭记 85
第8章 提炼需求说明 86
8.1 一个好的需求说明的例子 87
8.1.1 免费送货服务 87
8.1.2 实例 87
8.2 一个劣质需求说明的例子 88
8.3 提炼需求说明时要关心什么 90
8.3.1 实例要精确可测 90
8.3.2 脚本不是需求说明 90
8.3.3 不要使用流程式的描述 91
8.3.4 需求说明应关注业务功能，而不是软件设计 92
8.3.5 避免编写与代码紧密耦合的需求说明 92
8.3.6 不要在需求说明中引入技术难点的临时解决方案 93
8.3.7 不要陷入到用户界面的细节里 93
8.3.8 需求说明应该是不言自明的 94
8.3.9 使用叙述性标题并使用短篇幅阐释目标 94
8.3.10 展示给别人看并保持沉默 94
8.3.11 不要过度定义实例 95
8.3.12 从简单的例子入手，然后逐步展开 96
8.3.13 需求说明要专注 97
8.3.14 在需求说明中使用“Given-When-Then”语言 97
8.3.15 不要在需求说明中明确建立所有依赖 98
8.3.16 在自动化层中应用缺省值 99
8.3.17 不要总是依赖缺省值 99
8.3.18 需求说明应使用领域语言 100
8.4 提炼实战 100
8.5 铭记 102
第9章 自动化验证而不修改需求说明 103
9.1 非得自动化吗 104
9.2 从自动化开始 105
9.2.1 为了学习工具，先尝试一个简单的项目 105
9.2.2 事先计划自动化 106
9.2.3 不要拖延自动化工作或将其委派他人 107
9.2.4 避免根据原有的手动测试脚本进行自动化 107
9.2.5 通过用户界面测试赢得信任 108
9.3 管理自动化层 109
9.3.1 别把自动化代码当作二等公民 109
9.3.2 在自动化层里描述验证过程 110
9.3.3 不要在测试自动化层里复制业务逻辑 111
9.3.4 沿着系统边界自动化 112
9.3.5 不要通过用户界面检查业务逻辑 113
9.3.6 在应用程序的表皮之下进行自动化 113
9.4 对用户界面进行自动化 115
9.4.1 以更高层次的抽象来详细说明用户界面的功能 115
9.4.2 UI需求说明只检查UI功能 117
9.4.3 避免录制的UI测试 117
9.4.4 在数据库中建立环境 118
9.5 管理测试数据 119
9.5.1 避免使用预填充数据 119
9.5.2 尝试使用预填充的引用数据 120
9.5.3 从数据库获取原型 120
9.6 铭记 121
第10章 频繁验证 122
10.1 提高稳定性 123
10.1.1 找出最烦人的问题并将其解决掉，然后不停地重复 123
10.1.2 用CI测试历史找到不稳定的测试 124
10.1.3 搭建专用的持续验证环境 125
10.1.4 使用全自动部署 125
10.1.5 为外部系统创建较简单的测试替代品 125
10.1.6 选择性地隔离外部系统 126
10.1.7 尝试多级验证 127
10.1.8 在事务中执行测试 127
10.1.9 对引用数据做快速检查 128
10.1.10 等待事件，而非等待固定时长 128
10.1.11 将异步处理变成可选 129
10.1.12 不要用可执行需求说明做端到端的验证 129
10.2 获得更快的反馈 130
10.2.1 引入业务时间 130
10.2.2 将较长的测试分割成较小的模块 131
10.2.3 避免使用内存数据库做测试 131
10.2.4 把快速的和缓慢的测试分开 132
10.2.5 保持夜间测试的稳定 132
10.2.6 为当前迭代创建一个测试包 133
10.2.7 并行运行测试 133
10.2.8 禁用风险较低的测试 134
10.3 管理失败的测试 135
10.3.1 创建已知失败了的回归测试包 135
10.3.2 自动检查那些被禁用的测试 136
10.4 铭记 137
第11章 演化出文档系统 138
11.1 活文档必须易于理解 138
11.1.1 不要创建冗长拖沓的需求说明 138
11.1.2 不要使用许多小的需求说明来描述单个功能 139
11.1.3 寻找更高层次的概念 139
11.1.4 避免在测试中使用技术上的自动化概念 139
11.2 活文档必须前后一致 140
11.2.1 演化出一种语言 141
11.2.2 将需求说明语言拟人化 142
11.2.3 协作定义语言 143
11.2.4 将构建模块文档化 143
11.3 活文档必须组织得井井有条，便于访问 144
11.3.1 按用户故事组织当前的工作 144
11.3.2 按功能区域组织用户故事 145
11.3.3 按用户界面的导航路径组织 146
11.3.4 按业务流程来组织 146
11.3.5 引用可执行需求说明时请使用标签而不要使用URL 147
11.4 聆听活文档 147
11.5 铭记 148
第三部分 案例研究
第12章 uSwitch 152
12.1 开始改变流程 152
12.2 优化流程 154
12.3 当前的流程 156
12.4 结果 157
12.5 重要的经验教训 157
第13章 RainStor 159
13.1 改变流程 159
13.2 当前流程 161
13.3 重要的经验教训 162
第14章 爱荷华州助学贷款公司 163
14.1 改变流程 163
14.2 优化流程 164
14.3 活文档作为竞争优势 166
14.4 重要的经验教训 167
第15章 Sabre Airline Solutions 168
15.1 改变流程 168
15.2 改善协作 169
15.3 结果 171
15.4 重要的经验教训 171
第16章 ePlan Services 172
16.1 改变流程 172
16.2 活文档 174
16.3 当前的流程 175
16.4 重要的经验教训 176
第17章 Songkick 177
17.1 改变流程 177
17.2 当前的流程 179
17.3 重要的经验教训 180
第18章 思想总结 182
18.1 协作制定需求能在项目干系人与交付团队之间建立信任 182
18.2 协作需要事先准备 183
18.3 协作的方式多种多样 183
18.4 将最终目的视为业务流程文档，不失为一种有用的模型 184
18.5 活文档带来的长期价值 184
附录A 资源 186
版权页： 插图： 例子既能避免歧义又是进行准确沟通的好方法。在日常的交谈和写作中，我们会不假思索地使用例子。当我在Google里搜索“例如”这个词组时，返回的搜索结果超过了2.1亿页。 使用传统的需求说明时，例子会在软件开发过程中时隐时现。业务分析师通常会从商业用户那里获取到订单、发货单以及报表的样本，然后他们会将其转换成抽象的需求。开发人员会想出一些例子来解释边界情况并向商业用户或分析师作出澄清，而后他们会将其转化成代码，但他们并不会记录下这些例子。测试人员会设计出测试用例，它们实际上就是系统应当如何工作的实例；这些例子仅供他们自己使用，而不会拿来与开发人员或分析师进行沟通。 每个人都会创造自己的例子，且不说这些例子是否完整，连例子的一致性都无法确保。这就是为什么在软件开发中最终结果往往会背离最初设想的原因。为了避免这种情况，我们必须防止不同角色之间出现的误解，只维护一处事实来源。 例子是避免沟通问题的好工具。如果我们自始至终都能够捕获所有的例子，并在分析、开发和测试中一致地使用它们，那么我们就可以避免进入传话游戏中（而导致信息失真）。 Beazley公司引入实例化需求说明的时候，Marta Gonzalez Ferrero是当时的测试负责人。据她所述，开发团队承诺的工作量超出了他们的能力，同时他们发现，在实现开始的时候所获得的信息往往远远不够。他们的迭代周期是6周，而且开发团队和业务分析师身处于不同的大洲，这让事情进一步复杂化。开发人员从业务分析师那里得到的验收条件也比较抽象（例如，“对于这个业务单元，要确保所有正确的产品都能够显示出来”）。在迭代半途中发现缺少某些重要的东西，会严重扰乱产出。某轮迭代结束时，客户说团队交付的东西完全不是他们所期望的。每个迭代的最后一周保留给Model Office：实际上是一个迭代的演示会议。有一次，Ferrero到美国做ModelOffice，并且与业务分析师一起工作了两天，对需求进行举例说明。结果，团队在下一个迭代承诺交付的工作减少了20％，最终他们成功交付了自己承诺的部分。 “团队的情绪也好了很多，”Ferrero说道，“在此之前，（开发人员）在实现的时候会感觉自己是在瞎做，必须等待业务分析师的反馈。”据Ferrero所述，在他们开始对需求做举例说明后，返工量急剧下降。
“独一无二的、基于大量的业内研究提取出来的知识。”——Mike Stockdale Syterra软件公司“本书是我的挚爱，它教会我如何正确地做测试。”——Craig Smith Suncorp公司“本书将改变我们讨论和思考测试的方式。”——David Evans ThinkAlike咨询公司“本书是有关需求收集与维护的最好的图书。”——Oleksandr Alesinskyy NAVTEQ“基于众多团队的经验，它将让你的测试自动化事半功倍。”Rick Mugridge Rimu研究公司
以“specification by example”为主题讲解了50多个案例以对世界级成功团队数十次采访为基础与大家分享世界级团队的工作诀窍敏捷开发的新经典文献亚马逊网站全五星评价成功开发软件的必备秘籍
无
本书用比较浅显的实例表达了需求的重要性，变化性，可控性，提出很多可以使用的方法，比较实用。
这本书从独特的视角，讲述了需求分析的要点和难点。书中概括的实践方法可以立即运用到实践。但是这本书定价似乎偏贵了，书比较薄，定价即便是折扣之后，还是“洛阳纸贵“，Jolt获奖书籍，果然牛阿!
对需求有了相应更新的思路
内容主要是案例分享为主，书没看完，想看到一些比较具体的实施细则，不知道有没有，先读书。
五星不解释
看了一下，希望将书中的方法用到实际工作中，提高工作效率
正在阅读中，很受启发！
非常好非常好很有启发的书
书是正版，发货速度也很快，好评。
思考多于实践。
值得慢慢去读 很实用的经验
作者理念挺好的，读了之后作用明显
cx
内容肯定是不用说了，好
实例化需求适合有项目经验的开发人员阅读，有些地方翻译的不是很恰当。
项目中作为需求人员，可以看看这本书，很多参考的地方
概念性的内容，看了三分之一吧。发现翻来拂去的强调这个观点很重要，但这个观点的实践上，并未给出一个可操作性的框架和思路。感觉我最想知道的具体操作实践一个未提，先搁置着。
书是好书，不过有些看不懂，需要再提炼一下自己
如题，得到了集团总工程师的关注。
整体思路不错，但是太理想化。
没有很实际的内容，通篇讲大道理不建议购买
或许原著是一本五星级的大作,但是本书的翻译实在是烂得糟糕.文中充斥大量有语病的病句让人阅读起来一头雾水,痛苦不堪.所翻译的技术名词也非约定俗成的用于.以致一字一句都要读上个几遍才能初步揣测到语意,翻译质量之差犹如使用google机器翻译一般.而作为原著,大部分篇幅用来解释specification by example(实例化需求)的好处及其效果.对于真正如何开展specification by example而列出的例子实在是太少,少得只有聊聊两页.即使本书第三部分给出的是案例研究,可给出的例子全是类似厂商案例白皮书那种到皮不到肉的介绍.让人感到十分失望好书往往能让读者欲罢不能,可本书的却让人每读几页就有放弃的感觉总的来说,本书是我经期所购买的技术书籍中翻译及内容质量最差的一本.
本是一本好书，但是中文翻译真是太糟糕了。许多病句和不准确的名词造成阅读起来很困难，怀疑中文翻译是不是直接Google翻译贴过来的。。。不建议购买中文版。想阅读的朋友找英文原版看！
不知道是翻译的问题还是原著就和难懂，通篇不知所云，读了半天不知道是啥意思，最近半年来最失败的阅读体验
先说说书：书的内容很好，翻译质量也比较高。美中不足的是，书选择的纸张颜色太白了，看着费眼睛。再说说亚马逊：书的封皮有一定的磨损，属于保管不善。物流态度比较差，很没素质。另外，下订单时选择了POS机刷卡，交货时却要求现金。亚马逊的管理需要改进一下了。
还行，只是觉得有些实际的问题还是没有解决
开发人员需要看的，对需求有更正确的认识
其中的理念值得推荐，本人做软件研发，带团队，其中的诸多理念，方法值得学习，使用
先在新华书店看，网上买的。书很不错。
看完这本书之后我想看看测试驱动开发，呵呵。
团队开发质量低，返工严重，大量任务式的需求，需求的不明确 这些困扰的问题在本书中都有讲解 体会得深度可能需要结合自身的经历(我痛恨那些由于需求不明确而导致的返工)。 想解决一个团队测试和开发的脱节，本书也是一个不错的选择
对于有经验的人来说，作用有限。国外的环境似乎和中国的有很大区别，他们的老板和主管都不会拍脑门子。国内的会，所以……一开始就试图约束需求变更的源头，而不是应对更复杂变更需求的此类书籍，我都认为不太适合中国。... 阅读更多
实例化需求：团队如何交付正确的软件
加油，新书籍，还不错啦。
写的不错，正在学习中
看着挺轻松的