敏捷社区对正式可追溯性矩阵的讨论

在敏捷社区中，正式的可追溯性矩阵（Traceability Matrix）常常引发强烈反应。Jorge Argus在敏捷测试组（Agile Testing Group）上发起了一个关于在敏捷项目中是否需要可追溯性矩阵的讨论，引发了广泛讨论。

可追溯性与可追溯性矩阵的区别

Brad Appleton指出，关键在于理解“可追溯性”（Traceability）和“可追溯性矩阵”（Traceability Matrix）之间的区别。可追溯性是项目的一种期望属性，强调信息的透明性和可见性及其相互关系。而可追溯性矩阵是实现可追溯性的一种可能方式。

质疑可追溯性矩阵的必要性

Michael Bolton认为，在考虑如何创建可追溯性矩阵之前，应先质疑其背后的原因。他指出，只有当存在丢失真正有价值的公司记忆的风险时，才需要可追溯性矩阵。否则，可追溯性可以通过多种形式实现，如对话、故事、战略主题、历史记录、日志、源代码、自动化测试、设计文档、每日站会、电子邮件等。

Scott Amber在其文章《敏捷需求最佳实践》中质疑了可追溯性矩阵的必要性。他认为，可追溯性矩阵的感知相关性在于能够轻松进行需求变更的影响分析。然而，由于项目中有许多经验丰富的人，他们详细了解项目的各个方面，因此无需矩阵也能实现这一目标。他进一步指出，可追溯性矩阵的总拥有成本（TCO）远超过其带来的好处，除非有实际的法规合规需求，如FDA的CFR 21 Part 11法规。

可追溯性矩阵的高成本

Alistair Cockburn在Scrum开发组中引用了一项研究，表明在一个项目中，安装可追溯性工具和保持信息更新的成本极高，以至于客户从合同中删除了可追溯性要求。Brad Appleton也重申，手动创建、更新和维护可追溯性矩阵是展示可追溯性最耗时的方式。

自动实现可追溯性的方法

Ron Jeffries建议，最简单的方法是进行变更并查看哪些测试失败，从而了解影响范围。Mike Beedle则认为，在敏捷范式中，通过单元测试和验收测试可以实现从代码/设计到需求的可追溯性。Brad Appleton在其博客中提到，他通过TDD（测试驱动开发）在非常短的周期内工作，通过将故事名称或ID与提交关联，自动实现了可追溯性。

精益可追溯性策略

cmcrossroads在文章《精益可追溯性：策略与解决方案》中建议，如果有敏捷宣言的附录，它应该是“可信的透明度胜过繁琐的可追溯性”。文章指出，可追溯性的目标是实现透明度和识别，有许多可行的替代方案可以实现这些目标。团队应根据敏捷原则尝试实现精益可追溯性，例如使用版本控制和变更跟踪工具、任务驱动开发（TBD）、测试驱动开发（TDD）、简单的Wiki工具、基于事件的可追溯性（EBT）以及基于搜索的可追溯性等。

结论

大多数敏捷社区成员认为，维护正式的可追溯性矩阵是一种过度行为。团队应找出需要可追溯性矩阵的原因，并采用精益方法来实现可追溯性，而不是依赖繁琐的矩阵。