目前比较流行且为大家所熟知的敏捷开发方法有XP、KANBAN、Scrum、Lean等等，敏捷开发方法一般提供了一系列的基于敏捷思想的最佳实践，比如XP编程中的结对编程、重构、测试驱动开发、持续集成等优秀实践。以上这些敏捷方法中，大家最为熟知、企业应用最普遍的可能是Scrum了。严格上来说，Scrum并不是具体的敏捷开发方法，而是一种敏捷框架，它定义了一个敏捷骨架。
不同的敏捷开发方法
不同于其他敏捷方法另外一个特点是：Scrum不仅仅适用于软件开发
成功的实施敏捷开发给企业带来哪些收益
调查显示最常见的收益包括：
- 更好的管理变更优先级
- 提升项目透明性
- 更高的产出
- 提升团队士气
- 更短的产品上市时间
- ......
<code>"如果，你只是停留在敏捷的理论和僵化的指导性实践，这可能对你的公司或团队没有太大收益。""如果能够结合企业现状，不断的尝试和持续改进，那么，敏捷就会给你的公司和团队带来收益"/<code>
敏捷和传统软件开发方法的选择
敏捷开发方法和传统软件开发方法各都有各自的特点，选择敏捷还是传统开发方式要具体情况具体分析。例如，如果项目环境和需求比较稳定、技术可控性强、项目周期短、项目复杂性和风险比较低，选择传统软件开发方式往往更适合。相比，如果技术可控性比较低、需求易变、不太熟悉的新项目等等，可能敏捷开发方法更为合适。
敏捷 vs 传统软件开发
敏捷开发方法同样适用于汽车行业
Scrum、KANBAN、XP等敏捷方法/框架在汽车行业已经有比较多的应用。需要说明的是，这些敏捷的落地并不是完全的照搬，而往往是结合企业现状进行的 "定制化" 的敏捷。以Scrum为例，没有企业会完全在企业中完全照搬全部的Scrum模型，而是会采用Scrum中适合企业业务现状的实践，同时进行额外的扩展以适应企业研发特点。
<code>"之前也探讨过类似的问题，定制化之后还是敏捷开发吗 ？个人观点是，定制化之后可能不再是纯粹的敏捷了，但，只要是遵循了敏捷哲学(参考敏捷的核心价值观)，依然可以认为这是 "敏捷" 的。"/<code>
敏捷实践覆盖了ASPICE部分过程实践
我们比较敏捷和ASPICE其实没有太大意义，因为二者本质上属于不同的事物。敏捷，是一种软件开发思想，旨在提供 "更好的软件开发方法"，其衍生出了指导性的原则、敏捷开发方法和框架以及一些最佳实践。ASPICE，是用于汽车行业的软件过程改进和能力评定的标准，其关注点在软件过程改进和能力评定，提供了过程改进和能力评定模型。
敏捷和ASPICE并没有明显的冲突，二者可以共存，就好比是Scrum团队依然会应用极限编程中的实践。敏捷方法和实践支持了一部分ASPICE中的过程，但是要在敏捷实践和ASPICE之间做一一映射不是件容易的事情。
以MAN.3项目管理过程为例，敏捷实践如下：产品清单、燃烧图、发布计划、DoD、冲刺计划、冲刺清单、冲刺评审、每日站会、回顾会议等。
以SWE.4软件单元测试、SWE.5软件集成和集成测试过程为例，敏捷实践：TDD、持续集成和自动化测试、产品增量、重构等。
但是，ASPICE有些过程需要增加一些特定的敏捷实践才能支持：
以SUP.1质量保证过程为例，以下是需要考虑的方面:
- Srum框架中仅包Development Team、Scrum Master和Product Owner三个角色。质量保证过程需要项目级别的、独立QA角色，因此，敏捷需要扩展到项目级别，扩展新的QA角色以满足ASPICE要求。
- "可以工作的软件胜过面面俱到的文档" 是敏捷的核心价值观之一，弱文档是敏捷的特点，但在质量保证活动的证据需要被文档化。
敏捷和ASPICE适配中的一些问题
敏捷方法中的工件与ASPICE相关工作产品的同步。
敏捷有 "重个体，弱流程" 的特点，而ASPICE则 “重流程”。
敏捷的角色适当的扩展以满足ASPICE在项目级别的要求。
ASPICE评审需要证据支持，其中的一些活动和设计需要记录，另外，ASPICE中系统及软件架构设计和详细设计的文档化至关重要。
敏捷所提倡的短迭代，尤其是Scrum中2-4周的冲刺周期，在ASPICE中可能会有所不同。例如当扩展到系统级别时周期应该适当调整。
閱讀更多 瘋狂架構 的文章
