具体描述
本书是敏捷软件开发领域的经典著作，由IBM首席敏捷方法专家、世界级敏捷软件开发大师撰写，系统深入地讲解了规范敏捷交付（DAD）的概念和原理，以及规范敏捷交付过程框架的使用方法和技巧，为交付大型的企业级敏捷软件提供了行之有效的方法与最佳实践。
本书共21章，分为六部分：第一部分（第1～3章）介绍了DAD的概念、原理和根基，以及敏捷与精益开发方法的核心价值与原则；第二部分（第4～5章）讲解了DAD方法中的角色、权利和责任，以及如何组建DAD团队；第三部分（第6～12章）讲解了启动DAD项目的步骤和方法；第四部分（第13～17章）讲解了以增量的方式构造可利用的解决方案的步骤和方法；第五部分（第18～19章）讲述了如何发布解决方案，第六部分（第20～21章）介绍了企业环境中的DAD，讨论了如何治理DAD团队，以及敏捷开发实践中需要遵守的纪律。
作者简介
斯科特·安布勒（Scott W. Ambler）
IBMRational首席敏捷软件开发专家和精益软件开发专家，规范敏捷交付（DAD）概念的提出者和相应过程框架的开发领导者，敏捷建模、敏捷数据、敏捷统一过程和企业统一过程等方法的创始人，敏捷伸缩模型的创建者。著作等身，与他人合著图书20余本，包括《RefactoringDatabases》、《Agile Modeling》、《Agile Database Techniques》、《The ObjectPrimer, 3rd Edition》，以及《The Enterprise UnifiedProcess》等经典著作。此外，他还是《Dr. Dobb’s Journal》杂志的特约资深编辑。他的个人网站是www.ambysoft.com。
马克·莱恩斯（Mark Lines）
资深敏捷软件开发专家，规范敏捷方法教练，善于为软件开发组织提供全方位的指导。他在利用敏捷和精益生产技术加速开发进程和提高产品质量方面拥有丰富的实践经验。出版了多本著作，并经常作为演讲人出现在各种业界会议上。他还是IBMRational和UPMentors（2007年与他人合伙创立）的课程讲师。他的个人网站是www.UPMentors.com，联系方式为：Mark@UPMentors.com。
译者简介
阎小兵（Kevin Yan）
IBM中国开发中心资深开发经理，IBM全球质量软件工程专员。关注和推动企业软件产品开发转型、敏捷开发方法与实践、质量管理与度量，并在相关领域拥有丰富的实践经验。
目录信息
中文版序
序
前言
第一部分 DAD概述
第1章 DAD
1.1 背景——敏捷伸缩模型
1.2 DAD过程框架
1.3 以人为核心
1.4 注重学习
1.5 敏捷方法
1.6 混合型过程框架
1.7 是IT解决方案，而不只是软件
1.8 目标驱动的交付生命周期
1.9 企业意识
1.10 风险与价值驱动
1.11 可扩展
1.12 观点总结
1.13 延伸阅读
第2章 敏捷与精益开发简介
2.1 向规范《敏捷宣言》进发
2.2 规范敏捷思想的核心价值观
2.3 规范敏捷开发原则
2.4 精益开发原则
2.5 事实重于巧辩
2.6 观点总结
2.7 延伸阅读
第3章 DAD的根基
3.1 专业术语库
3.2 Scrum
3.3 极限编程
3.4 敏捷建模
3.5 敏捷数据
3.6 精益软件开发
3.7 IBM实践
3.8 开放统一过程
3.9 其他
3.10 谁忽视敏捷实践，谁就会置业务于风险境地
3.11 观点总结
3.12 延伸阅读
第二部分 以人为核心
第4章 角色、权利和责任
4.1 每个人拥有的权利
4.2 每个人承担的责任
4.3 DAD角色
4.4 观点总结
4.5 延伸阅读
第5章 组建DAD团队
5.1 组建高效团队的策略
5.2 完整团队
5.3 团队组织策略
5.4 建立自己的团队
5.5 与其他团队互动
5.6 观点总结
5.7 延伸阅读
第三部分 启动DAD项目
第6章 先启阶段
6.1 先启阶段如何运行
6.2 与企业其他部门的合作
6.3 落实资金
6.4 先启阶段中的其他活动
6.5 在什么情况下需要先启阶段
6.6 先启阶段的模式
6.7 先启阶段的反模式
6.8 观点总结
6.9 延伸阅读
第7章 确定项目愿景
7.1 什么是愿景
7.2 如何创立愿景
7.3 捕捉项目愿景
7.4 让利益相关者同意愿景
7.5 观点总结
7.6 延伸阅读
第8章 确定范围
8.1 选择恰当的需求细化度
8.2 选择正确的模型类型
8.3 选择建模策略
8.4 选择管理工作项的策略
8.5 选择捕获非功能性需求的策略
8.6 观点总结
8.7 延伸阅读
第9章 确定技术策略
9.1 选择架构规格的详细程度
9.2 选择正确的架构模型类型
9.3 选择架构建模策略
9.4 贯穿于生命周期的架构演进
9.5 观点总结
9.6 延伸阅读
第10章 制定发布计划
10.1 谁来制定计划
10.2 选择计划级别
10.3 选择计划策略
10.4 选择节奏
10.5 制定项目进度表
10.6 估算成本和价值
10.7 识别风险
10.8 观点总结
10.9 延伸阅读
第11章 建立工作环境
11.1 组建团队
11.2 选择工具集
11.3 建立实体工作环境
11.4 建立虚拟工作环境
11.5 可视化管理
11.6 使用开发指南
11.7 观点总结
11.8 延伸阅读
第12章 案例研究：先启阶段
12.1 AgileGrocers POS案例简介
12.2 开发共享愿景
12.3 需求预想
12.4 创建用户故事，排序工作项
12.5 架构预想
12.6 发布计划
12.7 先启阶段中的其他活动
12.8 运行先启阶段的其他方法
12.9 结束先启阶段
12.10 观点总结
第四部分 增量式构造可利用的解决方案
第13章 构造阶段
13.1 构造阶段如何运行
13.2 构造迭代的典型节奏
13.3 风险—价值生命周期
13.4 何时可以部署
13.5 构造阶段的模式
13.6 构造阶段的反模式
13.7 观点总结
第14章 启动构造迭代
14.1 敏捷计划的特点
14.2 迭代计划
14.3 计划的可视化
14.4 前瞻性计划和建模
14.5 观点总结
14.6 延伸阅读
第15章 构造阶段中典型的一天
15.1 规划团队一天的工作
15.2 协作构建可利用的解决方案
15.3 全天活动
15.4 深入了解关键敏捷实践
15.5 稳定当日工作
15.6 观点总结
15.7 延伸阅读
第16章 结束构造迭代
16.1 向关键利益相关者演示解决方案
16.2 从自己的经历中获得经验
16.3 评估进展和调整发布计划
16.4 评估余留风险
16.5 部署当前构建
16.6 决定前进策略
16.7 观点总结
16.8 延伸阅读
第17章 案例研究：构造阶段
17.1 继续AgileGrocers POS案例
17.2 规划迭代中的工作
17.3 后续的构造迭代
17.4 构造阶段中的其他活动
17.5 结束构造阶段的迭代
17.6 观点总结
第五部分 发布解决方案
第18章 移交阶段
18.1 移交阶段如何运行
18.2 规划移交阶段
18.3 确保生产环境就绪
18.4 让利益相关者为发布做好准备
18.5 部署解决方案
18.6 利益相关者会欣然接受吗
18.7 移交阶段的模式
18.8 移交阶段的反模式
18.9 观点总结
18.10 延伸阅读
第19章 案例研究：移交阶段
19.1 制定计划
19.2 协作部署解决方案
19.3 AgileGrocers公司欣然接受
19.4 观点总结
第六部分 企业环境中的DAD
第20章 治理DAD团队
20.1 治理要解决什么问题
20.2 为什么说治理很重要
20.3 为什么传统的治理策略行不通
20.4 敏捷治理
20.5 支持治理的敏捷实践
20.6 配合IT组织中的其他部门
20.7 度量敏捷团队
20.8 风险缓解
20.9 观点总结
20.10 延伸阅读
第21章 纪律
21.1 采用敏捷开发实践需要纪律
21.2 减少反馈周期需要纪律
21.3 持续学习需要纪律
21.4 增量式交付解决方案需要纪律
21.5 采用目标驱动的方法需要纪律
21.6 企业意识需要纪律
21.7 采用完整生命周期方法需要纪律
21.8 简化启动阶段需要纪律
21.9 简化移交阶段需要纪律
21.10 应用敏捷治理策略需要纪律
21.11 向精益转型需要纪律
21.12 观点总结
21.13 延伸阅读
· · · · · · (收起)
读后感
用户评价
这本书最让我感到惊喜的是它对“产品价值”的强调，而不是一味地强调“速度至上”。在当前这个“快就是一切”的氛围下，这本书像一剂清醒剂，时刻提醒我们，敏捷的终极目标是交付客户真正需要的东西，而不是交付一堆没人用的功能。作者在讨论“最小可行产品（MVP）”的界定时，引用了一个关于市场调研的经典悖论，指出很多团队将“功能集合”误认为“最小可行产品”。书中提出一个核心观点：真正的MVP，是能用最低成本验证你核心假设的那个最小闭环。为了说明这一点，作者深入剖析了一个失败的“电子商务重构项目”，详述了团队如何因为过早地投入到复杂的技术选型，而错失了市场先机。书中提出的“价值流图”分析工具，将开发过程中的每一个环节都映射到了最终产生的商业价值上，使得团队能够清晰地识别出哪些活动是真正的“价值创造”，哪些只是“流程噪音”。这种以价值为驱动力的叙事视角，彻底颠覆了我过去那种“完成任务即胜利”的固有观念。这本书提供的不仅仅是工具，更是一种自上而下的价值观重塑，它引导我们重新审视工作的意义。
评分我对技术文档的阅读习惯一向是“带着批判的眼光审视每一个论断”，但《敏捷软件开发实践》这本书里，有几个章节的内容让我完全放下了戒备，甚至产生了强烈的共鸣。特别是在探讨“持续集成与部署（CI/CD）”的自动化层面时，作者对“自动化债务”的描述精妙绝伦。他将自动化测试比喻成一座正在拔地而起的摩天大楼的基石，如果基石打得不牢固，上层应用做得再华丽也只是空中楼阁。书中举例说明，一个为了赶进度而跳过高覆盖率测试的团队，最终如何在生产环境的一次小更新中，因为一个未被覆盖的边缘场景而导致全面宕机，整个过程的描述充满了宿命般的悲剧感。这种通过具体失败案例来警示读者的手法，远比枯燥的指标要求有效得多。更难能可贵的是，作者并没有止步于批评，而是提供了一套详细的“自动化成熟度评估矩阵”，这个工具非常实用，我们可以直接拿来对团队当前的自动化水平进行量化评分，并依此制定改进路线图。这种可操作性和即时反馈机制，是很多同类书籍所欠缺的“重量级”支撑。
评分这本书的叙事风格非常平实，没有那些高高在上的术语轰炸，读起来感觉就像是资深的前辈在深夜的茶馆里，给我娓娓道来他多年摸爬滚打的经验教训。我尤其喜欢作者在谈论“风险管理”时的那种坦诚。他没有回避在敏捷实践中遇到的那些“灰色地带”——比如，当客户的需求突然发生重大偏移时，团队该如何保持士气和方向？作者引用了一个他在某金融科技项目中遭遇的“紧急重构”事件，详细描述了团队如何通过三次短促的站会，迅速将危机转化为一次架构优化的契机。这种“去神化”的处理方式，极大地增强了我对书中方法的信任感。很多技术书籍读完后，我总觉得知识是片段化的，但这本书的厉害之处在于，它成功地将“技术实践”与“人员管理”编织成了一张密不透风的网。譬如，关于“每日站会”的描写，作者花了很大篇幅讨论的不是“要汇报什么”，而是“如何让每个人都愿意敞开心扉说出真正的障碍”。读完这部分，我立刻回想起我们团队中那些沉默的成员，开始思考如何调整沟通的温度和频率。这本书的价值，正在于它能触发你对自身工作流程的深刻反思，而不是简单地提供一套现成的模板。
评分这本书的封面设计简直是一场视觉盛宴，那种深邃的蓝色调配上烫金的字体，立刻就能抓住我的眼球。我是一个对书籍包装有着近乎偏执要求的人，而这本《敏捷软件开发实战指南》无疑是赢得了我的第一印象分。翻开扉页，内容排版也相当讲究，字体大小适中，行距舒服，阅读起来丝毫没有压迫感。我特别欣赏作者在章节结构上的匠心独运，那种层层递进的逻辑关系，让人仿佛置身于一个精心规划的旅程之中。比如，第一部分对于“迭代规划”的阐述，并非空泛的理论堆砌，而是结合了多个真实项目案例，用生动的语言描绘了从需求梳理到蓝图绘制的全过程。书中大量穿插的图表和流程图，清晰地梳理了复杂的开发流程，特别是那张关于“反馈闭环机制”的示意图，我反复看了好几遍，才真正领悟到其中蕴含的精髓。这不仅是一本技术书籍，更像是一本关于如何高效协作、如何与团队建立信任的“软技能”教材。它没有一味地推崇某种“银弹”方法论，而是鼓励读者根据自身团队的特点进行灵活调整，这种务实态度，在充斥着理想化模型的行业书籍中，显得尤为珍贵。总而言之，从装帧设计到内页布局，这本书都展现出专业、细致和对读者体验的尊重。
评分我通常在周末才会比较有系统地阅读这类专业书籍，但《敏捷软件开发实战指南》的章节结构设计得非常适合“碎片化吸收”。我发现自己可以只用半小时阅读其中一个关于“跨职能团队组建”的小节，然后立刻能在接下来的工作中找到对应的应用点。这本书没有宏大的理论框架去压制读者的注意力，而是专注于一个个可独立拆解的“原子化实践单元”。比如，书中用近乎诗意的语言描述了“结对编程”的精髓——那是一种知识的双向流动，而不是简单地把两个人绑在一起。作者甚至细致到讨论了不同性格的开发者（例如“细节控”与“大局观者”）如何通过轮换角色，实现优势互补，避免陷入单一视角的陷阱。这种对微观操作的精雕细琢，让我体会到敏捷不仅仅是流程的变动，更是思维模式的彻底转变。读完这部分后，我尝试让团队中的两位资深和新手开发者进行了一次为期两周的结对，发现新人的学习曲线陡然加快，而资深者也从基础的“代码规范”中重新找回了对纯粹编程的乐趣。这本书记载的，是无数次实战中提炼出来的“操作手册”，而非空谈。
评分太啰嗦了点，可以学习一点思想，真正执行还有距离
评分内容很全面，作为参考使用非常棒。实际运用的话，还需要读者多多思量。
评分太啰嗦了点，可以学习一点思想，真正执行还有距离
评分内容很全面，作为参考使用非常棒。实际运用的话，还需要读者多多思量。
评分给敏捷开发模式加上一点正规约束和规范
相关图书
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2026 qciss.net All Rights Reserved. 小哈图书下载中心 版权所有