书名：改善对话：突破团队协作障碍
ISBN：978-7-115-59215-6
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 [英] 道格拉斯•斯奎勒尔（Douglas Squirrel）
杰弗里•弗雷德里克（Jeffrey Fredrick）
译 陈连生
责任编辑 郭 媛
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
读者服务：
微信扫码关注【异步社区】微信公众号，回复“e59215”获取本书配套资源以及异步社区15天VIP会员卡，近千本电子书免费畅读。
Copyright © 2020 by Douglas Squirrel and Jeffrey Fredrick.
This edition arranged with C. Fletcher & Company, LLC, through Andrew Nurnberg Associates International Limited.
未经作者书面许可，不得以任何方式复制或抄袭本书内容。
版权所有，侵权必究。
在彼得•德鲁克先生提出了“知识型劳动者”时，就注定了大量的知识型工作只能依赖于团队协作才可完成。但不少团队在尝试提升团队协作度的时候，遇到了诸如成本过高、效果不佳等问题。有没有一种简单、实用、效果又好的方法呢？本书的作者给出了答案——对话。
作者结合多年的真实咨询案例，提出关于对话的“4R法”，带领我们从最初的信任对话开始，走到人人为之负责的当责对话为止，真正做到“用对话突破团队协作障碍”，彻底提高团队检查问题、排除障碍、改善对话的能力。
书中的方法均为作者多年的经验总结，实践性强，落地效果显著，适合一切有志于突破团队协作障碍、构建高绩效团队（不仅仅是 IT团队）的团队成员与管理者阅读。
道格拉斯•斯奎勒尔（Douglas Squirrel）从事编程工作40余年，领导软件团队20余年。他利用对话的力量，在各种规模的技术组织中都创造了巨大的生产力。斯奎勒尔曾在金融技术、电子商务等类型的初创型公司中担任过首席技术官（CTO），为美国和欧洲的60余个组织提供过产品改进方面的咨询，为各种领导者提供过改善对话、对齐商业目标和创造有价值的碰撞方面的培训。他住在英国的弗洛霍尔特（Frogholt）的一座建于1450年的木质结构小屋中。
杰弗里•弗雷德里克（Jeffrey Fredrick）是国际公认的软件开发专家，拥有超过25年的工作经验，涵盖商业与技术两个方面。作为极限编程（XP）和敏捷实践的先行者，杰弗里在美国、欧洲、印度和日本的会议上都进行过发言。通过他在开创性的开源项目CruiseControl上的成果，以及作为持续集成和测试会议（CITCON）的共同组织者，他对软件的开发产生了全球性的影响。杰弗里在硅谷的工作经验包括担任产品管理副总裁、工程研发副总裁以及首席布道师等。他还担任过公司战略、产品管理、营销和互动设计等方面的独立顾问。杰弗里常驻伦敦，目前是Acuris旗下公司TIM Group的常务董事。他还主持伦敦组织学习聚会（London Organisational Learning Meetup），并在CTO Craft担任CTO导师。
“对话”是一件功效强大却又被视而不见的敏捷工具。这本书作为对话这件工具的指导手册，极具实用性，且其中的内容可立马付诸行动。如果你想要在敏捷领域获得成功，那么你务必要阅读这本神奇的手册。
──阿尔贝托·索维亚（Alberto Savoia），谷歌第一任工程总监，
《做对产品》作者
这本书就如何进行关键对话提供了必要的指导，这些关键对话构成了牢固而又灵活的工作关系的基础。这本书同时也提供了一个琳琅满目的工具箱。当对话出现问题时，工具箱中的工具可以帮助你走出困境。本书收录了实用的、真实的案例，如果你对工作中的人际交往感到痛苦不堪或者困惑不已，这本书你不能错过。
──伊丽莎白·亨德里克森（Elisabeth Hendrickson），技术执行官，
《探索吧！深入理解探索式软件测试》作者
一直以来，描述如何在公司氛围中改进流程和产品的图书可谓汗牛充栋。然而我很高兴这本书终于解决了关于人的方面的问题。通过这本实用指南，你将学会如何询问直击心灵深处的问题、如何将你的偏见抛诸脑后，并且你的沟通能力也会得到极大的改善。如果感觉其中的方法
很难付诸实践，那就多试几次吧！
──帕特里克·德布瓦（Patrick Debois），DevOps 之父，DevOpsDays创始者，《DevOps实践指南》合著者
这本书为广大工程师提供方法以提高检查问题、排除障碍、改善对话的能力。诸如“问题分数”（Question Fraction）这种启发方法令人感到惊喜连连，简单易记且入木三分。阅读这本书，将对话技能变为你的“超能力”。
──戈伊科·阿季奇（Gojko Adžić），作家，Neuri Consulting公司合伙人
对任何担任领导职务的人，或者对改善其整体工作氛围感兴趣的人来说，这本书都是不可或缺的。
──安迪·斯基珀（Andy Skipper），CTO Craft首席教练
如果你正在寻找一个实用的框架及其相关技术，以帮助团队消除沟通障碍、改善文化失调的问题，那么你应该阅读这本书。这本书绝非简单的诊断，而是带你领略你需要深刻掌握的5种对话模式，以便将支离破碎的团队文化转变为健康且高绩效的团队文化。
——保罗·乔伊斯（Paul Joyce），Geckoboard创始人、CEO
两位作者一针见血，将那些经过实战检验的技术一一展现于读者面前。对那些深陷在管理复杂度爆炸式增长的环境下，依然希冀可以泰然自若的现代工程领导者而言，这本书必将成为他们的必读之作。
——克里斯·克利菲尔德（Chris Clearfield），
Meltdown: What Plane Crashes, Oil Spills, and Dumb Business Decisions Can Teach Us About How to Succeed at Work and at Home合著者
这是一本非常睿智又极具可读性的书。作者一语道破天机：注重改善对话是将理论转化为组织实质性改进的坦途。
——里奇·科佩尔（Rich Koppel），TIM Group联合创始人、CEO
这是行业中一个不可言说之事，即大多数的“技术问题”本质上是人的问题。在这本书中，两位作者断定：我们可以通过更好的对话方式来解决这些问题，书中的各项建议都以结构化和分类化的方式给出，即使是技术专家也会运用自如。
——乔恩·托佩尔（Jon Topper），The Scale Factory创始人、CEO
改变企业的文化需要信念和技巧。这本书提供的这些方法都可以激发你的勇气，帮助你有效避开成功路上的危险。对任何想要建立协作性组织的CEO而言，这都是一部杰作。
——布伦特·德莱希（Brent Delehey），组织重建专家[1]，CEO
这本书是一本非常实用的指南，教你如何读懂别人真实的想法，并让他们可以在安全的氛围下坦露自身的恐惧。
——丽贝卡·威廉斯（Rebecca Williams），QA Chef软件工程师
[1] 原文是turnaround specialist，意为在组织遇到风险或者表现不如预期时而聘用的临时专家，帮助企业实现运营、战略和组织的转型工作。——译者注
《敏捷软件开发宣言》已经伴随我们走过了21个年头，在这21年里，我们见证了众多框架、工具、技术的诞生，也看到了这些新生事物在为我们实施敏捷、改善团队方面做出了巨大的贡献，也让我们的团队发生了翻天覆地的变化。
但无论怎么变化，“个体和互动 高于 流程和工具”依然是所有敏捷人心中最高的宗旨，也是我们在帮助团队走向成熟、帮助企业走向成功时，必须要坚守的核心守则。
然而要做好这一点并不容易。这其中缘由显而易见——“个体和互动”的范围太广了，广到它充斥在我们日常工作、生活的每个场景中。想要得心应手地应对这些场景，需要极高的技术和情商，否则你将随时面临各种不利境地。可以毫不夸张地说，只要你还属于这个社会，“个体和互动”就永远会有一席之地。此时，能否使用好“对话”这项充满魔力的工具，就成了能否真正理解并应用“个体和互动”的核心焦点。
对话不容易——对话不是把话说完就行了，它需要在准确理解对方意图的同时，在不造成双方压力的情况下，准确无误地将自己的观点附加上去并让对方理解，然后再开始新一轮的“理解—反馈—理解—反馈”。在这个过程中，但凡有一个环节没有做好，整个对话的过程就会悉数崩塌，更妄论通过对话最终实现协作的目的。
幸运的是，我们有这本书。书中，两位作者将自己过去几十年的经验总结成能用、实用、好用的4R法，让我们可以通过刻意的练习来提升我们的对话技术，从而以对话为切入点，改善团队关系，提升团队效率，甚至据此帮助组织取得竞争上的优势，在VUCA环境中持续“笑傲江湖”。同时，作者也希望我们保持好奇和脆弱，接受恐惧，建立信任，放弃对原因的控制，并做出有意义的承诺，所有这些都是企业健康的当责文化的必要前提。作者甚至将他们如何使用4R法来应对团队协作障碍并取得成功的经验毫无保留地贡献出来，让我们可以站在巨人肩膀上，把对话变成我们的“超能力”，从而在各个不同场景中勇往直前，进而无往不利。
在我第一次阅读这本书时，就被书中的各种技术、工具所吸引。其实早在着手翻译之前，我就已经将其应用到我的日常工作中，并取得了不错的效果。在将这本书中的技术应用到团队后，我能明显感觉到团队的沟通效率、氛围、交付能力等方面都有了一定的提升。团队给我的直接反馈是“沟通容易多了，误解变得少了，干活变得轻松了”。因此我有信心将这本书推荐给每一个人。
这本书可以翻译为中文，首先要感谢许峰老师，如果没有您向我推荐这本书，我不敢想象我将错失多么优秀的一本书；其次我要感谢第五空间学习中心的朱宏强老师，如果没有您当年的教导，让我有信心在教练这条路走下去，今天的我也许依然活得浑浑噩噩；当然也不能忘记王小刚老师，如果不是您的鼓励，慵懒的我也不会鼓起勇气翻译这本书；最后要感谢人民邮电出版社的郭媛编辑，感谢您对我的帮助和支持，指出了我在文字使用、语言表达上的种种错误，没有您，这本书阅读起来必会味如嚼蜡。
虽然我很想如作者所说的那样“继续说，不要停”，但毕竟作者的真知灼见才是这本书的主菜，我的这篇餐前甜点，该为主菜让路了。
陈连生
2022.7.21 于上海
作为组织中的领导者，你对转型提供了充分的支持，组织对此也表示接受。你聘请了咨询顾问，咨询顾问也对团队进行了培训，所有流程也都已就位。然而转型成果却迟迟不见踪影。原因何在？
作为一名团队成员——无论你是工程师、产品负责人、Scrum Master、系统管理员、技术负责人、测试人员，还是任何其他角色——你在培训、日常工作中使用了便利贴，也参加了相关会议，你对上述做法完全认同，并对改进的到来充满了期待。然而，你期待的改进却始终不见踪影。原因何在？
经过了多年的学习，以及若干次的行差踏错，我们开始明白成功的秘诀不仅仅是采用各种实践，还需要进行那些高难度对话，为各种实践的运作孕育出合适的环境。你与你的领导、你的团队之间的关系，正因错误的对话方式而变得岌岌可危。好消息是，你可以开始进行对话改善（conversational transformation），它可以为你奠定你想要进行的任何改进的基础，改善你的对话技术，增进你的人际关系并让你最终大获成功。
我们已经见识过对话的威力。我们已经为100多家不同行业、不同规模的组织提供过咨询服务。让我们感到非常惊奇的是，无论我们的沟通对象是谁——CEO还是初级开发人员，跨国银行总经理还是电商领域运维工程师，产品负责人还是项目经理，设计师还是研发人员——我们总能听到似曾相识的说辞：“为什么他不把事情做得更好？”“她为什么不去改变？”“我做不到。我无能为力。”等等。
不同层级的员工都会因无法改变现状而倍感沮丧，我们合作过的绝大多数组织存在类似的情况。我们对此感同身受，因为我们也曾深陷于此。
因此，我们非常高兴能提供另一种选择：为满足好奇心而开诚布公地对话，并借此展现出巨大能量。
我们多次看到个人、团队和整个组织摆脱了困境，并在他们释放了对话中的“超能力”后看到了超过预期的改进速度：一家儿童图书出版商，它的创作者和销售人员都能够畅所欲言，利用创意、灵感促使销售成功；一家人工智能初创型公司，每个人都参与制订战略，从而极大地提升用户满意度；一家金融服务公司在对其失败的案例做了毫不留情的剖析之后，其系统稳定性得到了有效保证。
当你认识到对话不仅仅是说话，而是一种充满技术的活动时，伟大的成果就会随之而来。对话的内涵远超你能看到和听到的：对话不仅包含那些被大声说出来的事物，还包含隐藏在我们说出来和没说出来的话语背后的思想和情感。
当我们驾轻就熟地掌握了对话的技术之后，我们就能更加敏锐地意识到自己的想法和感受，以及我们这些想法和感受的本源。于是我们变得更加善于与人分享这些信息。我们也越来越意识到自己没有读心术，我们其实无法预判对话伙伴会与我们分享哪些信息，于是我们在提问和倾听方面也就做得更加优秀。这些技能都是非常基本的操作，所以也就非常容易被忽略。当我们在这些方面做到优秀时，我们的对话才会变得更加富有成效，我们的组织文化才会变得更加和谐。
现在，论述如何诊断文化问题的图书在市面上比比皆是，其核心理念就是“鼓励合作”。这些书中提供了大量详尽的故事、实践和详细的案例，也包含不少诊断测试工具和应用工具。然而鲜有图书就如何真正解决这些问题给出卓有成效的做法，比如怎样做出改变，以及在你陷入困境时的对策。
比如帕特里克·兰西奥尼（Patrick Lencioni）在他的《团队协作的五大障碍》一书中就Decision Tech公司的兴衰做了详细的描述。通过这本书，兰西奥尼开发出了一种功能障碍的层级理论：忽视结果源于逃避责任，逃避责任的罪魁祸首又是缺乏承诺，并最终深挖至对冲突的恐惧和信任的缺失[1]。兰西奥尼的功能障碍模型对我们非常有帮助，并且本书中的4种对话模式（你将在后续内容中学到这些对话模式）就参考于此。然而，兰西奥尼几乎没有给出任何可用的建议，让你在发现功能障碍时就可以将其消除。
他说，为了建立信任，你可以在下述的5件事情中择一而做：分享你的过去、讨论你的团队成员的最重要的优势与劣势、提供反馈、进行人格类型分析，或者做一些团队拓展活动[2]。虽然这些做法可能会使你的团队成员变得亲密无间，但兰西奥尼并没有提供任何讨论或者证据来证明这些行为的效果，甚至没有给出当上述方法失败后的任何其他的备选方案。
兰西奥尼并非唯一提出问题却不给出解决方案的人。商业宝典、数字化转型指南、敏捷手册等皆是如此。它们帮你指出组织中存在的问题，却从不给出解决方案。其结果就是，我们看到无数公司在其内部都实施了正确的实践，却无法取得应得的成果。究其原因均在于他们没有改变文化氛围，而正确的文化氛围恰恰是那些实践得以施展的必要因素。
通过对本书以及书中提及的对话方法的学习，你和你的团队不仅可以诊断出组织的文化问题，还可以解决那些问题。我们已经看到，在那些内容有些难以启齿的对话中，如果始终保持透明和好奇的心态，确实有助于在团队中建立持久的信任，减少彼此之间的防备，从而做出其他关键改进。解释为何这些方法有效以及如何做也是很容易的，这就是本书将为你呈现的内容。
如果你有兴趣，可以开发出一些技能，使你能够接受开诚布公、单刀直入的沟通方式，从而创造一个让团队蓬勃发展的环境。培养这些技能绝非易事。用我们的朋友马克·科尔曼（Mark Coleman）的话来说就是，这将需要你在每个阶段都做些“让人感到步履维艰，甚至于气急败坏的工作”[3]。你将不得不直面自己对痛苦话题的恐惧，并且你将不止一次地希望能够聘请一位顾问，或者美化你的燃尽图，又或者增加些许监控，而不是进行另一场颇具挑战性的讨论。但是我们向你保证，相比较于让每一位成员都掌握的“5种对话”技能，没有哪件事情的优先级会比它更高。对这些成员而言，永无止尽地追求卓越是一种习惯和乐趣。
我们期待你加入我们的行列，让我们来共同学习那些促使你走向成功的对话技能，并且进一步开拓以及实践这些技能。
继续说，不要停
杰弗里（Jeffrey）、斯奎勒尔（Squirrel）
[1] Lencioni, The Five Dysfunctions of a Team: A Leadership Fable, “Exhibition”.
[2] Lencioni, The Five Dysfunctions of a Team: A Leadership Fable, “Understanding and Overcoming the Five Dysfunctions”.
[3] Coleman, “A Re-Imaging of the Term”.
我们将本书正文分成了两个部分：第一部分描述一些思想和理论，它们将是我们在第二部分介绍的对话工具的基础。
第1章有点儿像软件开发的历史。如果你想要直截了当地看到本书将要介绍的技术，你可以跳过本章。但是如果你对敏捷、精益和DevOps的源头感到好奇，那么本章就是为你准备的。我们将深入探讨在过去约20年中软件行业的巨大变革，回顾我们一路走来所经历过的风风雨雨。
在20世纪90年代，大规模生产模式为“软件工厂”提供了知识模型。正如工厂中的工人被期望成可互相替换的、被束缚在装配流水线上的单元一样，软件专业人员也被期望成在文档驱动的软件开发模式下可互相替换的单元。实践证明这种模式会带来灾难性的后果，随后一系列以人为本的方法论，如雨后春笋一般带动了整个软件组织的转型，这其中包括敏捷、精益和DevOps。
然而充满讽刺意味的是，虽然这些变革的实施随处可见，但人们常常忽略了以人为本的核心，而官僚主义对流程和实践的关注也导致组织深陷形式主义的事件之中[4]。为了取得真正的成效，组织需要利用对话中所呈现的人的力量，通过困难重重但卓有成效的对话来克服大家对这些方法的认知偏见。
第2章提供我们方法的核心技术：4R法为我们提供从对话中学习的步骤，而“双栏对话分析法”（two-column conversational analysis）除了提供给我们一个贯穿全书的记录对话的格式，还提供给我们从对话中学习的方法。我们建议在继续学习本书之前，至少阅读上述两个核心技术所在的部分，以及“分析对话”这一节的内容。
第2章开篇明义，你已经知道要前往的目的地。“信奉理论”[5]已经表明，最好的决策需要各方的合作、透明以及好奇心。继知名社会学家克里斯·阿吉里斯（Chris Argyris）之后，我们也将向你传达相同的观点。不幸的是，你的“使用理论”，也就是你在对话中的实际行为，却与信奉理论背道而驰。因此，我们将向你展示一种名为“4R法”的方法，这种方法可以让任何个人和团队在处理对话中的高难度话题时提升技巧，还将帮助你从对话中学习，并为下一次对话做好准备。
在第二部分即第3章到第7章中，我们将提炼的经验、教训和错误总结成5种对话的“指导手册”。请注意，这5种对话是对所有高绩效团队共有的5种关键特质的至关重要的讨论，而非仅仅针对软件团队。
5种对话的说明如下。
1．信任对话（the trust conversation）：我们坚信，与我们一起工作的人，无论是在团队内部还是团队外部，都与我们拥有一样的目标和价值观。
2．恐惧对话（the fear conversation）：我们开诚布公地讨论团队及其环境中的问题，并勇敢地克服这些障碍。
3．动机对话（the why conversation）：我们共享同一个激励我们前进的、明确的目标。
4．承诺对话（the commitment conversation）：我们定期且切实地宣布我们将要做什么，以及何时开始做。
5．当责对话（the accountability conversation）：我们向所有干系人传达我们的意图，并公开解释如何印证我们的行事结果与承诺是否存在相悖之处[6]。
这5种对话所涉及的特质为团队提供了充分运用当下流行的、以人为本的实践所需的一切。有了它们，就可以达成精英级的交付速度，可以无所畏惧地进行动态调整，并致力于向真正的客户展示能解决他们的问题的可工作软件。没有这些特质的加持，进度在站会中会被隐藏而不是被分享，估算变为徒劳无益的实践，团队目标埋没在工单中，挫折感弥漫于团队。
从信任对话开始，再到分别解决恐惧、动机、承诺和当责的对话，我们将循序渐进地告诉你如何在团队中改进这些关键特质。无论你是一名初级开发者，还是一名高级管理人员，这些方法都可以为你所用。我们也会向你解释，这些改进将如何直接转化为敏捷、精益和DevOps实践的改进结果。我们将以每个主题中的实际对话为例来展示这些方法在现实中的运作。
第3章到第7章均以类似如下的结构展开论述。
1．动机（motivational）部分，解释本章将要论述的对话的重要性。
2．故事部分介绍故事主人公在此类对话中面临哪些问题。
3．一至数个准备知识（preparation）部分向你传授本章对话中要使用的方法。
4．说明部分描述一种推进本章对话的方式。
5．在故事（续）部分，我们的主人公从对话中吸取教训，收到成效。
6．几个对话案例演示本章对话的一些变体。
7．案例学习将会讲述一个篇幅较长的故事，说明本章对话如何帮助组织改进。
8．结论时间部分总结本章主要内容，并告诉读者不同的角色如何使用本章提及的对话。
阅读本书只是开始。在学习如何处理每一个关键对话之后，你就可以践行所学的内容了。我们坚信你的努力会得到巨大的回报。当你改善了你的对话，你将会改变你所处环境的文化。
[4] 原文是cultureless rituals，作者想表达的是一种无视文化、单纯执行特定事件的行为。─译者注
[5] 该理论由克里斯·阿吉里斯提出，原文是espoused theory。后文中说的“使用理论”也由他提出，原文为theory in use。——译者注
[6] ①这5种对话中有4种受到了兰西奥尼的《团队协作的五大障碍》②的启发，第5种对话受到了西蒙·斯涅克（Simon Sinek）的Start with Why: How Great Leaders Inspire Everyone to Take Action③一书的启发。我们在每种对话中都加入了我们自己的经验和方法，也对两位作者给我们的启发表达最诚挚的感激。
② Lencioni, The Five Dysfunctions of a Team: A Leadership Fable.
③ Sinek, Start with Why: How Great Leaders Inspire Everyone to Take Action.
Perl开发者几乎都知道一个非常吸引人的首字母缩写词TIMTOWTDI，也就是“有多种方法可以做到这一点”（There is more than one way to do it）。这也是我们的信条。如同你将在本书中看到的，只要你以适当的方式应用这5种对话，我们是不会预先规定你应该使用哪种对话进行实践的。诸如“你的迭代应该多长”“你是否需要站会”“计划扑克应该使用哪种颜色”此类问题的答案固然重要，但我们认为“授人以鱼不如授人以渔”，知道如何获得这些答案更为重要。基于相同的原因，我们也尝试以此风格编写本书，以便于你可以根据自己的学习风格、需要或者心情，以不同的方式来使用它。
下面是一些我们建议的阅读本书的方式。但别忘了TIMTOWTDI，你完全可以根据你的喜好来阅读本书。
1．顺序阅读。如果你习惯碰到一个概念就一窥究竟，这种阅读方式正符合你的要求：从第一页开始，到最后一页结束。我们尝试在使用任何新的概念或者技术之前，就对其进行定义和说明，并尽可能避免引用后面章节才出现的内容。因此如果你在第3章掌握了“基于确认的沟通”（test-driven development for people），那么当这个概念出现在后面的“动机对话”一章时，你将不会有任何阅读障碍。每一章的内容都会按照你喜欢的逻辑顺序展开：首先是本章谈及对话的原因，其次是使用该对话涉及的相关技术，接下来才是对话本身，最后是若干示例。你可以通过4R法完成每章结尾的对话案例和你自己的案例，从而巩固你的学习成果。如果可以的话，你可以邀请一至多位朋友参与到此循序渐进的学习过程中。
2．选择性阅读。“不要用故事来迷惑我，快点儿告诉我能用到的方法。”如果这是你的想法，则可以从每章的“准备知识”部分开始阅读，我们将解释那些你可以立即使用的技巧以改善你的对话，进而提升你的团队绩效。接着请阅读主要对话（main conversation）的解释，一直到对话案例部分。在主要对话的解释部分中，我们会将各类技巧汇聚为一个整体。而在对话案例中，我们对实际生活中的对话进行了说明，并且你可以从中摘抄出一些警句、习语以及可用的方法。如果你选择了这种阅读方式，我们建议你每周阅读不要超过一个方法，并且在当周的日常对话中刻意对该方法进行练习。在每天结束时，统计一下你能够应用每种方法的频率，然后选择一个对话并用4R法对其进行分析。这种方法看似缓慢，实则稳健。如果能坚持这种反思性的练习，你将快速拥有各项技能。
3．社交型阅读。如同我们在“总结”中所描述的，对这些技能感兴趣的其他人，将会成为你学习这些材料的莫大助力。认知偏差加剧了这些对话的困难程度，也让我们对自身的错误“当局者迷”，但其他人却“旁观者清”。如果你有幸拥有这样一个学习小组，我们建议小组成员一起，使用前文所述的选择性阅读方式进行学习。每周学习内容不要超过一章，记录并分享你应用该章所提及的方法的频率，然后在一次小组会议中讨论并分析你的某个对话。与他人进行角色扮演和角色转换的做法将有助于对自己的表现建立信心，向其他人提供反馈的做法将有助于在自己的对话中发现改进的契机。
无论你使用哪种方式来阅读本书，须知“纸上得来终觉浅，绝知此事要躬行”。
本书建立在许多对话的基础上，有些是快乐的，有些是痛苦的，但它们都是学习的源泉。以下的这些人，他们与我们的对话帮助我们成长和学习至今，我们对他们非常感激。
本杰明·米切尔（Benjamin Mitchell）向我们介绍了克里斯·阿吉里斯（Chris Argryis）的著作，并耐心地与我们一起学习对话分析等技术。瓦沙姆·塔杰（Waseem Taj）、安迪·帕克（Andy Parker）、杰米·米尔（Jamie Mill）和莉萨·米勒（Lisa Miller）与我们一起学习如何分析对话并摆脱对高难度互动的恐惧。TIM Group的创始人里奇·科佩尔（Rich Koppel）和科林·伯绍德（Colin Berthoud）以及与我们一起工作的许多员工（尤其是与杰弗里一起工作的员工），尝试在透明度和好奇心的基础上发展一个学习型组织。史蒂夫·弗里曼（Steve Freeman）鼓励我们讲述TIM Group转型的故事（本书没有讲述这个故事，但分享了他们转型背后的对话）。
我们的 CTO辅导小组（CTO mentoring circles）和伦敦组织学习聚会的参与者，是本书许多概念的“试验田”。
克里斯·阿吉里斯和唐纳德·舍恩（Donald Schön），他们的理论支撑了本书大部分的内容。还有其他提出想法的人，包括来自Action Design的菲利普·麦克阿瑟（Philip McArthur）、罗伯特·帕特南（Robert Putnam）和黛安娜·麦克莱恩·史密斯（Diana McLain Smith），以及罗杰·施瓦茨（Roger Schwarz），他们的“8种行为”理论为我们的早期对话提供了极大的帮助。
帕特里克·兰西奥尼（Patrick Lencioni），他的层次化功能障碍（model of hierarchical dysfunctions）模型为我们的对话提供了参考。埃米·埃德蒙森（Amy Edmondson），他将“心理安全”引入了我们的词汇中。西蒙·斯涅克（Simon Sinek），他解释了“动机”的价值。斯蒂芬·邦盖（Stephen Bungay），他展示了简报与回传简报的价值。布勒内·布朗（Brené Brown），在他的帮助下，我们的故事才可能被写出来。戴维·伯恩斯博士（Dr. David Burns），他帮助我们理解对话的分形属性，这让我们创造了自己的人际关系现实。
阿利斯泰尔·科伯恩（Alistair Cockburn）、肯特·贝克（Kent Beck）以及早期敏捷软件开发社区的其他人，早在我们两个人还受困于软件工厂时，他们就率先提出了“人际关系大过天”的激进观点。玛丽·波彭代克（Mary Poppendieck）、汤姆·波彭代克（Tom Poppendieck）、埃里克·里斯（Eric Ries）等人，帮助将精益思想引入了软件世界。帕特里克·德布瓦（Patrick Debois）、约翰·阿尔斯帕（John Allspaw）和保罗·哈蒙德（Paul Hammond），他们打通了开发与运维之间的“职能墙”，并确保DevOps关乎文化而不仅仅是工具。
Geckoboard［包括保罗·乔伊斯（Paul Joyce）和利奥·卡萨拉尼（Leo Cassarani）］、Unmade Ltd.和Arachnys，他们中的每个人都友善地允许我们将他们与我们的工作细节加入本书。
安娜·希普曼（Anna Shipman），她富有洞察力的博文成了我们的研究案例。
Sofar Sounds，他们友善地允许我们引用一个关于他们的故事。
塞尔吉乌斯·布莱亚（Sergiusz Bleja），他允许我们将与他一起创建的案例研究加入本书。
比利时联邦养老金服务局的蒂埃里·德·波夫（Thierry de Pauw）和汤姆·扬斯（Tom Jans），他们友善地允许我们将他们的一个项目的细节作为案例研究。
伊丽莎白·亨德里克森（Elisabeth Hendrickson），她对本书感到非常兴奋，这使得她将我们介绍给IT Revolution公司，并且建议我们将本能反应（twitch）加入我们的分析内容。
马克·科尔曼（Mark Coleman），他在本书写作的关键阶段提供了非常有用的建议，并给我们提供了“高难度的情绪工作”的概念。
埃里克·米尼克（Eric Minick），他的洞察对我们取得成果提供了极大的帮助。
克里斯·马茨（Chris Matts）和西里洛·沃特尔（Cirilo Wortel），他们在本书成形的过程中向我们分享了故事和想法。
伊恩·欧日沃尔德（Ian Ozsvald）给了我们很多无与伦比的建议，并且在本书创作的初期与我们交往甚密。
戈伊科·阿季奇（Gojko Adžić），他向我们分享了许多关于他的出版物和咨询经验的信息，提出了许多建议，他在测试和产品管理方面的方法令人赏心悦目。
保罗·朱利叶斯（Paul Julius），他建议我们创办一场会议，这场会议直接导致杰弗里和斯奎勒尔相遇（当然，还有其他很多人）。这场会议最终被命名为持续集成和测试会议（CITCON）。我们多年来一直向这场会议的与会者承诺，我们会将本书完成并出版。
艾伦·韦斯（Alan Weiss）和杰拉尔德·温伯格（Gerald Weinberg），他们关于出版和推广的著作始终给我们以启发。
劳雷尔·鲁马（Laurel Ruma）和梅利莎·达菲尔德（Melissa Duffield），他们帮助我们将本书最初的想法结构化。
安娜·诺亚克（Anna Noak），她在我们整个提案和写作阶段的耐心反馈，对本书的完成至关重要。还有很多其他的来自IT Revolution出版社的人，他们以各种方式对本书做出了贡献。
我们的播客Troubleshooting Agile的听众，他们针对我们的很多想法提供了故事、建议和意见；米歇尔·崔（Michelle Choi）和劳拉·斯塔克（Laura Stack），他们一直在保障我们的播客持续运行。
感谢那些在过去20多年中，接受我们辅导，并让我们从其身上受益良多的团体和个人。
杰里·舒尔曼（Jerry Shurman）和乔·比勒（Joe Buhler），他们教会斯奎勒尔在智力活动中享受乐趣。
帕特·亚涅斯（Pat Yanez）、罗恩·弗雷德里克（Ron Fredrick）和玛丽莲·弗雷德里克（Marilyn Fredrick），他们为杰弗里提供了尝试解决难题的背景知识。
感谢罗伯特·舒斯勒（Robert Schuessler）敏锐的观察和迅捷的反馈。
最后，我们的家人，安德烈亚斯（Andreas）、安东（Anton）、埃利安娜（Eliana）、埃米琳（Emeline）、利安娜（Leanne）、莉萨（Lisa）和斯塔尔（Star），他们的耐心受到了考验，感谢他们从未停止对我们的信任，他们的支持是无价的。
本书由异步社区出品，社区（https://www.epubit.com）可为读者提供相关资源和后续服务。
您还可以扫码右侧二维码， 关注【异步社区】微信公众号，回复“e59215”直接获取,同时可以获得异步社区15天VIP会员卡，近千本电子书免费畅读。
作者、译者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎读者将发现的问题反馈给我们，帮助我们提升图书的质量。
当读者发现错误时，请登录异步社区，按书名搜索，进入本书页面（见下图），单击“提交勘误”，输入错误信息后，单击“提交”按钮即可。本书的作者、译者和编辑会对读者提交的错误信息进行审核，确认并接受后，读者将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。
扫描右侧的二维码，读者将会在异步社区微信公众号中看到本书信息及相关的服务提示。
我们的联系邮箱是contact@epubit.com.cn。
如果读者对本书有任何疑问或建议，请读者发电子邮件给我们，并请在电子邮件标题中注明书名，以便我们更高效地做出反馈。
如果读者有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发电子邮件给我们；有意出版图书的作者也可以到异步社区在线投稿（直接访问www.epubit.com/contribute即可）。
如果读者所在的学校、培训机构或企业，想批量购买本书或异步社区出版的其他图书，也可以发电子邮件给我们。
如果读者在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请读者将怀疑有侵权行为的链接通过电子邮件发给我们。读者的这一举动是对作者权益的保护，也是我们持续为读者提供有价值的内容的动力之源。
“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT图书和相关学习产品，为作者、译者提供优质出版服务。异步社区创办于2015年8月，提供大量精品IT图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网。
“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社近40年的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的Logo。异步图书的出版领域包括软件开发、大数据、人工智能、测试、前端、网络技术等。
异步社区
微信服务号
● 第1章 逃离软件工厂
● 第2章 改善你的对话
根据The Digital Helix: Transforming Your Organization’s DNA to Thrive in the Digital Age的作者迈克尔·盖尔（Michael Gale）所说，84%的数字化转型都是失败的[1]。为了理解为什么其他16%的转型是成功的，他经过研究发现成功需要：“彻底改变人们对交互、协作和工作的思考方式。如果你不花时间改变人们的行为，不花时间改变文化以及人们如何做决策，所有的一切都将徒劳无功[2]。”
对话，这一最具人性化的能力，是我们所寻求的此类改变的终极答案。人类具有独一无二、强大且灵活的语言能力。为了最大限度地利用这项能力，我们需要学习对话技能，克服我们固有的偏见。这些偏见让我们抗拒合作，抗拒人与人之间的连接。如果我们改善了对话，我们也将会改变文化。
了解我们所处环境的文化，有助于了解我们所需的改变。正如我们在本章中所描述的，我们仍然处于从软件工厂的大规模制造范式中走出来的过程中。这种“文档至上模式”（document-only model）本质上是一种没有对话的沟通模式。伴随着这种软件工程模式的失败，以人为本的模式逐步兴起，例如敏捷、精益和DevOps。但如果依然把重点放在流程和方法上，即使采用了这些新模式，也不过是在较小规模的开发任务上重复软件工厂的某些错误，也就是约翰·卡特勒（John Cutler）所说的“功能工厂”（feature factory）[3]。
[1] Michael Gale, as quoted in Rogers, “Why 84% of Companies Fail”.
[2] Michael Gale, as quoted in Rogers, “Innovation Leaders”.
[3] Cutler, “12 Signs You’re Working in a Feature Factory”.
我们两人都于20世纪90年代在某家中等规模的软件公司开始了彼此的职业生涯[4]，在巨大的台式个人计算机上处理C语言代码，并且各自有数十甚至数百名同事跟我们做同样的工作。我们就像是一部庞大机器中的小小零件。这也没什么好奇怪的，因为在20世纪人们信奉的是泰勒主义哲学，我们所服务的那部机器也不能独善其身。
弗雷德里克·温斯洛·泰勒（Frederick Winslow Taylor）是一名机械工程师，他领导了一场反浪费、反效率低下的专业运动，并成为这一过程中最早的管理顾问之一。在泰勒看来，工人之间工作方法的巨大差异是浪费的核心。他认为，最好的方法就是让每个人都学会正确的方法，然后让工人们毫无偏差地遵循这种方法，除此之外的任何方法都效率低下。那么谁来决定哪条道路才是正确的呢？当然是泰勒这样的专业管理者和咨询师。
泰勒是“科学管理”直言不讳的支持者。他说管理者的职责就是设计和理解最佳的工作方式，然后坚持不懈地将其标准化。在他那本极具影响力的书The Principles of Scientific Management中，泰勒为基于装配线的大规模制造提供了知识基础，低技能的工人在管理层的监督下，一次又一次做同样的简单任务[5]。
泰勒的观念创造了一种非常独特的机器化工作场所文化。工厂被视为一台庞大的机器。管理者是机械工程师，负责设计所有组件的工作方式，并检查它们是否正常工作。工人只不过是可随时替换的零件：他们在允许的误差范围内运作，否则他们就是有缺陷的，并将会被解雇。沟通是自上而下的，且仅限于命令与纠正。除了做被要求的工作之外，其他的东西都不是必要的，包括对话、合作、思考等。
[4] 杰弗里在宝蓝软件（Borland Software）公司，斯奎勒尔在Tenfold公司。这两家公司早已被“巨头”兼并。
[5] Nelson, A Mental Revolution: Scientific Management Since Taylor, 5-11.
在20世纪90年代，我们所从事的软件行业，将泰勒主义从工厂移植到了隔间。咨询师和销售人员向管理者承诺，只要使用了他们的新工具、新流程和新方法，工作就会轻松高效。“软件开发中遇到问题了？错误和延迟让你倍感沮丧？不要怕！我们已经将最佳实践写下来并随时准备为你服务！”管理者可以购买现成的软件系统，并告诉开发人员照做就行。随着工作流经每个定义好的检查点和流程卡点，管理者可以确保在预算范围内准时完成工作。或者，至少，咨询师和销售人员的承诺是这样的。
与机械化的装配线不同，软件行业相对更加轻量级。在这个行业中你将看到，管理者采用或者发明一种逻辑模型来描述单一正确的工作方式，并将其写入带有分步说明和流程图的文档中。这种文档驱动开发方法旨在通过对“最终程序组件运作方式”以及“每个软件工作者将如何实现自身工作”进行设计，并以此来杜绝任何犯错的可能性。设计过程会产生营销需求文档、产品规格说明书、架构文档、实施规格说明书、测试计划等，所有与人有关的活动都被考虑在内。厚厚的手册详尽地规定了每个数据结构的属性、哪种语言结构可以被使用，甚至注释的格式都位列其中。缜密的软件设计出现在设计者的办公桌上，每个数据列都被详细地说明，每个验证规则都被清晰定义，每个页面都被定义到像素级别。
这里有个逻辑要注意。每个人都知道在软件交付给客户之后，修复缺陷的成本将会变得更高。实际上，越早发现缺陷，修复成本就越低。修复设计者的流程图缺陷比修复代码的成本更低，而更新需求规格文档又比改变流程图成本更低。这一无可辩驳的逻辑告诉我们，我们应该在前面花时间把一切都做好，然后机械地实施，以节省下游的时间和金钱。这一切听起来都天经地义且聪明睿智。
然而不幸的是，这种逻辑的实际效果远不如预期。
1994年，Standish在其“恶名昭著”[6]的The CHAOS Report:1994中记录了一系列糟糕的运行情况，该报告涉及的软件项目的失败程度让人触目惊心。与桥梁、飞机、核电站的失败不同，作者说“在计算机行业，失败被掩盖、忽略或者合理化”。因此他们着手确定“项目失败的范围”“导致软件项目失败的主要因素”以及“能减少项目失败的关键因素”。该报告得出结论，在美国，有约31%的软件项目会被取消，这给美国软件公司带来约810亿美元的损失，而仅有16%的项目在既定时间和预算范围内被完成[7]。该报告揭露了泰勒主义方法的失败，以及由此造成的软件危机。
随着危机逐渐无法掩盖，寻找解决方案的人络绎不绝。美国卡内基梅隆大学软件工程研究所的能力成熟度模型（capability maturity model，CMM）就是其中一派的观点。为了帮助美国国防部评估软件承包商，能力成熟度模型加倍强调了文档和流程的重要性。这种方法的拥护者在追求可预测性的过程中，增加了监督和检查力度，还增添了许多规范。他们断言：“在统计方法控制下的软件开发过程将……在成本、进度和质量的预期范围内产生预期的结果[8]。”
其他来自软件行业的人，包括那些脚踏实地的软件从业者以及与他们一同工作的人，从其他地方找到了启发和灵感。作为软件的一线人员，他们身上的“伤痕”表明，理想化、机械化的方法，无论听起来多么合理，都无法解释软件项目成功或者失败的原因。他们不是从第一性原理[9]出发，而是观察在实践中起作用的东西。在试图理解他们的经历时，他们发现答案并不存在于文档之中。它既不是可以购置的工具，也不是对流程机械的应用，而是人。
阿利斯泰尔·科伯恩博士是一位敏锐且善言的软件实践观察者。他在论文“Characterizing People as Non-Linear, First-Order Components in Software Development”中观察到了这一点。标题让作者的观点一目了然。与能力成熟度模型形成鲜明对比的是，他说：“我现在认为过程因素只是次要问题[10]。”他发现项目的成功或失败很大程度上取决于人，并建议我们将改进工作重点放在利用人的特质上[11]。原因详见下文。
1．人是沟通交流的生物，在面对面的、直接的实时提问和回答方面做得最好。
2．随着时间的推移，人们很难表现得始终如一。
3．人充满变数，他们会随着时间和地点的不同而有所变化。
4．人们通常希望成为好公民，即善于环顾四周、主动采取措施、做“任何需要做的事情”以保证项目顺利进行[12]。
这种对于人的观点，与泰勒主义将人看作机械的、可替换的组件截然不同。期望他们像泰勒主义那样工作是无视人性的，是注定要失败的。经验发现，人与人之间的相处方式，以及他们在项目中的沟通方式所涉及的企业文化至关重要。实践者们可以看到，我们应该围绕人而不是流程来设计方法、完成项目。如果我们想要提高成功的机会，我们需要进行正确的对话，构建正确的文化。
[6] 原文为 infamous，但在翻遍了互联网相关消息后，并没有找到任何关于这篇报道的负面评价。结合上下文以及软件工程历史，这里应该是作者以调侃的方式表明The CHAOS Report:1994揭开了之前掩盖在软件行业的遮羞布。——译者注
[7] The Standish Group, The CHAOS Report: 1994, 3.
[8] Humphrey, Characterizing the Software Process: A Maturity Framework, 2.
[9] 原文为first principles，中文译为“第一性原理”，意为回归事物最基本的条件，将其拆分成各要素进行解构、分析，从而找到实现目标最优路径的方法。它是一个最基本的命题或假设，不能被省略或删除，也不能被违反。第一性原理相当于数学中的公理。最早由亚里士多德提出。——译者注
[10] Cockburn, “Characterizing People as Non-Linear, First-Order Components in Software Development”.
[11] Cockburn, “Characterizing People as Non-Linear, First-Order Components in Software Development”.
[12] Cockburn, “Characterizing People as Non-Linear, First-Order Components in Software Development”.
“人是软件方法中的核心”，这一思想引发了一场深远的变革。自世纪之交以来，这场变革重塑了软件开发过程。精益制造颠覆并改变了以前占主导地位的泰勒主义的大规模制造模式。精益制造通过改变工厂文化，在提高生产力和改善质量方面取得了长足的进步。精益制造依赖的不再是被视作可替换的组件的工人，而是一支“技术精湛、积极进取的员工队伍”，一支能够预见问题并设计出解决方案的队伍[13]。
敏捷软件开发、精益软件开发以及DevOps也同样颠覆和改变了软件工厂模式。每种方法都瞄准了软件工厂的不同要素，但其切入点都是“打破非人性化的大规模生产方式”。它们通过打破分工、引入合作来改变文化，以取代业已僵化的流程。
如同我们将要在后续章节中说的那样，上述这些运动的早期支持者都隐含了两个根本的价值观，即保持透明和拥抱好奇，这也使得他们提倡的方法发展出了成功的软件团队中5个关键特质中的部分或全部：高信任度、低恐惧感、清晰的动机、坚定的承诺以及可靠的责任感。而这些价值观所倡导的人际互动、信息流动、消除壁垒以及通力协作等特质，都是软件工厂所不具备的。
每一场成功的运动，最初取得的胜利都是让人惊叹的：早期采纳者报告说他们在产品上市时间、降低缺陷率、更高的团队士气上有了长足的进步。例如精益创业拥护者夸耀道“挑战不可能！每天发布 50次[doing the impossible(releasing to production) fifty times a day]”[14]。不出所料，包括我俩在内的很多人也加入了这股潮流之中，不断尝试新的方法，看看我们是否也可以重现同样的效果。
但问题在于，在敏捷开发、精益软件开发以及DevOps的爆炸式发展过程中，很多后来者依然重蹈覆辙，忽略了人际互动的重要性。这也是我们编写本书的原因。管理者以为他们可以像以前一样，继续保留工厂思维模式，并且只需要向别人发号施令。结果，他们聚焦于表面的、肤浅的过程改造：站会、在制品限制（work-in-progress limit，WIP Limit）、工具选择等。
如果忽略人的因素、没有正确的对话，这些变革都是完全无效的。因此，在我们服务过的数百个组织中，我们已经看到有失望的高管以及沮丧的团队宣称敏捷开发（或者精益软件开发、DevOps）行不通。
总而言之，他们以僵化观点看待以人为本的转型，不理解或者否认人际关系的重要性，然后他们还想知道为什么没有人愿意进行合作、为什么事情没有完成。
相比之下，本书的主题回到了成功所需的基本人际互动。让我们从回顾每一场运动的历史开始，这将使我们做好准备，去了解那项需要掌握的、可以使人们重新参与到流程中的简单技术：对话。
[13] Roos, Womack, and Jones, The Machine That Changed the World: The Story of Lean Production, 52.
[14] Fitz, “Continuous Deployment at IMVU”.
在20世纪90年代末，对软件工厂的反对之声导致了各种替代方法的大量涌现。与之前“文档驱动、重量级软件开发流程”的主流模式相反[15]，各种新方法所倡导的实践在当时看来是“异端邪说”，比如实时设计（just-in-time design）、频繁交付可工作的软件，以及让真正的客户参与到软件开发中等。其中文化变革要求从根本上减少规划活动（planning activity），提倡成员之间的协作互动。相较于软件工厂的主流做法，这些新方法的领导者看起来充满戾气，一心只想制造混乱。然而，在勇于尝试这些新方法的团队中，确有一些取得了惊人成效的故事，比如士气提升、快速交付、超高质量等。
然后在2001年2月，17名知名的“轻量级软件”运动支持者齐聚犹他州雪鸟滑雪场（Snowbird，Utah）。正如詹姆斯·海史密斯（James Highsmith）所记录的，他们是一个多元化的群体，其中包括极限编程（extreme programming，XP）、Scrum、动态系统开发方法（dynamic systems development method，DSDM）、自适应软件开发（adaptive software development，ASD）、水晶方法、特征驱动的开发（feature driven development，FDD）、实用编程（pragmatic programming）等各个方法的创始人[16]。但问题是，他们能找到共同点吗？
事实证明，他们做到了。结果正如马丁·福勒（Martin Fowler）所说，这些方法的共同点是一个“战斗号角”（call to arms），是一个“集结号”（rallying cry）[17]。它就是《敏捷软件开发宣言》[18]！在经历了近20年的风风雨雨后，它仍在全世界范围内被广泛使用着。
敏捷软件开发宣言[19]
我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划
也就是说，尽管右项有其价值，
我们更重视左项的价值[20]。
这17人组成的小组在遵循宣言的前提下，提出了一套经常被忽视的12条配套原则。对追求敏捷性的组织而言，这套原则仍然是一个有用的切入点。
我们遵循以下原则[21]。
我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
业务人员和开发人员必须相互合作，项目中的每一天都不例外。
激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
可工作的软件是进度的首要度量标准。
敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
以简洁为本，它是极力减少不必要工作量的艺术。
最好的架构、需求和设计出自自组织团队。
团队定期地反思如何能提高成效，并依此调整自身的举止表现[22]。
[15] Highsmith, “History: The Agile Manifesto”.
[16] Highsmith, “History: The Agile Manifesto”.
[17] Fowler, “Writing the Agile Manifesto”.
[18] 原文是Agile Manifesto，这里取官方正式名称《敏捷软件开发宣言》。——译者注
[19] 这里的翻译取官网中文翻译，未做修改。——译者注
[20] Beck, et al., “Manifesto for Agile Software Development”.
[21] 原则使用官网中文版，仅对格式进行了调整。——译者注
[22] Beck, et al., “Principles Behind the Agile Manifesto”.
这些原则与前文所说的宣言一起，体现了新方法论“以人为本”的本质。通过列举其中一些原则，我们可以看到，这些通用实践（common practice）为敏捷团队保持透明和拥抱好奇提供了框架。下面给出几个通用实践的示例。
● 业务人员和开发人员必须相互合作，项目中的每一天都不例外：通常体现为简短的每日会议。无论参与者的实际姿势为何，这项活动都被称为站会。这是一个让研发人员公开、透明地分享进度和所遇障碍的机会，并让其根据需要向团队中的其他人员寻求支持。
● 最好的架构、需求和设计出自自组织团队：敏捷团队应该公开协作，讨论各种备选方法之间的利弊权衡，每个成员公开、透明地分享他们的专业判断，并对其他人的判断充满好奇心。这可以在诸如“计划游戏”的实践中得到证实。在计划游戏中，估算是公开的（透明度），每位参与者给出的估算值之间的差异恰恰用来激发对话（好奇心）以发现意见分歧的原因。
● 团队定期地反思如何能提高成效，并依此调整自身的举止表现：敏捷的标志性实践之一就是回顾会，这是一个让团队成员讨论个人与团队经验的机会。回顾活动范围很广，例如在《敏捷回顾：团队从优秀到卓越之道》一书中所描述的那些活动。它们都依赖于团队成员公开、透明地分享其经验的能力和意愿，以及团队成员对其他人的经验的好奇心。
也许由敏捷开发导入的最显著的变化，不只是团队成员彼此之间的联系，还在于敏捷实践者如何拥抱客户。就如同前两条原则所说“我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意”以及“欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化”。这两条原则将透明度和好奇心作为团队与客户之间敏捷开发的核心协议。通过频繁交付软件，敏捷团队为客户提供了一个透明的进度视图，团队对客户下一步看重什么充满好奇，这意味着即使打乱团队原先的计划也在所不惜。
敏捷开发从来都不是一件事情、一系列实践，当然也不是泰勒主义者认为的可以强加于人的“最佳实践”。它提供的是一套价值观和指导方针，借此我们可以构建一个弹性的组织以适应这个日新月异的世界[23]。此处核心在于，敏捷方法要求一种支持协作和学习的文化。这种文化为研发人员创造了互相对话的机会，这种机会在软件工厂中则完全不存在。敏捷的成功为激进思想打开了大门，其带来的影响范围，早已超出其孕育出的软件团队内部范畴。
那么为何我们现在还经常能看到一些以20世纪90年代的方式运作的“功能工厂”，同时他们又自称“敏捷”呢？因为在功能工厂中只能看见工件和过程发生了变化，而思维模式和对话（也就是文化）依然如故。这些团队虽然没有堆积如山的文件和两年期项目计划，但在对上游客户需要一无所知、对下游业务影响不甚了了的情况下，源源不断地规划出需要实现的功能。软件装配流水线已经被“血汗工厂”所取代，每个工人都被分配了计件的工作。虽然工件的形式有所不同——需求以故事或者验收标准的形式提出，而不是使用庞大、僵化的文档；过去放置甘特图的地方可能被替换成燃尽图——然而换汤不换药，开发脱节、合作障碍、无休止的工作交接等现象依然存在，进度迟缓依然令人苦恼不堪，软件依然频繁出错。
[23] 实际上阿利斯泰尔·科伯恩和他的一些同事已经开始指导公司采用一种名为“方法论无关”（methodology-agnostic approach）的方法。这种方法恰恰提供了那些被称为“敏捷之心”的简单指导原则。
2003年，就在雪鸟会议通过《敏捷软件开发宣言》催生敏捷软件开发的两年后，经验丰富的程序员和软件团队负责人，同时也是夫妻的玛丽·波彭代克和汤姆·波彭代克，在他们的书《敏捷软件开发工具：精益开发方法》（Lean Software Development: An Agile Toolkit）中将精益制造的理念带入敏捷圈。
玛丽·波彭代克与汤姆·波彭代克深入研究了丰田生产系统（Toyota production system，TPS）的准时制（just-in-time）、减少浪费（waste-reducing）的制造方法且得到了深刻的见解，并将之移植到软件开发中。
波彭代克夫妇将精益软件的精髓提炼为一套颇具挑战性的原则[24]：
1．消除浪费；
2．增强学习；
3．推迟决策；
4．尽早交付；
5．赋能团队；
6．内置完整性（质量内建）；
7．整体优化。
[24] Poppendieck and Poppendieck, Lean Software Development: An Agile Toolkit, xxv.
波彭代克夫妇强调无处不在的优化、通过频繁交付快速学习，以及系统调优与系统思维。这些主题都与软件工厂不兼容，而且许多都建立在敏捷原则之上。当波彭代克夫妇于2003年写下他们的第一本书时，那些敏捷原则已经在逐步改变当时的状况。
不久，精益思想和实践开始广为传播。精益软件团队的特征如下。
● 和制造业同行一样，使用价值流图定位流程中的低效节点（又被称为muda，日文中的“浪费”）。
● 从最初功能开发到最后客户交付与实施，在全生命周期内寻找并消除流程中的瓶颈。
● 限制在制品。以质量保证（quality assurance，QA）团队为例，他们只接受对 10 个新功能的测试，而不是创建一个他们无法处理的、巨大的工作待办事项列表。
● 流程步骤之间强调拉动而非推动。以程序员为例，如果没有人可以评审其工作，他就会暂停编程工作，而不是创建更多未评审的、无法发布的代码“库存”。
越来越多的公司拥抱敏捷软件原则，越来越多的精益制造理念显示了它们的效用，包括用于管理瓶颈的约束理论（theory of constraints，ToC）和看板方法。看板方法甚至直接取消了轻量级的“冲刺”（sprint）的时间盒（timeboxing，一种固定时长的工作时间），支持直接通过拉动工作的方法来调节工作流。精益软件开发一直致力于“放眼全局”，它已经扩展到了各种规模的组织中，其中包括初创型企业［如埃里克·莱斯（Eric Ries）的《精益创业：新创企业的成长思维》所述］以及跨国公司［如耶兹·亨布尔（Jez Humble）等人合著的《精益企业：高效能组织如何规模化创新》所述］。
乍一看，波彭代克夫妇的原则或者精益实践中，几乎没有明确表示出“人本观点”，即我们需要担心的、引发麻烦的往往是人，难以处置的还是人，人与人之间的沟通很困难。这一点与《敏捷软件开发宣言》有所不同。回看这些原则，我们发现除了第二条（增强学习）和第五条（赋能团队）外，其他的都是关于流程和效率的。我们很容易得出结论，即我们所需要的只是对价值流图的技术分析以及大刀阔斧地消除浪费。很多精益方法的使用者都为此付出了代价。
但是如同波彭代克夫妇在《敏捷软件开发工具：精益开发方法》中所说的：“尊重人性基础，莫过于提供一个环境，让有能力的工人积极参与管理和改进他们所处的工作领域，并能充分利用他们的能力[25]。”波彭代克夫妇这番话，现在听起来更像科伯恩所说的“非线性、最重要的组件”（non-linear, first-order component），也就是人！如果我们继续深入研究，会发现更多与透明度和好奇心这一以人为本的基本价值观的关联：
● 为了消除浪费、内建完整性，并与整个系统配合工作，我们需要使我们在造成低效方面所犯的错误以及整个系统如何工作/不工作保持透明；
● 为了增强学习与快速交付，我们必须对实现目标所需的方案感到好奇，甚至可以同时尝试多种方案（快速学习的经典精益策略）；
● 为了授权团队，我们需要向他们公开表达我们正在努力实现的目标以及他们可以做出贡献的地方，我们还需要激发他们对客户和业务的方方面面的好奇心。
实际上，我们所看到的成功的精益软件团队，在很大程度上依赖于积极、坦诚、持续的沟通，其中包括直接的客户反馈、信息发射源（如构建状态指示器以及大型的、可视化的业务相关图表），甚至丰田风格的安灯系统（Andon light system）（团队成员使用的个人红/绿/黄色指示器，用以广而告知他们的工作遇到了障碍或阻碍）。这些工具和实践以透明度和好奇心为基础，持续改善对话氛围，使其更加富有成效。
与敏捷开发的问题一样，太多的组织在采纳了这些实践的同时，却忽视了这些实践背后的内在精神，最终“画虎不成反类犬”。我们看到一些组织虽然将精益六西格玛绿带证书挂在墙上，但缺乏协作和持续改进的文化的痼疾依旧存在。根据我们的经验，这完全是由高管所导致的──他们认为转型是可以购买的商品，然后又想知道为何价值流图会被抛弃、拉动系统会被闲置。
[25] Poppendieck and Poppendieck, Lean Software Development: An Agile Toolkit, 101.
到了2009年，拓展人性化软件运动边界的时机已经成熟，来自比利时的帕特里克·德布瓦正是“急先锋”。当时帕特里克是一位事业受挫的顾问和项目经理。在接二连三的项目中，他看到了开发人员和系统管理员之间的责任鸿沟严重阻碍进度，对此他非常恼火。尽管很多团队正在消除软件工厂的负面影响，但是在与部署和运行其代码的运维人员进行互动时，缺乏沟通、低信任度和流于表面的对话的老派做法依然大行其道。这些做法带来的效果与其在开发团队中带来的效果如出一辙，即进度缓慢、阻碍了每个人交付正确的可工作软件。很明显，敏捷开发需要向下游扩展，“运维团队需要敏捷起来，而且必须与项目结合在一起”[26]。
帕特里克开始尝试找寻其余对他所谓“敏捷系统管理”（agile system administration）感兴趣的人。起初参与的人很少，甚至在一次会议中，只有两个人出现在该新话题的会场上[27]。不过肯定也有其他人有同样的想法，特别是约翰·阿尔斯帕和保罗·哈蒙德，他们分别是Flickr[28]的运维和工程负责人。他们在名为“每天发布超过10次：Flickr的开发与运维合作”（10+ Deploys per Day: Dev and Ops Cooperation at Flickr）的演讲中，热情地呼吁开发者和运维人员之间的合作与信任。由于该演讲击中了当时研发过程的痛点，因此在敏捷圈快速传播开来[29]。帕特里克观看了他们演讲的直播，兴奋之情溢于言表，此后不久就在比利时的根特市（Ghent）举行了第一次DevOpsDays会议。在强有力的价值观和技术工具的武装下，DevOps运动诞生了。
[26] Debois, “Agile Operations”.
[27] Mezak, “The Origins of DevOps”.
[28] 雅虎（Yahoo）公司的照片分享网站。——译者注
[29] Allspaw and Hammond, “10+ Deploys per Day: Dev and Ops Cooperation at Flickr”.
这里没有DevOps独裁者，这里也没有DevOps自己的雪鸟滑雪场，因此DevOps的原则清单并不像敏捷那样班班可考。但是Flickr演讲是我们所知道的对DevOps目标最清晰的陈述之一，它可以作为一个试金石，用以衡量那些号称专注于DevOps的团队“是否言行如一”。该演讲的后半部分的原则如下（作者已对其稍加编辑，以便读者可更方便地将其编入列表）所示。
DevOps原则
a）不要刻板印象
b）尊重他人的专业知识、意见和责任
c）不要只是说“不”
d）不要隐瞒任何事情
a）相信每个人都在为企业尽最大努力
b）共享运行手册和升级计划
c）提供自助配置工具
a）失败总是会发生
b）培养自己应对失败的能力
c）举行失败应急演练
a）不指责
b）开发人员：记住，无法运行的代码将让人夜不能寐
c）运维人员：对感到痛苦的地方提供建设性的反馈[30]
[30] Allspaw and Hammond, “10+ Deploys per Day: Dev and Ops Cooperation at Flickr”.
注意到了吗？阿尔斯帕和哈蒙德对信任、尊重以及合作的关键要素的阐述是如此的明确。这显然是一场针对人的运动，而不是针对机器的运动。
当然，关键性的DevOps技术和团队实践还是存在的。这些技术和实践如下所示。
● 跨职能团队。开发人员和运维人员在一个团队中协同工作，而不是彼此孤立，将完成的代码从一方交给另一方。
● 减少人为干预。对注重 DevOps 的团队而言，服务器不再是具有独立身份和自定义配置的特殊设备，而是无差别的、完全一致的、可替换的机器，它们可以在任意时间被替换。
● 基础设施即代码（infrastructure as code，IaC）。系统管理员不再需要手动配置服务器，而是通过编写程序（用Puppet、Chef或者Kubernetes等工具提供的专用语言）来设置和测试机器。
● 自动化部署。一旦服务器上线运行，系统管理员和开发人员一同编写更多的代码，从而实现一键部署。部署可以由持续集成工具触发，从而进一步加强研发人员与其工作的连接。
● 共享度量指标。使用DevOps思维模式的团队将让工程师和系统管理员共同关注系统正常运行时间（system uptime）、错误率（error rate）、用户登录（user login）以及更多有关运行健康的指标，并共同解决所有被暴露出的问题。
20世纪80年代，西蒙·特拉瓦利亚（Simon Travaglia）为在线出版物The Register[31]创作了一部讲述系统管理员的漫画。漫画主角（The Bastard Operator from Hell，简称BOFH[32]，同时这也是该漫画的名字）鄙视开发人员和用户，并以无限制地增加他们的痛苦为乐。特拉瓦利亚当然是为了喜剧效果而夸大其词，但他谈及了传统组织中，开发人员和系统管理员之间存在的深深的猜疑和不信任，以及团队之间存在着的不可逾越的鸿沟。
因此，上述DevOps原则和实践对合作的要求如此明确也就不足为奇了：共享你的运行手册，展示你的度量指标，讨论你的失败（透明度），尊重另一方，避免指手画脚，找出你的行为产生的影响（好奇心）。DevOps摆脱了生产流水线思维，让开发人员和系统管理员彼此敞开心扉，共同关注彼此关心的问题而不是相互抨击对方。以人为本的价值观和特征支撑着DevOps运动，至少在它最初的构想中是如此。
但令人困惑的是，最近在一些企业中出现了一种趋势——指定一个独立于开发和运维的特殊团队，即DevOps团队。DevOps的全部意义在于加强不同专家之间的团队协作，而不是产生更多的孤岛。我们甚至看到“DevOps工程师”的招聘广告，他们显然是不同于普通工程师和系统管理员的特殊工种。这是怎么回事？我们相信这是管理中的文字游戏的结果。我们观察到，有些组织不是培养“个体和互动”，而是希望回避重新思考如何运转，并寄希望于通过改造软件工厂来实现其目的。最令人惊讶的是，许多企业已经实现了这个疑窦丛生的目标。
[31] Travaglia, “The Revised, King James Prehistory of BOFH”.
[32] BOFH为西蒙·特拉瓦利亚创造的角色，出现在同名漫画中。漫画描述的是一位系统管理员BOFH利用他的专业知识对抗他的敌人（用计算机问题为难他的人）并操纵他的老板的故事。——译者注
敏捷开发、精益开发和DevOps在改变软件领域方面的成功是不可否认的。那些看似极端的思想现在看来再正常不过。在一天内完成一项功能，或者在一周内开发完一个史诗故事[33]，这种事情无论出现在何种规模的公司里都不再令人惊讶。这正如IBM的项目总监埃里克·米尼克（Eric Minick）的描述：
回顾历史，对我来说最令人注目的是，交付工作实际上变得更好。只需要看看发布周期你就能发现这一点。团队曾经满足于每年一次的发布周期。随着敏捷技术在企业中的应用，他们为每个季度可以发布一次而感到自豪。而如果你现在每个季度发布一次，那么你已经落后于当前平均水平。每月发布一次对现在的企业而言比较正常。几乎每个大企业都有一些云原生团队每天都会发布，甚至每天发布好几次。这些节奏比15～20年前的情况好了一两个数量级。这一点真的很不错。
虽然我们的计划和项目范围发生了很大的变化，但有时候我们会有一种似曾相识的感觉。大型组织往往会被一些敏捷、精益或者DevOps流程所困。这些流程与之前的方法以一种奇怪的实践组合（又被称为“瀑布型Scrum”）在一起，并令人感到不安[34]。我们遇到过的很多小型组织或者初创型企业中，精益、敏捷和DevOps实践比比皆是，但是设计师、开发人员和运维人员却把自己描述为在“功能工厂”中工作，所有的微观管理和破坏自主性的做法与泰勒主义做法别无二致。这就好比将不同名字的小部件重新组装起来形成巨大的软件工厂。这种做法的确能带来一些好处，但这并不是“充满热情、紧密协作的团队合作、出色的客户关系以及有意识的设计思维”，这激励理查德·谢里登（Richard Sheridan）写了一本书Joy, Inc.: How We Built a Workplace People Love[35]。这当中发生了什么？
这个问题答案的一部分源于尼尔斯·普弗莱金（Niels Pflaeging），他在自己的文章“Why We Cannot Learn a Damn Thing from Toyota, or Semco”中回答了这个问题。普弗莱金想知道为何如此多众所周知的、在开创性组织中都能良好运作的实践案例所产生的变化却如此微小。他的见解是，阻碍变革的原因是“缺乏充满魔力的要素[36]，即我们对人性的认知、我们对周围的人的看法，以及什么在驱动他们[37]”。
组织已经接受了敏捷转型所创建的流程和工具，但是泰勒主义的工厂思维模式仍然“阴魂不散”。虽然要写的文档变少了、要读的需求说明也变少了，甚至连强制性的签字也几乎没有了，但上述减少的工作只会被无休止的计划会议和项目管理工具中的工单所替代。这些实践仍然提供了泰勒主义的承诺，即给予管理层所需的洞察力和控制力，因为管理者的角色仍然被定义为确保完成正确的事情。
做这些工作的人呢？还记得软件开发中那些非线性、最重要的组件吗？它们依然是最重要且非线性的。辛西娅·库尔茨（Cynthia Kurtz）和戴维·斯诺登（David Snowden）的Cynefin框架（见1.6节）为我们的讨论提供了一些可用的语言[38]。功能工厂意图将人放入框架中右下角位置，即“简单”象限：“如果我们让所有人都参加计划会议、站会和回顾会，他们就会自然而然地产生合作。”这种将人类物化的合作方法并不适用于人类，人类的本性刚好位于左上角的“复杂”象限。对比仅仅把一群人攒在一起就称之为一个团队，有意识地培养一个极具活力的高效组织需要更多的工作和技巧。
如果我们理解组织中的个人和团队本身就是复杂系统，那么我们应该怎么做？根据Cynefin框架，在复杂的情况下没有绝对正确的答案，适用于复杂象限的做法是“探究-感知-回应”[39]。然而，我们如何在人的身上使用“探究-感知-回应”呢？这就要用到我们所谓的对话，它也是带领我们走出软件工厂的必经之路。
[33] 这里说的是史诗故事Epic，是一种巨大的用户故事。——译者注
[34] West, “Water-Scrum-Fall Is the Reality”.
[35] Sheridan, Joy,Inc.: How We Built a Workplace People Love, 19.
[36] 可以在7.4节中看到关于这些充满神奇魔力的要素。
[37] Pflaeging, “Why We Cannot Learn a Damn Thing from Toyota, or Semco”.
[38] Kurtz and Snowden, “The New Dynamics of Strategy: Sense-Making in a Complex and Complicated World”, 462-483.
[39] Kurtz and Snowden, “The New Dynamics of Strategy: Sense-Making in a Complex and Complicated World”, 469.
Cynefin框架是一个“意义构建框架”，它的目的是产生共同的理解并改善决策（见图1-1）。
图1-1 Cynefin框架
虽然对于Cynefin框架社区有丰富的活动和应用，但该框架给我们上的第一节课是，适当的行为取决于你所在的领域。
● 当所处领域是“简单”（obvious）时（因果已经被充分理解），流程图这类的工具就很有用，因为可能性有限，当前的状态可以决定下一个正确的步骤。
● 当所处领域是“繁杂”（complicated）时（因果关系只有专家知道），我们会碰到难以理解的需求，例如对精密仪器中的意外行为进行故障排除。此时你需要通过自主分析或者聘请专家来开发相关的知识。
● 当所处领域是“复杂”（complex）时（因果只能通过回顾来理解），对于不可预测的部分，如项目过程中不断变化的团队动态，过去在其他环境（其他团队）中的经验已不再是下一步行动的有效指南。相反，在决定如何应对之前，你需要基于多个视角进行实验和研究以了解现存的模式，然后决定如何回应。
● 当所处领域是“混乱”（chaotic）时（因果之间没有任何关系），比如分布式系统中的故障，应该首先采取行动，尝试使情况回归正轨。
作为一个理论体系，Cynefin 框架与软件和人类密切相关。我们构建的软件系统，至少都是繁杂的，并且经常有计划外的复杂应急行为，而构建软件系统的团队本身就是复杂的。Cynefin 框架帮助我们进一步认识到人类本身就是复杂的，不受简单规则的约束。它还为我们提供了良好的语言来描述为什么大规模软件制造方法（由所谓的可以替换的工人来完成简单工作），会造成灾难性的后果。
微信扫码关注【异步社区】微信公众号，回复“e59215”获取本书配套资源以及异步社区15天VIP会员卡，近千本电子书免费畅读。
