4.7 用户推荐指数
科技
类型
7.9
豆瓣评分
可以朗读
语音朗读
182千字
字数
2012-09-01
发行日期
展开全部
主编推荐语
一部成功开发软件的必备秘籍。
内容简介
本书是在世界各地调查了多个团队软件交付过程后的经验总结。讲解了成功的开发团队如何通过示例实现规范，来建立利益相关者和开发团队之间的沟通桥梁，并讲述了敏捷验收测试和行为驱动开发；并在案例分析部分展示了一些团队实施实例化需求说明的历程。
目录
- 版权信息
- 前言
- 实例化需求说明
- 实践出真知
- 本书读者对象
- 本书内容
- 更上一层楼
- 本书没有源代码，也不介绍任何工具
- 谈谈术语
- 为什么使用“实例化需求说明”这个名字
- 过程模式
- 第一部分 开始
- 第1章 主要优点
- 1.1 更有效地实施变更
- 1.2 更高的产品质量
- 1.3 减少返工
- 1.4 更好的协作
- 1.5 铭记
- 第2章 关键过程模式
- 2.1 从目标中获取范围
- 2.2 协作制定需求说明
- 2.3 举例说明
- 2.4 提炼需求说明
- 2.5 自动化验证时不修改需求说明
- 2.6 频繁验证
- 2.7 演化出一个文档系统
- 2.8 实际的例子
- 2.8.1 商业目标
- 2.8.2 范围
- 2.8.3 关键实例
- 2.8.4 带实例的需求说明
- 2.8.5 可执行的需求说明
- 2.8.6 活文档
- 2.9 铭记
- 第3章 活文档
- 3.1 为什么我们需要权威的文档
- 3.2 测试可以是好文档
- 3.3 根据可执行的需求说明创建文档
- 3.4 以文档为中心的模型所具有的好处
- 3.5 铭记
- 第4章 开始改变
- 4.1 如何开始改变过程
- 4.1.1 把实施实例化需求说明当作更广阔的过程变更的一部分
- 4.1.2 专注于提高质量
- 4.1.3 从功能测试自动化开始
- 4.1.4 引入一个可执行需求说明的工具
- 4.1.5 使用测试驱动开发作为踏脚石
- 4.2 如何开始改变团队文化
- 4.2.1 避免使用“敏捷”术语
- 4.2.2 确保你得到管理层的支持
- 4.2.3 把实例化需求说明当作是比执行验收测试更好的方式来推销
- 4.2.4 不要让测试自动化成为最终的目标
- 4.2.5 不要太关注工具
- 4.2.6 在迁移过程中，遗留脚本也要有人维护
- 4.2.7 跟踪哪些人在运行（以及没有运行）测试自动检查程序
- 4.3 团队如何在流程和迭代中集成协作
- 4.3.1 Ultimate软件公司的Global Talent Management团队
- 4.3.2 BNP Paribas银行的Sierra团队
- 4.3.3 天空网络服务部门
- 4.4 处理签收和可追溯性
- 4.4.1 在版本控制系统中保存可执行需求说明
- 4.4.2 通过导出的活文档来签收
- 4.4.3 签收的是范围，而非需求说明
- 4.4.4 在“精简的用例”上签收
- 4.4.5 引入用例实现
- 4.5 警告信号
- 4.5.1 注意频繁改动的测试
- 4.5.2 当心回退
- 4.5.3 注意组织级的失调
- 4.5.4 当心“以防万一”的代码
- 4.5.5 注意霰弹式修改
- 4.6 铭记
- 第二部分 关键过程模式
- 第5章 从目标中获取范围
- 5.1 构建正确的范围
- 5.1.1 理解“为什么”和“谁”
- 5.1.2 理解价值从何而来
- 5.1.3 了解商业用户预期的输出是什么
- 5.1.4 让开发人员提供用户故事的“我想要”部分
- 5.2 在没有高层次控制权的情况下，协作确定范围
- 5.2.1 询问“为什么这些东西有用？”
- 5.2.2 询问替代方案
- 5.2.3 不要只顾最低层次的需求
- 5.2.4 确保团队交付完整的功能
- 5.3 更多信息
- 5.4 铭记
- 第6章 通过协作制定需求说明
- 6.1 为什么需要协作制定需求说明
- 6.2 最热门的协作模型
- 6.2.1 尝试大型的全体工作坊
- 6.2.2 尝试小型工作坊（“神勇三剑客”）
- 6.2.3 结对编写
- 6.2.4 让开发人员在迭代开始前频繁地审查测试
- 6.2.5 尝试非正式交谈
- 6.3 准备协作
- 6.3.1 举办介绍会
- 6.3.2 邀请项目干系人
- 6.3.3 进行具体的准备工作并事先审查
- 6.3.4 让团队成员尽早审查故事
- 6.3.5 只准备初始的实例
- 6.3.6 不要让过度的准备阻碍了讨论
- 6.4 选择协作模型
- 6.5 铭记
- 第7章 举例说明
- 7.1 举例说明：一个例子
- 7.2 例子必须精确到位
- 7.2.1 不要在例子中出现“是／否”的回答
- 7.2.2 避免使用等价抽象类
- 7.3 例子必须完整
- 7.3.1 用数据作试验
- 7.3.2 使用替代方法来检验功能
- 7.4 例子必须要真实
- 7.4.1 避免虚构自己的数据
- 7.4.2 直接从客户那里获得基本的例子
- 7.5 例子应该易于理解
- 7.5.1 避免探讨所有可能的组合
- 7.5.2 寻找隐含的概念
- 7.6 描述非功能性需求
- 7.6.1 取得精确的性能需求
- 7.6.2 为UI使用低保真度的原型
- 7.6.3 试用QUPER模型
- 7.6.4 讨论时使用核查清单
- 7.6.5 建立一个参照的例子
- 7.7 铭记
- 第8章 提炼需求说明
- 8.1 一个好的需求说明的例子
- 8.1.1 免费送货服务
- 8.1.2 实例
- 8.2 一个劣质需求说明的例子
- 8.3 提炼需求说明时要关心什么
- 8.3.1 实例要精确可测
- 8.3.2 脚本不是需求说明
- 8.3.3 不要使用流程式的描述
- 8.3.4 需求说明应关注业务功能，而不是软件设计
- 8.3.5 避免编写与代码紧密耦合的需求说明
- 8.3.6 不要在需求说明中引入技术难点的临时解决方案
- 8.3.7 不要陷入到用户界面的细节里
- 8.3.8 需求说明应该是不言自明的
- 8.3.9 使用叙述性标题并使用短篇幅阐释目标
- 8.3.10 展示给别人看并保持沉默
- 8.3.11 不要过度定义实例
- 8.3.12 从简单的例子入手，然后逐步展开
- 8.3.13 需求说明要专注
- 8.3.14 在需求说明中使用“Given-When-Then”语言
- 8.3.15 不要在需求说明中明确建立所有依赖
- 8.3.16 在自动化层中应用缺省值
- 8.3.17 不要总是依赖缺省值
- 8.3.18 需求说明应使用领域语言
- 8.4 提炼实战
- 8.5 铭记
- 第9章 自动化验证而不修改需求说明
- 9.1 非得自动化吗
- 9.2 从自动化开始
- 9.2.1 为了学习工具，先尝试一个简单的项目
- 9.2.2 事先计划自动化
- 9.2.3 不要拖延自动化工作或将其委派他人
- 9.2.4 避免根据原有的手动测试脚本进行自动化
- 9.2.5 通过用户界面测试赢得信任
- 9.3 管理自动化层
- 9.3.1 别把自动化代码当作二等公民
- 9.3.2 在自动化层里描述验证过程
- 9.3.3 不要在测试自动化层里复制业务逻辑
- 9.3.4 沿着系统边界自动化
- 9.3.5 不要通过用户界面检查业务逻辑
- 9.3.6 在应用程序的表皮之下进行自动化
- 9.4 对用户界面进行自动化
- 9.4.1 以更高层次的抽象来详细说明用户界面的功能
- 9.4.2 UI需求说明只检查UI功能
- 9.4.3 避免录制的UI测试
- 9.4.4 在数据库中建立环境
- 9.5 管理测试数据
- 9.5.1 避免使用预填充数据
- 9.5.2 尝试使用预填充的引用数据
- 9.5.3 从数据库获取原型
- 9.6 铭记
- 第10章 频繁验证
- 10.1 提高稳定性
- 10.1.1 找出最烦人的问题并将其解决掉，然后不停地重复
- 10.1.2 用CI测试历史找到不稳定的测试
- 10.1.3 搭建专用的持续验证环境
- 10.1.4 使用全自动部署
- 10.1.5 为外部系统创建较简单的测试替代品
- 10.1.6 选择性地隔离外部系统
- 10.1.7 尝试多级验证
- 10.1.8 在事务中执行测试
- 10.1.9 对引用数据做快速检查
- 10.1.10 等待事件，而非等待固定时长
- 10.1.11 将异步处理变成可选
- 10.1.12 不要用可执行需求说明做端到端的验证
- 10.2 获得更快的反馈
- 10.2.1 引入业务时间
- 10.2.2 将较长的测试分割成较小的模块
- 10.2.3 避免使用内存数据库做测试
- 10.2.4 把快速的和缓慢的测试分开
- 10.2.5 保持夜间测试的稳定
- 10.2.6 为当前迭代创建一个测试包
- 10.2.7 并行运行测试
- 10.2.8 禁用风险较低的测试
- 10.3 管理失败的测试
- 10.3.1 创建已知失败了的回归测试包
- 10.3.2 自动检查那些被禁用的测试
- 10.4 铭记
- 第11章 演化出文档系统
- 11.1 活文档必须易于理解
- 11.1.1 不要创建冗长拖沓的需求说明
- 11.1.2 不要使用许多小的需求说明来描述单个功能
- 11.1.3 寻找更高层次的概念
- 11.1.4 避免在测试中使用技术上的自动化概念
- 11.2 活文档必须前后一致
- 11.2.1 演化出一种语言
- 11.2.2 将需求说明语言拟人化
- 11.2.3 协作定义语言
- 11.2.4 将构建模块文档化
- 11.3 活文档必须组织得井井有条，便于访问
- 11.3.1 按用户故事组织当前的工作
- 11.3.2 按功能区域组织用户故事
- 11.3.3 按用户界面的导航路径组织
- 11.3.4 按业务流程来组织
- 11.3.5 引用可执行需求说明时请使用标签而不要使用URL
- 11.4 聆听活文档
- 11.5 铭记
- 第三部分 案例研究
- 第12章 uSwitch
- 12.1 开始改变流程
- 12.2 优化流程
- 12.3 当前的流程
- 12.4 结果
- 12.5 重要的经验教训
- 第13章 RainStor
- 13.1 改变流程
- 13.2 当前流程
- 13.3 重要的经验教训
- 第14章 爱荷华州助学贷款公司
- 14.1 改变流程
- 14.2 优化流程
- 14.3 活文档作为竞争优势
- 14.4 重要的经验教训
- 第15章 Sabre Airline Solutions
- 15.1 改变流程
- 15.2 改善协作
- 15.3 结果
- 15.4 重要的经验教训
- 第16章 ePlan Services
- 16.1 改变流程
- 16.2 活文档
- 16.3 当前的流程
- 16.4 重要的经验教训
- 第17章 Songkick
- 17.1 改变流程
- 17.2 当前的流程
- 17.3 重要的经验教训
- 第18章 思想总结
- 18.1 协作制定需求能在项目干系人与交付团队之间建立信任
- 18.2 协作需要事先准备
- 18.3 协作的方式多种多样
- 18.4 将最终目的视为业务流程文档，不失为一种有用的模型
- 18.5 活文档带来的长期价值
- 附录A 资源
- 图书
- 在线资源
- 工具
- 视频
- 演讲
- 文章
- 漫画
- 培训课程
展开全部
评分及书评
4.7
3个评分
- 给这本书评了4.0已经在尝试cucumber
TDD，愿人们都尊你的名为圣，愿你的国降临，愿你的旨意行在产品测试，如同行在开发。我们日用的测试，今天赐给我们，免了我们的技术债，如同我们免了人的债不叫我们遇到恐惧，救我们脱离凶恶。因为国度、权柄、荣耀，全是你的，直到永远，阿们。
给这本书评了5.0搭建了人和人 人和机器的沟通桥梁非常好的一本书
出版方
人民邮电出版社·图灵出品
图灵社区成立于2005年6月，由人民邮电出版社投资控股，以策划出版高质量的科技书籍为核心业务，主要出版领域包括计算机、电子电气、数学统计、科普等，通过引进国际高水平的教材、专著，以及发掘国内优秀原创作品等途径，为目标读者提供一流的内容。
