具体描述
本书讲解了Scrum 敏捷软件开发方法，让你在30 天内开发出全新的软件。读完本书，你会发现用敏捷开发方法能够让软件开发事半功倍，节省人力物力，大大提高工作效率。
本书适合于管理者、商务人士、小企业主、产品开发经理、IT 经理以及软件开发人员等阅读。
作者简介
作者简介：
Ken Schwaber
软件开发专业人士，在过去40年的职业生涯中，曾担任过程序员、分析师、咨询师、产品经理，还做过企业家。过去20年里，一直致力于发展Scrum，并帮助世界各地的机构使用Scrum。他是“敏捷宣言”最早的签署人之一，也是敏捷联盟和Scrum联盟的创始人，目前正努力通过Scrum.org来改善整个软件行业。
Jeff Sutherland
马萨诸塞州剑桥市Scrum Inc.的首席执行官，专门为世界各地的公司提供培训、咨询和辅导服务。同时也是波士顿风险投资公司OpenView Venture Partners的高级顾问，帮助所投资的公司实施Scrum和敏捷实践。多年来，Jeff已在众多软件公司和信息技术机构推广和提升Scrum。
译者简介：
王军
全球领先的Scrum敏捷专业培训咨询机构ShineScrum的首席执行官，资深Scrum敏捷培训师和教练，CSP、CSM、CSPO，美国纽英伦中华资讯网路协会董事和中国区主席。有20多年海内外软件行业从业经验，曾任甲骨文上海BI研发中心总监，2000年在美国担任计算机集成制造（CIM）首席工程师。他辅导过国内许多大型软件企业导入敏捷，是引导个人成为优秀敏捷实践者的导师。毕业于北京理工大学，拥有美国百森商学院创业学MBA学位。
李麟德
CSM、CSP。现任职于Oracle Endeca Information Discovery部门，专注于Java应用开发和自动化测试。拥有多年Scrum实践经验。
目录信息
你可能对你的软件公司感到沮丧，希望它能够更快、更灵活、更好地理解你的需要，并帮助你创造更多利润。在这一部分，我们首先找出令你沮丧的原因，然后想办法解决问题。
第1章 软件危机：错误的流程导致错误的结果 2
很多软件开发组织都在使用一种开发流程，而使用这种流程就意味着你肯定会遭遇浪费、无法控制的风险、不确定性、意外情况以及低价值。在这一章里，我们会研究为什么人们会选择这种流程，也会分析为什么这种流程注定要失败，最后再分享一些组织从失败中恢复的案例。
1.1 案例学习：FBI的“哨兵”项目 3
1.2 错误的方法：预测性流程 5
1.3 错误的结果：项目失败 8
1.4 案例分析：PTC 11
1.5 小结 14
第2章 Scrum：正确的流程产生正确的结果 15
有这样一个适合软件开发的流程。当开发人员使用它的时候，会立马提高生产效率、质量、价值、可控性、可预期性和满意度。我们会在这一章里看看这种流程是如何做到这一点的。
2.1 经验型流程实战 15
2.2 经验型流程真的能够解决问题吗 19
2.3 人类实践源于经验主义 24
2.4 尽管我们知道该如何做 27
2.5 敏捷性 28
2.6 小结 28
第3章 你也来试一试：创建试点项目 30
现在你已经对我们所宣称的更好的软件开发方法有所了解了。然而，过去也有很多人宣称他们的方法是最好的，并从你的口袋里赚到了很多钞票，却只为你带来了极小的改进，甚至没有任何改进。在这一章里，我们要向你证明我们所介绍的流程是可行的并且是免费的。
3.1 经验主义已经在组织中使用了 31
3.2 一个试点范例 32
3.3 这对团队成员来说可能是全新的工作方式 42
3.4 小结 44
第4章 我要做些什么 45
到目前为止，你已经学到怎么才能做得更好，也有了切身体会。你为这样的结果感到兴奋，同时也知道如何向软件组织介绍新的流程。在这一章里，我们会介绍如何应用你的经验帮助你的试点项目取得成功。
4.1 实践可能性艺术 45
4.2 创造透明的成长环境 47
4.3 相信你的员工能做更多 48
4.4 降低员工对确定性的期望 49
4.5 小结 50
第二部分 如何在30天内开发出软件
根据需求开发出更好的软件并不像过去那么困难。在这一部分里，我们将会介绍一套循序渐进的方法，帮助你从目前的状态过渡到让整个组织变得敏捷起来。
第5章 初试Scrum 52
我们用于帮助你改进软件开发的秘密武器叫做“Scrum”。是的，就是英式橄榄球里的争球。在这一章里，我们将会讨论Scrum是如何工作的，以及它为什么有效。
5.1 组建Scrum团队并为Sprint做计划 53
5.2 开始Sprint——向价值启航 53
5.3 进行Sprint评审 54
5.4 进行Sprint回顾 55
5.5 继续Sprint 55
5.6 小结 56
第6章 在项目中应用Scrum 57
软件开发中的大多数持续改进都是从项目开始的。你可以运用Scrum来进一步证明它的效果，或者在必须成功的、至关重要的项目中使用Scrum。这一章里，我们会探索如何培训开发人员。
6.1 自下而上的隐形Scrum 57
6.2 好处与收获 58
6.3 使用燃尽图管理工作进度 58
6.4 不要忽视复杂性：永远保持警惕 62
6.5 Sprint的长度 63
6.6 下一章 68
第7章 创建Scrum工作室 69
成功通常能够带来更多的成功。随着越来越多的软件项目成功实施Scrum，越来越多的人也希望加入到Scrum的行列中来。不考虑尝试变革整个组织，我们来看看如何从令人失望的现有部门中为Scrum开辟一片独立的天地。你将可以逐渐地从越来越多的项目和发布版本中享受Scrum带来的益处。
7.1 工作室是一个学习型的组织 69
7.2 工作室经理 70
7.3 培训和使用条款 71
7.4 工作室的设施 73
7.5 变革和难题 74
7.6 用数字进行管理 75
7.7 依赖于透明性的指标 78
7.8 一个完成并且完整的功能增量 79
7.9 一个类比 83
7.10 消除技术债务获得可用的增量 84
7.11 罪恶之源 89
7.12 小结 91
第8章 在企业中应用Scrum 92
Scrum在项目或者版本发布层面带来了初期的敏捷性，同时也带来了迅速响应机会和应对挑战的能力。为了获得最重要的收益，作为经验型流程的Scrum，必须让整个组织都融入进来。这一章里，我们会探索如何去做，以及为什么有些方法无法长久，而有些却可以。
8.1 深入但短暂的改变 92
8.2 深化并固化的改变 94
8.3 Carbonite公司的转型 95
8.4 Carbonite的改革之举 95
8.5 结果 96
8.6 Scrum实施中无可争议的两个元素 96
第9章 企业级转型：深化并固化改革 98
你希望在任期内让你的组织变得更精益、更高效、更敏捷，甚至希望这些利益和潜在的成因能够在组织中持久沉淀并且变成组织的文化。我们会在这一章里探讨如何才能进行企业级变革，实现以上这些期望。
9.1 企业转型工程 98
9.2 做好准备 99
9.3 启动转型工程 99
9.4 传播愿景和策略 102
9.5 推向整个组织 104
9.6 造成影响 106
9.7 度量、评估并巩固成果 106
9.8 巩固、推广并坚持 107
9.9 小结 108
第10章 用Scrum的方式实施Scrum 109
我们设计Scrum就是为了解决像软件开发这样复杂的问题。我们发现Scrum是管理组织变革和复杂问题的强力武器，而且能够在透明性、减少浪费、风险控制以及可预见性方面获得好处。这一章里，我们将会探索如何在这方面运用Scrum。
10.1 SeaChange International用Scrum实施Scrum 109
10.2 SeaChange的破冰之举 110
10.3 结果 112
10.4 Iron Mountain推广Scrum 112
10.5 转型团队 113
10.6 小结 115
附录A 术语 116
我们慢慢地、循序渐进地介绍一些新术语，这份附录可以作为你的术语参考。
附录B Scrum指南 120
通过阅读这篇权威的指南，你将了解到Scrum中的角色、工件及事件。这是一篇Scrum的圣经。
附录C 企业级敏捷攻略 139
这份附录更详细地介绍了第10章所述的进行企业级变革的计划。
· · · · · · (收起)
读后感
我们使用scrum敏捷开发还不到2年时间，从实践来说确实有点晚，但她给我们带来的好处是显而易见的，以前我们的交付能力一般是3个月到半年以上，现在比较大的需求能做到1一个月一次交付，有时甚至是半个月，小的修订就不说了。而且团队的灵活性大大增强，能随时随场景组织...
我们使用scrum敏捷开发还不到2年时间，从实践来说确实有点晚，但她给我们带来的好处是显而易见的，以前我们的交付能力一般是3个月到半年以上，现在比较大的需求能做到1一个月一次交付，有时甚至是半个月，小的修订就不说了。而且团队的灵活性大大增强，能随时随场景组织...
我们使用scrum敏捷开发还不到2年时间，从实践来说确实有点晚，但她给我们带来的好处是显而易见的，以前我们的交付能力一般是3个月到半年以上，现在比较大的需求能做到1一个月一次交付，有时甚至是半个月，小的修订就不说了。而且团队的灵活性大大增强，能随时随场景组织...
我们使用scrum敏捷开发还不到2年时间，从实践来说确实有点晚，但她给我们带来的好处是显而易见的，以前我们的交付能力一般是3个月到半年以上，现在比较大的需求能做到1一个月一次交付，有时甚至是半个月，小的修订就不说了。而且团队的灵活性大大增强，能随时随场景组织...
我们使用scrum敏捷开发还不到2年时间，从实践来说确实有点晚，但她给我们带来的好处是显而易见的，以前我们的交付能力一般是3个月到半年以上，现在比较大的需求能做到1一个月一次交付，有时甚至是半个月，小的修订就不说了。而且团队的灵活性大大增强，能随时随场景组织...
用户评价
这本书的叙事风格非常具有感染力，它很少使用那种枯燥的说教口吻，而是像一位经验丰富的同事在分享他的“踩坑”心得。在探讨单元测试和集成测试的编写哲学时，作者用了一系列生动有趣的“反例”来衬托“正例”的优越性。我特别欣赏它对“测试驱动开发”（TDD）的介绍，它没有把它包装成一种必须恪守的教条，而是将其定位为一种强大的思维工具，用以驱动更清晰的设计决策。阅读过程中，我常常会停下来，对着书中的代码片段进行反思，思考如果是我来写这段代码，我的思路是否能达到作者所强调的简洁和健壮程度。这种强烈的自我审视和对卓越的追求，是这本书最宝贵的精神财富，它真正培养的不是代码的搬运工，而是对质量有执念的匠人。
从整体的架构来看，这本书的知识点组织逻辑严密，呈现出一种高度提炼的体系感。它巧妙地在介绍完基础语法和核心模式之后，无缝衔接到系统级别的设计考量，比如如何平衡性能与可扩展性之间的矛盾。书中对数据库选型和数据迁移策略的分析尤为深刻，它清晰地对比了关系型数据库与NoSQL方案在不同业务场景下的适用性边界，避免了那种“万能”解决方案的误导。此外，关于API设计的部分，作者展示了RESTful原则的精髓以及如何优雅地处理版本迭代，这对于任何想构建面向未来的服务的开发者来说，都是不可多得的宝贵经验。总而言之，这套书更像是一份浓缩的“十年经验精粹”，它帮助我跨越了许多初学者常年徘徊不前的瓶颈期，提供了清晰、可靠的导航图，让我能够以更成熟的视角去看待软件开发这项复杂的工程活动。
我必须得说，这本书对特定技术栈的选取是极其巧妙且与时俱进的。它选择的技术组合并非盲目追逐最新的潮流，而是基于当前工业界最成熟、应用最广泛的框架和语言生态展开的。比如，在讨论后端服务构建时，它对异步编程模型的深入浅出解释，配合具体的代码示例，彻底打消了我对并发处理的许多困惑。更让我感到惊喜的是，书中竟然有专门的篇幅讲解了部署流水线（CI/CD）的自动化策略。以往很多书籍在讲完代码实现后就戛然而止，但这本书却将焦点延伸到了如何将代码可靠、快速地推向生产环境这一关键步骤。作者对容器化技术（如Docker）的介绍，并不是那种浮于表面的“如何运行”的教程，而是着重阐述了其在环境一致性和依赖隔离上的核心价值，这无疑是拓宽了我的视野。
这本书在处理实际项目流程方面的叙述，简直就是一本操作手册的升级版。它详细拆解了一个典型软件项目的生命周期，从需求分析的模糊地带如何提炼出可执行的用户故事，到版本控制策略的最佳实践，每一个环节的描述都充满了实战经验。我特别喜欢其中关于敏捷开发实践的章节，它没有陷入那种理想化的理论描述，而是坦诚地讨论了在真实团队协作中，Scrum或看板方法可能遇到的摩擦点以及如何巧妙地规避它们。作者对风险管理的见解也十分独到，书中列举了多个因初期规划不足导致的“技术债务”案例，并通过生动的图表展示了技术债务累积的指数级增长效应，这让我对前期投入质量有了更深刻的敬畏之心。读完这部分，我感觉自己像是完成了一次高强度的模拟演练，对未来参与任何规模的开发工作都有了更清晰的信心坐标。
这本书的装帧设计得非常简洁有力，封面采用了一种深邃的蓝色调，配上清晰、现代感的白色字体，给人一种专业且值得信赖的感觉。我尤其欣赏它排版的舒适度，字体大小适中，行间距处理得当，即便是长时间阅读也不会感到眼睛疲劳。初次翻开时，我注意到了它对软件开发核心概念的介绍方式，那种从宏观架构到具体实现步骤的层层递进，仿佛一位经验丰富的导师在引导初学者建立起完整的知识体系。它并没有一上来就抛出晦涩难懂的专业术语，而是先从“为什么”开始，解释了良好软件设计的哲学基础，这对于理解后续的技术细节至关重要。书中对“干净代码”的论述尤为精彩，它不仅提供了编码规范，更深入剖析了代码可读性和可维护性对整个项目生命周期的深远影响。这种注重底层思维构建而非仅仅停留在工具层面的教学方法，让我对后续的学习充满了期待。
其实很多领域都可以用敏捷的方法解决问题
翻来覆去的一些话，虽然书本来也不厚，其实就1、2页的大标题，弄几个图的事儿。比较失望，不推荐买入。
非常浅的一本书，吹了一个概念罢了 想系统学习或者得到准则等信息的就忽略掉吧 浪费时间
其实很多领域都可以用敏捷的方法解决问题
其实很多领域都可以用敏捷的方法解决问题
