敏捷项目中的跟踪矩阵

有关正式跟踪矩阵的话题，往往能在敏捷社区中激起强烈的反响。Jorge Argus 在敏捷测试讨论组里发起了一个有意思的话题，讨论在敏捷项目里采用跟踪矩阵的必要性，引发了大家热烈的讨论。

Brad Appleton 认为，关键在于理解“可跟踪性”和“跟踪矩阵”的区别。可跟踪性，是指一个项目的某种期望属性，说明了诸多重要信息之间的相互关系，是项目保持一定的透明度和能见度。跟踪矩阵是实现可跟踪性的一种手段。

Michael Bolton 发表了类似的看法，他认为在着手采取创建跟踪矩阵的详细措施之前，必须要探究背后的原因。

有人想了解可跟踪性？他们为什么要跟踪这些信息？需要多久为他们提供一次信息？期望哪种形式的信息？什么样的信息格式对他们来说是可以接受的？还有，信息的价值和为此付出的成本是否匹配？

Michael 认为，只有公司的重要信息可能被忘记时，才用得到跟踪矩阵。如果不是这个原因，跟踪性可以用多种形式实现，例如谈话、故事、战略主题、历史记录、日志、杂志、源代码、自动化测试、设计文档、每日 scrum 会议和 email 等等。

Scott Amber 在文章《敏捷需要最好的实践》中，对跟踪矩阵的必要性提出质疑。他认为，通过跟踪矩阵的关联，能够很容易地分析需求变化所造成的影响。矩阵会显现出系统受变更所影响的方面。然而，即使没有矩阵也能很容易做到这点，项目中有许多经验丰富的成员，他们了解各方面的细节。Scott 补充道：

根据我的经验，人们对跟踪矩阵评价过高。因为要维护这个矩阵的总成本（TCO）远远超过了它能带来的好处，即使用专门的工具来做这件事情也是如此。要让项目干系人了解真实的成本和收益，再做决定。跟踪矩阵毕竟只是一个有效的文档，可以用来辅助业务决策过程。 […]

如果有明确的规章管理的要求，那我就对可跟踪性的作用坚信不疑。例如食品和药品监督管理局的联邦法规第 21 章 11 款，你必须遵守这些规定。如果可跟踪性仅仅是由“这是一个好主意”来驱动的话，我很怀疑它能否起到作用。

在 Scrum Development 讨论组内， Alistair Cockburn 引用了一个研究，来支持他的观点。

在一个（企业的 IT）项目中，我们特意研究了采用工具进行跟踪，以及通过人工来跟踪信息和更新的成本。我们发现代价高得惊人，客户也因此在合约中取消了对可跟踪性的需求。

Brad Appleton 再次重申他的观点，利用人工来创建，更新和维护跟踪矩阵，是展示可跟踪性作用的最耗时的做法。

那么是否有办法确保跟踪矩阵得到自动维护呢？

Ron Jeffries建议，最简单的方法是做些改变，看看哪些地方没有通过测试。这将会让开发人员了解哪些地方受到影响。Mike Beedle 也给出了类似的建议 。

根据敏捷的范式，代码 / 设计到需求的可跟踪性，是通过单元测试和验收测试来完成的。测试反映了对需求的追踪，因为它们要执行特定代码以实现需求。

Brad Appleton 在博客中提到了一种可能的解决方案，他使用 TDD 进行很短周期的开发。每个周期内的典型任务包括写测试、让代码通过测试、重构代码、提交修改。每次提交要带上将相关的名字和故事 ID。Brad Appleton 认为，通过这些短周期，可跟踪性会自然得到体现。

在文章《精益跟踪：战略和解决方案浅析》中，cmcrossroads 建议，如果敏捷宣言里还需要增加什么，那就增加下面这句话：

值得信赖的透明度超过令人厌倦的跟踪机制

这篇文章中谈到，跟踪性是为了达到透明和一致。要达到这个目标，除了正式的跟踪矩阵，还有其他可行的替代方案。团队需要配合敏捷原则才能达到精益跟踪的要求。文章中谈到如下一些选项：

• 要了解“可追踪性”和“追踪”并不是一回事
• 采用版本控制和变更追踪工具
• 在版本控制和变更追踪之间进行基本的迭代
• 基于任务的开发（TBD）
• 测试驱动开发（TDD）
• 采用简单的工具：Wiki，以及基于 Wiki 的规范框架
• 基于事件的追踪性（EBT）
• 基于搜索的追踪性——不需追踪的可跟踪性
• 简单基于搜索的可追踪性（“google 一下”）

Alistair 根据自己的经验，在邮件列表中发表了意见：

根据我 30 年来在商业，工业，研发和部分政府部门的经验，我从未见过采用跟踪矩阵能够收回成本的。 如果你有不同的经验，如果你通过创建和维护跟踪矩阵能够收回你在上面付出的钱，请告诉我们。

很明显，敏捷社区的大部分人相信，维护一个正式的跟踪矩阵有点过火。团队应该寻找建立跟踪矩阵背后的原因，采用精益方法来达到项目的可跟踪性。

查看英文原文： Traceability Matrix in an Agile Project