敏捷的价值观：
-
个体和交互>过程和工具
-
可以工作的软件>面面俱到的文档
-
客户合作>合同谈判
-
响应变化>遵循计划
-
虽然上述右项有价值，但我们更重视左项
请注意这 5 条价值观中的最后一条：“虽然右项有价值，但我们更重视左项。”这一条其 实是对前 4 条价值观的解释说明，很多人在传递敏捷价值观时其实只讲了前面 4 句，而忽 略了最后这一句，很大程度上，这导致了大家对敏捷的误解。
敏捷重视可工作的、有价值的软件，减少一切不必要的文档。注意，是不必要的文档，而不是所有文档。
正确理解敏捷的基石
12 条敏捷原则：
-
我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
-
即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
-
经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔 越短越好。
-
在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
-
围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
-
在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
-
工作的软件是首要的进度度量标准。
-
敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
-
不断地关注优秀的技能和好的设计会增强敏捷能力。
-
简单——使未完成的工作最大化的艺术——是根本的。
-
最好的构架、需求和设计出自于自组织的团队。
-
每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
敏捷的实践方法:
- 极限编程
- Scrum
- 特征驱动开发
- 动态系统开发方法
- 自适应软件开发
- 水晶方法
- …….
规模化敏捷的方法：
- SaFe
- Less
这些方法从共性上来说都遵守了敏捷的价值观和原则，不同的是它们针对了不同的应用场景，比如说 Scrum 在新软件开发中更好用，而看板在维护类的软件开发中更胜一筹。
总之，
敏捷 = 价值观 + 原则 + 一系列符合价值观和原则的方法。
一点个人的思考,
从前在互联网公司，我们从来不谈敏捷，但是在不加班的情况下，每周都能发布新版本，有灰度发布，有线上数据跟踪产品质量，每个人都是整个产品的owner，看到不足就去优化，整个流程十分敏捷。
现在在外企，我们每天开站立会，做Scrum，号称是在使用敏捷，但实际上只能1个月发一次版本，没有灰度发布，线上数据不完善、不准确，每个人只能对自己负责的模块做修改，看到其他模块的优化点，也难以推进，因为团队的价值趋向似乎是:”这是不是我们的OKR？“。多个Global团队50个移动端工程师，和微信移动端一样的人数，却只做出了GooglePlay上两三星的产品。
敏捷的核心并不是敏捷的方法论、工具，而是小步快走，不断试错，快速反馈。这也是互联网公司们最值得借鉴的价值观。