先看看我们为什么要聊这个话题。如下图所示，如果把敏捷看成一颗大树，那么敏捷宣言就是这棵树的根基所在，我们可以称其为敏捷的“道”之所在；而敏捷的12原则，则可以看做是大树的枝干，也是敏捷的技“法”所显；最后大树的枝繁叶茂，是有很多的敏捷方法和工程实践所组成，也可以说这是敏捷的“术”之所用。我们在工作中正是通过不同的敏捷方法、框架以及工程实践来践行敏捷的道和法。所以对具体的Scrum而言，我们尝试着来看看是如何在其中体现这些价值和原则的。
敏捷宣言的四个核心价值观
个体和互动高于 流程和工具
工作的软件高于 详尽的文档
客户合作高于 合同谈判
响应变化高于 遵循计划
我们先来看第一个核心价值：
个体和互动高于 流程和工具。这条价值观其实强调的就是以人为本，描述的是一个紧密合作，自我驱动，自己做出决定的一个团队，而不是被动接收指令然后执行的一个团队。敏捷原则中我们可以看到：“无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。”这条原则非常直观的反应了敏捷的第一条价值观。Scrum里面所有的会议都在创造一个强制沟通的机会，以每日站会来说，15分钟的会议，用于团队成员之间面对面的同步当下进展、状态和风险障碍等。用这种面对面的互动代替传统意义上的流程来更及时的在团队层面获得反馈，更好的促进团队合作的工作氛围。我们来看下一条原则：“要善于激励项目人员个体，给他们以所需要的环境和支持，并相信他们能够完成任务。” 可以看到这同样是一条尊重个体的原则，相信个体的能力。在Scrum中，Scrum Master很重要的职责就是给团队创造所需要的环境和支持，移除障碍，帮助团队成员发挥自己的能力，从而带来项目的成功。相信团队才能更好地赋能团队，让团队成长。
第二条价值观：
工作的软件高于 详尽的文档。了解这条价值观我们首先要认识到敏捷不是否定了所有的文档，不是说敏捷就不再需要文档了，而是说敏捷更重视可工作的软件，我们只需要创建并维护必须的文档，然后把精力更多的放到软件本身上面。事实上在敏捷里面文档依然存在，比如经常说的用户故事其实也是一种文档，只是用户故事用于需求理解的交流而不是任务交接。曾经在一家企业践行过“代码即文档”，省去了对于大量文档的维护更新和对于代码的注释，把这部分精力用于让代码更可读。因为在实践中很多文档被创建出来以后就很少有人去维护（代码里的注释同意也存在这个问题，虽然这不正确，但这是事实存在的），导致代码改动以后会出现文档和代码注释和代码都不一致，给后续的修改bug和重构带来麻烦。但是即使有这样的共识，对于到底是否需要文档在scrum的实践中我们依然在不停的探寻哪些文档是必须的，最终确定下来有部分文档依然是需要被创建和维护的。总的原则是如果用于留痕的过程文档是不必须的，用于交流的文档则是必要的，比如设计文档和接口文档。在十二原则中“我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。”、“要不断交付可用的软件，周期从几周到几个月不等，且越短越好。”、“可用的软件是衡量进度的主要指标。”无不是在强调可工作的软件高于详尽的文档。在scrum的实践里面，我们可见整个框架的设计也在遵循PDCA的模型，传统的瀑布模式每个PDCA大循环的周期相对较长，scrum将PDCA的周期降为一个迭代，每个迭代的输出是Increment，而Increment则通过可工作的软件而不是文档来体现（软件开发的团队），scrum里明确定义一项工作除非符合DoD，否则不能将其视为Increment的一部分，也就是Scrum结束的交付应该符合DoD的标准，应该是可工作的。在Scrum的工程实践中，CI/CD的使用，也使得持续集成，按需发布成为可能，将产品开发和发布解耦，实现尽快提供可工作软件的目的。
第三条价值观：
客户合作高于 合同谈判。
如图我们可以知道，敏捷的出现本来就是为了打破需求和开发之间的墙。恶搞从需求到产品之间的图片已经够多了，但如果需求和开发之间是一个传递或者移交的过程，他们之间的墙一直存在的话，那些图片就不是恶搞，只是现实世界的照片而已。十二原则中“项目过程中，业务人员与开发人员必须在一起工作。”就是在具体的描述这个价值。在能把事情做正确之前，先要确定做正确的事儿，否则将是南辕北辙，做出很多业务并不需要的功能是项目中的最大浪费。
Scrum对于team的定义并没有区分角色，Scrum team负责所有与产品相关的活动，也就是不存在一个team负责写需求，而另外一个team负责实现它，理论上从需求到交付都是“one team”的责任。实际上组织中往往是产品部门或者专门的需求团队在负责写需求，所以需要因地制宜的去设计如何在组织中如何去落地该项价值。我们在日常工作中尝试过需求人员组织上属于产品/需求team，但是特定的产品人员daily work跟随特定的scrum team（一个或者多个），这种情况可以work，但是副作用是产品人员归属感不够，有时候还会因为他原生team的工作影响scrum团队的工作。也尝试过组织重构，将产品人员拆分到不同的scrum团队中，将其作为scrum team的固定成员，解决了其归属感问题。还在不同的组织中尝试团队独立，daily meeting邀请产品成员定期参加，retro会议邀请产品同学参加的模式，也工作的还可以。总之需要根据组织的文化和结构为基础，业务和开发合作为目标，找一个适当的工作模式，避免客户合作，避免合同谈判。
第四价值观：
响应变化高于 遵循计划。Scrum的三个支柱之一就是“适应”，Scrum发明出来的目的之一就是为了能够更快的响应外界的变化，而不是闭门造车，直到最后才发现需求已经不是当初的模样。十二原则之一“欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。”对于价值观和原则需要正确理解，这里的响应变化和在项目后期也欢迎对需求提出变更，并不是说我们的需求可以随时发生变化，正在做的需求频繁发生变化说明需求的质量出了问题，是需要反思和采取行动提高需求质量的。在Scrum中只是强调一个特定的Sprint中并不欢迎需求的变更。Scrum里面是通过需求的拆分和Product backlog的管理来实现响应变化的。这样我们可以聚焦优先级最高的需求，无论是需求分析还是实现，都从当前优先级最高的需求开始，而没进入Sprint的需求，则可以非常灵活的响应变化。传统的项目管理模式中，在项目启动之初确定所有的需求和范围的方式，非常不利于对于变化的响应，而Scrum中Product Backlog是按需进行梳理，周期进行优先级的调整，从而做到响应变化，而不是仅仅遵循计划，毕竟在当下，唯一不变的就是变化。
在十二原则中，我们还将遵循以下几个准则，但我并不想一定要把它们放到四个价值观里面，因为它们更偏向于持续改进和工程实践，尝试着分别对其做一些解释：
敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。Sprint被翻译成冲刺，但是冲刺并不能被演绎成“死亡行军”，不是倒排期，不是白加黑，5加2，大干多少天，然后休息。而是有节奏的持续的交付有价值的增量，团队不断地获得成功。Scrum里通过透明，承诺，时间盒来保证一个迭代中任务是适当的，Sprint Planning则是在PO和团队间达成协议，保障持续开发的仪式。
对技术的精益求精以及对设计的不断完善将提升敏捷性。” Scrum里面并没有规定需要采用何种工程实践，事实上团队在这个框架里面可以采用任意的技术和方法，而作为Scrum最要要解决的软件开发类项目而言，工作完成的根本还是需要回归到软件开发的技术本身，所以毫无疑问对于技术的精益求精和对设计的不断完善就成了Scrum工作的必然选择，采用更先进的语言，更易扩展的设计，更便利的工具，只有这样，才能更好的实现每个Sprint交付可工作的软件。
要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。Scrum是基于经验主义和精益思维的，而精益的根本在于减少浪费。所以在Scrum的工作中，从需求的层面，聚焦于优先级最高的需求，更早的交付，更快的获取反馈，只做有价值的功能；从代码层面，TDD则可以保证代码的简洁，避免镀金的发生。
最佳的架构、需求和设计出自于自组织的团队。Scrum指南中明确定义了Scrum team是自组织的，没有人告诉他们如何将Product Backlog 条目转化为价值的Increment，他们自己决定了如何去做。只有被充分授权的自组织团队，团队成员才有勇气做正确的事并处理那些棘手的问题。华为提出的“让听到炮火的人做决策”也是同样的道理。
团队要定期反省如何能够做到更有效，并相应地调整团队的行为。Scrum团队是不停的进化的，而不是停滞不前的，无论是技术还是过程管理，都需要变得更有效率，敏捷从来不是目的，组织的效能才是。精益思想之一就是“追求卓越”，Scrum里面也是需要我们持续改进的，典型的落地方法就是Retrospective meeting，在回顾会议里面，SM采用教练、引导技术，带领团队定期回顾过往的结果和行为，达成行动改进项，让团队继续的成长！
如上所述，在Scrum里面，不管是理论还是实践，都在践行敏捷宣言的价值观和十二原则，这也就是为什么建议在导入Scrum之处，需要先“守”，就是因为需要通过Scrum的3355和工程实践固化这些价值和原则，只有这些形成肌肉记忆以后，才有后面的“破”和“离”。
参考文章：
网友评论