我们通常所说的敏捷开发，一般都是指的敏捷实践，比如Scrum、XP、Kanban、Scrumban等，但是按照《Becoming Agile》对敏捷开发的定义：

敏捷是一种思维方式：由价值观定义，由原则指导，通过许多不同的实践体现。

敏捷定义

我们今天就来通过敏捷实践中可能遇到的一些小冲突，聊一聊敏捷的4条价值观和12条原则是如何指导敏捷开发的。

1. 敏捷价值观

---

1.1. 什么是敏捷价值观

大家可以登录敏捷宣言官网，自行查看敏捷的4条价值观，也可以直接看下面的截图：

敏捷宣言的4条价值观

1.2. 价值观如何指导敏捷实践

1.2.1. 个体和互动 > 流程和工具

• 可能的冲突

如果从《高效能人士的七个习惯》来看，个体是个体的积极主动，互动是人们的合作共赢。

个体与互动需要以平等的文化为基础。个体与互动的障碍是命令与控制的文化。在命令与控制的文化之下，人们处于压抑状态，聪明才智无法发挥。

我们可能经常会遇到的一个场景是：

这事领导说了算，我对大局毫无影响，所以我就不说了。

• 实践指导

有很多招式可以协助个体与互动在Scrum中发生：

• 故事点估算有促进每个人都说话的半强制作用。
• 在每日站会上可以加一个练习，随机一人复述大家讲的要点。
• 在每日站会上，可以随机一人充当一分钟项目经理，总结迭代目标、完成的趋势、风险、士气等。
• 在迭代评审会上，可以交叉演示他人的工作。
• 制定并落实结对、备份工作的计划。
• 在计划会上，随机一人总结迭代目标。
• 轮流一人主持会议，包括会前准备、会中引导、会后跟进。
• 在梳理会、计划会、评审会、回顾会结束时，现场快速调查反馈大家对会议的满意度。

1.2.2. 工作的软件 > 详尽的文档

• 可能的冲突

工作的软件背后是全局优化，详尽的文档背后很可能是部门墙。这样的文档形成过程漫长，而且花了很多时间在一些拿来推卸责任的内容上。

• 实践指导

Scrum中跟保证工作的软件有关的模式有：

• 每个迭代都要输出潜在可交付的产品增量。
• 通过DoD保证质量。
• 开发与测试融合，缩短反馈周期。
• 开发与测试融合，目标一致，减少考核上的冲突，减少在bug记录、传递、扯皮上的时间。
• PO与团队融合，即时验收反馈。
• 支持XP实践，加速反馈，提升质量。

1.2.3. 客户合作 > 合同谈判

• 可能的冲突

客户合作的障碍是不信任，以至于花了太多时间在工作量的计量上，反而无暇顾及价值和质量等。

• 实践指导

Scrum本身是不能破除合同墙的，但有很多有助于客户合作的机制：

• 每迭代演示可工作的软件。
• 产品列表、迭代列表等工件的透明。
• 产品列表梳理、迭代计划会、每日站会、迭代评审会、迭代回顾会等事件的透明。

1.2.4. 响应变化 > 遵循计划

• 可能的冲突

遵循计划带来的是虚假的安全感，背后的担心是如果不遵循计划，自己的诉求将无法被满足。

• 实践指导

Scrum在响应变化方面的模式有：

• 滚动的迭代计划可以吸纳一个迭代之后的任何变化。
• 持续的产品列表梳理确保变化能被及时理解，放置于合适的优先级。
• 长期稳定的全功能团队带来的协同效应有助于缩短学习期。

2. 敏捷原则

---

2.1. 什么是敏捷的原则

大家可以登录敏捷原则官网，自行查看敏捷的12条原则，也可以直接看下面的截图：

敏捷的12条原则

2.2. 原则如何指导敏捷实践

2.2.1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

• 可能的冲突

在全流程的上下游中，各部门各有自己的计划，没有共识的价值优先级，持续不断及早交付有价值的软件，无从谈起。

• 实践指导

Scrum模式：

• 以Product Backlog为载体，PO与客户对齐价值。
• 迭代交付。

2.2.2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

• 可能的冲突

同价值观四。

• 实践指导

同价值观四。

2.2.3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

• 可能的冲突

缩短迭代需要全局优化。

• 实践指导

Scrum采用一到三周的迭代。

2.2.4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。

• 可能的冲突

部门墙。

• 实践指导

Scrum有专职PO，并且有足够权威。

2.2.5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

• 可能的冲突

同价值观一。

• 实践指导

同价值观一。

2.2.6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

• 可能的冲突

保存证据推卸责任的文化，恐惧。

• 实践指导

Scrum五个会议。

2.2.7. 可工作的软件是进度的首要度量标准。

• 可能的冲突

同价值观二。

• 实践指导

同价值观二。

2.2.8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

• 可能的冲突

996是福报。

• 实践指导

持续改善与稳定步调相得益彰。

2.2.9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

• 可能的冲突

临时工心态。

• 实践指导

长期稳定团队。

2.2.10. 以简洁为本，它是极力减少不必要工作量的艺术。

• 可能的冲突

竖井工作模式。

• 实践指导

准确理解客户需求。

2.2.11. 最好的架构、需求和设计出自自组织团队。

• 可能的冲突

同价值观一。

• 实践指导

产品列表梳理、迭代计划。

2.2.12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

• 可能的冲突

同价值观一。

• 实践指导

迭代回顾会。

3. 结论

1. 当文化与Scrum的冲突不可愈合时：
   放弃Scrum，放弃敏捷，放弃持续改善。
2. 当文化可松动时：
   选择部分Scrum实践，尝试使用。持续改善，而不拘泥于Scrum。
3. 当文化与Scrum吻合时：
   团队可以一起讨论敏捷宣言价值观和原则哪些在自己的Scrum实践中做到了，哪些还没做到，如何改善。