大多数人都曾经在这里或其他地方 - 在你的项目中，你会得到非常小的请求，你很乐意照顾，但在某些时候，小事情会加起来。有时候实施某些东西的时间比重新协商项目计划要少。
提供规格/要求计划是不错的，它不是一个注定的项目，你在什么时候吹哨并开始重新谈判？ 任何请求？当该请求需要其他页面/表单时？或者只是觉得它？很想听听你如何打电话。
答案 0 :(得分：12)
在项目计划中预算N小时的临时请求。 （你知道它会发生，为什么不在那里？）然后跟踪你的临时请求并在预算爆炸时重新协商。
答案 1 :(得分：4)
任何请求？
真正的目标是让顾客满意而不被扯掉，对吧？敏捷方法在很大程度上解决了这些问题。新的要求总是出现，如果你没有解决它们，你最终会构建过时或功能失调的东西。所以你需要的是客户对流程的支持，尽快的工作原型，以及大量的迭代。当然，还有一个吨更多，但这应该足够了。
编辑添加：客户支持意味着他们知道您正在使用新功能代替无论您将要做什么，并且他们达成一致。如果你已经完成了你的日程安排和预算而仍然没有完成，那么他们就一直和你在一起并且知道原因。没什么大惊喜“什么？你没有完成？！”
答案 2 :(得分：1)
我会说它什么时候会影响日程安排/发布日期。如果发生这种情况，那绝对是吹口哨的时候了。如果范围蔓延幅度足够大，或者如果有足够的累积变化影响您按时发货的能力，那么您应该推迟。
答案 3 :(得分：1)
预算爆炸的那一刻。你不能继续做所有这些“免费赠品”附加组件 - 除非你是为慈善事业做的。
一旦你把脚放下一次，你会发现请求变干了！
答案 4 :(得分：1)
我只是在这种情况下使用内部工具，我们的既定目标是在无法提前预测需求的情况下，最好地服务于我们“客户”的任何想法。所以，我的答案就是一点点。
我的观点是，这个决定通常都是政治性的，除非你是公司的负责人，否则它可能不会取决于你。不满意的顾客向你的老板过头的成本可能会更具破坏性。
我非常相信敏捷和持续的需求收集，其中包括了解用户如何使用产品，并尝试满足他们的需求。但是，每个用户都有自己的“善于拥有”，并且没有办法满足每个人。如果你有多个目标用户，民主是一个很好的系统 - 只能实现大多数用户可以从中受益的东西。
如果您的客户是一个有凝聚力的团队（例如，您是为特定组织中特定部门的用户制作的），请运行Wiki网站或类似SO或其他引擎，他们可以列出，然后协作投票可能的功能。明确表示您将优先（但不保证）更高级别的功能，并且您可能不会优先考虑那些未获得其他人投票的内容。
通过这样做，您可以让客户对想法应用一些协同过滤（或同伴压力）。您也将获得一些可见性，因此人们可以看到他们的愿望未被尊重的原因。一个重要的附带好处是，现在请求功能的任何人都有兴趣制定请求及其理由，以便他们可以让其他人投票给他们。这将消除一些愚蠢的半生不熟的想法。
当然，所有这一切的一个潜在假设是你预算了一些时间与任何支付项目费用的“misc功能”。
答案 5 :(得分：0)
估计完成日期更多的是概率曲线，而不是单个日期。
任何额外功能都会降低满足特定日期的可能性。
如果可能性下降变得“重大”或值得一提，你应该“吹口哨”。