工作思考——敏捷开发(1)

敏捷软件开发宣言

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

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

客户合作高于 合同谈判

响应变化高于 遵循计划

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

个体和互动 > 流程和工具

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

周而复始,无法自拔

工作的软件 > 详尽的文档

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

迭代开发模式

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

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

Martin文档第一定律

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

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

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

公众号:QCECUSJ

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

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181105G1PVH000?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

同媒体快讯

扫码关注云+社区

领取腾讯云代金券