前言
在写这篇文章之前，我曾天真地认为ASPICE和敏捷开发最大的区别在于：文档和条目化。
而ASPICE和敏捷开发融合的最大挑战在于：如何将汽车工程师习惯的文档，转化成条目化的结构，从而实现任务的原子化分配与追踪，基于敏捷冲刺，实现任务的迭代关闭。
不过，在与上百家客户进行深入地讨论之后，我逐渐认识到，以上只是挑战之一。事实上，二者之间，还有更多底层认知层面的挑战。事先声明：笔者深度参与过完全不同的两种团队的管理模式，对于二者都有亲身的实践。虽然个人情绪不可避免，但笔者还是希望能尽量站在客观的角度，对二者进行深入地流程拆解并分析，秉承批判思维，试图从批判的过程中，重新认识二者的优点和缺点。本篇文章不在于证明谁对谁错，而是通过在对标准理解的基础上，对流程进行极限拆解，引起读者任何一种流程实际落地的思考。
本篇文章为系列之一，下一篇文章，我会继续拆解Agile敏捷开发的流程细节。
1
ASPICE流程中的版本管理：
初衷与实现
版本管理的初衷
在ASPICE流程中，版本管理的核心目标是确保开发过程的稳定性和可追溯性。通过严格控制需求、设计、代码等文档的版本，ASPICE希望在开发过程中建立清晰的基线，以便在出现问题时能够快速追溯到问题的根源。这种做法在理论上是无可厚非的，毕竟在汽车软件开发中，任何一个微小的错误都可能导致严重的安全问题。
以下是大多数团队采用的常见做法，也是ASPICE流程的常见模式。
到此为止，上述流程都没有任何问题，运行得非常完美，大多数团队都能顺利执行。
接下来，是这个流程中的hard模式。
版本管理的“魔鬼地狱”
当确定了接下来一段时间的基线之后，团队进入开发阶段，假设距离发版截止日还有1个月时间。
假设开发的过程中，基线不存在任何变化，那么一切就都太“完美”了，直接基于基线中的需求、架构设计、测试用例执行完就好了，得到软件包v1。
软件包v1也与基线v1（即其中的所有文档版本），建立了关联。
但实际工程项目中，这种“风平浪静”的开发模式，永远也不可能存在（有杠精估计要说，应该一次把需求、架构设计、详细设计都写清楚，这样就不需要变更了。这类杠精，估计还没有在项目中真正磨练过）。
大部分时候，这一个月内会发生很多变化。
发现设计文档考虑不全面，需要修改
客户要求增加新需求
客户要求修改原需求上的某个逻辑
竞争对手推出新功能，产品经理希望废弃上个版本的需求，紧跟潮流，直接上新需求
......
此时，团队有两种选择。
就在当前基线，立刻开始执行变更流程
等待当前基线结束（1个月时间），在下次基线中加入上述变化
假设团队选择1，就在当前基线，立刻开始执行变更流程。团队有如下3种处理方案：
方案1：整个基线v1全部复制一份到v1.1，在其中需要更改的文件上直接更改，邀请CCB评审，直至通过
优点：操作方便，整体全部复制一份，不需要动啥脑筋
缺点：
中风险：一个基线中含有大量文档，每次变更都需要复制整个基线，随着变更次数增多，基线的版本越来越多,中心化的管理，导致文档数量急剧增多，系统速度变慢
中风险：难以比较任何两个基线版本的差异。这种方式是无脑把前一个基线版本整体复制，修改时直接在复制后的文档上修改，通过添加变更履历，解释变更细节。但变更履历往往仅能对变更进行概况描述，而无法完整呈现细节。且系统本身无法对两个基线版本进行字段级别的差分对比
高风险：如何选出受变更影响的其他文档，并一起改变，是难点，系统往往很难自动识别出变更受影响项，需用户手动识别，遗漏风险非常高，导致bug流出
方案2：把其中需要修改的文档v1.0拿出来，改成v1.1,邀请CCB评审，直至通过。作为补充文件，和基线v1构成一个整体
优点：只选择需要修改的文档，而其余不受影响的文档则不变，文档数量不会急剧增加，不会对系统造成很大开销
缺点：
高风险：难以保证后续真正实施变更的用户，在看基线的同时，也注意到变更，从而导致实际实现与基线有差距。需要建立变更与原需求之间的追溯性，并且要确保用户会注意到这个变更
高风险：如何选出受变更影响的其他文档，并一起改变，是难点，系统往往很难自动识别出变更受影响项，需用户手动识别，遗漏风险非常高，导致bug流出
方案3：把其中需要修改的文档v1.0拿出来，改成v1.1,邀请CCB评审，直至通过。并且用户在基线v1内，查看需求文档时，第一眼就看到v1.1，不能看到v1.0版本，或者需要主动跳转才能看到v1.0版本
优点：继承了方案2的优点，且避免了方案2中的缺点1，即实际执行变更的用户，第一眼看到的是变更后的内容，而不是变更前的内容，避免了实现不一致
缺点：
中风险：难以比较任何两个基线版本的差异。因为用户看到的基线中，包含了没有任何变化的1.0版本的需求，也包含了有变更的1.1版本的需求，这些1.1版本的需求，相比于1.0变了啥，比较难以查看
高风险：一个需求有了多个版本，加入基线时的v1.0版本，变更之后的v1.1版本，对于需求的状态推进、责任人管控都是难点
到此为止，我们注意到，无论是采用哪一种变更管理流程，都有不小的挑战。
此外，团队还面临着另外一个挑战：评审通过后的文档，阶段性定稿，加入到基线中，进行归档。而各类文档本身，不会就此停下来，而是还在持续更新。此时，任何一份文档都有了多个实体：不断变化的本体，以及被加入到各个基线中用于存档的复制体。同一份需求文档，内部可能包含几百条需求。每条需求，在不同的基线中，责任人可能不同、状态可能不同，没有被加入基线中的本体，责任人和状态也不同。如何来定义需求的真正责任人和状态呢？什么才叫是真正的需求关闭呢？是在基线中的某个版本关闭了叫关闭，还是本体关闭，才叫关闭呢？
相信分析到这儿，你大概已经理解了，想在当前基线内实施变更，是一件多么有挑战的事情。
这就是为什么那么多严格遵循ASPICE的团队，主观上不愿意，或者客观上难执行变更的原因。
那就不变呗，在下一次基线中再进行变更。那一次基线的开发周期是多长呢？上面我举的例子是1个月，但实际上应该是3个月或者更长。也就是说，3个月内，尽量不要响应变化！
10年前，德系车企和供应商大抵都是这么做的，可能现在仍然是这么做。德国汽车走下坡路的原因有很多，这里不做深入探究，但是，上述流程是否造成了下坡路的结果，读者自行判断。
上述整个流程分析的图示，我汇总如下：
2
什么是“伪基线”？
相信已经有很多读者被我上述描述的基线与变更流程吓到了。事实上，有很多汽车行业的流程质量工程师，都在其中深陷泥潭。
于是，有人想到了一个好方法：既然打完基线之后，变更这么麻烦，那么我是否可以在开发完之后，再打基线呢？比如规定5月30号要发版，从3月1号开始，需求、架构、详细设计、测试用例、代码，都在不断修改，直到5月28号，集成工程师编译出一个软件包，经过测试之后，发现这个包基本没什么大问题了，此时可以释放给下游了（比如甲方客户），此时再把需求、架构、详细设计、测试用例、以及所有的其他文档及软件包，都打包成一个整体，放入到基线中。
这种方法是否可行呢？
我觉得这种方法，打出来的“基线”，应该换个名字，叫“阶段性快照”。而此快照不是用于团队基于此做开发的，而是用于查看阶段性实现状态的。因此不具备“Baseline”的意义，也不存在在上面执行变更的需要了。
我暂且将其命名为“伪基线”吧。
他只是用于给甲方客户，以及评审老师一个交待，仅此而已。不具备任何指导开发的作用。
写在最后：作为一个多年来一直从事解决研发团队优化流程与效率工具的工程师，本篇文章难免代入工程师的个人经验与偏见，甚至还有一些信息茧房，欢迎大家在评论中理性讨论，也欢迎添加作者微信，深入探讨。
