(source:Bing)

文/侯哥

在上一篇关于敏捷开发的文章《“敏捷”适用于汽车软件开发吗？》发出之后，引起了很多的讨论，阅读量也迅速的攀升。

有些朋友对于什么是敏捷还是有自己不同的看法，对于汽车行业是否应该采用敏捷也有着完全不同的看法。这种争论已经很久没有看到了，国内的汽车圈看起来很活跃，但是实际上却沉闷的很，大家都在忙着炒作概念，很少见到有对主流的趋势提出争议的声音。正如股市一样，如果所有人都在买买买，那么其实可能是到了该卖卖卖的时候了。

opinion often differs。

言归正传，关于“敏捷”这个被炒得火热的概念究竟是什么呢？目前国内大多数人所谈的敏捷开发基本上都指的是SCRUM方法。对于“敏捷Agile”这个概念本身，有些人觉得它是一种方法论，有些人觉得是一种哲学或思想，也有人说敏捷是一种瀑布模型的变形和应用。在敏捷宣言的网站上，“敏捷”被称为methodology方法论。

其实敏捷是方法论还是哲学都无所谓，你觉得它是什么它对你来说就是什么，如果你把它当做一种思想，那么你可以把它应用于任何领域。如果你把它当做一种软件开发的方法论，那么你就可以完全参考它去设计你的开发流程。对我而言，“敏捷”是一种思想，可以应用于很多领域的思想：无论是工程还是生活中，只要涉及到需求和交付，就都可以考虑是否应用。

关于SCRUM，公认的观点是：它和Adaptive Software Development（自适应软件开发）, Crystal，XP（Extreme Programming，极限编程），FDD（Feature Driven Development，特性驱动的开发）等都属于按照敏捷思想而产生的方法论（methodology）或行动框架（Frameworks）或是敏捷的一种具体应用形式。总之，SCRUM不等于AGILE，至少是不完全等于。

在此，我并不想给出究竟什么是敏捷的定义，因为这个东西过于复杂，不同的人、站在不同的角度、出于不同的目的、不同的经验等都会对其形成不同的认识和理解。无所谓对与错，只要自己觉得逻辑自洽也就足够了。

关于“敏捷”的个人观点：

敏捷是一种思想和开发哲学，可以应用于很多领域

标准的敏捷开发方法比较适合纯软件的开发项目，但其他的开发也可以适当的借鉴其中的思想和原则。

现代汽车开发流程早已经不是纯“瀑布开发”，实际上是多个改进型的瀑布模型多次迭代，从这个意义上来说，已经比较“敏捷”了，至少体现了多个敏捷开发的原则。

任何流程和工具也无法替代人的作用，好的流程和工具可以大大提升工作效率和质量。

生搬硬套的推行敏捷实际上是“削足适履”，结合自己的实际情况（人员规模、能力、业务特点、项目情况、市场情况等）而设计真正适用的流程和方法才是真正的敏捷，否则就成了“画虎不成反类犬”。每个行业、每个公司、每个项目都有自己的具体特点，想一劳永逸的靠一种方法来应对所有的问题是不现实的。只有那些能够因时、因地、因人制定不同策略与方法的管理者才是真正有智慧的、成功的管理者。

这里引用一句胡适的名言：多研究些问题，少谈些“主义”。

最后引用一句侯哥的名言：批判与赞扬都是简单的，能够针对具体问题提出有建设性的建议才是最难的。

附录:

下面翻译一篇文章（Comprehensive Guide to the Agile Manifesto，https://www.smartsheet.com/comprehensive-guide-values-principles-agile-manifesto）,供大家参考，请大家看看原味的“敏捷”是什么。

 

敏捷宣言的全面指南

是20世纪90年代行业挫折的结果。业务需求（客户要求的应用程序和功能）与满足这些需求的技术交付之间存在巨大的时间差，导致许多项目被取消。在这个滞后期，业务、需求和客户的要求都发生了变化，最终产品不能满足当时的需求。当时以瀑布模型为首的软件开发模式没有满足对速度的要求，也没有利用软件可以被快速改变的优势。

2000年，包括Jon Kern、Kent Beck、Ward Cunningham、Arie van Bennekum和Alistair Cockburn在内的17位 "思想领袖 "首先在俄勒冈州的一个度假胜地开会，随后于2001年在犹他州的雪鸟滑雪场的小屋开会。正是在第二次会议上，《敏捷宣言》和《十二原则》被正式写入。宣言中写道。

"我们正在通过实践和帮助他人来发现更好的软件开发方法。通过这项工作，我们已经开始重视。

1.个体和互动 高于 流程和工具

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

3.客户合作 高于 合同谈判

4.响应变化 高于 遵循计划

"也就是说，虽然右边的项目有价值，但我们更重视左边的项目"。（可以理解为V流程的右边是设计，左边是开发和验证）

敏捷宣言的四个基本价值观

敏捷宣言由4个基本价值观和12个支持原则组成，这些原则将敏捷方法引入到软件开发中。每一种敏捷方法都以不同的方式应用这四个价值，但它们都依赖于这些价值来指导高质量、可工作的软件的开发和交付。

