在过去的五年时间里，我所在的公司和团队一直使用的都是敏捷开发模式，我也在2018年底获取了Scrum联盟的CSM认证，对于敏捷的理解也是从最初的感性认识到现在的理性认识。今天开始和你一起重新温习敏捷，先来正确理解一下敏捷吧。
相关阅读：
（1）如何正确理解敏捷？
（2）如何正确推进敏捷？
（3）如何填好推进的坑？
（5）无处不在的敏捷思想
1 敏捷的初心
2001年，一群大师聚集在美国犹他州，吃吃喝喝头脑风暴，搞出了一个敏捷宣言，阐述了5条价值观，如下图所示。
对于敏捷宣言，在学习和实践的前期我和团队都有一个常见的误解：认为左边的最重要，右边的没有价值。
但是，请注意最后的一句话“虽然右项有价值，但我们更重视左项”，结合前面每一条的“胜过”二字，就可以理解为：与每一条中右面的内容相比，左面的内容是敏捷更加重视的，但是，不代表建议你停止右边的内容。
比如“可以工作的软件比面面俱到的文档更加重要”，但这并不意味着就完全放弃文档的编写，而是不必要的文档可以放弃，比如：交接类文档、提测描述类文档、接口说明文档（比如可以完善注释和集成Swagger等工具在线展示）。而一些有价值的文档，如设计方案文档、架构体系文档等，还是不能省的。
因此，敏捷的价值观其实并没有否定右项的价值，这些右项的内容也很重要，在敏捷里也不是建议大家都不做。敏捷的价值观其实也就体现了敏捷的初心，敏捷的初心是建议我们通过一系列方法来让我们的研发工作更加高效、灵活和有序，所以它强调团队成员的能动性和相互之间的协作，也更重视应对变化。所以，如果“流程和工具”、“详尽的文档”、“合同谈判”又或者“遵循计划”能够让研发工作更高效有序，那敏捷其实也是不反对也不放弃做的，这或许也是敏捷的真谛。
2 敏捷的原则
只有敏捷价值观是无法具体指导我们具体工作的，因此由它的价值观又引出了经典的敏捷十二条原则，是每个学习敏捷的童鞋都应该反复理解的话：
（1）我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
（2）即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
（3）经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
（4）在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
（5）围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
（6）在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
（7）工作的软件是首要的进度度量标准。
（8）敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
（9）不断地关注优秀的技能和好的设计会增强敏捷能力。
（10）简单——使未完成的工作最大化的艺术——是根本的。
（11）最好的构架、需求和设计出自于自组织的团队。
（12）每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
这十二条原则也可以帮助我们正确理解敏捷，里面的原则对于敏捷的价值观做了细致的描述，它重视各方的协作，强调持续改进和响应变化，不夸张的说，它基本涵盖了软件项目管理中比较具体的基本流程。
我们要做的就是，正确理解这些原则，然后以此为基准去实践，并随时审视和回顾以指导自己的做事。
3 敏捷的方法
理解了价值观和原则，我们还需要掌握一些可落地的方法论。当然，敏捷联盟的大师们早就为我们思考好了，例如 XP（极限编程）、Scrum、特征驱动开发、动态系统开发、SaFe、Less等等，他们被统一称为敏捷方法。还有一些配套的技术实践，例如TDD（测试驱动开发）、BDD（行为驱动开发）、CI（持续集成）等等。换句话说，只要是符合敏捷价值观和原则的方法论，都可以称之为敏捷方法。
其实，这些方法从共性上来看，它们其实都遵守了敏捷的价值观和原则，差别都只在于它们针对了不同的应用场景。因此，这里提一下大家可能都存在的另一个误解，也是我和团队在学习初期的一个常见误解：敏捷就是Scrum。
毫无疑问，这个误解的确很常见，因为Scrum是目前较为主流的敏捷实践方法，大部分公司做敏捷转型也都是使用和培训的Scrum，导致了我们会有这样的误解。但是，从上面可以了解到，Scrum不是敏捷的全部，它只是敏捷的一个落地方法之一。
说到Scrum，既然它是采用度最广泛的一个方法论，就不得不提我自己曾经对于Scrum的一个常见误解：Scrum就是3355。
什么是3355？
第一个3代表3个角色，即Product Owner（产品负责人）、Scrum Master 和 团队；
第二个3代表3个工件，即Product Backlog（产品待办事项列表）、Sprint Backlog（迭代待办事项列表）和 Product Increment（产品增量）；
第三个5代表5个事件，这也是大家感受最深刻的，即Sprint Planning（迭代计划会议）、Daily Scrum（每日站立会议）、Sprint Review（迭代评审会议）、Sprint Retrospective（迭代回顾会议）、Backlog Refinement（产品Backlog梳理会议）；
第四个5代表5个价值，即承诺、专注、开放、尊重和勇气；
3355代表了Scrum的精髓，其中每一个点都可以展开阐述许多文字，这里不再赘述。学习了3355，但是并不代表理解它和照搬它就可以做好Scrum，这也是初步实践Scrum的团队所经常犯的错误。因为，实践Scrum还有约束条件需要我们严格遵守，如果不遵守这些约束条件，你可能实践的是假Scrum。
比如在Planning开始之前，Product Owner需要准备好Backlog，使得需求能够达到准入的标准。如果没有准备好或是不够准入，那么团队的开发节奏仍然会被打乱。又比如Scrum讲究时间盒约定，迭代周期、会议时间、发言时间都有严格的时间规定。如果不遵守约定，那么团队会被耗在各个会议上面而一直没有结果，最终团队成员的厌烦感就会一股脑而上。
综述，Scrum其实不只3355，还包括一些背后的规则和条件，只有先准备好和遵守好这些规则和条件，在此基础之上应用3355，才能让它发挥作用。
说到Scrum，提一下Scrum联盟的认证路线，有条件的企业可以引入Scrum认证培训机构（当然，这是一笔不小的花费）给员工进行系统化的认知和体验培训，帮助员工掌握Scrum。为避免有打广告的嫌疑，这里我就不推荐培训机构了，大家自己找吧。
4 小结
一句话理解敏捷的话，那么敏捷应该是 价值观+原则+符合价值观和原则的一堆落地方法论。
对于敏捷，我们需要从价值观、原则和具体落地方法上对它有个全面的认识，才能在落地实践中有正确的方向，随时纠正自己不要走偏不要违背了敏捷的初心。
对于方法，无论它是不是Scrum，又或者它是否打着敏捷的名头又或者冠以敏捷，本身是无所谓的，我也更是觉得并非要全盘采纳敏捷的所有方法（很多时候我发现我们都很迷信3355的流程），只要在具体实践中能够体现敏捷思想，改变自己改变团队，持续改进提高效率，最终完成公司的目标，那就是敏捷的方法。
参考资料
（1）宋宁，《说透敏捷》（极客时间课程）
（2）Jeff Sutherland & Ken Schwaber《Scrum Guide（2020版）》
（3）周金根，《敏捷开发的12条敏捷原则》
（4）Mike Cohn，《Scrum敏捷软件开发》
（5）一些企业内训的敏捷培训资料
Edison, Certified ScrumMaster
