答主在2016年写了这个答案:写工业等级代码是怎样一种领会？, 其时也比较年青，基本上是以抱定“工业规范必定是宝物”的心态写的那个答案，能够说其时答主对aSPICE和ISO26262 part6 的流程推崇备至，可是这些年逐渐有了些新的感悟。

　　答主这几年也是比较崎岖，公司换了两家，部分换过四次，在中、美、德、英四个国家的轿车软件部分作业过，才智了不同的流程和文明，令我惊讶的是，一切这些公司、部分和项目，有一点是相同的：都是国际前五名的轿车零部件供货商哦，竟然历来没有一个项目彻底遵从了aSPICE和ISO26262 part6流程...

　　注重我的不少童鞋也在轿车行业：有一家算一家，别管您是国内的、国外的，国企仍是外企，传统车厂仍是新势力，主机厂仍是零部件，有哪位能告诉我你们是严厉依照这两个流程来开发软件的？我真的很想知道。

　　这就阐明问题了。我初步考虑，或许不是这届项目办理不可，而是这些流程呈现了一些问题，现已不太习惯现在的轿车软件开发，特别是HAD（Highly Assist Driving）大布景下轿车软件的开发了。在此，我想结合我的项目经历，谈一谈我了解的实践的软件开发流程。现实上，咱们许多部分现已初步在做这方面的实践，并取得了不错的效果。

　　首要，结合我自己的专业，我想谈的是轿车行业里大型（超越一百万行代码）、严重安全体系（safety-critical system）软件的开发流程。业界对此有现已两个流程规范：ISO26262 part6 和aSPICE。前者现在是发布轿车相关软件有必要恪守的规范，而后者基本上只要群众、戴姆勒等几家德国车企才强制要求（从我和他们打交道的状况来看，我都很置疑他们自己内部遵不恪守这些流程..）。

　　关于这些流程的扫盲贴能够看这个答案：写工业等级代码是怎样一种领会？， 相关细节这儿就不重复了。

　　我在这儿想评论的，是一种与灵敏开发相结合的V型开发流程。这并不是我随便生造的，而是我在实践项目中部分实践过的流程，很期望在这儿和咱们沟通。

　　无论是ISO26262 part6 仍是aSpice，它们的中心都是“V型开发流程”，说白了便是个变形的瀑布（Waterfall）流程。

　　吹到天上，架构规划也要等软件需求文档冻住了才干进行，而单元规划要等架构规划文档冻住才干初步。每一级依靠上一级的完好输出作为本级的输入。讲真，在实践项目里，真的十分简单窝工！一旦软件方案或许资源上有一点变化，比方需求暂时改变，或许架构师被领导暂时抽调，那真的是产生连锁反应，整个项目后续都受影响，最终便是无穷无尽的加班。

　　再者，现在商场的实践状况便是，软件需求是永久不或许冻住的！V型流程树立的根底都快没有了。现在HAD功用许多上马，OEM们分秒必争逐鹿蓝海，甭说造车新势力，便是传统主机厂，也是不或许比及功用彻底想了解了、写好了再把完好的需求文档给你的。往往都是先搭个结构，有个大致主意，需求就发布了。紧接着便是一遍一遍的沟通、测验、修正，咱们都在抢时间，每周都有新功用进来。就这，你还盼望软件需求有冻住的一天？！做梦呢。往往是上一版刚冻住，后续还没打开，新需求就又来了，一切人都溃散。

　　第三便是“人”的问题。这个问题很影响项目施行，但我历来未见有帖子仔细评论过，所以想多写点。许多注重我的童鞋都是业界人士。我想问问你们，在实践状况里，上图的6到11这些环节中，您觉得那个环节最重要、薪水最高、最有意思、领导最注重、最简单升职/换岗啊？

　　毫无疑问是7和8，架构规划和功用单元规划对吧，没悬念嘛。那么哪个环节或许职位最不受注重、薪水最低、最无聊单调、最不简单换岗啊？6软件需求/需求工程师啊，彻底没作业开展嘛。大一点的企业乃至爽性外包了对吧，咖喱味的需求有没有？

　　现实便是，做软件需求工程师和测验工程师的童鞋，凡是有经历、有才干、有时机的，都会尽力转成操控工程师或许架构师，这家公司转不了，哪怕换岗也要转。说句得罪人的话，您公司里的需求工程师，是不是相对来说，都是对产品不那么了解、经历不多，或许水平欠佳的搭档在担任啊？

　　可是，要命的是，依照V型开发流本来的界说和初衷，最最重要的职位恰恰便是需求工程师。需求是一个项目的底子，是项目履行的榜首级，能够说全部的全部都是环绕软件需求打开的。一个水平欠佳的需求工程师，不到位的了解和水平欠佳的需求文档，往往会给项目带来灾难性成果，有些乃至是后期补偿不了的。我想这一点童鞋们或多或少都有领会。

　　在评论完坏处今后，为了改善流程，咱们要明晰一下V型流程的中心，把它们保存起来，取其精华去其糟粕。

　　就像我在之前文章里论说过的， V型开发流程的中心有两个：1.完结分层次的测验和验证和2. 树立完好的可回溯性。这两点是必定要保存下来的。否则在软件发布今后，底子就无法经过ISO26262或许aSPICE的检验审阅。

