Scrum的锅，别让Agile背

Posted 2021-04-25 盛安德软件

1

Scrum的锅，别让Agile背

我们强调敏捷作为一种理念或价值观，因为Scrum或任何方法与工具层面的东西都可以被我们学习，但如果我们不能理解敏捷在文化或抽象层面的背景，我们的学习最多可以做到形似，而没有神在其中。大家会认为这些Scrum的条条框框没有价值，最终连敏捷也一并放弃。

2

Scrum不适合作为了解和学习敏捷的切入点

Scrum在中国被认为是敏捷（Agile）的代名词，Scrum强调快速迭代，敏捷（Agile）就成了快速迭代。我们对敏捷的错误认识，很多都来自Scrum。但不能说Scrum不敏捷，只能说Scrum不适合作为了解和学习敏捷的切入点。

很多人对我说再过几年会有新的软件开发模式出现，敏捷也会过时，我认为Scrum作为敏捷（Agile）的一个方法，或许会过时，但敏捷不会。敏捷不是一种方法，而是以敏捷宣言为核心和基础的一套理念和价值观。

Scrum出现的时间恐怕比敏捷还早，到今天仍有人对Scrum是否符合敏捷理念提出质疑。我认为作为工具，Scrum让具备敏捷理念的人使用，就符合敏捷理念；被不具备敏捷理念的人使用，什么可能都有。所以更需要学习的，是敏捷理念，而不是工具。

对敏捷理念的学习很困难，因为理念太过抽象，很难找到一套方法让学习的过程变得容易些；一个工具或方法的学习却容易得多，很多培训机构利用这一点，把Scrum培训作为敏捷培训的敲门砖。如果方法或工具是硬件，理念就是软件。硬件更新了，软件不变没有用的。

3

敏捷的敲门砖就是敏捷宣言

敏捷理念的核心是人，所以敏捷宣言的第一条就关于人，“个体和互动高于流程和工具”，个体与个体的价值是第一位要考虑的，流程与工具则是一般的组织里最重要的因素。以个体和个体价值为核心的团队应该怎样组织和管理？只有自组织和自我管理。换句话说，团队是围绕个体和个体价值建立的，传统的组织（模式）正好相反：个体要围绕组织的目标或计划展开工作。

怎么保证自组织的效率？乱套了怎么办？敏捷宣言第二条：“工作的软件高于详尽的文档”，工作的软件让团队里每个人都清楚的了解目前团队的问题和挑战，每个人自我管理的目标，都指向“工作的软件”，“工作的软件”就是德鲁克经常提到的“成效”，知识工作者每个人的工作都应该指向“成效”，而不是给上级或客户的文档和汇报。

交付有压力怎么办？来自上级或客户的压力，最终会传导给每个团队成员，团队还能保持“独立和自我管理”吗？客户和上级必须参与到项目中来，和团队一起对价值的交付负责，而不是作为甲方，通过合同施压，这就是“客户合作高于合同谈判”。客户如何参与项目或合作？ODC模式，而不是“Project based”，已经为我们提供了最佳实践与可行的方案。

不久前还有同事争论，一个迭代内的需求能否变化？在一些培训课程里说，Scrum方法里，迭代内需求不能变化，Scrum Master负责保护团队，保证迭代内的需求不变。那就违背了敏捷宣言的第四条：“响应变化高于遵循计划”，培训课程里的说法里，同时还违背了敏捷宣言第三条“客户合作高于合同谈判”。只要有利于价值的交付或者“客户的竞争优势”，团队在任何时间都应该“欣然面对变化”。

敏捷和传统模式从方法上完全分开，并且能够更高效的完成项目，是通过对成效的不断追求完成的。它不去定义项目边界（合同），也没有严格意义的“计划”，但通过追求最优的成效，来完成比“计划”或固定“合同”更好的结果。