作者简介

尤里根·赫斯伯格（Jorgen Hesselberg）

Comparative Agility联合创始人，享有盛誉的一个敏捷诊断和持续改进p台。在过去十多年间，他主持领导过无数个企业成功实现变革，培训过几千名专业人员，涉及的主题有敏捷和Scrum、破环性创新和企业转型策略。

译者简介

王晶

Odd-e敏捷教练。⼀直⼯作在软件研发前沿，拥有26年的IT经验。熟悉敏捷产品开发的各种实践，如CI/CD、⾃动化测试、⽤户故事地图和实例化需求等。热衷于敏捷，活跃在敏捷社区，是Scrum和XP的践⾏者。

审校简介

思特奇未来信息科技研究院

思特奇与电子科技大学联合成立的基于科技共享、共研、共进的创新孵化实体。通过创新的运行模式，为科技人才提供一个公共的、开放性平台，通过大数据、人工智能、物联网、5G、智慧运营、智慧城市、云计算、区块链和安全等产业相关技术的研发创新与消化吸收提高，积极推进技术和科研成果产业化，服务于前述领域的产业发展。

《正确敏捷：大公司如何实现全方位的业务敏捷》凝聚着作者十多年引领企业敏捷转型的精华，阐明了如何快速启动转变，如何在行进过程中保持良好的势头并持续改进以最后如期实现敏捷转型。透过本书，作者想要帮助读者“确认眼神”，找到对的顾问，优化组织结构，设置现实的期望，合理度量进展，等等。

《正确敏捷：大公司如何实现全方位的业务敏捷》适合打算导入敏捷以及打算长期保持业务敏捷的任何企业和机构使用。

1.2.3  软件吞噬世界：拥抱不确定性并变得敏捷
德鲁克和圣吉关于社区和学习型组织的理论问世之后，产生了深远的影响，但它们在20世纪80年代后期和90年代迅速崛起的新知识工作者群体（软件开发人员）中引起了更强烈的共鸣。虽然软件开发作为一个职业处于相对初级的阶段，但个人电脑（PC）的兴起和互联网的出现对软件开发人员产生了巨大的需求，并且越来越多的产品，从大型计算机到袖珍计算器和咖啡机，在一开始设计时就将软件自然包含在内。软件开发的工作开始激增，这意味着一种新型的工人（及工作）正在兴起，迫切需要一套新的规则。
软件开发人员拥有早期知识工作者（比如建筑师、律师和学者）的许多特征，但创建软件更加强调团队合作、持续学习和有效沟通。作为一门学科，软件开发既是一门艺术，又是一门科学。它的核心是通过创建可以利用机器计算能力的算法来解决复杂问题。
通过实验和团队成员之间的协作来达成对问题更好的理解，不只适用于软件开发领域，还适用于整个产品开发。1986年，竹内弘高（Hirotaka Takeuchi）和野中郁次郎（Ikujiro Nonaka）在《哈佛商业评论》中发表了文章“新新产品开发游戏”，描述了一种用橄榄球做比喻的新的工作方式，团队成员经常像传球一样在团队内分享信息和知识。
类似于运动团队，软件开发团队是一群为了实现共同目标而在一起的、具有互补技能的人。
文章指出，为了创建令客户信服的解决方案，促进学习以便验证我们对客户需求的假设是产品开发过程中不可缺少的至关重要的部分。竹内和野中警告说，目前的工作方式是不可持续的，其中对客户的所有假设都是预先设定的：
    “跨国公司在开发产品时必须同时具有速度和灵活性。这一点在很大程度上依赖于反复试验和边做边学，这是一个动态过程。我们今天需要的是在不断变化的世界中不断创新。”11