　　分层次的测验，也便是单元测验（Unit Test）、集成测验（Integration Test）和硬件在环测验（HIL Test， Hardware in the loop），这些是有必要的，无法省掉也无法变化。可是，为了提高流程的灵敏性，在文档的完好性和可回溯性上，咱们能够适作为一点退让。V型流程要求每一过程都要时间树立完好的文档和可回溯性，然后才干进行下一过程。依据实践项目经历，我以为，这一要求能够放宽到“在老练软件发布的时分，具有完好的文档和树立可回溯性”。用浅显的话讲便是从准则或许从流程上答应“先写代码后补文档”的做法，或许说，“文档、代码一同写”。

　　当然，这种退让必定有一个条件，便是项目团队有充沛的沟通和项目组长有明晰的结构，从我的实践项目经历来看，这是不难做到的。

　　为了处理传统V型流程的的坏处，我在项目实践中引入了一些灵敏开发的元素，比方Scrum master，Sprint，Kanban Board等等，这儿咱们暂时先不评论这到底是“真实的”灵敏开发仍是仅仅借用概念。

　　1.与原有的V型流程在成果上兼容。在老练的软件发布时，用新流程开发的软件相同具有完好的文档、完好的可回溯性以及完好的分级测验报告。新流程彻底不影响原有的项目审阅和质量操控。

　　2.新流程右侧（测验侧）不变，而左边（规划侧）由瀑布式开发变成了“灵敏式”开发。各个过程从本来的次序进行变成以Sprints的方式齐头并进，最大极限地提高灵敏性。

　　项目组长扮演Scrum Master的人物，安排例会。例会上需求工程师、架构师、根底软件工程师、应用层工程师（操控工程师）每人论述本周的发展，对新需求或新修正项达到一起知道。这种知道是经过非正式的方式，比方口头沟通、演示来达到，并经过email和会议记录的方式（而不是冻住的完好文档）明晰固定下来。随后组长明晰这周的使命，并设置要害结点，构成一个Sprint，每位工程师初步完结自己规划的使命，发现问题快速反应，这是并发的。

　　当要害结点到来的时分，再次例会，组长检查发展并依据新需求拟定下一个Sprint的使命。这样跟着Sprints的进行，最终会构成完好的需求文档、规划文档和代码，一起完结可回溯性文档。随后全部就和传统V型流程相同了：交给集成工程师进行集成，随后进行各级测验。

　　为了完结这种新流程，软件团队的人员架构也需求做必定微调。项目组长与需求工程师、架构师、根底软件工程师、应用层软件工程师组成一个灵敏开发小组，而软件集成工程师和测验工程师需求在灵敏开发完毕后才出场作业，不再归于某个开发小组，而是为一切小组服务。

　　需求留意的是，这种架构对项目组长提出了十分高的要求。高并行意味着各位工程师在履行自己使命时分或许会有抵触。组长必定要有才干协调好现已产生的使命抵触，而且还要有才干预见未来的抵触；另一方面，因为每个工程师的使命毕竟是含糊界说的（没有冻住的文档），组长要有大局掌控的才干，并和每位工程师流通沟通并承认工程师现已充沛了解自己的使命。

　　能够说，组长的才干是能否完结新流程的一个关键。不过我的参加过的项目中，这是实践完结过的。而我自己也做过项目组长，新流程并没有杂乱到无法完结。

　　能够说，新流程的优势是显着的。首要，新流程灵敏性大大添加，窝工状况缓解。每位工程师在每个Sprint的初步就（以“含糊”、非正式的方式）明晰了自己的使命——如前所述，这种使命以Email、会议纪要的方式固定，以和组长的沟通来确保正确性——不用再等候自己前级的输出。就算架构师消失一周，其他工程师照样能写自己的代码/文档。架构师消失只会影响他自己的发展，最终只要架构师自己加班而不是连累全员加班。

　　其次，新流程不用等候需求文档冻住。客户给一点咱们就做一点，客户要改、要加料，研制团队能够从流程上随时奉陪，十分符合现在造车新势力和自动驾驶相关研制的节奏。

　　最终，新流程必定程度上能够补偿需求工程师的缺位。在String的履行中，使命分配能够比较灵敏。本因由需求工程师承当的使命能够分配一部分给其他工程师。比方与客户的沟通、技能谈判，对需求的剖析和承认等等，假如需求工程师才干满足，则这是他的本职作业；假如需求工程师才干、经历欠佳（这是遍及状况），则这部分作业能够分配给架构师、操控工程师来完结，而让需求工程师退化为一个把文字打进DOORS体系里的打字员或许文档收拾员...（这也是从咱们的项目实践里无法的总结出来的）。

　　新流程也有着他的下风。比方，高并行意味着对一切工程师都提出了更高的要求，无论是经历、技能仍是团队合作都要求愈加严厉，这无疑对企业是一个新的应战；特别是项目组长，更是必定要由经历丰富的职工担任，导致小企业里或许没有满足数量的职工能够担任组长。然后，组长假如消失了，比方病了、或许换岗了，对项目会有相当大的冲击。

　　您甭说这比方还真产生过。曾经有一次一个项目组的英国组长接连度假三周（不得不说欧洲人假日便是多....）,导致项目发展缓慢，气得客户打电话过来谩骂.....不过这应该是企业全体考虑的问题，比方设置第二组长等等。

　　这篇文章我想写给有必定根底的轿车软件从业人员，所以中心假如有解说不行详尽的当地还请见谅。也能够留言提出定见让我修正。在此答主也是抛砖引玉，期望和咱们一起沟通～