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