这一洞察吸引了前海军精英苏瑟兰（Jeff Sutherland），他参与了Easel公司的IT系统开发。他与Easel的同事一起开始定义一种更灵活的软件开发方法，该方法考虑了从实践中学习、紧密的团队协作以及频繁的反馈环。1995年，苏瑟兰与软件开发人员兼行业顾问施瓦伯（Ken Schwaber）一起在OOPSLA（面向对象编程、系统、语言和应用，Object Oriented Programming Systems Languages and Applications）行业会议上正式确定了他们称之为Scrum框架的工作方式。Scrum把竹内和野中的研究结果具体化，形成一种非常简单但不容易精通的产品开发方法（第3章有更多关于Scrum的叙述）。
Scrum解决了产品开发在管理方面的问题，但并没有提及开发软件时可能需要的特定技术实践。著名软件工程师贝克（Kent Beck）在20世纪90年代末提出极限编程（XP）及其著作《解析极端编程》（Extreme Programming Explained）来解决这一需求。XP的核心目标是降低变化成本。也就是说，进行渐进式和迭代式适应性变化的反馈环速度越快，我们越有可能构建出能够完成既定目标的软件。贝克敦促管理者认识到变化是软件开发的一个自然并可取的方面。不要试图定义不变的需求，我们应该计划和预期变化，这是产品开发过程的一部分。参见图1.1。13
贝克的工作引起了鲍勃大叔（Robert Martin，Uncle Bob）的注意。马丁是芝加哥一位成功的C ++及面向对象设计的顾问。经常有客户希望他可以提供一个过程将他用的实践打包流程化。由于自己无法在流程设计上取得很大的进展，马丁对贝克的工作产生了浓厚的兴趣，在慕尼黑举行的两次软件会议后，他俩成为工作搭挡。马丁知道贝克正在做他感兴趣的事情，所以他前往波特兰拜访贝克并了解测试驱动开发以及如何结对编程。马丁了解得越多，越确信他和贝克的工作越来越接近于客户的要求。
 
图1.1  极限编程实践通过反馈环中的多个层次来创建快速学习机会
差不多在同一时期，1991年，犹他州的方法论家科伯恩（Alistair Cockburn）服务于IBM刚刚起步的咨询部门，他的目标是深入了解项目团队取得成功的原因。科伯恩发现，从Smalltalk和C++项目开始，使项目团队取得成功的因素在当时的文献中并没有记录下来。在采访了数十个项目团队之后，他将成功团队的关键要素提炼成他所称的Crystal Family方法，这是一系列适合特定类型项目的轻量级流程。关键是每个项目都需要适合自己的方法。方法随着形势的变化而变化。14
当这些思想领袖正在或多或少地彼此独立地探索更好的软件开发方式的时候，软件行业本身正处于一个糟糕的状态。在20世纪70年代、80年代和90年代，有几起案例因成本严重超支、长期质量问题以及令人尴尬的延期而成为头条新闻。1994年，Standish集团发布了一份高引的“混乱研究报告”（Chaos Report），该报告发现软件项目的平均成本超支率高达189%。15其他调查显示，有一半的项目尽管还在做但基本不会被认为是成功的项目。还有更糟糕的，交付给客户的所有大型软件产品中有四分之三不符合客户的要求。
工作者（程序员）并没有因为事情的发展状况而无法继续工作。在整个20世纪90年代，软件行业的专业人士经常定期会面并分享想法。这些新兴的思想有哪些共同点呢？我们可以通过哪些方式来改进软件开发？人们认识到了需要改变，但这些想法并没有以有意义的方式结合在一起。
这种情况即将改变。极限编程开始在社区中占据一席之地。有一天，鲍勃大叔（Robert Martin）在芝加哥与福勒（Martin Fowler）共进午餐，他2000年秋在贝克组织的极限编程峰会上见过这位极限编程专家。他们觉得有必要通过某种峰会让志同道合的人聚集在一起并创建一个“轻量级流程宣言”。然后，两人开始确定应该参加会议的人，以确保能代表许多不同的观点。后来，鲍勃大叔（Robert Martion）通过电子邮件发出了“轻量级流程峰会”的邀请，其中一位受邀者就是科伯恩（Alistair Cockburn）。
科伯恩，他本人出于同样的原因正在安排类似的活动，于是热情地接受了邀请。并且，科伯恩建议在他家附近的犹他州组织进行，方便负责后勤相关事宜。
就这样，在几个月之后，2001年2月，贝克、科伯恩、马丁、福勒、施瓦伯、苏瑟兰及其他11位经验丰富的思想领袖齐聚犹他州的雪鸟城，寻求一种正确的软件开发方法。他们一起思考如何运用他们的集体经验来改进软件开发。作为软件开发人员，他们为自己的技艺感到非常自豪。然而，他们对软件工程的总体状态以及软件开发（作为一种职业）被消极看待并不满意。他们希望开发出能让客户很开心的软件，他们希望能够影响组织创建合适的环境以构建出色的软件。
经过几天的探讨和辩论，还包括相当数量的滑雪、少量的泡酒吧以及热水澡的贡献，这些程序员写下了由4个价值观和12个原则组成的《敏捷软件开发宣言》，也称为《敏捷宣言》。
敏捷宣言的价值观和原则受到这些领袖在会前几年中创造和形成的方法之启发：Scrum、Crystal、极限编程（XP）、动态系统开发方法（DSDM）和特性驱动编程（FDD）。第3章有更多关于其中一些方法的信息。所有这些方法和潜在的理念都是为了开发更好的软件。然而，在拟定“宣言”时，这些软件专业人员意识到他们创造了一些更为深刻的东西。

