内容简介：
本书以敏捷软件开发为中心，系统阐述了敏捷原则和实践的先进理念和重要意义，并分别讲解了Scrum、极限编程、精益和看板四套敏捷实践的应用。作者从开发团队的日常困境入手，用讲故事的形式展开问题，由表及里，层层讲解，并在每一章最后附上参考书，便于读者进一步查找学习。本书内容生动，语言通俗易懂，集趣味性和实用性于一体，是学习敏捷开发、提升团队效率的极佳参考书。
作者简介：
Andrew Stellman
是O'Reilly畅销书作者、敏捷教练、项目领导人、软件工程项目经理、开发人员和系统架构师。具有20多年的软件开发项目管理经验，是公认的软件开发专家。
Jennifer Greene
是一位优秀的软件测试人员，曾与不同的软件开发团队共事，并且构建了很多相当酷的工程。她还是一位畅销书作者，曾撰写过Head First PMP、Head First C#。其中Head First C#为她与Andrew Stellman合著。
目录：
序xv
前言xvii
第1章 学习敏捷1
1.1 什么是敏捷2
1.2 本书的读者对象5
1.3 本书的目标6
1.4 努力建立敏捷思维6
1.5 本书结构9
第2章 理解敏捷价值观11
2.1 团队主管、架构师和项目经理走进了一间酒吧……12
2.2 没有银弹14
2.3 敏捷可以拯救乱局吗16
2.3.1 引入敏捷，带来变化17
2.3.2 “聊胜于无”的结果18
2.4 视角割裂19
2.4.1 视角割裂带来的问题21
2.4.2 为什么视角割裂只能做到“聊胜于无”22
2.5 敏捷宣言帮助团队认识实践的目的24
2.5.1 个体和互动高于流程和工具25
2.5.2 可工作的软件高于详尽的文档25
2.5.3 客户协作高于合同谈判26
2.5.4 响应变化高于遵循计划26
2.5.5 原则高于实践27
2.6 理解敏捷的“大象”28
2.7 着手采用一套新方法32
第3章 敏捷原则37
3.1 敏捷软件开发的12 条原则38
3.2 客户总是对的吗38
3.3 交付项目40
3.3.1 原则1：最优先要做的是尽早、持续地交付有价值的软件，让客户满意40
3.3.2 原则2：欣然面对需求变化，即使是在开发后期。敏捷过程利用变化为
客户维持竞争优势41
3.3.3 原则3：频繁交付可工作的软件，从数周到数月，交付周期越短越好42
3.3.4 改进电子书阅读器团队的项目交付计划44
3.4 沟通和合作46
3.4.1 原则4：在团队内外，面对面交谈是最有效、也是最高效的沟通方式48
3.4.2 原则5：在整个项目过程中，业务人员和开发人员必须每天都在一起工作49
3.4.3 原则6：以受激励的个体为核心构建项目，为他们提供环境和支持，
相信他们可以把工作做好51
3.4.4 在电子书阅读器项目中采用更好的沟通方式52
3.5 项目实施——推进项目53
3.5.1 原则7：可工作的软件是衡量进度的首要标准53
3.5.2 原则8：敏捷过程倡导可持续开发。赞助商、开发人员和用户要能够
共同、长期维持其步调，稳定向前54
3.5.3 原则9：坚持不懈地追求技术卓越和设计优越，以此增强敏捷的能力55
3.5.4 改善电子书阅读器团队的工作环境55
3.6 项目和团队的持续改进56
3.6.1 原则10：简单是尽最大可能减少不必要工作的艺术，是敏捷的根本56
3.6.2 原则11：最好的架构、需求和设计来自自组织的团队57
3.6.3 原则12：团队定期反思如何提升效率，并依此调整57
3.7 敏捷项目：整合所有原则58
第4章 Scrum和自组织团队62
4.1 Scrum的规则64
4.2 第1幕：Scrum的适用条件65
4.3 Scrum团队中每个人都要对项目负责67
4.3.1 Scrum主管指导团队的决策67
4.3.2 产品所有者帮助团队了解软件的价值68
4.3.3 每个人都对项目负责69
4.3.4 Scrum有一组自己的价值观75
4.4 第2幕：状态更新只是社交网络的玩法78
4.5 整个团队参与每日Scrum例会80
4.5.1 反馈和“可见− 检查− 调整”周期80
4.5.2 最后责任时刻81
4.5.3 召开有效的每日Scrum例会83
4.6 第3幕：将冲刺计划写到墙上86
4.7 冲刺、计划和回顾会议87
4.7.1 迭代式与增量式87
4.7.2 冲刺成也在于产品所有者，败也在于产品所有者89
4.7.3 可见性和价值观89
4.7.4 计划并执行有效的Scrum冲刺93
4.8 第4幕：尽力之后94
第5章 Scrum计划和集体承诺99
5.1 第5幕：出乎意料100
5.2 用户故事、速度和普遍接受的Scrum实践102
5.2.1 提升软件价值102
5.2.2 以用户故事构建用户真正会用到的功能103
5.2.3 满意条件105
5.2.4 故事点和速度106
5.2.5 燃尽图108
5.2.6 通过用户故事、故事点、任务和任务板来计划并实施冲刺 111
5.2.7 广受认可的Scrum实践115
5.3 第6幕：第一次胜利116
5.4 回顾Scrum价值观116
5.4.1 具体实践没有价值观也有效果（只是别管它叫Scrum）117
5.4.2 你的公司文化与Scrum的价值观兼容吗119
第6章 极限编程与拥抱变化128
6.1 第1幕：开始加班129
6.2 极限编程的主要实践130
6.2.1 编程实践130
6.2.2 集成实践131
6.2.3 计划实践132
6.2.4 团队实践133
6.2.5 为什么开发团队抵制变化，上述实践如何提供帮助134
6.3 第2幕：计划有变，但我们还是看不到希望137
6.4 极限编程的价值观帮助团队改变心态139
6.4.1 极限编程帮助开发人员学会与用户协作141
6.4.2 开发团队的怀疑会破坏实践的效用142
6.5 正确的思维从极限编程的价值观开始144
6.5.1 极限编程的价值观144
6.5.2 以善意铺就144
6.6 第3幕：势头的变换147
6.7 理解极限编程价值观，拥抱变化148
6.7.1 极限编程的指导原则149
6.7.2 极限编程指导原则可以加深对计划的理解151
6.7.3 极限编程指导原则与实践相互促进152
6.7.4 反馈循环154
第7章 极限编程、简化和增量式设计163
7.1 第4幕：再次加班164
7.2 代码和设计165
7.2.1 代码异味和反模式（如何判断你是不是聪明过头了）166
7.2.2 极限编程团队主动寻找和修复代码异味168
7.2.3 钩子、边界情况以及功能过多的代码170
7.2.4 代码异味会增加复杂性175
7.3 把编码和设计决定留到最后责任时刻175
7.3.1 决然重构，偿还技术债务177
7.3.2 持续集成，排查设计问题179
7.3.3 避免一体式设计180
7.4 增量式设计与极限编程的整体实践182
7.4.1 有时间进行思考，团队才能做好工作184
7.4.2 团队成员彼此信任并共同作出决定186
7.4.3 极限编程的设计、计划、团队和整体实践形成了一个带动创新的系统186
7.4.4 增量式设计与为了复用而设计188
7.4.5 简化单元交互，系统实现增量式成长190
7.4.6 优秀的设计源自简单的交互190
7.5 第5幕：最终得分192
第8章 精益、消除浪费和着眼全局200
8.1 精益思维201
8.1.1 你已经理解了很多精益价值观201
8.1.2 承诺、选择意识和集合式开发203
8.2 第1幕：还有一件事……207
8.3 创造英雄与神奇思维209
8.4 消除浪费210
8.5 加深对产品的理解214
8.5.1 着眼全局216
8.5.2 找到问题的根本原因218
8.6 尽快交付219
8.6.1 使用面积图可视化工作进度221
8.6.2 限制进行中的工作，控制瓶颈225
8.6.3 拉动式系统帮助团队消除约束226
第9章 看板方法、流程和持续改进233
9.1 第2幕：紧赶慢赶的游戏234
9.2 看板方法的原则236
9.2.1 找到一个出发点并由此进行实验性的演进236
9.2.2 用户故事进去，代码出来238
9.3 用看板方法改进流程240
9.3.1 将工作流程可视化241
9.3.2 限制进行中的工作246
9.4 测量并管理流量251
9.4.1 用CFD 和进行中工作面积图测量并管理流量252
9.4.2 用利特尔法则控制系统的流量259
9.4.3 用进行中工作上限管理流量，自然地创造缓冲263
9.4.4 让过程策略明确统一265
9.5 看板方法下自然发生的行为266
第10章 敏捷教练275
10.1 第3幕：还有一件事（又来了？！）……276
10.2 教练要理解人们为什么不想改变277
10.3 教练要理解人们如何学习280
10.4 教练清楚如何让一套方法起作用284
10.5 进行敏捷指导时的原则285
关于作者288
关于封面288
文章试读：致谢 我们写作本书的目的是帮助读者学习敏捷。本书的完成离不开大家的帮助和支持。首先， 我们要感谢优秀的编辑Mary Treseler。从我们初次在曼哈顿市中心的一家印度餐厅跟她讨论本书的那天开始，一直到今天我们看到这本书，在这过程中，她付出了极大的努力。她在我们与O’Reilly 出版社的合作中起到了十分重要的作用。没有她的支持，我们就不会有今天的成绩。 我们也要感谢O’Reilly 出版社的...
(查看全部试读)