项目经理不但要用管理实践掌控项目，还可以欢迎团队改变自己的技术实践，从而获得更大收益。本章包含的一系列实践，能为项目带来很多好处。项目经理和团队要根据自身的实际情况，判断如何调整、使用这些实践，而不要强制推行。如果你认为它们有所裨益，不妨将其介绍给团队，并欢迎团队积极尝试。

　　在项目中使用持续集成

　　开发人员用一两个小时编写一段代码，对其进行编译，测试，复查，构建，运行冒烟测试，并验证做出的改变不会破坏现有系统代码，再将其签入到代码库中。持续集成就这么发生了。

　　持续集成可以让开发人员马上得到所做工作的反馈。他们开始考虑将大任务拆分成更小的部分（这可以让他们以更快的步伐前进），还能尽早识别出项目的集成风险。持续集成让开发人员每天都能有所收获，帮助项目团队找到符合自己的节奏。

　　开发人员只有在完成了某个功能的代码后才将其签入，这就是按阶段集成的方式。有些开发人员一周签入一次代码。有些更糟糕的项目，开发人员一到两个月才签入一次代码。按阶段集成会打断项目的节奏。构建时出现的问题，会中断设计和编写新功能代码的人们的思路。他们不得不记住很多小细节，而这些小细节覆盖了从项目开始直到进行集成的各个阶段。如果忘记了这些细节，项目进度会放缓，因为团队发现了缺陷，而且必须想起可能是几个月前所写代码的细枝末节。这其实是一种同时处理多任务的方式，而且特别不容易发现。人们是在做同一个项目的工作，而且手上的任务可能也相关，但是思考问题时的抽象层次却有所不同（设计比调试的抽象层次更高），而且也不再是处理同一个功能的问题，思考问题的上下文由此发生了变化。所有切换上下文的代价都发生在这里，在设计下一个功能时，开发人员可能会因此而丧失好的想法，还可能增加向设计中引入缺陷的潜在风险。

　　频繁构建是为开发人员和项目经理准备的

　　如果你提出使用每日构建，测试人员可能会抱怨：“我们做不到以如此快的速度构建，只能每周构建一次。”频繁构建，比如每小时甚或每天，不是为测试人员准备的。频繁构建可以为开发人员提供反馈，同时让项目经理了解项目状态。

　　如果测试人员可以利用每日构建来运行测试，那就太棒了。不过即使测试人员做不到这一点，通过每天构建可工作的代码，并维持这样的节奏，开发人员也可以从中获得有价值的反馈。

　　如果项目经理不能将变更后的代码集成到代码库中，你可以采取持续集成的变种。假设你管理一个项目团队，大家的任务是扩展一个已存在产品的设计。团队目前正在处理的部分产品代码是整个产品的基础。如果这部分代码无法运行，那整个产品都不能运行。你现在不想签入代码，因为这样会破坏现有的产品，而且会占用三个月的时间来添加和替换产品的现有功能。你该怎么做？

　　应该选择现有状况下的最佳方案。你可以将主代码库做一个分支版本，并让所有开发人员在这个分支版本上开发。他们每次签入一些代码，都会与主线代码进行同步，保证自己的分支代码是最新版本。这使得开发人员总是在最新和最全的代码版本库上进行开发，而且他们一直都在进行集成。当他们完成各自工作后，就会将所有代码都合并回主线。

　　这是持续集成的一个变种。如果必须重写已经存在的代码，而且在开发变更代码时不想破坏现有系统，可以采用这种方式。如果项目经理管理的项目所提供的服务要为一组产品使用，比如一个程序库或是一个平台，这种方式同样适用。

　　不管使用持续集成与否，都应该为构建产品创建自动化冒烟测试。冒烟测试仅仅是为了验证要构建的版本没有问题。你想添加多少回归测试都可以，我不拦着，但是使用冒烟测试，是要知道当前的构建版本是否对大家有用。

　　有了自动化冒烟测试，项目团队就可以知道是不是有人破坏了当前构建版本。如果能尽早知道一个构建完成了，你就可以在其基础上做些自己想做的工作。要是必须依赖其他开发人员或是测试人员才能知道当前构建版本出了问题，那你就不能以最快的速度修复当前构建版本了。

　　别让烟跑出去！

　　作为测试人员，寻找问题是我的职责所在。而且，我也很擅长这个。我有一句座右铭：“别让烟跑出去。”

　　有一次，我加入了公司的一个新项目。开发人员以前从没有与专业测试人员一起工作过。我拿着一张有15个缺陷的列表，走到他们中一个人的面前，然后说：“你得说说这是怎么回事，要不我把这些问题提交到缺陷跟踪系统里面如何？”他们都惊呆了。

　　我向他们说明，这些缺陷通过一个自动化冒烟测试都可以找出来。没有哪个缺陷需要靠我的专业知识和经验才能发现。我不想浪费时间找出这些易于发现的缺陷，而是要找出更捣蛋的缺陷——时而发生的问题、系统可伸缩性上的问题和可靠性问题。我想钻到代码之中，把高难度缺陷一个个都揪出来，直到它们全部显形。

　　那个开发人员脸色发白，屏住呼吸说道：“呃，好吧，我希望你也能那么做。需要我配合你什么？”

　　我解释了我的座右铭：“你的工作是尽量保证不出问题。我的职责是尽量让问题血淋淋地暴露出来。明白了么？”他表示同意。我想我听到他跟别人说我有点嗜血倾向。不过，管他的，我对此毫无意见。

　　我签入了我的测试代码，开始构建自动化冒烟测试框架。开发人员开始一点儿一点儿地加入冒烟测试。如果我找到了一个冒烟测试应该发现的问题，就会冲到加入这个缺陷的开发人员跟前，对他说“别让烟跑出去”。不久之后，大家只要一看到我走向开发人员的小隔间，就会有人大叫：“是谁把烟放出去的？”

　　我们现在合作得非常好。这些开发人员的工作表现非常好，而且他们也让我能很好地完成自己的工作。我们的产品NB极了！（这么说没事吧？）

　　让构建版本正常工作，这对建立并保持项目的节奏大有裨益。能够第一时间发现构建版本出现问题，也使得项目经理可以将项目带回正常的节奏，或者发现是什么使得团队无法保持节奏。

　　实际上，如果项目的产品要在多种型号的计算机、数据库或固件上运行，要确保团队每天都为所有的平台编译并构建产品。如果不这么做，到了项目结束的时候，项目经理就得忙着解决那时才能发现的问题了。在项目中越早发现兼容性方面的差池，就越容易应对，而且开发人员在后面的工作中也能将其牢记在心。