敏捷金字塔

敏捷所包含的知识领域可以概括为一个金字塔结构，金字塔的最底层，也就是一切的根基是敏捷的核心价值观，也就是著名的《敏捷宣言》，中间支撑的部分是敏捷的12项原则，而最顶层则是敏捷的各种实践和方法。我们今天要对敏捷宣言和12项原则进行解读。

首先，需要说明一点，敏捷宣言并不是敏捷的起点，在敏捷宣言起草之前，各种敏捷流派已经存在，并且在“敏捷”这个概念出现之前，像scrum、XP这样的方法被称为“轻量”方法，关于敏捷的历史我们就不做赘述了，总之，在2001年2月11日这一天，17位敏捷领域的资深大咖，聚集在了美国犹他州的雪鸟滑雪场，也许各位大佬也不确定这次聚会到底会不会有结果，或者还是抱着华山论剑的心态，但最终的结果是，他们共同起草了一份敏捷宣言以及背后的12条原则。

说起敏捷宣言，很多人都在讨论中间的四句话，而我们今天会从真正的第一句说起，因为如果你只看中间的四句话或许你会逐渐走到岔路。

真正的第一句：“我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：”这句话可以给我们两个信息，首先，敏捷不是一个完美的方法论，不是项目管理的圣经，我们要保持探寻的心态，我们要不断追求更好的状态，而追求的方法不是多看几本书，多了解几个知识点，而是身体力行的实践，只有实践你才能理解敏捷的精髓，才能体会各种方法和实践是如何诠释敏捷精神的。

第二句：“个体和活动 高于 流程和工具”，流程和工具重不重要呢？答案肯定是重要的，流程和工具能够帮助我们更快、更简单的做事，能够给我们带来很多便利，但是流程和工具只是辅助我们的，或许流程和工具能够帮助我们达到一个及格的分数，但是如果你想要一个高分，仅靠流程和工具肯定是达不到的，归根结底还是靠人、靠每一个个体、靠优秀的团队。所以敏捷宣言提倡关注个体与个体以及团队间的互动，面对面沟通、不断调整、尊重和团队共创。

第三句：“工作的软件 高于 详尽的文档”，文档重不重要呢？有必要的文档当然重要，文档能够帮我们记录很多东西，是我们的知识库，但是不必要的文档就是浪费时间和精力了，比如：打印出来要用小推车装的需求规格说明书（作者亲身经历），这样的文档真的有人看吗？真的有人看完吗？如果有，请联系我，我对您充满好奇。所以衡量产品价值的一定是产品本身，所谓的可工作也不是能够启动、没有Bug，而是能够帮助客户解决问题。

第四句：“客户合作 高于 合同谈判”，合同谈判一定是我们不想看到的，但是什么才是真正的客户合作呢？是我们努力满足客户的要求？还是我们想方设法让客户付款？笔者觉得既然是合作就要双赢、共赢，双赢不是单方面付出，是大家齐心协力达到共同的目标，所以敏捷也不是单方面的，多少案例中因为只有研发团队的敏捷，而客户和相关方置身事外，而导致敏捷无法发挥作用。

第五句：“响应变化 高于 遵循计划”，遵循计划是传统项目管理中非常鲜明的特点，在上一篇中我们也聊过，传统项目中想要变更是要走CCB的，而且会有很大比例最终被拒绝掉，那我们回到起点，客户为什么变化呢？当然我们不否认会有客户或产品负责人本身能力问题造成的变化，但更多的是市场的变化、环境的变化导致的，所以变化意味着我们距离真正的目标更近了一步，所以我们要拥抱变化，拥抱变化就是拥抱机会，一个和客户更好合作的机会，一个打造更优秀产品的机会。

注意！还有一句：“也就是说，尽管右项有其价值，我们更重视左项的价值。”，所以敏捷从来没有否定流程、工具、文档、计划的重要性，左侧的内容不是用来替代右侧内容的，实践中，很多企业推行敏捷，就开始抛弃计划，不写文档，随意变更，那说到底你从根源上就已经错了，你的指南针指向的根本不是南方！

敏捷有12条原则，如果说敏捷核心价值观是树的根，那12条原则就是树的枝干！

1-我们的最高目标是通过尽早和持续的交付有价值的软件来满足客户；2-欢迎对需求提出变更，即使在项目开发后期，要善于利用需求变更，帮助客户获得竞争优势；3-要不断交付可用的软件，周期从几周到几个月不等，越短越好;4-项目过程中，业务人员与开发人员必须在一起;5-要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务;6-无论是团队内还是团队间，最有效的沟通方法是面对面的交谈;7-可用的软件是衡量进度的主要指标;8-敏捷过程提倡可持续的开发，项目方，开发人员和用户应该能够保持恒久稳定的进展速度;9-对技术的精益求精以及对设计的不断完善将提升敏捷性;10-要做到简洁，尽可能减少不必要的工作，这是一门艺术;11-最佳的架构，需求和设计出自于自组织的团队;12-团队要定期反省如何能够做到更有效，并相应调整团队的行为;

1-我们的最高目标是通过尽早和持续的交付有价值的软件来满足客户；曾经有过一项统计，一个软件产品，用户一直会使用的功能只有7%，经常使用的占13%，当然还有16%左右是偶尔会用到的，但是大部分的功能是不会使用的，这也符合80/20原则，产品20%的功能已经满足了客户80%的需求，所以我们要尽早交付这20%的功能，也就是说我要梳理MVP，快速投入市场，并且价值的输出是要持续的，从项目的角度会有一个终点，从产品的角度我们希望能够一直持续下去，只要产品还在持续改进的工作就不会停止。

