工作思考——敏捷开发（1）

敏捷软件开发宣言

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

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

客户合作高于 合同谈判

响应变化高于 遵循计划

最近抽了点时间看了下IT行业软件开发模式中的敏捷开发，深有启发，其中的四条开发宣言引起了我的注意。也就是说，敏捷开发认为尽管右项有其价值，我们更重视左项的价值。然而在汽车ECU软件流程中又是怎么样的呢？很遗憾，我相信大公司应该都是完全相反地，今天我们来说说前两点。

个体和互动 > 流程和工具

很多企业却因为过度关注流程和文档，却忽略了最重要的东西，那就是工作的软件。从而导致软件delay却成为了家常便饭的事情。其实在软件释放的周期中，建模开发和测试其实只是占了一小部分。相互之间的沟通成本和流程文档耗尽大量工程师的effort。这里要更正一个误区，有不少人认为流程是软件的保障。这点我不同意，我认为应该是有用的流程才能真正的保障软件质量，套用二八原则来说，只有少数的流程才是真正有意义的，才能真正保证软件的质量。这是后话，我们以后再谈。

周而复始，无法自拔

工作的软件 > 详尽的文档

我个人一直奉行一个观点：出现软件bug不可怕，及早修复最重要。在ECU软件开发中，软件是所有后续工作的前提。由于软件delay或者bug，经常会导致标定计划的delay或暂停。所以不能工作的软件，对于标定工程师和客户来说简直就是灾难。只有尽快的修复bug才能让标定计划得以保证，始终让自己的软件处于一个“被测试的状态”，而不是被标定和客户丢在一边长灰尘，更可最大程度降低客户抱怨。

迭代开发模式

可以看出，只有这个循环尽可能的快速，才能最大程度的保证软件周期以及软件质量。很遗憾，在开发阶段常常受制于一些无意义的软件发布计划以及发布的流程，大大延长了这个周期，导致软件delay频繁。

关于文档，包括OEM提供的规范文档，以及供应商在自身开发流程中留下的文档等。供应商这部分文档一般是不提供给OEM的，只是用于在内部审查以及开发者记录等。而在敏捷开发过程中，最核心的就是工作的软件，只有在必要时才会编写文档：

Martin文档第一定律

直到迫切需要并且意义重大时，才来编制文档。

显然，随着ASPICE的普及，在未来OEM将更看重供应商在ECU软件开发中的文档，从需求的分解到测试，每一步都要记录，review，包括双向追溯，并保存文档记录。可见ASPICE 和 敏捷开发，两者相违背。如何协调两者的关系，将敏捷开发运用于汽车软件行业，还有很长的路要走。

▼ 长按以下图片 → 关注汽车ECU设计 ▼

公众号：QCECUSJ

还没关注的赶紧关注起来!!!!