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