2-欢迎对需求提出变更，即使在项目开发后期，要善于利用需求变更，帮助客户获得竞争优势；即使在项目开发后期，这句是很重要的，变更是要经过评估，也是要谨慎的，但是如果有必要，即使在开发后期，我们仍然期望发生改变，因为一直错下去，即使到了终点也没有意义。就像导弹发射，明知道目标错了，击中又有什么意义，而敏捷就是巡航导弹，永远跟随正确的目标前进。

3-要不断交付可用的软件，周期从几周到几个月不等，越短越好；敏捷期望交付周期是短的，在scrum中会推荐1-4周的迭代，足够短就可以足够快的获得反馈，研发过程是要遵循PDCA循环的，需要不断调整才能越来越好。

4-项目过程中，业务人员与开发人员必须在一起；很多企业的现状是，业务人员整理好需求，组织一个评审会，把需求简要澄清后，就算交接完工作了，接下来再想找到业务人员就很难了，不是在忙就是马上要忙，问多了会提醒你一句文档里不是都写了吗？你仔细看看。我们暂且不说文档到底能不能覆盖全部的需求，即使文档是正确的，研发人员能够做到100%理解吗？所以最有效的方式一定是面对面的沟通，哪怕吵一架，也比闭门造车来的痛快！

5-要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务；我们说过一切的基础是人和团队，敏捷推崇尊重的文化，我们要给团队提供环境同时也要相信每个人有能力做到自己承诺的事情，而每个人也应该有勇气对任务作出承诺，对困难发起挑战。

6-无论是团队内还是团队间，最有效的沟通方法是面对面的交谈；今年年初，因为疫情的原因，很多公司采用远程办公的模式，本来大家都觉得在家里办公应该是很爽的事情，但是结果却发现一言难尽。即使有各种远程协助工具的支持，大家依然期盼着早日能够回到公司上班，正所谓：“远程办公苦不苦，你自己心里最清楚 ！”。

7-可用的软件是衡量进度的主要指标；不知道大家有没有类似的经历，笔者在大学时期，喜欢用迅雷下载电影观赏，当时宿舍的网络是公用的，为了不影响别人下载是要限速的，或者是趁别人不用时抓紧下载，总之，下载个电影一波三折，有时当你马上下载好了，已经准备好好欣赏了，发现进度停在了99.9%的位置，用尽各种办法都无果，这时候笔者的情绪充满失望、愤怒和无奈，甚至会直接卸载掉软件（过后再重新安装回来），这种感觉就像研发花了几个月的时间交付给客户一个不能用的产品，研发觉得付出了很多努力，但是对客户来说什么都没有得到，0和99.9没有区别。

8-敏捷过程提倡可持续的开发，项目方，开发人员和用户应该能够保持恒久稳定的进展速度； 关于这一条原则，后续介绍XP(ExtremeProgramming)极限编程的时候，也会有所体现，XP中提出40小时工作制，就是每周五天，每天8小时。敏捷是不提倡加班的，因为这个过程应该像长跑，要可持续，不是冲刺一两个迭代就结束了，但是很多人会说我们上了敏捷后加班更严重了，这个因素很多，后续也会聊这个话题，但是在这里我们应该知道敏捷提倡恒定的速度，加班解决不了根本的问题。

9-对技术的精益求精以及对设计的不断完善将提升敏捷性；敏捷是提倡拥抱变更的，如果想要变更除了产品和人员的适应性外，一定要有良好的技术支撑，大到企业级的架构设计，小到一个方法的设计模式都是对技术精益求精需要关注的内容，而在XP中，提倡频繁进行重构，重构本身也是对设计和技术的持续改进。总之，技术和设计的打磨是敏捷灵活性的基础保障。

10-要做到简洁，尽可能减少不必要的工作，这是一门艺术；这条原则与精益理论提倡的杜绝浪费是非常契合的，精益生产指出了生产过程中的7种浪费，在软件开发中也同样适用，比如：额外的功能特性、部分完成的工作、不必要的步骤、上下文切换、软件缺陷、等待、工作移交，这些都是我们要尽量避免的浪费。

11-最佳的架构，需求和设计出自于自组织的团队；自组织是敏捷团队的典型特点，但是自组织是一个非常难达到的状态，想要自组织不仅仅要团队有责任感，还需要更多的激发大家的兴趣，比如：跳广场舞的大爷大妈，大家都喜欢做同样的事情，不需要有人拿着鞭子抽，时间到了就自发的开始跳舞，这就是自组织，想要自组织，还有一个必要的前提，就是团队要够稳定，塔克曼模型有说，团队会经历从组建到成熟并最终解散的多个阶段，如果团队不稳定，可能只会在震荡和稳定阶段来回踱步，又怎么可能达到自组织的状态呢？

12-团队要定期反省如何能够做到更有效，并相应调整团队的行为；团队的自我检视和调整是非常重要的敏捷实践，后续介绍scrum时会和大家重点聊聊团队如何通过每日站会和回顾会议追求持续改进；“悟从疑得，乐自苦生”，反思总会有所收获，在很多公司做敏捷转型时，推行了scrum，但是敏捷回顾会变成了一个可开可不开的会议，那我觉得这样的状态，“伪敏捷”都算不上，只能叫“每疌”。

这一篇我们聊了敏捷的核心价值观和12条原则，相信大家对敏捷有了基本的认识和理解，在开始介绍敏捷实践之前，我希望和大家聊一聊敏捷的适用范围，敏捷不是万能的，敏捷不是银弹，那在什么样的环境下使用敏捷最有效？敏捷是不是只适用于软件开发？下一篇再见吧！

作者简介，杨久成

某商业银行PMO

敏捷、DevOps实践者，培训师！

欢迎联系我深度交流！