为日常活动提供工具

  透明的待处理队列如此有用是依赖于精确的数据。通常，收集数据完全成为一个主要活动，这一活动依赖于大量参与者的意愿一致性。在实践中，这种对于簿记工作的纪律化的关注很少保持不变，尤其是在那些强活动期间。

  具有讽刺意味的是，团队所需要的大多数数据与已被软件管理的其他活动是直接有关系的。开发人员签入（check in）源代码，编译器解析源代码，测试人员编写和运行测试，他们的活动都已经在Project、Excel、缺陷数据库或工时单中进行了跟踪。如何才能自动地收集数据、关联它们并使用它们来度量过程呢？

  Team System采用了以下方法。它为团队成员的日常活动提供了工具，从而不需要额外开销就能收集过程数据。例如，每次当一个开发人员将修改完的源代码签入到版本控制系统中时，工作项便会被更新以反映出哪些任务和应用场景被此代码更新了。这种关系被概括在一个“变更集”（changeset）中，当下一次构建运行时，它识别出所包含的变更集，并使用构建号来更新工作项。执行测试时，测试使用相同的构建号。这样，测试结果、源代码变更和工作项就都被Team System自动关联在一起了（参见图1-11）。

  除了保证待处理队列的及时性和可见性，自动化数据收集还将那些能够以日为基础从多个维度显示质量的趋势和比较的度量元填充到数据仓库中。正如销售或生产进度等数据仓库所提供的商业智能功能那样，数据仓库为软件开发过程提供了智能。

  简化观察

  有了数据仓库，一些基本的问题就容易回答了：项目是否按计划进行，或者它离结束还有多远？计划变更了多少？谁的工作完成了，谁的工作未完成，谁的工作需要重新平衡一下？我们应该用什么速率来估计剩余的工作？我们的测试的收效如何？很多项目经理都乐于运用坚实的数据来回答这些基本问题。当数据收集自动化了以后，这些问题的答案就都直接明了了。

  Project “Smells”

  更有意义的是，大多数项目经理乐于找出那些被数据指示出可能存在问题的盲点区域。这就是我们现在常说的“味道（smell）”，即代码的可疑区域。对于整个项目的问题也往往表现为一些难以阻止的味道，现有的度量元还不能很好地揭示这些味道。我将在第9章中更详细地讲述味道，现在我们只是分享一个普通的例子。想象一个显示了你的缺陷率和测试通过率的图（参见图1-12）。