在项目中某个过程的起点，很多团队会召开一个 kick off 会议，告诉所有人这次任务的目标是什么，终点在哪里。但是，在项目执行过程中，目标可能会有所调整，执行方式也和我们最初设想的不一样，甚至需求本身都可能产生变化。虽然我们可以通过各种各样的努力，在一个项目开始之前，把需求想得足够清楚，任务分解得足够细致，但是，变化仍然不可避免。即使项目内容本身没有变化，但团队人员可能走走散散，一个人可能参与多个项目，也有可能中途去了其他项目组，或者有其他新成员加入。此时，基线已经发生了变化，仅仅知道最初的起点已经不够了，我们更关心的是，“当前这个时刻，我们的需求是什么”。所以基线管理的本质，并不是为了记录起点，记录起点太简单了，备份一下就可以了；基线管理的本质，是要记录项目进行的每一时刻的所有要求，以及相对于原始起点的变化。如果中途的变化无法及时通知到每一个人，可能造成一种后果：需求变了，但是开发人员不知道；架构变了，测试人员不知道；测试用例变了，产品同学不知道；项目范围变了，项目经理不知道，导致项目无法按时交付。最后造成的后果就是，原本定义要做一台SUV，最后可能做成了三轮车，或者最初计划3个月交付，最后变成了3年。最初的需求和最后的实现南辕北辙。既然变化在所难免，我们能做的就是去积极面对。虽然在实现目标的过程中，会产生一些偏移和变化，但是如果能记录在怎样的基础上，发生的何种变化，变到了哪儿，那么即使是变错了，也可以很轻易地调头回来，或者能在事后进行分析，是由于何处的变化产生了最终的后果。而如果没有项目开始的起点，就好像是脚踩西瓜皮，溜到哪儿算哪儿，既很难回到当初的起点，也很难做事后总结分析，也无法做回滚。可能有人会说，在互联网开发，貌似没有基线的概念，也进行得很好。因为要随时响应市场的变化，市场需要什么，互联网人就做什么，比起知道起点在哪儿，他们更关心市场希望他们去哪儿。这种情况，其实不是不在乎，而是由于互联网的迭代速度足够快，几天一个版本，在很短的时间内，团队变化可以忽略不计，而任何目标的偏移，也不会立刻就遗忘，加上互联网的敏捷开发，特别强调人与人的快速沟通与信息同步。一旦下一个版本发布之后，上一个版本的起点，就显得不是那么重要了。但是，这并不代表在互联网开发里面没有基线管理，而是基线管理可以短时存储在于每一个人心中，并且通过快速的口口相传，实现了信息传递，而忽略了纸面记录。所以，无论是快速迭代，还是做长期大型项目，都存在真实或者虚拟的基线管理。从这里我们得出的一个结论就是：在一个多人的、中长期的项目中，不同阶段的周期可能比较长，这时候我们需要通过基线管理，来实现任一时刻的需求记录，以及相对于原始起点的变化。
最前沿的电子设计资讯
