前几天写培训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条敏捷宣言，基本上会得到一片掌声；但如果向高层领导宣传这四条，多半会得到几个很难回答的问题。但价值观版本的敏捷宣言则是相对安全的。
如何运用“价值观”版本的敏捷宣言？
价值观版本的敏捷宣言可以看作是是否敏捷的底线。
比如当被问到一个似乎与4条敏捷宣言和12条敏捷原则相左的问题时，基于敏捷价值观可以找到或判断一个潜在的答案是否还“敏捷”。
当然这个判断有时候要动点脑筋，这也是为什么会存在敏捷的生态系统帮助迅速裁定。（请参考本版其他博文）
不过价值观版本的宣言有点空，应该在敏捷语境中去理解和应用。
尾声
1. 这两条价值观似乎除了敏捷之外其他方法也会推崇（至少不会否认），为什么这里称之为敏捷的价值观？
答：其他方法会更加推崇别的东西，如果只选择用20个文字描述整个方法，绝对不会是这两行。
2. 如果客户价值 不等于 公司价值，我应该怎么办？（比如客户执意要加需求还不给钱，应该敏捷还是不敏捷？）
答：额……如果一个公司无法把客户价值和自身价值绑定在一起，这个公司一定运营在相当危险的状态，这不是敏捷不敏捷能解决的问题。
这和讨论在发生核战争后是否应该继续使用敏捷开发差不了太多。
如果公司老板是市场、销售出身，请多听并遵从他的判断，他不大会在这种事情上吃大亏的。
如果公司老板是搞技术出身的，这个比较危险了，请他多听并遵从市场、销售的判断吧，能好一点。
