《敏捷组织设计：面向数字化转型和持续交付的组织重构》从组织角度来探讨如何在数字化转型的场景下实现真正的持续交付，描述了如何设计一个敏捷的组织，使其能够鼓励团队始终聚焦于自主、专精和目标，交付高质量的价值。
《敏捷组织设计：面向数字化转型和持续交付的组织重构》读者对象包括组织决策者、独立软件开发商和互联网企业的高管，负责IT、产品管理、工程或软件开发的副总裁或董事或主管，与IT 部门和IT 业务伙伴对接的业务主管、财务相关人员、数字化业务的投资者，关心高管意见的技术人员、ICT 战略制定者、IT 治理小组成员以及流程质量/SEPG 小组成员、流程顾问和教练。
《敏捷领导力：团队成长工具箱》针对敏捷领导力框架，阐述了如何提升四大技能，运用工具线思维来帮助团队取得持续的成长。通过无人机等项目案例，书中描述了如何组合使用关键价值指标、影响阶梯、所有权模型、自由矩阵、学习时间、验证学习栏、习惯矩阵和TO GRIP这八个工具才能达到好的效果。
《敏捷领导力：团队成长工具箱》适合中层管理人员阅读，是帮助团队保持持续动力和效能的理想参考书。
大部分业务模型的生命周期中，基本上都遵循启动、扩张、稳定/上岸这样的三部曲。《向上一步：精益敏捷中的增长思维与实践》收集了一些鲜活的实际例子，展现了新一代企业家和内部创业者在面对挑战时如何借力精益敏捷的原则来实现更好的发展。
通过对全球化创业公司和独角兽企业的采访，作者萃取出一手的珍贵建议，对处于业务生命周期各个阶段的企业家和连续创业者有重要的参考和指导作用，可以帮助他们在创业、持续运营和及时转向之间做出更好的决策。
《价值流动：数字化场景下软件研发效能与业务敏捷的关键》聚焦于传统项目管理模式的误区和问题，强调了以产品为导向的管理模式，同时基于丰富的案例创造性地提出了流框架，这是一种观察、度量和管理软件交付的新方法。流框架可以帮助公司从面向项目的管理模式转变为软件时代以产品为中心的创新管理模式，从度量驱动软件效能提升以及在组织在不同层面驱动变革的角度，提供了数字化转型成功落地的一种新的思路。
《走出硝烟的精益敏捷：我们如何实施Scrum和Kanban》真实反映了一个团队的精益敏捷落地过程。第Ⅰ部分介绍了团队是如何实施主流敏捷方法 Scrum的。主题涵盖如何写产品列表，如何准备、制定、公开和编写计划，如何布置团队空间，如何 开每日站会，如何做演示和回顾，如何对待固定价格的合同，如何结合使用Scrum和XP，如何做测 试，如何管理多个团队，如何管理分布式团队。最后，作者还给出了一个很有价值的ScrumMaster检 查清单。第Ⅱ部分主要介绍Scrum和Kanban的结合使用。在对比两者之后，作者通过一个具体的案例 来说明如何搭配使用两种方法来实现价值最大化。
《走出硝烟的精益敏捷：我们如何实施Scrum和Kanban》行文风趣，具备较强的知识性和可读性，适合所有打算导入并实施精益敏捷的软件从业人员 阅读和参考。
《SRE实践手册:软件组织如何规模化实施站点可靠性工程》基于作者在西门子医疗的SRE转型经历，为读者提供了SRE落地实践过程，主题涉及如何从基础设施、组织文化和流程等层面，从全景的角度实际导入和实施SRE工程过程。《SRE实践手册:软件组织如何规模化实施站点可靠性工程》共15章，实用性强，可操作性强，指导性强，适合想要启动SRE实践的组织和团队阅读与参考。
《深入核心的敏捷开发：ThoughtWorks五大关键实践》介绍了ThoughtWorks是如何实践敏捷开发的，主题包括测试驱动开发、持续集成、持续交付、全功能团队、需求分析和敏捷转型等。ThoughtWorks经过十多年的实践和沉淀，总结得出一套独特的、切实可行的敏捷软件开发核心原则、核心实践、管理体系和敏捷转型过程。全书共5部分18章，介绍了什么是合理正确的需求分析方法，如何采纳先进和理性的技术，自适应的团队组织形式是怎样的，如何建立客户价值优先的思维，如何持续改善软件交付方法。与此同时，作者也提到了一些可能遭遇的坑，引导读者参与思考什么是敏捷的实质。
《深入核心的敏捷开发：ThoughtWorks五大关键实践》面向开发者、敏捷咨询顾问、CIO和CTO，可以帮助他们顺利导入和实施敏捷。
敏捷组织设计：面向数字化转型和持续交付的组织重构
在大多数企业，IT 的表现都不如人意。IT 要为业务赋能尚且费力，更别说扮演差异化要素了。IT 不给力造成的一个结果是，业务和技术（IT）经常剑拔弩张。这对数字化转型来说不是个好兆头。我认为，糟糕的组织设计是造成这种遗憾的主要原因。2014 年 6 月麦肯锡的全球调查①也表明，在大型企业中，组织结构问题被认为是实现数字化目标的主要障碍。
企业管理者通常会从非行业特色的视角看待组织设计，将其视为纯粹是 HR 领域的事。然而在筹划组织重组时，又很少只从 HR 角度入手。与传统的观念不同，本书探索了如何从 IT 领导力的视角进行组织设计，从而给组织设计提供一个可靠的基础。这个基础的建立很重要，因为在实践中，IT 组织的设计很少从基本原则出发通盘考虑。时下常见的组织设计大多是偶然的产物，可能是并购的结果，或是为了留住员工而做的妥协，亦或是组织各层级领导的主意。这就跟软件中逐渐堆积的技术债一样，我们必须时不时退后一步审视组织的设计，否则组织设计也会逐渐腐化。
21 世纪的组织设计不仅涉及组织结构，而且还事关企业文化、团队政治、经营管理甚至物理空间。综合个人的行业经验，现有的关于组织设计、精益和敏捷的文献以及一些广受好评的个人和团队心理学的著作，我提出一套关于敏捷组织设计的理论。本书针对组织结构和经营管理配置提出的建议，很多已经被几家新生代的独立软件开发商所应用。我也解释了其他企业的 IT 部门如何能够从中受益。与此同时，本书中涉及团队政治和企业文化的章节，无论对独立软件开发商还是企业 IT 部门，都同样适用。
有几位审稿人出于好意，建议我在书名中使用精益而不是敏捷，以便卖得好一些。显然，如今精益更流行，而敏捷已经过时了。但最终我还是选择了以敏捷为题，因为敏捷非常重视以人为本，而这正是我提出的解决方案的核心。
① https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/the?digital-tipping-point-mckinsey-global-survey-results
时下流行的写书风格是把一篇文章的内容扩充成一本书。而本书恰恰相反，我把大量主题融为一本书，因为我相信这些主题是相互联系的，需要加以综合论述。本书涉及的主题很广，反映出一个现实：IT 领导角色需要关心的范围很广。当然，一本书无法穷尽所有相关问题。诸如创新、知识管理、人员多样性、绩效评估等主题没有在本书中涵盖或者只是捎带提及。
这里涉及的许多主题都属于 IT 治理的范围。但是，传统的 IT 治理过早地陷入了对标准和框架的讨论。本书的讨论基本上和标准和框架无关。此外，本书所讨论的文化方面一般不被认为是 IT 治理的范畴。
本书不是手把手教你操作的菜谱。我描述问题、探索原因并提供解决方案。然而，我并没有详细说明实施解决方案的步骤。只有几个章节提供了从现状迁移的步骤。此外，最后一章有一个小节针对几种推荐方案的采用顺序提供了建议。但总的来说，迁移的规划需要在具体背景中制定。我希望读者可以借鉴本书提供的建议，规划他们自己的迁移过程。此外，我也可以提供咨询服务。
本书中提出的许多建议已经在现实世界中取得了一定的成功。只要有公开的成功或失败的证据，我都在书中列举出来。即使没有直接的公开证据，本书中的建议也有来自一线经验的理由和例子提供支持。一旦意识到传统方法没有带来预期的效果，我们就会更容易认真考虑本书建议的替代方案。
我提供了许多小故事来说明现状问题。它们的灵感来自于真实案例，但隐去了公司名称、人名和其他细节。如有雷同，纯属巧合。它们不是完整的故事，也没有最终结论。然而，故事之后的章节提供了处理问题的方法。越是能够将这些情景与自己的经历联系起来，就越会发现本章的其他内容具有启发性。书中提及的很多例子都来自电子商务（网上零售）领域，以便不同背景的读者都能理解。
前面四个章节是阅读本书其他章节的前提。第 8、9、10 章分别讲了项目、财务和人员配置，它们是一个整体。其余各章可以独立阅读。尽管我努力将相关的讨论放在一起，但各章之间仍有许多交叉引用。这也表明这些主题是相互关联的。
鉴于本书涉及的范围很广，我不得不提炼了一些次一级的主题。但我又不想花太多精力去解释这些次级主题。作为补充，我在文中提供了章后注，链接到网上可靠来源的免费解释（不采用离线或付费的来源）。读者可以从本书的配套网站agileorgdesign.com 获取这些链接。
本书适合以下读者阅读和参考：
● 参与组织设计或治理的执行官和其他决策者
● 独立软件开发商和互联网企业的高级管理人员
● 负责 IT、产品管理、工程或软件开发的副总裁、董事或主管
● 与 IT 部门和 IT 业务伙伴对接的业务主管
● 财务控制、财务分析员和投资经理
● 数字化业务的投资者
● 关心高层领导意见的技术人员
● ICT 战略制定者
● IT 治理小组成员
● 流程质量 /SEPG 小组成员、流程顾问和教练
本书服务于面临 IT 和业务敏捷挑战的大中型 IT 组织（50 至数千名 IT 员工）。我所说的 IT 组织，可能直接服务于业务（即软件本身就是业务，例如独立软件开发商），也可能间接服务于业务（例如互联网业务和企业 IT）。也就是说，IT 供应商（IT服务公司）也可以利用本书中的内容更有效地与客户协作。
为什么投资者也会出现在目标读者对象中？组织设计中的问题不会立即在财务报表中显示出来。然而从长远来看，它们有可能是决定商业成败的关键。由于投资周期往往比高管任期更长，所以数字化业务的投资者最好能了解这个话题，并要求高管承担起相应的责任。如果已经实施 IT 敏捷和业务敏捷，本书的内容可能看起来显而易见或者老生常谈。然而，你可能会遇到一些新的角度、观点或技术。也就是说，这绝不是一本入门级的书。它假定读者有一定的软件交付经验，至少要了解 Scrum 或 XP 等敏捷方法以及 DevOps 和持续交付的基本理念。
敏捷领导力：团队成长工具箱(略，参见单书页面)
向上一步：精益敏捷中的增长思维与实践(略，参见单书页面)
价值流动：数字化场景下软件研发效能与业务敏捷的关键(略，参见单书页面)
走出硝烟的精益敏捷：我们如何实施Scrum和Kanban(略，参见单书页面)
SRE实践手册:软件组织如何规模化实施站点可靠性工程(略，参见单书页面)
深入核心的敏捷开发：ThoughtWorks五大关键实践(略，参见单书页面)
斯里拉姆·纳拉扬(Sriram Narayan)
在Thoughtworks先后担任IT管理顾问（为电信、金融服务、能源、零售和互联网行业的客户提供IT敏捷指导）、领导力教练和创新总监。他是Thoughtworks技术顾问委员会的创始成员，该委员会现在负责编撰Thoughtworks的技术雷达。在Thoughtworks产品部门工作的两年时间里，他参与了产品创新和持续交付工具Go的市场宣传。他还有开发人员、开源贡献人员、管理人员、产品负责人、测试员、SOA架构师、培训师和敏捷教练等多个身份。他偶尔也写博客和在大会上发表演讲，可以访问sriramnarayan.com，进一步了解他的著作、演讲和联系信息。
熊 节
中国最早的敏捷实践者之一，引领和参与了敏捷在中国的发展历程，亲自指导多家知名企业实现敏捷及数字化转型，译著代表作品有《重构》和《敏捷中国史话》等。熊节发起并成立了极限编程合作社，致力于帮助中国企业重回敏捷正道。
彼得·柯宁格(Peter Koning)
带领过很多敏捷团队。从莱顿大学计算机科学专业毕业后，他开始担任程序员和团队经理。2005年，他在荷兰和罗马尼亚担任团队经理的第一年，迈出了敏捷Scrum实践的第一步，第一次认识到文化的重要性。随后几年中，他先后担任过Scrum Master、团队经理、敏捷项目经理和部门经理。
王凌宇
敏捷创新践行者，企业级敏捷变革推动者。组织敏捷变革周期模型提出者。在大型软件公司和互联网上市公司推行企业级敏捷变革取得成效。代表译著有畅销书《敏捷软件开发：用户故事实战》。在TiD质量竞争力大会和敏捷之旅等业界会议担任演讲嘉宾。
尤尔根·阿珀罗( Jurgen Appelo)
作家、演讲者和培训师，全球有400名授权培训师通过他的管理研讨会来帮助创意型组织在21世纪得以生存和发展。他是初创公司Agility Melly的合伙人。他是畅销书《幸福领导力》和《管理3.0:培养和提升敏捷领导力》的作者。
杨志昂
男生名女生的命，理工脑文艺心，当过程序媛，做过管理者。时而理性，时而感性。可严密论证，可天马行空，个性既矛盾又综合。好学好问，门门懂样样求精的万精油型人才。
周子衿
主修商业分析,精通SAS和R语言，奉行深思慎行的原则，主要兴趣方向为通过技术途径来探寻商业价值与人文精神的平衡，对日语、古希腊神话、莎士比亚戏剧和音乐史有一定的研究。
米克·科斯腾（Mik Kersten）
科斯腾博士致力于通过新的工具和框架来实现软件价值流网络，帮助业务与开发之间的沟通，实现从项目到产品的思维和实践转型。同时，他也是开源项目Eclipse Mylyn的创始人和领导者。写过超过100万行开源代码，先后有7个成功的开源和商业产品上市。基于博士期间对开发工具与敏捷、DevOps集成的研究成果，他创办了Tasktop。
张乐
腾讯DevOps与研发效能资深技术专家。DevOps运动国内早期布道者与推动者。长期在一线互联网大厂负责研发效能提升、研发效能度量体系建设、敏捷与DevOps实践落地以及DevOps工具平台研发工作。多部DevOps及研发效能领域著作的作/译者。
姚冬
华为云应用平台部首席技术架构师，IDCF及中国DevOps社区发起人。代表作品有《敏捷无敌之DevOps时代》《DevOps业务视角》以及《运维困境及DevOps解决之道》等。
李淳
资深敏捷教练和创新专家，现就职于光大科技，担任DevOps产品的业务带头人和总架构师。从业十五年，长期深耕于过程改进、软件设计、体验设计、需求侧创新等理论的研究和落地实践。
吴非
TOGAF认证架构师，专注于企业架构研究与实践、产品研发、敏捷DevOps转型和HR数字化转型等领域。腾讯云、华为云和阿里云最有价值专家（MVP），SAFe和DevOps领域多部重点著作的著（译）者。
亨里克克里伯格（Henrik Kniberg）
作为一名IT从业人员，他热爱调试、重构和优化。同时，也更爱即兴表演。
他曾经担任三家瑞典IT公司的CTO，帮助很多客户改进过流程。作为精益敏捷社区的活跃人士，他和Scrum联合创始人苏瑟兰、精益专家波彭迪克以及看板创始人安德森过从甚密。在国际性会议中，他也曾多次获得最佳讲师奖。亨里克在东京长大，目前全家居住在斯德哥尔摩。他热爱音乐和作曲，是当地乐队的贝司手和键盘手。
马蒂斯斯加林（Mattias Skarin）
看板的早期实践者，精益教练，主要帮助软件公司顺利实施精益和敏捷。
他擅长从开发到管理各个层面的实践，曾经帮助一家游戏开发公司的开发部门把开发周期从24个月缩减到4个月，使其重新赢得了公司的信任。
他拥有10年核心业务系统开发经验，先后创建过两家公司。他拥有质量管理硕士学位。
李剑
（凉粉小刀） 全栈程序员，2004年参加工作至今，目前专注于移动开发领域。曾任ThoughtWorks高级咨询师和InfoQ首席编辑。出版的作品恰好可以凑够朋友圈九宫格，算是为国内敏捷社区的发展做了一些微不足道的贡献。
弗拉迪斯拉夫·乌基斯博士是西门子医疗Teamplay云平台的研发主管及SRE负责人。作为软件开发负责人，他先后推动了组织内部的持续交付、SRE和DevOps转型，参与了架构、部署、测试、运维和文化相关工作以及规模化实施新的工作流程。
乌基斯博士在德国埃尔朗根-纽伦堡大学获得计算机科学学士学位，后来在英国曼彻斯特大学获得硕士学位。在他的职业生涯中，先后从事软件架构、企业架构、创新管理、私有云和公有云计算、团队管理、工程管理、投资组合管理、合作伙伴管理以及数字化转型过程等工作。
肖然，ThoughtWorks创新总监，数字化转型专家，DDD China及China Agile Coach创始人，致力于推动敏捷精益的工作方式，持续探索更好的思维和协作方法，帮助更多的人迎接数字化时代的挑战。
张凯峰，ThoughtWorks首席咨询师，ThoughWorks洞见主编，InfoQ中文站知名编辑，2016、2017、2018、2019 ThoughtWorks技术雷达峰会出品人，QCon Beijing 2010、2012、2016、2017、2018专题出品人，热衷参与技术社区与技术传播，跨界于程序员和编辑两个世界。
敏捷组织设计：面向数字化转型和持续交付的组织重构
详细目录
第 1 章 背景 1
1.1 焦点 3
1.2 业务、IT 以及影子 IT 4
1.3 业务 -IT 的效能 5
1.4 数字化转型 8
1.5 双模 IT 及双操作系统 11
1.6 涵盖角度 12
1.7 小结 13
第 2 章 敏捷信条 15
2.1 理解敏捷宣言 16
2.1.1 第一个例子 16
2.1.2 第二个例子 17
2.2 持续交付与 DevOps 17
2.3 敏捷文化 19
2.4 常见主题 20
2.4.1 快速失败 20
2.4.2 迭代优于增量 21
2.4.3 价值流优化 23
2.4.4 信息辐射器 24
2.5 敏捷已死 24
2.6 小结 26
第 3 章 核心主题 29
3.1 重新审视软件开发 30
3.1.1 源代码和二进制包不是产品 31
3.1.2 产品是用户或客户使用的东西 31
3.1.3 软件开发是设计过程 32
3.2 治理的目的是追求价值而非可预测性 34
3.3 组织的目的是响应变化而非优化成本效益 35
3.4 设计的目的是激发内在驱动力和即兴协作 39
3.4.1 自主 40
3.4.2 专精 40
3.4.3 目的 40
3.4.4 即兴协作 41
3.4.5 一种有机的方法 41
3.5 小结 41
第 4 章 上层建筑 43
4.1 业务的活动与成果 44
4.1.1 成果导向赋能自主 46
4.1.2 成果的责任人 47
4.1.3 成果的设计 48
4.2 中心化与去中心化 49
4.3 竖井 50
4.3.1 业务 -IT 鸿沟 51
4.3.2 IT 组织内的竖井 51
4.3.3 高阶竖井 52
4.4 观点小结 54
4.5 行动小结 54
第 5 章 团队设计 57
5.1 提出问题 58
5.2 职能团队 59
5.2.1 高延迟交接导致停滞 60
5.2.2 职能团队的传统诱惑 63
5.2.3 什么情况下可以有职能团队 64
5.2.4 独立的测试、验证、确认 65
5.3 共享服务 66
5.3.1 共享团队会失去目标 66
5.3.2 减少共享团队间的摩擦 67
5.4 跨职能团队 68
5.4.1 DevOps = 跨职能开发团队 IT 运维团队 70
5.4.2 响应式组织 70
5.4.3 利用率 72
5.4.4 T 型人才 72
5.4.5 团队规模 72
5.5 其他领域的跨职能 73
5.5.1 医院 Pod 团队 73
5.5.2 跨职能博物馆布局 74
5.5.3 分任务系统 74
5.6 向跨职能团队迁移 75
5.7 实践社区 77
5.8 维护团队 77
5.9 外包 79
5.10 矩阵：解决还是解散 81
5.10.1 共享服务矩阵 83
5.10.2 专有产能和可替换人员矩阵 83
5.10.3 专有产能和专有人员矩阵 83
5.10.4 单体跨职能产品团队 83
5.10.5 由面向活动的子团队组成的跨职能配置 84
5.10.6 由面向成果的子团队组成的跨职能团队 84
5.11 观点小结 85
5.12 行动小结 86
第 6 章 问责制 89
6.1 权力和层级 90
6.2 运用问责制平衡自主性 91
6.3 责任分配 92
6.3.1 谁来对结果负责 93
6.3.2 责任地图 94
6.4 最小化权力斗争 96
6.4.1 矩阵瘫痪 97
6.4.2 绝对的层级 97
6.4.3 教授 - 企业家 98
6.5 确定成果负责人 100
6.6 迁移 101
6.7 决策问责 102
6.7.1 决策记录 104
6.7.2 工具 105
6.7.3 范围 106
6.7.4 阻力 107
6.8 计划和执行 108
6.8.1 分离的危害 109
6.8.2 森林和树木 111
6.8.3 职责重叠 112
6.8.4 应对阻力 113
6.9 组织债 114
6.10 观点小结 115
6.11 行动小结 115
第 7 章 一致性 117
7.1 阐明通用一致性的战略 118
7.2 IT 与业务对齐 120
7.2.1 MIT 的运营模式 122
7.2.2 步速分层应用策略 123
7.2.3 一致性图 124
7.3 结构一致 126
7.4 让业务发挥作用 126
7.5 观点小结 127
7.6 行动小结 128
第 8 章 项目 129
8.1 计划驱动的软件项目怎么了 130
8.2 为能力而非项目编制预算 131
8.3 以业务能力为中心的 IT 133
8.4 项目商业论证 136
8.4.1 持续交付和分析支持的收益验证 138
8.4.2 弱化金融商业论证 138
8.5 价值驱动型项目 139
8.6 项目经理 140
8.7 治理 141
8.8 变革计划和倡议 142
8.8.1 数字化转型计划 143
8.8.2 限制在制品数量 143
8.9 观点小结 145
8.10 行动小结 145
第 9 章 财务 149
9.1 相关性 150
9.2 成本中心还是利润中心 150
9.3 内部结算 151
9.4 资本支出和运营支出 152
9.4.1 不依赖考勤表的资本支出和运营支出会计 153
9.4.2 活动分类 155
9.5 传统预算 155
9.5.1 目标 156
9.5.2 预算编制 157
9.6 敏捷预算 157
9.6.1 敏捷式滚动预算 158
9.6.2 协作式预算编制 159
9.6.3 企业 IT 的风险投资 160
9.7 观点小结 161
9.8 行动小结 161
第 10 章 人员配置 163
10.1 应对人才危机 164
10.1.1 限制范围和复杂度 165
10.1.2 组织设计助力人才留存 166
10.2 超越项目团队 166
10.2.1 成本 167
10.2.2 挑战 168
10.2.3 其他反对意见 168
10.3 改进人员配置 169
10.3.1 按技能而非角色配置人员 169
10.3.2 职衔 171
10.3.3 剖析技能 172
10.3.4 避免兼职任务 174
10.3.5 团队个性组合 174
10.4 观点小结 175
10.5 行动小结 176
第 11 章 工具 177
11.1 鼓励即兴协作的访问控制 178
11.2 工具链的微妙影响 179
11.2.1 工具访问的竖井 179
11.2.2 工具使用的竖井 181
11.2.3 工具专业化的竖井 182
11.3 技术并非价值中立 183
11.4 工具评估 187
11.5 观点小结 188
11.6 行动小结 188
第 12 章 指标 191
12.1 指标不能说明全部情况 192
12.1.1 能够度量，不能预测 193
12.1.2 速率 193
12.1.3 应对未知的未知 194
12.2 仪表盘促进无知 195
12.3 目标和奖励的问题 196
12.3.1 目标会诱发局部优化 198
12.3.2 目标是一种控制机制 201
12.3.3 目标和奖励侵蚀内在激励因素 201
12.3.4 目标导致博弈 203
12.3.5 古德哈特定律 205
12.3.6 隐含的目标 206
12.3.7 目标隐含着奖励 206
12.4 改革指标体系 207
12.4.1 取消奖励措施 208
12.4.2 逐步放宽目标 209
12.4.3 允许评估 209
12.5 设计更好的指标 212
12.5.1 成果导向的指标优于职能导向的指标 212
12.5.2 聚合的指标优于特定细粒度的指标 213
12.5.3 适应性指标优于预测性指标 213
12.5.4 适应滞后指标 214
12.5.5 补偿指标 214
12.6 对指标改革的异议 215
12.6.1 结合上下文的讨论无法规模化 216
12.6.2 我的团队只对胡萝卜和大棒有反应 216
12.6.3 好的尝试（从节省成本的角度） 216
12.7 迁移 217
12.8 观点小结 217
12.9 行动小结 218
第 13 章 规范 221
13.1 什么是规范 222
13.2 强化规范 223
13.3 合作优于竞争 225
13.4 灵活的政策 227
13.5 一致性高于统一性 228
13.6 请求原谅而非允许 232
13.7 保密调查 233
13.8 平衡理论与实践 234
13.9 观点小结 236
13.10 行动小结 236
第 14 章 沟通 239
14.1 内生动力 240
14.2 人际沟通：常见问题 240
14.2.1 强调等级 240
14.2.2 非言语型微暴力 241
14.2.3 言语型微暴力 243
14.2.4 战争隐喻 245
14.3 人际沟通：缓解措施 246
14.3.1 新员工入职培训 246
14.3.2 脉动图 247
14.4 通过内部沟通提升员工投入度 248
14.4.1 集体会议 249
14.4.2 博客和视频 249
14.4.3 问卷调查 250
14.4.4 线上论坛 251
14.5 书面讨论 252
14.6 可视化工具的使用和误用 255
14.6.1 可视化信息可能会在不经意间误导人 256
14.6.2 文字的首要地位 257
14.6.3 意义胜过美学 258
14.6.4 幻灯片 258
14.6.5 摒弃推销 259
14.7 文档、报告和模板 261
14.8 观点小结 262
14.9 行动小结 263
第 15 章 办公空间 265
15.1 开放式布局 266
15.1.1 如何实现开放式布局 267
15.1.2 墙面空间 267
15.1.3 独处和隐私 268
15.1.4 对开放式布局的批评 269
15.2 人体工程学 270
15.3 远程工作 271
15.4 观点小结 273
15.5 行动小结 273
第 16 章 结语 275
16.1 效果小结 276
16.2 推广顺序 278
16.3 信息辐射器 279
16.4 演练示例 280
16.5 IT 服务 282
16.5.1 合同 284
16.5.2 接触最终用户 284
16.5.3 保证客户参与 285
16.5.4 内在动机 285
16.5.5 未来趋势 287
16.6 全球内部交付中心 287
16.6.1 商业态度 288
16.6.2 文化差异 288
16.6.3 老气横秋的经理 289
16.6.4 CMM 之旅 289
16.6.5 预后 290
16.7 超越 IT 291
词汇表 293
参考文献 297
敏捷领导力：团队成长工具箱(略，参见单书页面)
向上一步：精益敏捷中的增长思维与实践(略，参见单书页面)
价值流动：数字化场景下软件研发效能与业务敏捷的关键(略，参见单书页面)
走出硝烟的精益敏捷：我们如何实施Scrum和Kanban(略，参见单书页面)
SRE实践手册:软件组织如何规模化实施站点可靠性工程(略，参见单书页面)
深入核心的敏捷开发：ThoughtWorks五大关键实践(略，参见单书页面)
书单推荐
