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