《深入核心的敏捷开发：ThoughtWorks五大关键实践》的特色如下：
萃取自ThoughtWorks十年敏捷实践
有效、有用、深入核心的敏捷开发
系统梳理切实可行的敏捷落地框架
《深入核心的敏捷开发：ThoughtWorks五大关键实践》的主题如下：
核心原则，核心实践，管理体系，敏捷转型，真实案例
来自项目实际演练过程中的深度思考与适应性行动参考
敏捷，精益，Scrum，Kanban，究竟应该怎样有效落地
涉及行业广、具有深度启发性的敏捷实施落地调研结果
《深入核心的敏捷开发：ThoughtWorks五大关键实践》介绍了ThoughtWorks是如何实践敏捷开发的，主题包括测试驱动开发、持续集成、持续交付、全功能团队、需求分析和敏捷转型等。ThoughtWorks经过十多年的实践和沉淀，总结得出一套独特的、切实可行的敏捷软件开发核心原则、核心实践、管理体系和敏捷转型过程。全书共5部分18章，介绍了什么是合理正确的需求分析方法，如何采纳先进和理性的技术，自适应的团队组织形式是怎样的，如何建立客户价值优先的思维，如何持续改善软件交付方法。与此同时，作者也提到了一些可能遭遇的坑，引导读者参与思考什么是敏捷的实质。
《深入核心的敏捷开发：ThoughtWorks五大关键实践》面向开发者、敏捷咨询顾问、CIO和CTO，可以帮助他们顺利导入和实施敏捷。
第1章 敏捷宣言到底有几句
“嗨，A同学，敏捷宣言有几句？”
“4句呀，分别是个体和互动……”
如果你的答案和A同学一样，也认为是4句，那么请你继续往下读，相信会对你有所帮助。
如果你的答案和A同学不一样，认为不是4句或者不知道，那么可以选择性阅读，它不一定对你有所帮助。：)
为什么写此文
当我还是一名敏捷实践的试行者，接触到的第一个信息就是敏捷宣言(非4句)，虽然不能完全领悟，但当时的教练让我把它熟记于心，说这个就是敏捷。我想：我终于知道敏捷了。
当我还是敏捷教练时，向大家介绍敏捷，问都有谁知道敏捷宣言的时候，有部分同学举手，他们的答案和A同学一样。我想这下可有的喷了。
现在我是敏捷咨询师，接触到一些企业内部的敏捷实践者，问他们同样的问题，他们的答案也和A同学一样。我想：“这下你该请我们做咨询了。”
就在前不久，我听了一些敏捷培训，讲师提到敏捷宣言的时候，竟然也都介绍4句敏捷宣言，之后我饶有兴趣地百度了“敏捷宣言”的关键字，也询问了周围的敏捷实践者，得到的答复是敏捷宣言就是4句呀，大家都知道的……我忽然意识到此事的严重性，我是时候分享给大家了！
敏捷宣言到底有几句
让我们来看一下原版的敏捷宣言。以下是官方的翻译：
数一数有几句？6句。这里并不想纠结于数字，你也许会说敏捷宣言中有4句价值观，这似乎也没错，但问题是你了解其余2句吗？敏捷宣言流传至今，我们心中似乎只记住了那4句，其余的2句被我们天然屏蔽了，甚至我们还一直在做“敏捷宣言只有4句”这样的知识传递！难道那两句不重要吗？答案肯定是否定的(不重要为什么要写在宣言里……)，两句的偏差带给我们的是敏捷转型方向上的错误。让我们来看一下这两句告诉我们了一些什么。
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观。
通过这句我们了解到敏捷宣言是通过不断实践总结出的价值观。价值观不是具体详细的目标及实践，它是在我们心里的一种根深蒂固的思维取向，它会影响我们做出的每一件事情。所以有团队会说，我们现在已经敏捷了，因为我们做了迭代开发，这种单纯的实践=敏捷是不成立的，我们需要多维度了解团队的价值观是否符合敏捷的价值观。
虽然右项也具有价值，但我们认为左项具有更大的价值。
这句是敏捷宣言里最重要的一句话。如果你丢了第一句，说宣言有5句，这个还可以原谅。但如果你丢了这一句，那绝对是个错误！在做敏捷转型的过程中常遇到这样的现象：“敏捷说了不需要文档，太好了，我们以后就不用写文档了！”“敏捷说了不需要计划，我为什么要给你计划？！”这样实施的后果可想而知，这样的案例比比皆是，这就是敏捷转型方向上的错误。
为什么会有这样的错误呢？原因就是忽视了宣言中的最后一句话。宣言的价值观中英文用了over中文翻译是“高于”，A高于B，多数人的理解就是A比B好，那么为了敏捷转型我们就只用A舍弃B，这似乎是字面上的正常的理解，但这不是宣言中要表达的意思。想必当初17位大牛早已预见了这样问题，他们用最后这句强调，给大家正确的引导。告诉大家宣言中的价值观不能理解为取A舍B这样的二分。敏捷的价值观是承认右项是有价值的，不过我们要更重视左项的价值，这不是二分！当初软件开发在不断发展的过程中，大家越来越重视右项的价值，这时敏捷站了出来，提出在这个过程中我们要更加重视左项的价值，它并不是让我们要放弃右项实施左项。
在我们实际做敏捷转型的过程中，左右两项通常情况下也是共存的，不过我们更重视左项。例如你在帮一个团队在做敏捷转型，你发现产品把需求都录入系统中，告诉大家他的任务已经完成，之后研发按照系统中录入的需求进行研发，期间他们无任何沟通。这时你应该做的是加强他们之间的互动，例如让产品给研发对着系统的需求讲一遍，研发在过程中发现问题立刻和产品沟通，不过度依赖于系统中的描述等，你不能认为宣言里说了互动比工具更重要，就让他们停止使用系统只靠互动，这样团队会“手忙脚乱”，就算团队勉强坚持下来了(且不说效果好坏)，最后你会发现数据统计的工作如果没有工具，对团队来说就是一场噩梦。这样的例子还有很多。
目录
序曲 ThoughtWorks的敏捷开发 1
第Ⅰ部分 核 心 原 则
第1章 敏捷宣言到底有几句 19
为什么写此文 19
敏捷宣言到底有几句 20
第2章 开发人员的客户思维 23
开发人员与客户思维 24
第Ⅱ部分 核 心 实 践
第3章 基于统一迭代节奏的全功能团队 33
从汽车贴膜看专业团队 33
团队的精进之道 37
第4章 基于用户故事的需求及范围实时管理 41
估算的目的 41
需求风险的坏味道和对策 44
需求的冰川 50
浅谈软件项目规模估计，到底在估什么 53
软件项目规模估计，怎么估？ 57
第5章 基于持续集成和测试前置的质量内建 63
关于Gitflow 63
改善单元测试的新方法 68
超越“审，查，评”的代码回顾 74
不做代码审查又怎样 76
敏捷实践之提前验收 82
让我们再聊聊TDD 85
结对编程的正确姿势，你学会了吗？ 89
第6章 基于效能和周期时间的持续改进 95
看板和利特尔法则 95
点之殇 100
高效回顾会议的七步议程 107
第7章 组建人人深度参与的统一团队 111
开不好站会？因为不同阶段站会的目的不一样 111
展示会的七宗罪 114
浅谈敏捷离岸团队沟通 119
第Ⅲ部分 管 理 体 系
第8章 为什么你的Scrum会失败？ 129
三个角色 130
四个会议 132
第9章 技术领导者即服务 135
责任拆解 136
技术栈管理 137
第10章 项目管理中的敏捷实践 139
敏捷的项目管理：追求最大价值的成功 140
那么，这个定义是正确的吗？ 141
用户故事 142
估算和迭代计划 143
迭代会议和功能演示 144
站会和用户故事开卡 145
代码审查和回顾 145
最大程度的可视化 147
沟通计划 148
结语 150
第11章 也谈精益 151
追求快速价值交付的小批量生产模式 152
追求极致卓越的生产匠艺 154
结语 155
第Ⅳ部分 转 型
第12章 团队敏捷转型的三个阶段 159
阶段一(Agile 0～1)：建立敏捷流程，缩短交付周期 160
阶段二(Agile 1～3)：引入技术实践，质量内建，减少返工 161
阶段三(Agile 3～5)：提升价值交付效率和响应力 165
结语 166
第13章 绩效考核，敏捷转型的鸿沟 167
敏捷转型过程中的必然挑战 167
传统绩效考核 169
绩效考核的困境 170
如何破局？ 171
第Ⅴ部分 案 例
第14章 一个交付故事 179
技术带来的新挑战 179
自治团队的演化 181
第15章 又一个交付故事 185
明线：所有权？经营权？决策权？监督权？ 185
暗线：寻找时间之矢 188
第16章 一个遗留系统自动化测试的七年之痒 191
背景 191
七年之痒：痛点 191
问题分析 192
解决问题 193
第17章 如何在团队建设工程师文化？阿里资深技术专家这么做 197
工程师文化与KPI文化 197
敏捷 200
基础技术团队实践 200
第18章 敏捷转型下的团队管理：来自一线管理者的思考 207
管理者的“神光”并不总是好事 209
敏捷转型下管理者应该如何自处？ 210
需要团队管理者首先要做到信任和放手 210
自组织团队需要适度的灰度管理作为土壤，以管理者的自律来浇灌 210
附录 2017中国企业敏捷实施的调查与反思 213
参考文献 225
