敏捷宣言：主义？价值观？口号？再谈敏捷生态系统

你的名字 2023-08-17 15:49 92阅读 0赞

前几天写培训PPT，突然发现不知道把敏捷宣言放在那里好。

因为看上去，敏捷宣言中既有体现价值观的内容，也有直接的操作层面上的内容。大家请看（前后删除了一些）：

个体与互动 胜于 过程与工具

可工作软件 胜于 复杂文档

用户协作 胜于 合同谈判

响应变化 胜于 遵循计划

如果感觉看不太明显，那么我们来两个对照版本，就会感觉更加清晰。

**“价值观”版本的敏捷宣言**

客户价值 胜于 软件和文档\#1

受激励的个体 胜于 过程与工具\#2

\#1是关于需求管理的价值观，包含了多层含义，基本上是4条敏捷宣言的后3条+其他，包括：

1.1 可工作软件 可以向客户交付价值、验证价值是否被实现

1.2 用户协作 保证软件更好地体现客户价值

1.3 响应变化 产生客户价值

1.4 按优先级交付 全包客户价值最大化

1.5 迭代式交付 确保价值交付

……

\#2是关于计划管理的价值观，很接近原来宣言的第一条，包含了：

2.1 开发团队自己估算 产生激励

2.2 时间盒 产生激励

2.3 同行压力（以跨职能团队而非个人进行估算和跟踪） 产生激励

……

**“操作”版本**

就是上面的1.1……2.1等，很接近。

操作版本很接近敏捷12原则，没什么新意。尽管这些原则是“原则”，但某些情况下某些原则可能得不到实现，但你依然可以继续敏捷。

但价值观版本的宣言就不同了，不能违背。

本文的目的，是推广前面提到的“价值观”版本敏捷宣言。

--------------------

“价值观”版本的敏捷宣言到底有什么用？

“价值观”比4条式宣言更接近敏捷的精神层面，换言之，很多敏捷操作都可以违反但依然可以称为敏捷，但如果无法体现敏捷价值观，就真的不是敏捷了。

请看下面两个经常被问到的问题（请先尝试在4条老版本的敏捷宣言找答案）：

1. 进度质量成本需求你砍哪个？

2. 在固定需求固定价格的合同项目里边可以采用敏捷吗？

别看“价值观”版本的宣言更简单，但答案却更容易找到。

1. 需求。因为需求是唯一可能被砍却不太伤及客户价值的一个（因为多数需求都不常用）。延期一倍，缺陷多多，成本超支，每一个对客户或公司都可能是不可忍受的。

2. 可以。倘若项目一切顺利，敏捷能使客户得到更多价值（更贴切更重要的需求）；倘若项目延期、超支，敏捷能最大限度保证老板能拿回一部分尾款（因为我们手里有一个客户能使用的有价值的产品）；如果老板没有办法用部分需求拿回部分尾款，则敏捷使他更容易判断距离完成所有需求还要多久；如果到了山穷水尽的状态，敏捷使得客户更可能选择给部分钱买部分功能凑合实现一些价值（何况是真正重要的那部分价值）而非鱼死网破，但我还没听说客户给部分钱买设计文档的……

再来看几个被问过的问题（也是先尝试在老版本的敏捷宣言找答案）：

3. （政府）客户执意需要一个WORD版本的需求才能结项，即使我们认为没有必要，因为我们软件都做完了给客户用上了，怎么办？

（补充信息：客户很重视这些文档吗？是的，会有他们上级的审批、备案，否则项目无法向上级报告结束。）

答：显然，这些文档对客户很有价值（无论我们怎样理解），所以这是要向他们交付的“可工作产品”的一部分。当然，既然是有价值的，在签订合同的时候，请向他们就这些文档的编写报价。

4. （游戏研发，策划=PO）策划人员让我们开发某些功能，但评审会上他们看了产品后不满意，把这个功能给砍了，让大家积极性很受挫，怎么办？

答：对“满意不满意”而言，不需要一个真正“可工作的产品”（测试过-无缺陷-随时可以上线的），因此应该提前商量实现到什么状态策划可以判断是否满意，以最大程度节省工作量。而由于知道不需要一个“可工作的产品”而是“可帮助判断研发方向”的产品，团队对于功能的命运会有所心理准备，并为“这个功能被砍掉”而感觉交付了价值（因为避免了走向错误的方向导致玩家流失）。这是一个典型的“客户价值 胜于 可工作软件”的例子。

注：EA等厂家均有“可工作产品”的不同标准，因为游戏产品总是变化太多，方向模糊。

再来看看下面这个笔者设想过又否定了的开发模型（估计Ken也想过但也否定了）：

5. 这个模型基本和Scrum相同，唯一的差异是：没有Sprint，大家总是开发最高优先级的需求；当中途……其实没有中途，因为没有Sprint……发生变更时，PO会找到Team，描述一个新的需求，设定其优先级，并按优先级“插入”到Backlog中；团队仍然自行估算工作量，PO也接受；比这个需求更优先的需求不会受到影响，而不优先的则被打断（如果开始了）或推迟（如果没开始）。

分析：这个模型完全符合老版本的四条，在“响应变化”上甚至更胜一筹，但是？

但是这个模型中缺少因时间盒产生的激励，人们整体缺少里程碑的感觉，找不到点停下来看看自己的承诺是否完成了。而且由于预期可能有更优先的功能出现，团队可能会对已经完成估算并设定了完成日期的任务漫不经心。

BurnDownChart因为长期无法到底，使人们缺少冲刺感觉。

再看看一个相关的问题：

6. 在Sprint中不允许变更，但是如果真的来了一个点子，能让原来的某个功能更好（或让原来的某个功能被放弃，注意是某个而非整个Sprint），怎么办？被问了100遍的问题了，绝对是Top5的最常见问题。

答：无论选择变更（正如5中所提，下次大家知道会变，就不再承诺完成了）还是不变（眼看着自己在开发一个不好的功能-下个迭代就会被推倒重来；或者明知道功能会被扔到，还继续开发……）都会对团队积极性有所打击，所以？

所以最好的方法是MosCoW方法，就是把Sprint中的功能分为一定要、最好有、关键时刻可以放弃的三类（你不会认为真的还有一类是：必须没有的把？呵呵），若发生变更，接受并扔掉最后一类。前提是，Team总是从第一类开始做。这样两个价值观都被保护了。

--------------------

如何看待原来的敏捷宣言？

感觉，敏捷宣言更像是口号而非核心价值观的描述。打个比方，“打土豪分田地”、“土豆烧牛肉就是~~主义”、“住瓦房穿绸缎吃细粮”都是口号，易于理解，应者云集，不过只是体现但不等同于核心价值观。

因此理解敏捷的时候，不应该把敏捷宣言当作判断是否敏捷的最终标准，也未必是放之四海皆准则的口号。

比如如果对程序员宣传4条敏捷宣言，基本上会得到一片掌声；但如果向高层领导宣传这四条，多半会得到几个很难回答的问题。但价值观版本的敏捷宣言则是相对安全的。