实例化需求 团队如何交付正确的软件PDF电子书下载

第一部分 开始 2

第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.2BNP 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

第二部分 关键过程模式 48

第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

第三部分 案例研究 152

第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