1. 个体和互动 高于 流程和工具

敏捷宣言中的第一个价值是“个人和交互高于过程和工具”。重视人比重视过程或工具更容易理解，因为是人响应业务需求并驱动开发过程。如果是过程或工具驱动开发，团队对变更的响应就会较慢，也不太可能满足客户的需求。沟通是重视个人与重视过程之间差异的一个例子。就个人而言，沟通是流动的，需要时就会发生。在流程的情况下，通信是有计划的，需要特定的内容。

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

在历史上，大量的时间都花在为开发和最终交付编写产品文档上。技术规格书、技术要求、技术说明书、接口设计文件、测试计划、文档计划和每一项所需的批准。这个清单很广泛，是开发长期拖延的一个原因。敏捷并没有消除文档，但它以一种形式简化了文档，使开发人员能够在不陷入细节的情况下完成工作所需的内容。敏捷文档将需求作为用户故事，这对于软件开发人员开始构建新功能的任务是足够的。

敏捷宣言重视文档，但它更重视可工作的软件。 

3.客户合作 高于 合同谈判 

谈判是客户和产品经理制定交付细节的阶段，在这一过程中，细节可能会被重新协商。协作是完全不同的东西。对于像Waterfall这样的开发模型，在开始任何工作之前，客户通常会对产品的需求进行详细的协商。这意味着客户在开发开始之前和完成之后都参与到开发过程中，而不是在开发过程中。敏捷宣言描述了在整个开发过程中参与和协作的客户。这使得开发更容易满足客户的需求。敏捷方法可能会在定期的演示中包含客户，但是一个项目也可以很容易地让最终用户成为团队的日常成员，并参加所有的会议，以确保产品满足客户的业务需求。

4. 响应变化 高于 遵循计划

传统的软件开发将变更视为一种费用，因此应该避免变更。目的是开发详细,精心计划,与一组定义的特性和一切,一般来说,首要任务是一切,和大量的许多依赖于交付一定的顺序,这样团队可以在下一个拼图的工作。 

在敏捷中，迭代的短时间意味着优先级可以从一个迭代转移到另一个迭代，新特性可以添加到下一个迭代中。敏捷的观点是，变化总是能改善项目;更改提供了额外的价值。 

也许没有什么比“方法裁剪”的概念更能说明敏捷的积极改变方法了，在《正在使用的敏捷信息系统开发方法》中定义为:“一种过程或能力，在这种过程或能力中，人类代理人通过上下文、意图和方法片段之间的响应性变化和动态相互作用来确定特定项目情况的系统开发方法。”敏捷方法允许敏捷团队修改流程，使其适合团队，而不是相反。

12个敏捷宣言原则

这十二项原则是“敏捷运动”标题下的方法论的指导原则。他们描述了一种文化，在这种文化中，变化是受欢迎的，客户是工作的焦点。正如敏捷宣言的签署人之一Alistair Cockburn所描述的那样，他们也展示了该运动的意图，即让开发与业务需求保持一致。 

敏捷开发的十二个原则包括: 

1. 通过早期和持续的软件交付获得客户满意度——当客户定期收到工作软件时，他们会更高兴，而不是在发布之间等待较长的时间。

2. 在整个开发过程中适应不断变化的需求——当需求或特性请求更改时避免延迟的能力。

3.频繁交付可工作的软件——Scrum适应了这一原则，因为团队在软件sprint或迭代中运行，以确保定期交付可工作的软件。

4. 在整个项目中，业务涉众和开发人员之间的协作——当业务和技术团队保持一致时，可以做出更好的决策。 

5. 支持、信任和激励员工——有动力的团队比不快乐的团队更有可能完成他们最好的工作。 

6. 允许面对面的交互——当开发团队在同一地点时，交流会更成功。

7. 可工作的软件是进度的主要度量——向客户交付功能性软件是衡量进度的最终因素。

8. 敏捷过程支持一致的开发速度——团队建立可重复和可维护的速度，以交付可工作的软件，并且他们在每个版本中都重复它。

10. 简单性——开发足够的内容，以立即完成工作。

11. 自组织团队鼓励优秀的架构、需求和设计——拥有决策权、所有权、定期与其他团队成员沟通，并分享交付高质量产品的想法的熟练和积极的团队成员。

12. 定期反思如何变得更有效——自我完善、流程改进、提高技能和技术可以帮助团队成员更有效地工作。

敏捷的目的是使开发与业务需求保持一致，敏捷的成功是显而易见的。敏捷项目以客户为中心，鼓励客户指导和参与。因此，敏捷已经发展成为整个软件行业乃至整个行业的软件开发的总体视图。

source:https://www.smartsheet.com/comprehensive-guide-values-principles-agile-manifesto

---

作者: 侯哥@Roy 专注汽车电子电气架构开发

编辑: 文昌@Vincent 汽车信息安全从业者

---

往期文章

“敏捷”适用于汽车软件开发吗？

自动驾驶的纯视觉路线靠谱吗?

架构设计到底在做什么？

智能汽车会成为带轮子的手机吗？

汽车智能了，隐私安全呢？