【敏捷1.2】敏捷宣言的官方解释：12条敏捷原则

原创

码农老张 2021-09-27 18:02:00 ©著作权

文章标签 项目管理编程语言 java 大数据敏捷开发 文章分类 Java 后端开发

©著作权归作者所有：来自51CTO博客作者码农老张的原创作品，请联系作者获取转载授权，否则将追究法律责任

敏捷宣言的官方解释：12条敏捷原则

上一篇文章中说到的敏捷宣言，可以说是整个敏捷体系中最精髓的部分了。说实话，不仅你觉得，我也觉得这四句话有点太简单，太抽象了。难道真正的敏捷只是遵循这四句话就可以了吗？不要 too young too simple 了。

在现实的项目环境中，各种因素往往是复杂多变的，敏捷宣言的概括虽说是可以覆盖到大部分的问题，但毕竟还是太过于笼统抽象了。所以，各位大佬们在发布敏捷宣言的同时，还给出了 12 条敏捷原则，可以看成是对敏捷宣言的官方解释及补充。

既然这么说了，那么其实也就意味着这 12 条敏捷原则也是官方给出的东西了呗。因此，不管是考试还是面试，这 12 条原则就和敏捷宣言一样，是必须掌握的东西。幸好的是，这 12 条原则也非常地“简单”。

原则一：我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意

有印象吗？对应的是敏捷宣言中的哪句话呢？这个原则可是照搬过来的哦！

在这一个原则，我们就会看到几个名词：持续交付、客户价值，以及为了实现这个原则所应该采取的开发方式：迭代式生命周期。记住，这些名词都和这个原则有着千丝万缕的关系。

原则二：即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势

同样的，这个原则也是来自于敏捷宣言中的一句话。另外，这里有客户价值和迭代思想的体现，通过快速迭代来实现客户的竞争优势从而提高客户价值。

这个原则也是与传统的项目管理最不同的一点，传统的项目管理中，非常注重的一点就是变化是一切罪恶的根源。所有的一切应该是围绕着计划进行的，变化会产生一系列的问题，包括但不限于时间延长、成本增加、质量降低等等。所有的变化一定要走完善的变更流程，要有记录，要能追溯。但是，在敏捷中，变化是受欢迎的，是值得我们去拥抱的，为什么呢？就是上面的原因，它能够提升客户价值。

原则三：经常性地交付可工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好

这个原则是顺着原则二的继续深入。快速地、短期的交付，也就是让客户和用户在很短的时间间隔里就可以体验到新的、不断累加的产品功能，就能尽早地让客户验证对产品的想法以及尽早地发现产品中的问题。

通常来说，在 Scrum 中，迭代（冲刺）周期一般为 2 到 4 周。而在 XP 中，则更有可能一周就完成一次迭代。

原则四：在整个项目开发期间，业务人员和开发人员必须天天都在一起工作

这个原则很明显是在说明沟通的重要性。在现代社会中，我们很多人即使天天坐在一个办公室里，也只会通过 QQ 、微信之类的聊天工具来交流。而在敏捷中，更提倡的是面对面的沟通，而且在项目成员和客户之间，最好也是没有隔阂的就在一个地方办公，而且有什么问题都是直接能够用面对面的说话来交流的。

当然，这真的非常难。在传统的项目开发中，外包团队经常会有入驻的开发形式，其实这就是为了更好的解决沟通问题。但是，在敏捷中，更提倡的是让客户也就是甲方派一些关键人物参与到乙方的工作中来。这样就能够快速的获得客户的意见，同时客户也能够随时清晰地知道开发的状态。

在这其中，除了在一起工作之外，看板是也一个协同办公很重要的工具，还包括站会、回顾会议等等各种简单小型的会议。如果不能在一起工作的话，或者不能面对面的工作沟通的话，这些沟通工具就完全不能发挥它们的作用。

就和前面说过的一样，让双方甚至多方天天在一起工作真的很难。但总有一些方法可以解决，比如周期性地同步工作一段时间，或者由资深的业务分析师来充当“用户代言人”。

原则五：围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作

在敏捷中，人是整个项目成功非常重要的一个因素。而在传统的项目管理中，人则是一个工具。也就是说，在传统项目管理中，所有的人都要遵循计划，告诉他应该做什么，怎么做。而在敏捷中，则是以激励为主，不会告诉你做什么，一切以你自己来决定。通过用户故事来认领你要完成的工作，通过故事点数来评估自己完成的速率。团队里的人都会认可你的工作，也会无条件的支持你、信任你。

在这里，我们会联想到几个名词：自组织、团队、勇气以及尊重。在将来的学习中，我们还会见到它们的身影。

原则六：在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈

不用多解释了吧？和原则四的内容很贴切吧，在原则四中我们也讲过了，面对面的交流沟通是敏捷中最重要的内容。

在人和人的交流中，面对面沟通时三大要素影响力的比率是：文字7%，声音38%，肢体动作55%。因此，为什么原则四要强调在一起办公的原因也再明显不过了。当然，我们也可以排个序，面对面说话当然是最好的，其次是视频会议，再次是电话会议，而文档的传递也就是传统意义上的邮件沟通则是最差的一种交流方式。

