一个需求在已经进入测试阶段时，还要改需求文档吗？为什么呢？

进入测试阶段，不代表需求就稳定了。

虽然传统研发流程极力规避需求的不稳定性，但愿望美好，现实残酷，需求变化才是常态。

因此敏捷研发提出拥抱变化，妥协的办法其实是我把研发周期尽可能缩短，在这个周期内还是尽量别改需求了。但说好咱不是排斥这个事，只是要改也不能随意改。

所以说，研发过程中，即便已经到了测试阶段，需求变化，实际上是一个无法规避的问题，这个原因太多了：

• 用户有了新想法，不想要原来的方案了
• 老板有了新点子，有个功能得调整
• 产品经理发现个重要细节没考虑到，要加进来
• 开发人员发现有个严重Bug没法改，要么改需求要么再等3个月
• 安全团队说有个新风险，要考虑到需求中
• 法务团队说有个模块不合规，要补充合规需求
• 合作方对接的模块不稳定，有些接口要重新定义
• .... 等等等等

另外还有很重要的一点，其实就是需求的传递，是有很大衰减效应的，不同的角色听到的，理解的，传递出来的以及最后实现出来的，可能千差万别。比如下图经常用来描述需求传递中的信息错位，非常形象

那这个就没办法了吗？

其实不管是传统研发流程还是敏捷方法，都非常强调对需求的清晰描述和传递到位。敏捷中对Story有INVEST原则的要求，需求精炼会、计划会其实也都是对需求本身理解一致性上的保证。

对于团队来说，其实就是在追求需求的确定性，所以在一定周期内尽可能保证需求的稳定是基本要求。

大家都认可的这个周期间，需求可以变化，但要作为异常处理，变化带来成本，成本要有着落，如此，规则清楚定义好，变化既然不可避免，那么只要成本能承受，就接受变化。