工作思考 —— 敏捷开发
Posted 汽车ECU设计
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了工作思考 —— 敏捷开发相关的知识，希望对你有一定的参考价值。
敏捷软件开发宣言
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
最近抽了点时间看了下IT行业软件开发模式中的敏捷开发，深有启发，其中的四条开发宣言引起了我的注意。也就是说，敏捷开发认为尽管右项有其价值，我们更重视左项的价值。然而在汽车ECU软件流程中又是怎么样的呢？很遗憾，我相信大公司应该都是 完全相反 地，今天我们来说说前两点。
个体和互动 > 流程和工具
很多企业却因为过度关注流程和文档，却忽略了最重要的东西，那就是工作的软件。从而导致软件delay却成为了家常便饭的事情。其实在软件释放的周期中，建模开发和测试其实只是占了一小部分。相互之间的沟通成本和流程文档耗尽大量工程师的effort。这里要更正一个误区，有不少人认为流程是软件的保障。这点我不同意，我认为应该是有用的流程才能真正的保障软件质量，套用二八原则来说，只有少数的流程才是真正有意义的，才能真正保证软件的质量。这是后话，我们以后再谈。
工作的软件 > 详尽的文档
我个人一直奉行一个观点：出现软件bug不可怕，及早修复最重要。在ECU软件开发中，软件是所有后续工作的前提。由于软件delay或者bug，经常会导致标定计划的delay或暂停。所以不能工作的软件，对于标定工程师和客户来说简直就是灾难。只有尽快的修复bug才能让标定计划得以保证，始终让自己的软件处于一个“被测试的状态”，而不是被标定和客户丢在一边长灰尘，更可最大程度降低客户抱怨。
可以看出，只有这个循环尽可能的快速，才能最大程度的保证软件周期以及软件质量。很遗憾，在开发阶段常常受制于一些无意义的软件发布计划以及发布的流程，大大延长了这个周期，导致软件delay频繁。
关于文档，包括OEM提供的规范文档，以及供应商在自身开发流程中留下的文档等。供应商这部分文档一般是不提供给OEM的，只是用于在内部审查以及开发者记录等。而在敏捷开发过程中，最核心的就是 工作的软件 ，只有在必要时才会编写文档：
Martin文档第一定律
直到迫切需要并且意义重大时，才来编制文档。
显然，随着ASPICE的普及，在未来OEM将更看重供应商在ECU软件开发中的文档，从需求的分解到测试，每一步都要记录，review，包括双向追溯，并保存文档记录。可见ASPICE 和 敏捷开发，两者相违背。如何协调两者的关系，将敏捷开发运用于汽车软件行业，还有很长的路要走。
▼ 长按以下图片 → 关注汽车ECU设计 ▼
还没关注的赶紧关注起来!!!!
以上是关于工作思考 —— 敏捷开发的主要内容，如果未能解决你的问题，请参考以下文章