目录
第I部分  敏捷的业务场景
第1章  敏捷的必然性    3
1.1  雅典战胜微软    4
1.2  现代管理的起源    7
1.2.1  科学管理：打造更多的效率机器    7
1.2.2  知识工作者的崛起：释放创造力潜能    9
1.2.3  软件吞噬世界：拥抱不确定性并变得敏捷    10
1.2.4  VUCA与Cynefin：在美丽新世界中找到业务方向    16
1.2.5  Cynefin框架    18
1.3  复杂世界中的领导力    21
小结    24
问答环节    25
更多资源    26
注释    28
第2章  企业敏捷    31
2.1  定义企业敏捷    32
2.2  设计业务敏捷：平衡三大关键杠杆    34
2.2.1  做正确的事情（价值）    35
2.2.2  正确做事（质量）    42
2.2.3  以正确的速度做事情（优化流动）    45
2.3  在企业中解锁敏捷    52
2.4  绩效因子：敏捷的五个关键维度    52
小结    54
问答环节    54
更多资源    57
注释    58
第II部分  敏捷的五个维度
第3章  技术    61
3.1  做正确的事情：创造客户喜爱的产品    62
3.1.1  商业模式画布：一个可即时对齐的交互式工具    62
3.1.2  精益创业：验证正在做的产品是否值得做    65
3.1.3  延期成本：理解时间如何影响产品在生命周期中的利润    68
3.2  以正确的方式做事情    73
3.2.1  Scrum：增量并迭代地交付价值    73
3.2.2  Kanban：通过可视化来驯服混沌    78
3.3  以正确的速度做事情（优化流动）    81
3.3.1  XP    81
3.3.2  价值流图    85
小结    88
问答环节    89
更多资源    91
注释    93
第4章  组织设计    95
4.1  物理工作环境的设计    96
4.1.1  为卓越团队而设计    96
4.1.2  高绩效团队背后的科学原理    97
4.1.3  案例分析：NAVTEQ更有效的协作空间    98
4.2  组织结构    105
4.2.1  职能型组织    105
4.2.2  事业部型组织    107
4.2.3  矩阵型组织    109
4.2.4  正在兴起的组织结构：社会民主制和合弄制    110
4.2.5  敏捷组织的架构    114
4.3  对敏捷组织结构设计的探索    117
小结    119
问答环节    119
更多资源    121
注释    123
第5章  人员    125
5.1  永远不要低估人员的重要性    128
5.2  敏捷组织中人员的特征    130
5.2.1  培养成长思维    130
5.2.2  发展企业的成长思维    132
5.2.3  拥抱多样性    132
5.3  构建支持敏捷人员的环境策略    135
5.4  敏捷组织对HR的影响    136
5.4.1  与团队合作来改善招聘    136
5.4.2  设计有意义的薪酬、奖励及评价机制    138
5.4.3  创建更多的相关角色，定义更灵活的职业发展计划    139
5.4.4  逐步授权团队，赋能于人    140
5.4.5  HR：从控制型转变为解锁组织敏捷的关键    141
小结    141
问答环节    142
更多资源    144
注释    145
第6章  领导力    147
6.1  领导力的影响    149
6.1.1  第5级领导力    150
6.1.2  第5级领导力=敏捷领导力？    151
6.2  青色领导力    152
6.2.1  红色：通过武力来领导    154
6.2.2  琥珀色：通过命令来领导    154
6.2.3  橙色：通过效率来领导    154
6.2.4  绿色：通过职责来领导    155
6.2.5  组织：由相互关联部分组成的有机生态环境    155
6.2.6  青色：作为一个有生命的实体    156
6.2.7  青色组织：未来组织的蓝图？    157
6.3  超越预算：一个敏捷管理模型    158
6.3.1  超越预算的起源    159
6.3.2  超越预算：少一些自上而下的控制，多一些信任和赋能    159
6.4  传统CEO的末路？    162
6.5  敏捷领导力的三个基石    163
小结    164
问答环节    165
更多资源    166
注释    167
第7章  文化    169
7.1  文化的深远影响    171
7.2  我们如何体验文化    172
7.3  施耐德文化模型    174
7.3.1  合作文化：“我们因一起工作而成功”    174
7.3.2  控制文化：“我们因控制并一直保持而成功”    176
7.3.3  能力文化：“我们因最出色而获得成功”    177
7.3.4  培养文化：“我们因培养为实现共同愿景而努力的人而成功”    178
7.4  文化对持续变革的影响    179
7.5  业务敏捷相关度量的特征    186
7.5.1  可执行    186
7.5.2  可使用    187
7.5.3  可审计    187
7.5.4  额外的启发    188
7.6  有意义的业务敏捷度量示例    189
7.6.1  度量指标，有助于支持做正确的事情    190
7.6.2  度量指标，用于支持以正确的方式做事情    192
7.6.3  度量指标，用于支持以正确的速度做事情（流动）    194
7.7  绩效系统的转变→行为转变→文化转变    196
小结    197
问答环节    198
更多资源    200
注释    201
第III部分  解锁敏捷
第8章  建立组织级别的敏捷工作组    205
8.1  敏捷工作组的使命与意义    205
8.2  敏捷工作组的特征    209
8.2.1  技能互补    209
8.2.2  敬业    210
8.2.3  博闻，见多识广    211
8.2.4  值得信赖    212
8.2.5  谦逊    212
8.2.6  热情拥护    213
8.3  外部咨询师的角色    214
8.4  组织结构与敏捷工作组    215
8.4.1  系统整体视角    215
8.4.2  寿命短暂    216
8.4.3  双启动模式    217
8.5  为敏捷工作组招贤纳士    218
8.5.1  来自管理层的阻力    218
8.5.2  潜在候选人的犹豫不决    219
8.6  AWG到底意味着什么？    220
小结    221
问答环节    221
更多资源    222
注释    223
第9章  业务敏捷的运营模型    225
9.1  解锁敏捷：拥抱变化，精准执行    227
9.2  探索：拥抱变化的引擎    229
9.3  创收：精准执行经过验证的战略方针    239
9.3.1  传达之迷失：产品战略从愿景转为幻想    240
9.3.2  通过渐进细化，精准执行    241
9.3.3  通过快速闭环来精准执行    255
9.4  适度平衡：“拥抱变化”与“精准执行”    257
9.5  关于规模化框架    258
9.5.1  规模化敏捷框架（SAFe）    258
9.5.2  大规模Scrum（LeSS）    258
9.5.3  规范化敏捷框架    258
9.5.4  使用规模化框架的好处    259
9.5.5  使用规模化框架的缺点    259
小结    261
问答环节    261
更多资源    263
注释    264
第10章  解锁敏捷：战略路线图    267
10.1  解锁企业敏捷：一个高层次的战略路线图    269
10.1.1  合作转型（第一波）    269
10.1.2  自我导向（第二波）    271
10.1.3  根深蒂固（第三波）    272
10.2  您的行动有多敏捷？组织敏捷五个维度的应用    273
10.2.1  技术    274
10.2.2  组织设计    275
10.2.3  人员    275
10.2.4  领导力    277
10.2.5  文化    278
10.3  通过组织级改进待办列表来识别和驱动变革    279
10.3.1  用敏捷的方式解锁敏捷    279
10.3.2  步骤1：清晰定义并沟通企业转型的意义    280
10.3.3  步骤2：识别阻碍我们达成目标的主要障碍    281
10.3.4  步骤3：建立企业转型待办列表并落实具体工作    284
10.3.5  步骤4：保持前进的势头，持续监控进度，沟通结果，寻求反馈，庆祝失败    289
10.3.6  企业转型失败的十大原因    293
10.3.7  走上敏捷正途的七个标志    297
10.4  路就在前方，你准备好了吗？    299
小结    300
问答环节    301
更多资源    302
注释    303