当然，我们并不是说禁止一切的文档交流。在某些情况下，一些 Wiki 类文档有其独特的功用，而且是不可代替的功用。

原则七：工作的软件是首要的进度标准

这里又再次提到了工作的软件，也就是正式可用的软件。既然我们不停地迭代，不停地上线。那么如果客户想要知道现在的进度，直接使用线上的软件就可以了呀。要知道，敏捷区别于传统项目开发的一大特点就是不停地持续交付真正可用的软件产品。

在敏捷中，一个功能无法使用，也就意味着这个功能是没有交付的。这种情况下，进度标准就被清晰的定义为每个功能是否交付，而且只有两个选项，已交付和未交付。当然，对于开发团队来说可能还有更多的选项，但对于客户来说，这两个就足够让他们清晰的知道现在产品已经开发到什么状态了。

原则八：敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度

其实说人话就是每次迭代的时间保持一致。比如我们确定好了两周一个迭代，那么后面就尽量不要改变这个迭代周期。另外一点则是每次迭代所完成的工作量也应该是要保持一致的。在这里，我们会用到“用户故事”中的“故事点”的概念。也就是每次迭代我们都应该完成相同的“故事点”功能以实现迭代中工作量的一致性。

良好的迭代规律能够为团队带来欢乐和生产力。试想在一个动荡的，充满不确定性的环境中，如何才能让团队保持平衡产出呢？另外，也可以将一次项目的开发比喻成一次长跑，在奥运会的长跑比赛中，解说员都会说稳定的节奏对于长跑的重要性。而短跑更像是每一次的迭代，在 Scrum 中，迭代也叫做冲刺。因此，整个项目开发过程，其实就是在稳定节奏下的一次次拼尽全力的冲刺。

原则九：不断地关注优秀的技能和好的设计会增强敏捷能力

这一点可以说是更重视于软件开发中的架构设计。代码一旦变得复杂，冗余，就会失去敏捷性。特别是长时间积累的，经过多人之手的传说中的“shi山”级别代码。之所以说不断关注，原因其实就像我们的项目进程一样，对于代码来说，也是不断地迭代升级的，当然，它有一个更专业的名词：“重构”。

持续不断的重构，其实也正对应着敏捷中的一个思想，那就是不断精进，这个概念来源于丰田的精益生产标准。而这个精益生产，也正是敏捷思想的启蒙概念之一。把控每一个环节，消除浪费，对应到敏捷软件开发的实践中，就是测试先行、持续集成以及重构的综合应用。要知道，返工和严重的 BUG ，正是最大的浪费来源。

原则十：简单（尽最大可能减少不必要的工作）是一门艺术

这个原则是我最喜欢的原则，当然，相信也是不少人最喜欢的原则。敏捷从不提倡过度设计，所以，适合当下的就是最好的。即使要为将来做准备，也要在严谨的论证基础上进行适当的扩展准备。

反过来说，这个原则最主要杜绝的其实也是一种浪费，那就是过度设计的浪费。我们经历过太多的项目，真的是看别人有什么就要做什么，最后的结果却总是不了了之了。根据28法则（帕累托），你的项目中用户最常用的功能其实只有那么 20% ，而剩下的 80% 可能大部分人都根本不知道。当然，也就可能剩下的这 80% 功能是为了那 20% 的用户所准备的。不过，如果是一个迭代的敏捷开发过程，那么我们最优先要做的，正是那 20% 的核心功能。至于如何做呢？最简单的方式去实现他们。然后在将来不断地重构升级。

原则十一：最好的架构、需求和设计出自于自组织的团队

敏捷很重视个人，但其实它更在乎的是整个团队。而在各种团队形式中，敏捷又最推崇的是自组织的团队。这是一种什么样的团队呢？代码共有、人人负责、团队计划、自主分解、自主协作、自我约定。看着是不是感觉很美好，没错，这样的团队非常难形成。

首先，我们要有一个小而精的规模，敏捷中不提倡太大的团队，如果人数过多，那么混乱也就随之而来。团队也一样要“简单”。

其次，团队成员的水平要高，甚至最好是通才。但这个太难实现了，所以，我们推崇教练机制。说白了，就是一种老带新的机制，有项目管理教练，有编码教练，当然也可以有产品教练，设计教练。

最后，团队宗旨要明确，没有目标的团队很难取得进步，在团队内部也很难沟通，至少，我们要为了同一个目的去工作，不是吗？

原则十二：每隔一段时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整

这个原则好理解，我们中国有句古话“吾日三省吾身”。这句话出自《论语》，意思就是每天都要对自己提三个问题进行反思。而在敏捷中，我们也非常重视这个反省的过程。因为我们的迭代速度快，所以有时候一些错误的构架和 BUG 确实是不可避免的，但是要拿出“勇气”，敢于“反省”和“重构”。另外最重要的一点是，这些都是在团队的基础上进行的，也就是说，错误不是某一个人的，而是团队中的问题。

在 Scrum 中，回顾会议就是非常重要的一个会议。通常在一个迭代结束之后都要进行一次回顾会议。目的就是让团队搞清楚我们在上一个迭代做了什么，有哪些收获，有哪些不足，怎么改进。说实话，不管是团队还是个人的进步，真像都在于我们如何去总结沉淀自己的经验。