1.4一个工作项数据库

1.4一个工作项数据库

Visual Studio Team System (VSTS)进一步发展了透明的产品待处理队列的概念（参见图1-6）。Team System使用一个公共的产品待处理队列来跟踪团队中所有的已计划的、活动的和已完成的工作，以及大多数关于此工作所采取的行动及做出的决策的历史记录。这些单元被叫作“工作项”，用户可以在Visual Studio、Microsoft Excel和Microsoft Project里的数据库视图中查看和编辑它们，同时将它们同步到一个公共数据库中。

 



图1-6 VSTS颁布并提供了过程，将源代码、测试、工作项和度量元联系在一起。工作项包括了项目中需要跟踪的所有工作，比如应用场景、服务质量的需求、开发任务、缺陷和风险。这些都可以在Team Explorer、Visual Studio、Microsoft Excel或Microsoft Project中查看和编辑

后面都是一个数据库，类似的工具将信息碎片组合在一起。项目经理、业务分析员、开发人员和测试人员不需要在随机分布的工件之间的剪切和粘贴，相反，他们看到的都是同样的工作，无论是预先已计划好的还是工作中临时安排的，无论是来自于很好理解的需求还是在修复缺陷时发现的（参见图1-7）。与相互分离的项目跟踪工具和技术不同，VSTS中的很多数据都能自动收集。

 



图1-7这是工作项在VSTS的Team Explorer或Visual Studio中显示的例子。注意：所有任务、需求和缺陷都显示在一个地方

因为VSTS使用了公共的数据库来跟踪工作项，它把数据提供给了Team Explorer，同样提供给了Microsoft Excel（参见图1-8和图1-9）。使用Excel和Project是为了方便，而非必须。所有的功能在Team Explorer中都可用，它是Team Foundation的客户端。如果你使用Visual Studio Team System客户端版或者Visual Studio Professional，那么Team Explorer则显示为开发环境内的一组窗口。

工作项的离线编辑、管理，和“What-If”假定分析

对于这些任务，要使用Excel或Project。工作时，你的文件存储在你的本地客户机。当你下一次与数据库同步时，这些变更会被写回Team Foundation，那时任何潜在的合并冲突会被加亮显示。与之相反，当你使用Team Explorer时，变更在会话期间就已保存到数据库中了。

图1-8使用VSTS时，在Microsoft Excel中可以显示和编辑相同的数据。所有工作项，无论什么类型，都存储在同一个Team Foundation数据库

 

图1-9你可以使用Microsoft Project，以完全双向访问Team Foundation数据库的方式来计划和管理部分或全部的工作项

Team System的可扩展性使得Microsoft的合作伙伴可以增加功能。例如，Personify Design的Teamlook使团队成员能够在Microsoft Office Outlook中查看他们在多个Team Foundation服务器上的团队项目。Team Foundation Server的扩展性使得Teamlook能够在熟悉的通信工具Outlook中跟踪工作项（参见图1-10）。

 



图1-10有了Personify Design的Teamlook，你就可以使用Outlook作为Team Foundation Server的客户端

为日常活动提供工具

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

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

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

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

简化观察

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

Project “Smells”

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

 



图1-11 度量元仓库收集了项目中所有行动的数据，从而提供将数据的不同来源和维度联系在一起的报表

  

图1-12x 轴标明了项目中的不同的构件；柱形显示了每个构件的测试通过率，点和线显示的是活动的缺陷数

基于图1-12，你得出什么结论？大概是Instore Pickup Kiosk代码的图形很完美，因此你会在其他地方寻找问题。

同时，依赖少量的度量元也是危险的。在图1-13中，同一轴上添加了代码波动（增加、修改、删除的代码行数）和测试的代码覆盖率（已测试的代码行或块的百分比）。

突然间，图形就被颠倒了。在Instore Pickup Kiosk构件中有很高的代码波动，而测试对代码覆盖没有达到所预想的程度。图1-13揭示出我们的测试已丧失了时效性，不能测试新功能。这可能就是为什么此构件虽然通过了测试，却没有覆盖实际代码。

图1-13 增加了构件的代码覆盖率和代码波动后，数据所展示的景象就完全不同了

多维度的度量元和味道

能够看到项目数据的更多维度是度量元数据库的一个直接的好处，度量元数据库从日常活动中收集和关联数据。它提供了一个用于追踪味道的量化、可视化的工具。采用这种方法，你能够达到在以敏捷方式工作时最严格的一致性报告所要求的可见性水平，对于远程项目，甚至离岸软件项目，你也可以得到与本地项目能得到的一样的可见性。