是否有人可以发送有关在软件发布中引入最后一刻要求或范围的危险的文章？常识对吗？然而，忽视常识是人类的天性。
我有一群业务利益相关者声称在前世拥有所有这些“IT/软件工程”经验，但他们反复询问为什么他们不能在 UAT 期间甚至有时甚至在 UAT 之后增加范围。
最佳答案
并不少见的问题，是的，它发生了。 :)
我知道 COST 是固定的，因为客户不愿意为要求的额外范围支付任何额外费用。对吗？
如果是这种情况，可能这就是项目文件的“验收标准”出现的地方。 UAT 是否已被签署？如果是这样，您手头有一个更好的案例，可以将额外的范围作为一个需要额外时间和成本的增编项目。如果您没有明确定义的“验收标准”，则需要说服为什么这是一项额外的工作。
以上纯粹是从业务和成本的角度来看的。从工程的角度来看——是的，毫无疑问，由于涉及额外的规划、测试和“回归测试”、文档和交付周期，这会带来额外的开销。根据要添加的附加范围，可能还会进行代码重构。 “支持你的论点，软件项目的额外范围不仅仅是在多层建筑中增加一层，你可以只关注正在添加的新楼层。”也许您向您的高级管理人员或业务用户(任何您需要的人)解释这一点，以便至少从下一次开始将此类范围变更降至最低。 (请记住，它们只能在现实世界中最小化，不能像在理想世界中那样被取消)
稍微偏离您的问题，一天结束时 - 必须从所有不同的角度来看待一个项目 - 质量、时间和成本，您无法同时满足所有这些。因此，如果您是项目经理，您需要发表自己的意见——可能会根据具体情况要求额外的时间或额外的资源。与其在项目结束时受到打击，不如现在就承担责任并站起来，以便更清楚地了解范围和时间。
如果您下次需要更好地处理它，请查看这些承包模式是否对您有帮助 - http://www.derailleurconsulting.com/blog/three-contract-models-for-scrum-projects .
话虽如此，我也承认，在某些情况下，作为项目经理，我不得不接受有限的额外范围(无需额外费用)，在这些情况下，我将“客户满意度和客户保留率”放在首位别的。一旦客户与我们建立了长期关系，我们就更容易在范围界定问题以及如何花费额外的努力等方面说服客户。最终，我们无法摆脱业务规则和我们正在解决的不仅仅是一个工程问题。
关于testing - 最后一分钟范围变更？当然为什么不呢？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11691802/