具体描述
《敏捷迭代开发（管理者指南）》是敏捷和迭代开发方法的权威指南。著名软件方法大师CraigLarman在书中不但说明什么是敏捷／迭代方法，其运作机制、实施策略以及原因，而且通过具有统计意义的重要研究数据，以及大规模的项目案例分析，为读者呈现了最具有说服力的采用迭代开发的有力证据。《敏捷迭代开发：管理者指南》主要内容包括：大量实用的敏捷和迭代技巧，面向敏捷／迭代项目主管的新管理技能，敏捷与迭代的价值与实践，Scrum、XP、UP和Evo的关键实践，以及常见问题的问答。
无论是对IT主管、项目经理，还是对软件开发人员，这都是了解敏捷和迭代开发最理想的一本书。
作者简介
作者介绍
Craig Larman 享誉国际软件界的专家，是面向对象技术和开发以及迭代和敏捷开发方法的积极倡导者。他曾在Xerox公司担任首席精益软件开发教练、在Ericsson公司担任大规模Scrum和企业敏捷顾问、在Valtech公司担任首席科学家。除本书之外，Larman还著有Applying UML and Patterns和Practices for Scaling Lean & Agile Development和Scaling Lean & Agile Development等书。其中Applying UML and Patterns是面向对象分析和设计以及迭代开发方面的畅销书。
译者介绍
张晓坤 中国科学院计算所硕士，曾经是中央民族大学计算机系讲师，在多家IT公司担任过技术总监。2006年创业，先后创办了神州酷奇（北京）科技发展有限公司和北京魔笛创新科技发展有限公司。现为北京魔笛创新科技发展有限公司董事总经理、神州酷奇（北京）科技发展有限公司董事。曾翻译多部计算机技术方面的书籍，除本书外还包括《.NET 本质论 第1卷：公共语言运行库》、《C#编程语言详解》、《轻快的Java》《.NET模式：架构、设计与过程》等。
目录信息
1.1软件是新产品开发2
1.2后续内容预告4
1.3Web资源4
1.3.1主要的链接或文章网站4
1.3.2更多的特别网站5
第2章迭代和渐进7
2.1迭代开发7
2.2风险驱动和客户驱动的迭代计划9
2.3时间箱迭代开发10
2.4迭代期间，外部利益相关者不能变更迭代内容11
2.5渐进开发和自适应开发11
2.6渐进需求分析12
2.7早期排名前十的高级需求和技能分析13
2.8渐进和自适应计划13
2.9增量交付15
2.10渐进交付15
2.11最常见的错误16
2.12特定的迭代和渐进方法16
2.12.1Evo16
2.12.2UP16
2.12.3其他方法17
2.13后续内容预告17
2.14推荐读物17
第3章敏捷18
3.1敏捷开发18
3.2方法的分类19
3.3敏捷宣言和原则20
3.3.1敏捷宣言20
3.3.2敏捷原则20
3.4敏捷项目管理21
3.5拥抱沟通和反馈22
3.6以人为本的编程22
3.7简单的实践和项目工具23
3.8经验型过程与规定型过程23
3.9基于原则与基于规则24
3.10可持续规程—人员接触24
3.11团队是一个复杂的自适应系统24
3.12敏捷是在夸大其词吗25
3.13特定的敏捷方法25
3.13.1Scrum26
3.13.2XP26
3.13.3Crystal方法26
3.13.4敏捷建模27
3.13.5其他方法和实践28
3.14后续内容预告28
3.15推荐读物29
第4章故事30
第5章动机35
5.1如果问题不是太多，就不要修复它35
5.2软件项目中变化的事实36
5.3迭代开发的关键动机37
5.4迭代地迎接需求挑战39
5.5瀑布型的问题41
5.5.1问题：“完成”前期的需求规格说明就万事大吉43
5.5.2问题：迟到的集成和测试43
5.5.3问题：“可靠的”前期进度和估算43
5.5.4问题：“计划工作，按计划工作”的价值44
5.6后续内容预告44
第6章证据45
6.1概要46
6.2研究的证据47
6.2.1迭代与渐进研究47
6.2.2规模研究50
6.2.3有关变化的研究51
6.2.4瀑布型失败的研究53
6.2.5生产力的研究54
6.2.6质量和缺陷的研究55
6.3早期历史项目的证据56
6.3.11970年以前57
6.3.220世纪70年代58
6.3.320世纪80年代之后61
6.4标准团体的证据62
6.5专家和思想领袖的证据65
6.5.1HarlanMills66
6.5.2TomGilb66
6.5.3FrederickBrooks67
6.5.4BarryBoehm68
6.5.5JamesMartin68
6.5.6TomDeMarco69
6.5.7EdYourdon70
6.6迭代开发的商业案例70
6.7瀑布型有效是历史的偶然72
6.8后续内容预告75
6.9推荐读物75
第7章Scrum76
7.1方法概览77
7.1.1分类77
7.1.2介绍78
7.2生命周期79
7.3工件、角色和实践80
7.3.1角色81
7.3.2实践82
7.3.3核心实践82
7.3.4Scrum会议：细节84
7.3.5Scrum会议的价值85
7.3.6工件86
7.3.7其他实践和价值观88
7.4价值观88
7.5常见错误和误解89
7.5.1Scrum项目失败是怎么回事89
7.5.2什么时候你知道自己并不了解Scrum90
7.6样板项目90
7.7过程混合91
7.7.1Scrum+Evo91
7.7.2Scrum+UP91
7.7.3Scrum+XP92
7.8采用的策略92
7.9现实与幻想93
7.10优势与其他93
7.10.1优势93
7.10.2其他94
7.11历史94
7.12后续内容预告95
7.13推荐读物95
第8章极限编程96
8.1方法概览96
8.1.1分类96
8.1.2介绍98
8.2生命周期100
8.3工件、角色和实践101
8.3.1角色102
8.3.2实践103
8.3.3核心实践104
8.3.4工件106
8.3.5其他实践和价值观106
8.4价值观108
8.5常见错误和误解109
8.5.1极限编程项目失败是怎么回事109
8.5.2什么时候你知道自己并不了解XP112
8.6样板项目112
8.7过程混合113
8.7.1XP＋Evo113
8.7.2XP＋Scrum113
8.7.3XP＋UP114
8.8采用的策略114
8.9现实与幻想116
8.10优势与其他116
8.10.1优势116
8.10.2其他117
8.11历史118
8.12后续内容预告118
8.13推荐读物119
第9章统一过程120
9.1方法概览121
9.1.1UP121
9.1.2介绍122
9.2生命周期125
9.3工件、角色和实践128
9.3.1角色129
9.3.2实践130
9.3.3核心实践130
9.3.4UP指南131
9.3.56个最佳实践131
9.3.6工件132
9.3.7其他实践和价值观133
9.4价值观133
9.5常见错误和误解135
9.5.1统一过程失败是怎么回事135
9.5.2双重瀑布思想135
9.5.3其他的常见错误136
9.5.4什么时候你知道自己并不了解UP137
9.5.5UP“专家”不是迭代专家138
9.6样板项目138
9.7过程混合139
9.7.1UP+Evo139
9.7.2UP+Scrum140
9.7.3UP+XP140
9.8采用的策略141
9.9现实与幻想142
9.10优势与其他142
9.10.1优势142
9.10.2其他143
9.11历史143
9.12后续内容预告144
9.13推荐读物144
第10章Evo146
10.1方法概览146
10.1.1分类146
10.1.2介绍148
10.2生命周期150
10.3工件、角色和实践152
10.3.1角色153
10.3.2实践154
10.3.3核心实践154
10.3.4工件160
10.3.5其他实践和价值观163
10.4价值观164
10.5常见错误和误解164
10.6样板项目165
10.7过程混合165
10.7.1Evo+Scrum166
10.7.2Evo+UP166
10.7.3Evo+XP166
10.8采用的策略167
10.9现实与幻想167
10.10优势与其他167
10.10.1优势167
10.10.2其他168
10.11历史168
10.12后续内容预告169
10.13推荐读物169
第11章实践技巧170
11.1项目管理170
11.1.1多团队或多现场的早期开发171
11.1.2艰难的多团队或多现场迭代计划171
11.1.3跨多个迭代的重叠或者“流水线”活动172
11.1.4滚动波浪式自适应计划与预见性计划174
11.1.5计划：考虑在“星期三”结束177
11.1.6计划：整个团队的计划会议178
11.1.7计划：工作者评估178
11.1.8计划：用WidebandDelphi改善评估178
11.1.9计划：多次迭代计划会议179
11.1.10计划：敏捷的任务制定180
11.1.11计划：不要忘记为迭代工作的开销做预算180
11.1.12任务：每次迭代都要进行时间估算180
11.1.13计划：自愿180
11.1.14可视化的项目计划181
11.1.15迭代目标：风险、覆盖面、急迫性、技能性开发181
11.1.16迭代目标：将什么分级181
11.1.17迭代目标：如何分级？打点投票182
11.1.18迭代目标：如何分级？定量方法182
11.1.19迭代目标：相关的迭代长度183
11.1.20迭代目标：在第一次开发迭代之前184
11.1.21迭代目标：第一次开发迭代184
11.1.22迭代目标：用例和场景184
11.1.23迭代目标：主要需求和次要需求185
11.1.24迭代目标：不要向一个迭代中添加需求185
11.1.25跟踪迭代进度186
11.1.26跟踪迭代过程——跟踪什么186
11.1.27跟踪和计划：XPlanner187
11.1.28IID项目中的挣值跟踪187
11.1.29对风险评级187
11.1.30管理风险188
11.2环境188
11.2.1持续集成188
11.2.2项目的Wiki网190
11.2.3CASE工具和逆向工程190
11.2.4考虑使用绘图仪191
11.2.5单间和公共工作室191
11.2.6解放墙壁191
11.2.7贴纸或者白板漆192
11.2.8数码照相机192
11.3需求192
11.3.1敏捷建模193
11.3.2定义并遵循愿景规划193
11.3.3产品愿景箱193
11.3.4Moore风格的愿景声明194
11.3.5产品表单194
11.3.6渐进的需求研讨194
11.3.7跨迭代跟踪需求196
11.3.8直接用户介入需求和产品196
11.3.9可以使用用例196
11.3.10可以量化197
11.3.11将GUI粘在一起197
11.3.12头脑风暴198
11.3.13灵感记录198
11.3.14类聚198
11.3.15思维导图198
11.3.16团队轮流编写199
11.4测试199
11.4.1测试驱动开发199
11.4.2用于验收测试的Fit和Fitnesse201
第12章常见问题解答202
12.1问题清单202
12.2问题和解答204
参考文献222
· · · · · · (收起)
读后感
2008年春，项目做的对敏捷有了点兴趣，花了两个晚上浏览了《敏捷迭代开发——管理者指南》，理念式的书，看起来比较轻松，摘录一些自己的体会。 原文在 http://iamsujie.com/7000/7008/，欢迎大家来探讨相关话题 有些需求在开始的时候是提不出来的，或者说没法细化的，强行的...
评分2008年春，项目做的对敏捷有了点兴趣，花了两个晚上浏览了《敏捷迭代开发——管理者指南》，理念式的书，看起来比较轻松，摘录一些自己的体会。 原文在 http://iamsujie.com/7000/7008/，欢迎大家来探讨相关话题 有些需求在开始的时候是提不出来的，或者说没法细化的，强行的...
评分2008年春，项目做的对敏捷有了点兴趣，花了两个晚上浏览了《敏捷迭代开发——管理者指南》，理念式的书，看起来比较轻松，摘录一些自己的体会。 原文在 http://iamsujie.com/7000/7008/，欢迎大家来探讨相关话题 有些需求在开始的时候是提不出来的，或者说没法细化的，强行的...
评分2008年春，项目做的对敏捷有了点兴趣，花了两个晚上浏览了《敏捷迭代开发——管理者指南》，理念式的书，看起来比较轻松，摘录一些自己的体会。 原文在 http://iamsujie.com/7000/7008/，欢迎大家来探讨相关话题 有些需求在开始的时候是提不出来的，或者说没法细化的，强行的...
评分2008年春，项目做的对敏捷有了点兴趣，花了两个晚上浏览了《敏捷迭代开发——管理者指南》，理念式的书，看起来比较轻松，摘录一些自己的体会。 原文在 http://iamsujie.com/7000/7008/，欢迎大家来探讨相关话题 有些需求在开始的时候是提不出来的，或者说没法细化的，强行的...
用户评价
这本书最令我感到惊喜的是，它对“衡量成功”这一核心议题进行了革命性的重新定义。在许多组织里，管理者依然习惯于用“按时交付”或“预算控制”来衡量项目成功，而这本书则清晰地引导我们转向以“商业影响”和“客户满意度”为导向的指标体系。作者详细列举了如何设计与商业目标强绑定的关键绩效指标（KPIs）和度量（Metrics），并强调了区分“有效指标”和“虚假指标”的重要性，这一点对于那些深陷“活动导向”陷阱的团队来说，是极其宝贵的警示。书中关于指标透明化的建议，帮助我们打破了信息孤岛，使得整个团队的目标感空前一致。此外，对于如何运用数据来驱动而非压制团队的决策过程，书中的描述细致入微，展示了一种既科学又充满人文关怀的管理方式。这本书让我深刻认识到，敏捷的本质不在于你开了多少站会，而在于你是否真正围绕价值在高效地学习和适应。
评分这本书的行文风格非常务实且带有强烈的实战色彩，读起来丝毫没有枯燥感，更像是一位经验丰富的老兵在与后进者进行一对一的经验传授。作者在描述如何建立高效的反馈循环时，所采用的对比手法令人印象深刻：他将传统瀑布模型下的“延期验收”与敏捷的“持续集成验证”进行了场景化的对比分析，让读者瞬间就能领会到其中的巨大效率差异和质量保证上的优势。尤其是在处理技术债务和需求漂移方面，书中提出的“价值流映射”工具的使用指南，简洁明了，操作性极强，我立刻尝试将其应用到我们当前的两个遗留项目中，发现效果立竿见影。它没有避开敏捷实施中的那些“脏活累活”，而是坦诚地告诉管理者，转型是一场马拉松，需要有策略地“打小胜仗”来积累信心和动力。这种直面问题的勇气和提供解决方案的智慧，使得这本书的价值远超一般的管理书籍。
评分与其他强调自组织和自下而上驱动力的敏捷读物不同，这本书清晰地勾勒出了高层管理者在推动敏捷文化落地的关键角色与责任。它没有将所有负担都推给一线团队或Scrum Master，而是着重强调了高层领导者必须是“变革的首席倡导者”。书中关于如何构建支持敏捷的组织结构、调整预算分配机制以及重塑绩效评估体系的部分，提供了极具前瞻性的战略指导。特别是针对大型企业中遗留的、僵化的采购和合同流程，作者提出了一些富有创意的过渡性策略，这些建议非常贴合现实中的官僚主义障碍。阅读过程中，我感觉作者是一位深谙企业政治运作的智者，他理解变革的阻力来自何方，并提供了绕过或瓦解这些阻力的成熟路径。这本书的深度在于，它不仅仅教你如何“做敏捷”，更教会你如何“成为一个支持敏捷的组织”。对于寻求系统性变革的CEO或高管团队来说，这是一部不可多得的战略蓝图。
评分我花了很长时间寻找一本能够真正触及企业转型痛点的书籍，市面上很多敏捷主题的书籍要么过于学院派，要么就是一味推崇Scrum或Kanban的特定框架，让人感觉受限。然而，这本著作的独到之处在于，它把“人”放在了核心位置。作者细腻地描绘了在敏捷转型过程中，团队成员，尤其是中层管理人员所面临的心理落差和不适感。书中关于“建立心理安全感”的章节，简直是教科书级别的示范，它详细解析了在一次失败的迭代后，管理者应该如何引导团队进行无指责的复盘，并将失败转化为集体的学习经验。这种对组织文化的深层次挖掘，远比单纯的技术流程优化来得更有价值。此外，书中对于如何与非技术部门——比如市场、销售或法务——建立有效的跨职能协作机制，提供了非常实用的“翻译”和沟通策略，解决了许多大型组织在推行敏捷时经常遇到的部门壁垒问题。这本书真正做到了“知人善任”，体现了敏捷精神在组织层面的落地哲学。
评分这本书的内容深度和广度着实让人耳目一新，尤其是对于那些在传统项目管理模式下摸爬滚打多年的管理者来说，简直像是一盏指路的明灯。它并非简单地罗列敏捷的各种术语和实践，而是深入剖析了在实际操作层面，管理者应该如何从思维模式上进行根本性的转变。书中对“仆人式领导”的阐述尤其到位，它不是空泛的理论，而是提供了大量可操作的案例和具体的对话技巧，帮助管理者理解如何真正地赋能团队，而不是仅仅进行微观管理。我特别欣赏作者对于风险管理这一环节的探讨，在高频次交付的压力下，如何通过迭代反馈来提前识别并控制潜在的“黑天鹅”事件，这一点上，作者展现了远超一般敏捷布道者的深刻洞察力。读完后，我感觉自己对“交付价值”的理解从一个模糊的概念，变成了一套清晰、可衡量的系统。对于那些渴望带领团队实现真正高效益转型的领导者，这本书无疑是案头的必备工具书。它成功地架起了理论与实践之间的鸿沟，让敏捷不再是口号，而是日常工作流中的有机组成部分。
评分用处不大，没什么干货，大都是概念性的东西，历史也占了很大的篇幅
评分第一遍读完，接下去再细读一遍
评分用处不大，没什么干货，大都是概念性的东西，历史也占了很大的篇幅
评分用处不大，没什么干货，大都是概念性的东西，历史也占了很大的篇幅
评分用处不大，没什么干货，大都是概念性的东西，历史也占了很大的篇幅
相关图书
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2026 book.quotespace.org All Rights Reserved. 小美书屋 版权所有