汽车行业如何做基线管理？

在汽车行业，我们经常提到“基线管理”这个词，在ASPICE的最新标准中，Baseline一词出现了也出现了32次之多，有些项目经理，言必谈基线管理。

那么基线管理究竟是什么？为什么重要？是否可以选择不做基线管理？如果一定要做基线管理，我们应该怎么做？

我们试图通过这一篇文章，来说清楚这个话题。

首先，究竟什么是基线？

网上有各种各样关于基线的定义，在这里说一下我的理解：基线是一次项目任务的起点。

在大部分企业中，项目都是分阶段、多人协作执行的，特别在汽车行业。从大的整车研发生命周期来看，可能分为市场调研、概念设计、原型设计、产品定义、功能设计、架构设计、详细设计、功能实现、测试验证、生产、制造、售后与维修等过程。在每一个过程中，都会产生各种各样任务，甚至由多家企业协作完成。所谓的基线，就是每一个“过程”中的起点，在这个起点，包含了后续整个项目的所有要求、设定、规范等一切输入。需要强调的是，此处所说的过程，并不是指整车研发生命周期中的具体某个阶段，而完全是由项目组自己来定义的。也就是说，什么时候需要记录起点（即基线），完全是由项目组自己来定的。在软件开发中，大多数时候，我们会针对一个计划中的待发布版本，创建一条基线。

第二个问题是，为什么要做基线管理？

在项目中某个过程的起点，很多团队会召开一个 kick off 会议，告诉所有人这次任务的目标是什么，终点在哪里。但是，在项目执行过程中，目标可能会有所调整，执行方式也和我们最初设想的不一样，甚至需求本身都可能产生变化。虽然我们可以通过各种各样的努力，在一个项目开始之前，把需求想得足够清楚，任务分解得足够细致，但是，变化仍然不可避免。即使项目内容本身没有变化，但团队人员可能走走散散，一个人可能参与多个项目，也有可能中途去了其他项目组，或者有其他新成员加入。此时，基线已经发生了变化，仅仅知道最初的起点已经不够了，我们更关心的是，“当前这个时刻，我们的需求是什么”。所以基线管理的本质，并不是为了记录起点，记录起点太简单了，备份一下就可以了；基线管理的本质，是要记录项目进行的每一时刻的所有要求，以及相对于原始起点的变化。

如果中途的变化无法及时通知到每一个人，可能造成一种后果：需求变了，但是开发人员不知道；架构变了，测试人员不知道；测试用例变了，产品同学不知道；项目范围变了，项目经理不知道，导致项目无法按时交付。最后造成的后果就是，原本定义要做一台SUV，最后可能做成了三轮车，或者最初计划3个月交付，最后变成了3年。最初的需求和最后的实现南辕北辙。

既然变化在所难免，我们能做的就是去积极面对。虽然在实现目标的过程中，会产生一些偏移和变化，但是如果能记录在怎样的基础上，发生的何种变化，变到了哪儿，那么即使是变错了，也可以很轻易地调头回来，或者能在事后进行分析，是由于何处的变化产生了最终的后果。而如果没有项目开始的起点，就好像是脚踩西瓜皮，溜到哪儿算哪儿，既很难回到当初的起点，也很难做事后总结分析，也无法做回滚。

可能有人会说，在互联网开发，貌似没有基线的概念，也进行得很好。因为要随时响应市场的变化，市场需要什么，互联网人就做什么，比起知道起点在哪儿，他们更关心市场希望他们去哪儿。这种情况，其实不是不在乎，而是由于互联网的迭代速度足够快，几天一个版本，在很短的时间内，团队变化可以忽略不计，而任何目标的偏移，也不会立刻就遗忘，加上互联网的敏捷开发，特别强调人与人的快速沟通与信息同步。一旦下一个版本发布之后，上一个版本的起点，就显得不是那么重要了。

