6月29日，由阿里云研发协同RDC、阿里云云效和云栖社区联合举办的“首届阿里巴巴研发效能嘉年华”上，阿里巴巴资深专家、敏捷教练洪湖带来“拥抱‘黑天鹅’”的演讲。本文主要从黑天鹅事件开始谈起，接着分析了哪些模式是脆弱的，而后分享了通过案例得出了从变化中获益的启示，最后着重说明了打造敏捷组织的重要性。
随着云计算、大数据、AI智能等前沿科技的发展，传统的研发速度越来越难满足企业快速发展的需求，研发效能也成了继商业模式、技术突破之后的另一核心竞争力。本文主要从黑天鹅事件开始谈起，接着分析了哪些模式是脆弱的，而后分享了通过案例得出了从变化中获益的启示，最后着重说明了打造敏捷组织的重要性。一起来了解下吧：
黑天鹅事件
在发现澳大利亚的黑天鹅之前，欧洲人认为天鹅都是白色的，但这个不可动摇的信念随着第一只黑天鹅的出现而崩溃。人们总是以自己有限的经验和不堪一击的信念来解释不可预测的黑天鹅事件。黑天鹅无法预测，我们应该做的是适应这种不可知的未来。
那么，产品开发中可能会碰到什么样的“黑天鹅事件”？
我们先来看看想做一个成功产品的背后会有什么样的假设呢？
假设1：找到了正确的问题；
假设2：产品被正确定义；
假设3：产品被正确构建；
假设4：做出来的产品可以解决问题；
假设5：有足够多的人愿意买单。
任何一个假设都有可能不成立，在得到最终验证之前，你没法预测假设是否成立。
既然黑天鹅事件不可预测，那就不要天真地试图预测，我们需要适应它们的存在。
怎样适应“黑天鹅”事件呢？《反脆弱》这本书中给我们介绍了两点：降低脆弱性和从变化中获益的能力。弄清楚什么是脆弱的，比预测对其造成伤害的某个事件是否会发生、何时会发生要容易得多。
什么是脆弱的
瀑布开发
在瀑布模式下：
如果产品目标错了，只有产品发布后才能知道目标错了。而目标是在我们掌握知识最少的时候做出的决策；
如果架构出问题了，也就是技术风险，可能要到后期测试时才会暴露，而我们在设计阶段，未写一行代码时就做出了最重要的架构决策；
同样地，还存在集成风险，大家开发的很多模块代码在开始测试时才开始集成在一起；此外还有需求变化、延期等······
总体来看，瀑布开发是很脆弱的，它很难应对黑天鹅事件，一旦发生，我们没办法及时响应变化。
传统项目管理
对于传统项目管理，我们会管理四个变量，范围、时间、成本、质量。大家都说质量很重要，它会影响我们长期的发展，所以质量不能牺牲。然后我们要确定范围，估算什么时候可以交付，以及需要的成本。
在规定的时间、规定的成本里，按照质量的要求，成功的交付了我们达成一致的范围，这就是一个成功的项目。
那么，如果这时发生了“黑天鹅”事件，我们会怎么办呢？
我们会采取一些秘密武器：例如Copy & Paste，可以快速的把功能实现出来，此外还可以减少测试、没有自动化、不重构和去掉同行评审等。
之所以会采取以上的一些方法，是因为质量具有滞后性，其它几个变量发生变化都是马上就会有反馈的。从而我们的系统开始变的混乱，到处是重复的代码。每次修改，我们都要祈祷别出问题，因为我们的代码容易出错，缺少自动化测试的保护。
整个响应速度越来越慢，我们不断积累债务，忙于应付新功能，忙于修改BUG。
所以传统项目管理模式是脆弱的。
组件团队
现在比较多的团队是这样一种分工模式：一群开发按照各自的组件作分工，一个需求过来后，会把任务分配给各个人，各自负责一个模块。他们之间的工作量不会均衡，这时往往会同时启动多个需求，出现大量并发任务在进行的情况。
这时，如果某模块进展不如预期，所有需求都会受影响；如果出现有人离职、请假时，或者当需求发生变化时，都需要调整所有人的计划。
为此，有的组织会组建一个团队去负责某个模块，开发人员围绕软件模块组合成团队。这解决了问题了吗？并没有。
这种模式一定会导致瀑布式开发，当一个团队负责某一模块时，由谁来进行需求分析？由谁来完成高层设计？由谁来完成端到端的测试？由谁来做计划、协调？，都不是某个团队，这就需要有业务分析师分析好需求，需要一个架构工程师将架构做好，需要有专门的测试人员做端到端的测试，我们还需要优秀的项目经理，来贯穿协调。
如果中间发生任何变化，都会影响到其它团队，协调起来非常困难。
这种模式也会鼓励追求局部效率最优，当我们去看所有的需求时，假设有两个团队D和E，前面高优先级的需求与它俩都没有关系，它俩可能会启动新需求。而当它启动新需求时，需要与其它团队讨论，对其他团队造成干扰，反而拖慢整个开发进度。
因此，组件化分工、组件团队也是脆弱的。
高耦合的代码
图中反应的是内聚和耦合的关系，显然它是高耦合的。
- 内聚：一个单位内部各种元素之间的关联紧密程度；
- 耦合：两个或多个单位之间的关联紧密程度。
高耦合会导致代码难以重用，加小需求可能需要修改N多个地方，随之可能会带来一些BUG。
因此，低内聚高耦合的代码是脆弱的。
总结
什么是脆弱的？
从流程角度来说，传统的瀑布开发、项目管理模式是脆弱的；
从技术角度来看，低内聚高耦合的代码、计划式设计、缺失自动化保护是脆弱的；
从人的角度的说，专业化分工、组件团队、竖井组织也是脆弱的。
从变化中获益
从变化中受益的关键之处在哪呢？我们可以从以下两个案例中得到启发：
米格-15 vs F-86军刀战机
为什么处处占尽优势的米格-15会败给F-86军刀呢？
制胜的关键是不是绝对速度更快，而是比对手更快的完成OODA环。
小白鼠实验的启示
为什么用小白鼠？因为它的基因序列与人类很类似，繁殖快，生长周期短，且成本低。
当我们面对不确定的“黑天鹅”事件时，从变化中获益的关键是：更快的、更低成本的学习循环，以更快的速度、更低的成本来验证假设、响应变化。
因此，我们可以给敏捷性定义：组织在不断变化和不可预测的竞争环境中应对变化和创造变化的能力，这就是我们要打造的能力。
打造敏捷的组织
那么，如何才能更快的速度、更低的成本 验证假设、响应变化？
小批量 à 短周期 à 快速反馈 à 响应变化
小批量
小批量的背后是有理论支撑的，如果分析排队论，会发现批量以及资源利用率对周期的影响，随着批量和利用率的增加，周期会急剧上升，它不是线性的。
如何小批量呢？
将大需求拆分成小需求，然后按照优先级排序，进行开发。要避免按模块拆分。
我们考虑风险驱动和价值驱动去排序，先把高价值、高风险的东西完成掉，快速的获得这些反馈，才可能以更少的代价、更低的成本、更快速的获得收益。
很容易得出，迭代开发模式是更适合来应对黑天鹅事件。
技术支撑
演进式设计：原来可以完成所有的设计再开始写代码，现在要变成一种演进式的设计，不要去实现未来的需求，只做适度的预先设计并保持合理的设计状态，才可能在需要添加需求时轻松搞定。
改成小批量也不是没有代价的，随着批量越大，有些成本是会下降的，而有些成本是会增加的。敏捷开发许多技术上的实践恰恰是希望解决这些问题，如果我们能够在减小批量时不显著增加成本，我们就可以更好的应对开发变化。那么，哪些实践会帮助我们控制小批量的成本呢？
测试自动化
我们需要构建分层的自动化测试体系，图中越向上，越接近业务，反应真实需求状况；越往下，越面向技术，成本更低、影响范围更小，发现问题定位起来更容易。我们需要分层的自动化测试体系支撑快速迭代模式。
持续集成/持续部署
工程师每修改几行代码，每完成一小点功能，我们就可以提交代码，触发自动化测试得到验证，才能快速地获得反馈，去保证软件一直处于可工作的状态，如果没有技术手段的保证，是没有办法用迭代开发模式的。
敏捷项目管理
让范围成为变量。在开发需求分析过程中，坚持质量内建，在时间和成本的约束下，让价值产出最大化。
全功能团队
在组织层面我们需要全功能团队，面向特性的自组织团队保证端到端的价值交付。一个需求的交流协作都是团队内部的交流协作，可以更快速的应对变化。我们更鼓励无差别的全功能团队，当需求发生变化时，可以很容易作出调整。
我们希望打造有一个敏捷的组织，从交付层面讲，用小批量、短周期方式更快地作迭代，用全功能的组织形式灵活地响应变化，同时，我们需要获得快速地反馈不断持续改进。
与其预测风雨，不如打造方舟！
