现在，越来越多的企业和软件从业者都接受了“敏捷”概念。在我做持续交付咨询的时候，也可以听到客户能够把“敏捷宣言”倒背如流：

“个体和互动高于 流程和工具

工作的软件高于 详尽的文档

客户合作高于 合同谈判

响应变化高于 遵循计划”

如果，这就是你知道的“敏捷”的全部。那么，你对“敏捷”的认识还没有及格，在我做咨询的过程中，会发现以下几个常见的遗漏点：

1. 所谓“敏捷”，指的是“敏捷软件开发”

“敏捷宣言”的网址是：http://agilemanifesto.org/直译就是:敏捷宣言.非盈利组织。

但实际上这个静态网站的标题确是“Manifesto for Agile Software Development”，即“敏捷软件开发”的宣言。所以，当我们讲敏捷的时候，指的是“软件开发”。软件开发不包括软件的设计和维护。但敏捷的价值观已经向上游的设计阶段和下游的维护阶段延伸。带来的分别是“用户故事”和“DevOps”。

关于用户故事，大家可以参考《用户故事与敏捷方法》，《精益设计:设计团队如何改善用户体验》

对于DevOps，大家可以参考https://theagileadmin.com/what-is-devops/ 实际上，在DevOps兴起之前就有敏捷系统管理和维护的概念了。

2. 不要忘了右项的价值。

很多人往往在说敏捷宣言的时候漏了最后一条。即：“尽管右项有其价值，我们更重视左项的价值。”

这点的关键是，“敏捷软件开发宣言”是一个价值观。在该价值观的引导下，我们选择左边的价值。但不是忽视右边的价值。“敏捷就是没有文档”，“敏捷就是没有流程”，“瀑布流程和敏捷势不两立”都是不正确的认识。

敏捷的价值观让我们减少了时间——这种不可再生资源上的浪费。而这些时间上的浪费表现在不能更早的交付有价值的软件上面。因为软件开发是一种成本和风险都很大的团队活动。如果不能尽早的兑现价值，这些软件开发的工作就是最大的浪费。

个人认为，敏捷的实践是一组工具箱，这组工具箱中的每个工具实践都是解决特定问题的。传统的瀑布流程中有很多的东西可以用敏捷工具箱里的工具改进。纠结于“敏捷是不是完整”也是一种“不敏捷”的表现。毕竟，“个体和交互 高于 流程和工具”。

此外，“敏捷”是一个价值观，而不是一种制度。

3. 知道价值观，还要知道“敏捷软件的12条原则”

在敏捷宣言后面的第一条，是一个几乎被所有人忽略的链接，这个链接就是“敏捷软件的12条原则”：http://agilemanifesto.org/iso/zhchs/principles.html

1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。（没有最快，只有更快，用快速的工具和技术交付软件。）

2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。（需求变动没事，反正代价比较小。）

3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。（越快让客户给软件提反馈最重要。首先是“能工作”，其实是“正确的工作”，最后是“工作的好”。如果不能工作，就是浪费时间，把最痛苦的事情最先做。）

4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。（经常沟通和理解，避免出现期望偏差。）

5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。（KPI这种东西就是基于“不信任”而设计的。）

6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。（邮件，IM，电话都不是很好的沟通方式。）

7. 可工作的软件是进度的首要度量标准。（只有能用了，才知道接下来该干什么。）

8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。（响应变化，缺少资源就要增加，避免工作被阻塞，否则都会打破步调。）

9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。（敏捷不光求“快”，还要求“好”。不要为了快，把好的实践都抛弃了。）

10. 以简洁为本，它是极力减少不必要工作量的艺术。（简单即是美，能不要的都不要。敏捷的软件犹如罗丹的雕塑。）

11. 最好的架构、需求和设计出自自组织团队。（不要让不专业的人士指导专业人士该怎么做，“He/She can He/She Up”。）

12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。（反思（回顾会议）是让团队成员之间更加明确方向和暴露状态的的最好形式。此外，敏捷的团队是没有“屌丝”和“码农”的）

这12条原则也是指导敏捷实践和工具的原则。当你“站会”，“Kick Off”，“Code Review”，“Pair”，“Retro”的时候，想一想是不是遵循了这12条原则。如果没有遵循，请用这12条原则审查自己的敏捷实践吧。

好了，你的“敏捷”知识及格了吗？