需求可追溯性：七个悄悄拖垮项目的错误
无法追溯的需求，就是无人负责的需求。在那些跑偏的项目中，原因很少是一开始缺了某个想法，而是那根线索的缓慢丢失——它把相关方最初的需要，与回应它的设计、实现它的工作、以及证明它的测试连在一起。等到有人察觉时，团队已经在为范围争论，测试计划也早已与当初约定的内容对不上了。
可追溯性不过是一种纪律：让这根线索在两个方向上都保持完整——向前，从需要到交付的功能；向后，从一项工作回溯到它存在的理由。在团队分散、优先级不断变动的两年疫情之后，这根线索比以往更容易断裂。过去隔着办公桌就能确认一条需求的人，如今要跨越时区、借助聊天工具来做这件事，那些原本顺带完成的小确认，就这样不再发生了。
团队在哪里弄丢了线索
把需求文档当成终点。 一份获批的规格说明让人很有成就感，于是被归档遗忘。但需求会贯穿整个项目。如果没有任何东西把每条需求与随后的设计、构建和测试连起来，文档就沦为历史记录，而非可用的工具。
缺乏唯一且稳定的标识。 若靠段落编号或某人记得的某句话来指代需求，文字一经修改就再也追不下去。每条需求都需要一个简短、固定的编号，能在改写和重排后依然有效。
让设计与测试脱离源头。 设计决定匆忙作出，测试按开发者的理解写就，二者都没有回指当初为其背书的需求。几个月后，没人说得清某项功能是正确的，还是仅仅存在。
接受变更却不重新追溯。 变更请求获批，构建随之更新，但受影响的需求、设计和测试从未重新审视。覆盖率悄然出现漏洞，唯有生产环境才会暴露。
把冗长的任务清单误当作可追溯性。 详尽的任务清单只显示人们在做什么，而非为何而做。若每项任务与某个需要之间没有联系，再忙碌的团队也可能交付大量没有任何相关方真正要求的工作。
把矩阵做得过重。 相反的失败：可追溯性矩阵繁重到无人维护。如果更新它比干活还费时，它几周内就会过期，并且比没有更糟，因为人们还在信任它。
交给工具而非交给人。 软件能保存这些链接，却无法在需求变动时判断出需要一项新测试。必须有人把覆盖率当作一个持续存在的问题来负责，而不是一次性的设置。
让线索保持完整
目标是一种轻量、诚实、团队真正会持续维护的追溯。给每条需求一个稳定的编号。维护一个简单的矩阵，向前把每个编号链接到它的设计、构建和测试，并确认你能反向阅读——从任意一项测试回到它所服务的需要。最重要的是，把重新追溯纳入你的变更流程：当一条需求移动时，关联的设计和测试要在同一时刻一并审查，而不是拖到最后。
从第一天起就带编号地记录需求，而非在交付后期补救式地加上。
在每个里程碑审视覆盖率：每条需求都应抵达一项测试，每项测试都应抵达一条需求。
尽早标记孤儿——没有测试的需求，或没有需求的测试，都是需要回答的问题。
把矩阵保持得足够小，让团队无需被人催促就会更新它。
做得好的可追溯性是安静的。它很少出现在进度报告里，因为那些让线索保持完整的项目，正是不会爆出戏剧性意外的项目。这份没有戏剧性，本身就是全部意义所在。
如果你的团队正为范围、覆盖率，或证明交付物符合约定而苦恼，XNM 的项目集与项目交付咨询服务可以帮助你建立经得起审计的可追溯性。