但是，这并不代表在互联网开发里面没有基线管理，而是基线管理可以短时存储在于每一个人心中，并且通过快速的口口相传，实现了信息传递，而忽略了纸面记录。所以，无论是快速迭代，还是做长期大型项目，都存在真实或者虚拟的基线管理。

从这里我们得出的一个结论就是：在一个多人的、中长期的项目中，不同阶段的周期可能比较长，这时候我们需要通过基线管理，来实现任一时刻的需求记录，以及相对于原始起点的变化。

基线管理究竟应该怎么做？

在这里我分享一些基线管理的原则。

1、一个地方能够存储项目进行中，“每一刻”的基线，即项目当前的最新需求。

前面已经讲过，基线管理不是简单的存储最初的需求，基线管理要解决的最核心的问题是，如何让团队所有人都能时刻知道，当前的最新需求是什么。

2、能够在有需要时，轻松反查项目最初的基线是什么。

如果对于最新的需求，任何成员有疑问，或者觉得不合理，那应该能随时支持他去查找：这个需求最开始什么样子的？中途在何时经历了什么变化？谁发起的这个变化？谁同意的这个变化？

3、基线存储好之后，允许增加、删除、变更需求，甚至是多个用户、随时随地提起变更。

既然变化是不可避免的，或者说从本质上来讲，基线管理不是为了记录“不变”，反而是为了“应对改变”，那么我们就要大胆拥抱变化。所以应该随时随地允许任何人去针对基线，提起变更请求。变更请求应该是并行的，也就是多人可以随时随地提起变更请求，而无需关注其他人是否也有变化。这一条道理说起来简单，做起来却很难，为什么？有些团队可能会记录每一条变更请求，会在该变更请求上详细记录变更要点，如果同意之后，则最新需求=此条变更请求+原始需求，对照着看，确定最新的需求。试想，如果两个人针对同一条需求提起变更，先后被同意，那么最新的需求应该是，原始需求+变更A，还是原始需求+变更B呢？无奈之下，只得串行。即A的变更被同意之后，B再在A的基础上提起变更。这在实际工程项目中是不合理的，极易造成阻塞。

4、原则上，变更一定要经过评审，没有经过评审的变更，团队其他人不需要知道，也无需做出反应。变更一旦通过，团队所有人都能被“通知”。

任何人发起的变更请求，一般来说，需要通知团队里面的几个关键角色进行评审。如果这几个人都评审通过之后，变更才算是真正有效的，才能对原始需求做出正式修改。而评审的范围有多大，应该多大，就看团队自己的决定。有些团队可能需要邀请每一个人。这在大中大型项目中显然是不合理的。所以一般会指定几个人，指定一个变更评审委员会，由他们来进行作出决策。但决策完之后，所有人都应该轻松知道这个决策，而无需关心决策的过程。

5、如果团队一致同意变更无需经过评审，直接通过，也需要支持，这是团队自己的决定。

有些团队的变更非常快。如果所有变更都需要经过评审，这个时间可能会很长。虽然在有些工具上，比如 MappingSpace 里面，变更评审已经完全做到了线上并行评审，但仍然存在等待评审结果的时间。有些互联网开发团队会充分放权，他们也有变更，但是他们相信每一个人的技术能力，并且他们也希望可以快速响应需求的任何变化。只要有变更，就进行快速的线下沟通，确保所有相关人员都知道。这当然也可以，所以我们也需要允许。不过一定需要技术兜底。这个兜底是什么，就是第6条。

6、无论是上述哪种情况，经过评审或者不经过评审，后续都需要能够追溯到，从基线起点开始，经历了哪些新增、删除、变更，以便事后追溯。

这个过程应该是自然而然的，而不是需要工程师去各个地方翻箱倒柜，找到最初的存档，找到中间变化的每一个过程。工程师应该直接找到这条最新的需求，在其基础上，就能轻松看到其变化的具体过程。万一发现变更的过程不对，可以轻松地回到正确的道路上。

作者介绍：

罗宇超，云体科技创始人，软件质量工程师，工具链工程师。