「声动派」，专注互联网价值传播，为你分享大连接时代的一切！
本文大约7500字 阅读需要18分钟
作为向敏捷转型的技术团队，你是否在向团队介绍Scrum的时候觉得很困难？他们是不是存在抵触？他们是不是在实践过程中还是不懂如何去做？是不是还会提一些违背敏捷的低级问题？也许是团队成员还不明白什么是敏捷、什么是Scrum、它们之间什么关系以及敏捷能解决什么问题？
本文从方法论的角度，详述复杂问题、敏捷、Scrum之间的关系，有助于敏捷团队举一反三，应对敏捷实践中遇到的各种问题。希望通过这篇文章，大家都能找到这些问题的答案，本文也可以作为刚开始转向敏捷的团队作为敏捷导入宣讲的内容，让团队了解转向敏捷的必要性并快速踏上敏捷实践之路。
第一部分
// 人类和动物的不同？//
先不急讲敏捷，大家来思考这样一个问题：人类和动物有什么不同？
◆1.1 会思考
人是会思考的动物，虽然有些动物也会思考，但只有人类才能更高级的思考。人类会进行抽象思维，但动物则不能。
◆1.2 会用工具
有的动物也会使用工具，比如大猩猩会用木棒取食白蚁、小狗也衔着篮子捡垃圾，但人不仅会使用工具还会制造工具，会根据自己的需要制造满足需求的工具。
◆1.3 会分工协作
分工协作动物也会，比如狼群会成群结队合围猎物。但人的分工协作更广泛，不限人群和目标，可以随时组织一组人为达成一个目标进行合作。
◆1.4. 不断进步
以上技能动物都或多或少会一点，有没有什么是人类独有的呢？ 那就是人类会不断的进步，而动物只会原地踏步。动物所具有的那些能力可以说是天性，与生俱来，并不会传承和进步。
第二部分
// 人类进步原因？ //
先来看一个原始人躲避老虎的故事：
1）一群原始人，第一次遇到了老虎，看到老虎来了，撒腿就跑，但人跑不过老虎，有人被吃了；幸存的人说我是往树木多的地方跑，老虎行动不便，就不会被老虎吃掉了；
2）这群原始人，第二次遇到老虎，看到老虎来了，撒腿往树林里面跑，但还是有人被吃了；幸存的人说我当时抓住树枝往树上爬，老虎不会爬树，爬到树上就不会被老虎吃掉了；
3）这群原始人，第三次遇到老虎，看到老虎来了，立马往树上爬，但老虎一蹦就爬上树把树上的人吃了；幸存的人说要往水里游，老虎不会游泳，到水里就不会被老虎吃掉了。
后来有没有人再被吃？ 肯定有，但这并不重要，重要的是人类躲避老虎的能力在不断进步，被老虎吃掉的几率会越来越小。
人类的进步的原因就在于上图：
在实践过程中遇到问题后，人类会想出各种解决方案去解决问题；
在解决完问题后，人类会对解决问题的过程进行总结；
总结结果精炼后会产生经验，为了让更多人获得经验，人类会将经验进行推广；
推广的经验得到广泛的实践，但任何经验不能解决所有问题，世界不断变化，又会遇到新的问题；
通过这样一个不断的循环，解决了各种各样的问题，人类总结的经验也原来越多，经验也越来越有共适性。
第三部分
// 方法论与方法 //
经验是什么？经验是知识的累积，包含方法论和方法。
▎什么是方法论？什么又是方法?
►方法论，Methodology，定义的是What和Why，What定义了问题范围，Why定义了问题逻辑及基本原则。
►方法，Method, 定义的是How，指具体的操作方式和过程，以及使用到的工具和技巧。How是What的解决方案，How的适用性可以用Why来鉴定。
一个问题范围对应有一个方法论，一个方法论可能对应多种方法。每种方法都符合方法论的旨意，都能够解决一定范围的问题。
◆3.1 问题范围（What）
将各种各样相似的问题放在一起，把他们放在一起作为一类问题，用相同的方法都可以解决。这一类问题经过归纳，可以定义出一个问题范围。躲避老虎是一个问题，躲避狮子、躲避狼也是一类问题， 这类问题可以归纳为：躲避危险动物。
◆3.2 逻辑原则（Why）
逻辑原则指明了解决对应范围问题的方法的方向，也可以验证方法是否符合原则，有没有违背基本要求；躲避危险动物的逻辑是： 尽量远离危险动物, 让危险动物不能靠近自己
◆3.3 具体方法（How）
具体方法是符合逻辑原则(Why)的一种方案，也就能够解决指定范围的问题。躲避危险动物的方法很多，如不去危险动物出没的地方，爬上大树，跳到水中，钻进山洞堵住洞口等，还有主动的方式，如用火把驱赶；有了具体的方法框架才方便推广，实践过程中才有具体的参考。
另外以下通过减肥例子看看方法论和方法之间的关系：
减肥方法论：
What: 人体减肥
Why: 人体代谢理论（摄入和消耗比例），身体状况能够接受，不影响正常生活
减肥方法：
How: 具体减肥的方式，比如跑步、节食、营养搭配、禁食、桑拿等
假如你是一个180斤的人，长期不运动，爱吃甜食，有夜宵习惯，工作繁忙。你希望减肥，节食减肥会影响工作，适合少食多餐低糖低油的营养搭配的减肥方式；另外通过多跑步的方式来加大消耗。也许换个别的人，可能直接用禁食+桑拿的极端方法。
第四部分
// 变化和改进 //
◆4.1 方法不断改进
一种方法往往不是万能的，同一个方法论下的各种方法各有优点，它们会相互借鉴，不断改进，使得自身在解决范围问题的时候更加有效。
以市场推广为例，方法论是符合产品定位，推广成本效益比例适当。具体的推广方法有传统的户外媒体推广、报纸推广、电视推广等。在互联网还不流行的年代，电视推广可能是最好的推广方式，但用户都进入互联网后，新的换联网推广方式会有更好的推广效果。
另外各种社交软件的发展，产生了社交口碑推广、网红直播推广、答题直播推广等各种各样的方法，这些新的方法都有较好的成本效益比，投入一定成本，就能够达到很好的市场推广目的。
◆4.2 全新的世界
世界在变化，问题也在不断的变化，旧的方法论不一定适合，需要有新的方法论去解决新出现的问题，相应也需要新的方法框架。
通过总结分析新的问题的内在逻辑，结合旧的方法论体系，演化出新的方法论。
在新的方法论的指导实践中，基于旧的方法做改进，进而产生出符合新的方法论的方法框架。
◆4.3 复杂的世界
更多的时候，世界是复杂的，原来的问题变得复杂了，但我们并未能够及时意识到，还在沿用对于旧问题的方法论及方法，发现并不能解决问题，这时候会借鉴参考多种方法，想出新的解决方案。
问题的解决促使对新的复杂问题的分析，以及对旧方法论的反思，发现旧的方法论已经不适合，需要改进出新的方法论。新的方法论再回过头来指导实践新的方法，促使新的方法能够得以更进一步的改善。
◆4.4 繁杂的世界
前面讲的减肥问题，是比较具体的问题，是一个个人的问题，不涉及组织、体系或系统，问题范围比较窄，其对应的方法论和方法都相对不容易变化。但一旦问题涉及一个组织或一个系统，变化的因素太多，问题从复杂变为繁杂，可能会有很多方法论都适合。
比如“企业盈利”这个问题，方法论是选择一个有前景的市场方向，招一批有能力的人，吸引充足的投资，激发全员斗志努力拼搏。这样一个方法论是没有具体的方法的，因为方法论的每一个指标都又是一个问题，也在随着社会环境的变化而不断变化。以前互联网、电商、外卖是市场方向，现在直播、云计算、大数据是市场方向，以后物联网、AI是市场方向。
有能力人的定义以前是有技能或有管理能力的人，现在是有学习能力、有进取心的人；吸引投资之前找投资人，现在可能找政府合作、搞众筹； 激发斗志以前靠KPI，现在可能靠OKR、丰厚的年终奖。但这些还不够，世界变化的速度比产生新方法的速度还快。原来蓝海的市场转眼就变成了红海，今天红海市场明天可能变成死海。
变化繁杂的世界，产生变化繁杂的问题，有没有应对的方法论和方法呢？当然有，这些繁杂的问题都是组织管理性的问题，根据问题复杂度程度不同，有不同的方法论和方法。接下来了解一下复杂度模型。
第五部分
// 复杂度模型 //
英国赫特福德大学（University of Hertfordshire)商学院管理教授和复杂性和管理研究中心主任 Ralph Stacey 提出了新型的基于结构化混沌的复杂性战略管理理论。在其所著的《战略管理和组织动力学》第2版中提出了Stacey’s Zone of Complexity，也被许多人所推崇，也有人称为the Stacey matrix或Ralph Stacey's Agreement & Certainty Matrix，广泛应用于管理/领导、问题解决和决策等方面。
复杂度模型(Stacey Matrix) 是以两个维度：确定性程度（Certainty ）和 同意程度（Agreement），将空间划分为5个区域。
确定性程度（Certainty ）：靠近确定性一端（Close to Certainty）是因果关系明确，在另一端（Far from Certainty）则不明确，通常是从未遇到的情形, 也可简化理解为行为导致后果的确定性程度。
同意程度（Agreement）：关于一致性的程度。可简化理解为方向意见一致性程度。
在不同区域（即不同的情景）采用不同的方法论策略是非常重要的，如下图：
◆区域1：一致且确定
该区一致且确定，这是一个很有秩序（Order）的状态。通过技术理性决策（Technical rational decision making），即用收集过去数据的技术来可靠地预测未来，规划行为实现结果，并用计划来监控实际行为或结果，重点在于可重复地工作以提高效率和效能。
◆区域2：相对不一致但确定
当确定或清析但未能同意如何执行甚至方向也不能定下来，这情况需要执行政治决策（Political decision making），重点在于如何控制(control)、妥协(compromise)、谈判(negotiation)和建立联盟(domainant coalitions)来确定方向。
◆区域3：一致但相对不确定
当项目方向等都很一致但对于做什么或怎么做不是很了解时，这时需要借助顾问（Consulting）执行判断决策（Judgmental decision making），重点在于如何按照所同意的方向前进，检讨是否按方向前进，即愿景控制(ideological control )和逻辑增量（logical incrementation）。如果做得东西无法达成方向目标，则需要调整做的内容。
◆区域4：非常不一致也非常不确定
如果方向不一，而且做什么都不了解的话，这是混沌（chaos）状态或无秩序状态（anarchy），所有组织都应该避免(massive avoidance)这情况发生，不然会引起解体（disintegration）。
◆区域5：不一致也不确定
在以上的状态中还有空隙，即是同意程度和确定性程度都在中间的位置，也有人称之为混沌边缘（the edge of chaos），这是最有效创新（innovation）的区域，在传统管理的方法不是太有用的情况，重点在于促进共创式（Co-creation）和提供自组织管理空间，可以采用的技术有开放空间技术(Open Space Technology)和世界咖啡(World Cafe)、头脑风暴(brainstorming) 和辩证式探究(dialectical Inquiry) 、议题构建(agenda building)等，往往靠直觉(Intuition) 和粗略应付(muddling through)，提倡快速产出而非给出完整解决方案(outcomes rather than solutions)， 识别问题(identification)并快速开发和做出选择(development & selection)。管理风格是错误容忍决策(garbage-can decision making)或非程序化决策(unprogrammable decision making)。这个区域也是敏捷方法最有效的情况。
非常不一致和非常不确定的混沌的状态是几乎无法控制的，企业组织处于这样的状态本身是一件很危险的事，应尽可能避免。
一致且确定是属于简单事情的领域，对于管理而言是相对比较容易的。如工厂流水线，可以通过分析去年或上个月的销售数据，决定要生产多少产品，产品销量和收入都是可预期的，只是制定好计划后对生产过程进行监控确保能够正常进行并完成。
如果存在不一致或者不确定，这就是复杂和繁杂的领域，敏捷方法论对于解决这些复杂领域问题最有效。那么敏捷是什么？为什么敏捷方法适合解决复杂问题？
第六部分
// 敏捷 //
2001年2月，Martin Fowler，Jim Highsmith等17位著名的软件开发（包括 Scrum、极限编程 (XP)、动态系统开发方法 (DSDM) 和 Crystal 的创始人、以及功能驱动开发的代表人物和软件行业的其他几位思想领袖）专家齐聚在美国犹他州雪鸟滑雪圣地，举行了一次敏捷方法发起者和实践者的聚会。
在这次会议上面，他们正式提出了Agile(敏捷开发)这个概念，并共同签署了《敏捷宣言》。雪鸟会议是对之前几十年中软件开发实践探索的总结，是水到渠成的一个结果。每种敏捷方法实现敏捷方法论核心价值的途径略有不同，就如许多计算机语言以不同的方式展现面向对象编程的核心功能一样。
敏捷本身并不是一种方法，它是一个多种敏捷方法涵盖性术语，是一个经典的先由方法改进再通过反思总结出的方法论，它包含敏捷宣言和敏捷原则。
◆6.1 敏捷宣言
敏捷宣言只是简单的四句话，但却是敏捷方法的精髓，在谈敏捷方法之前就必须先对敏捷宣言有所理解。
【敏捷宣言】
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
这四句话从句式上可以看出是基于原有的一个方法论基础改进而来，提出了实践过程中更应该优先考虑的价值和原则。虽然宣言中右项也很有价值，但是我们认为左项更有价值。这里要注意，不是说右项没有价值，相反右项也有必要。原有的方法论（流程和工具、详尽的文档、合同谈判、遵循计划）对于简单明确一致的事情而言是比较有效的，但对于复杂不一致不明确的情况却无能为力。
►个体和互动 高于 流程和工具
流程和工具在解决计划型的问题时很有效果，对流程和工具的改进可以直接提高生产力。但在解决复杂繁杂问题的时候，注重个体和互动才能提高团队绩效。对一个项目进行的“沟通饱和度”研究显示：当不存在任何沟通问题时，团队效率可以达到业界平均水平的 50 倍。为便于沟通，敏捷方法依赖于频繁的检查和调整周期。尊重每个人的价值，每次都诚实交流，所有数据、行为和决定都保持透明，相信每个人都是团队的支撑力量，积极投身于团队和团队目标。个体和团队做出承诺时，他们才会肩负起实现高价值的责任感。
虽然强调个体和互动，但流程和工具对于团队协作和工作方式还是很必要的。
►工作的软件 高于 详尽的文档
在传统项目合同中有时会看到分别在需求、设计、开发、测试阶段提供什么文档，其实详尽的文档对客户来说确并不重要，用户需要的是一个能够运行起来，能够实质解决工作中问题的可工作的软件。详尽的文档对开发团队也不重要，上百页的报告没有人愿意写，更没有人愿意去读。传统简单项目的可工作软件是可预期的，但复杂项目的需求本身在不断变化，需要频繁间隔周期性的提供小部分可工作的软件，以便频繁的搜集对产品和开发过程的反馈，保证团队始终是在处理最具有价值的功能，而且这些功能可以满足用户的需要。
虽然强调提供可供做的软件，但并不是不要文档。在开发过程中仍然需要进行内部交流，也需要和客户交流，仍旧可能需要制作原型，书写一些主要需求和算法，只要团队认为足够就行了。
►客户协作 高于 合同谈判
项目的最终目标是提供给客户满意的产品，只有客户才更清楚怎么样才能满意，客户和开发团队密切的在一起工作，通过与客户频繁沟通和反馈，把问题及早暴露出来，以免隐藏的问题在后期造成更大的影响。
虽然强调客户协作，但为了双方利益和需要仍旧需要进行合同谈判。
►响应变化 高于 遵循计划
计划赶不上变化，行业数据显示，有超过 60% 的产品或项目需求会在软件开发过程中发生变化。敏捷项目承认开发过程中的不确定性，所以不会在开发中制定长时间的复杂计划，它们的成功都是建立在现实反馈的基础上的。传统项目即使按时按预算完成计划的所有功能，客户往往也会不满意，因为他们所得到的与他们希望得到的不能完全相符。客户在看到可用软件之前可能并不知道自己想要的是什么。如果客户直到项目完成时才看到工作软件，再想融入他们的反馈意见为时已晚。敏捷看重客户反馈，以便团队能在产品开发过程中合并反馈和新需求。
虽然强调响应变化，但并不是不需要计划了,反而我们需要更多的规划。不确定性是影响计划正确的主要因素，对大部分不确定而言，在获取知识、减少不确定性的唯一办法是通过执行，然后获得反馈。许多项目管理方法是“规划、规划、规划－执行”，而敏捷开发方法是“规划－执行－调整”、“规划－执行－调整”。一个项目的不确定性越高，敏捷开发方法对取得成功就越是至关重要，不断学习和调整是敏捷开发的核心。
◆6.2 敏捷原则
敏捷宣言就像一面旗帜，给大家指明了前进方向，而敏捷原则就像路标，给大家指明了前进的路线。每一条敏捷原则都可以用于检验行动本身是否符合敏捷要求，是敏捷的行动路线指南。
【 敏捷宣言遵循12原则 】
❶我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
❷欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
❸经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
❹业务人员和开发人员必须相互合作，项目中的每一天都不例外。
❺激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
❻不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
❼可工作的软件是进度的首要度量标准。
❽敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
❾坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
❿以简洁为本，它是极力减少不必要工作量的艺术。
⓫最好的架构、需求和设计出自自组织团队。
⓬团队定期地反思如何能提高成效，并依此调整自身的举止表现。
第七部分
// Scrum //
1990年代初，肯·施瓦伯在其公司使用了一种方法Advanced Development Methods（先进开发方法），这种方法后来发展为Scrum。同时，杰夫·萨瑟兰在Easel公司开发了一种类似的方法，并首次称之为Scrum。1995年，在奥斯汀举办的OOPSLA '95上，萨瑟兰和施瓦伯联合发表了论文首次提出了Scrum概念。2001年敏捷宣言发布后，施瓦伯与麦克·比窦（Mike Beedle）合著了《敏捷软件开发-使用Scrum过程》一书，介绍了Scrum方法。
最近的一项调查显示，大约 50% 的敏捷开发从业者表示他们的团队采用的是 Scrum。另外 20% 表示他们采用 Scrum 与 XP 组件。另外 12% 表示他们只采用 XP。全球有 80% 以上的敏捷实现采用 Scrum 或 XP。可以说Scrum是敏捷方法论使用最广泛的敏捷方法。
Scrum是一个符合敏捷方法论的、解决复杂问题的方法框架，它通过迭代、增量的方式，在最短时间交付最大价值的产品。
▎Scrumn框架可以概括为“3355”，即3个角色、3个资产、5个仪式、5个价值。
3个角色： 产品所有者、开放团队、ScrumMaster
3个资产： 产品待办列表、冲刺待办列表、增量
5个仪式： 冲刺计划会议、每日站会、冲刺评审会议、冲刺回顾会议、冲刺
5个价值： 勇气、开放、专注、承诺、尊重
Scrum只是一个方法框架，并没有说明做事的细节，只是让我们做事情的时候有路径可寻。它没有教如何去写代码，它只是告诉我们通过一定的方式应对变化快速的产出价值。
对于一个产品研发团队，或者经常面对不确定不一致问题的团队，要使用敏捷的方式来改善工作效率，掌握Scrum无疑是最好的选择。Scrum整个方法框架制定了团队的角色、工作方式以及价值观，给刚践行敏捷的团队一个行动参考。
Scrum还提供各种培训课程，以便团队成员能够更快的掌握Scrum精髓，包括基础级别的 ScrumMaster认证(CSM), ProductOwner认证(CSPO)，Scrum开发者认证(CSD)，以及相应针对基础级别更高等级(Advanced)的A-CSM,A-CSPO, A-CSD, 还有专业级别的认证Scrum专家(CSP，包括CSP-SM、CSP-PO、CSP-D)，以及指导级别的Scurm培训师(CST)和认证Scrum教练(CSC)。建议有条件的团队成员根据自己的角色去进行基础级别的认证学习，或者至少进行CSM的认证学习，通过ScrumMaster去推动整个团队去实践改善敏捷方法的使用。
当然，需要意识到实践敏捷并非一蹴而就的事情，也不是获得CSM认证就掌握了敏捷方法。比如从传统项目角色转向Scrum的角色，很多人都需要有一个较长的时间才能从意识和行为上去做到。
Scrum强调自组织，传统习惯了指挥发号施令的管理方式都需要改变，需要一点一点的践行。实践过程中往往还需要大胆的让团队去失败，从失败中体会敏捷方法的深意。另外每个团队面临的任务不一样，遇到的问题也不一样，对完成的定义也不同，没有一个标准或范例可以拿来直接照抄使用。
第八部分
// 总结 //
通过以上介绍，相信大家对敏捷方法论、Scrum敏捷方法都有一定的了解，用一张图来概括：
虽然Scrum核心内容不多，但要实践好还是不容易，要掌握很多技巧和实践经验才能深刻理会。
很多团队急急忙忙推行Scrum，通过大量的培训让团队成员学习Scrum的做法，团队成员把Scrum看成了一套流程和管理工具，但Scrum往往没有给出具体的做法，经常就会问我该怎么做？应不应该这样做？这样做是对还是错？ 这些问题都是对以上这幅图的关系没有深刻理解导致的，只要明白了这些关系，很多问题都可以迎刃而解。
为了防止在敏捷实践过程中走偏走错，整理了几句话，用于团队不时反思：
不要心中只有站立会和冲刺，
要心中有Scrum方法框架。
不要心中只有Scrum方法框架，
要心中有敏捷方法论。
不要心中只有敏捷方法论，
要心中有复杂问题本身。
*本文著作权归作者所有，转载请联系作者获得授权。