作为一个开发团队，我们面临很大的压力（内部），为我们的客户提供准确的发布日期。我们该怎么做呢？
我们看到的问题在于准确定义每个版本所需的内容，并且不知道在发布期间我们的优先级可能会如何变化。我们正在使用FogBugz并认为我们可以利用基于证据的调度来帮助解决不确定性，但我们不希望客户对置信区间感到满意。
我看到Fog Creek的政策是在实际发布之前，不会告诉客户哪些版本可用。还有其他人采用这种方法吗？
编辑：感谢您的回复 - 很难选择一个已接受的答案，所以我投了几票来给你业力。我选择了cowgod，就像我想要处理自己开发的方式一样。答案 0 :(得分：4)
对于我目前正在进行的项目，我们每周都会提供产品发布和质量保证（QA）发布。如果QA已经批准了前一周的部署，那么将进行生产，我们最新的错误修复和功能请求将打包发布给QA。我们无限期地继续这个过程。
我们有一个文档Wiki，可以使用客户端能够查看的最新发行说明进行更新。
答案 1 :(得分：3)
只是给出不同的观点：
我们发布了发布日期！
对于大型企业，您只能在周末发布内部产品，这意味着您可以快速了解：
a /只有52个 b /有一个很多的竞争来保留其中一个（物流团队是竞争对手之一，用于服务器和/或网络升级，并防止任何发布到生产，因为服务器可以被关闭在任何时候）
所以我们没有选择发布日期：我们一年只有少数几个，而且不太可能改变。
为了提供有意义的版本，我们在发布日期前几周定义了一个“顶级内容”会议，以便定义实际部分版本（目前的一些发展不会是在其中，因为它们被证明过于复杂，或者依赖于尚未准备好的其他部分，或者用于任何其他“优先”变更）
然后，发布经理确保所有团队在测试环境中合并所选择的开发项目以进行所有认证/ UAT /预生产测试周期。 （我在这里跳过很多细节）
然后我们交付。准时。 （然后做一些补丁;））
答案 2 :(得分：2)
如果您遇到这样的压力，让您的客户知道您何时发布，您可以尝试一些XP技术，例如让客户先决定他们想要哪些功能并进行TDD。
答案 3 :(得分：2)
当我参与准确说明发布日期的项目时，我们通过将功能划分为“此版本必不可少”和“可以下载到下一版本”，然后选择发布日期来完成我们非常自在，我们可以完成所有必要的功能，并认为至少有一些机会完成所有必要的功能。
当然，这提出了一个问题，即为什么我们甚至考虑不必要的功能，但在实际项目中，通常有几件事可以在一个方向或另一个方向上移动，根据（a）客户是否获得拟议功能的风采，如果是，他们是否喜欢它，（b）预计下一个版本将会多久以及客户升级的容易程度，（c）您的业务计划如何受到影响，现在是一个可销售的产品，或明年的真棒终极产品。
所以实际发生的是三个类别，“必不可少且预计仍然是必不可少的：如果没有按时完成，我们将被迫延迟发布”，“现在被认为是必不可少的，但我们可能会改变主意发布日期接近“，并且”暂时不被视为此版本，但如果时间允许，我们会将其推进“。
我参与过的许多项目已经运行很长时间，临时版本基本上是当前工作版本的快照。说“给出了一个准确的发布日期”就像是作弊，当实际发生的是客户要求更新时，您检查了该客户的活动错误列表，并发现您有两个影响他们的未决问题，他们花了一个星期的时间来解决这两个问题并进行验证，并告诉他们“我们会在1-2周内给你一个下降”。
答案 4 :(得分：2)
作为最常提供Fog Creek答案的人，我可以说我们的mouth wide shut政策非常聪明，但需要管理。几个月来，在管理层的祝福下，我想出了一些对我有用的东西，让我感觉不像是某个即将卸任的总统政府的阻挠成员，并且有助于给客户一些上下文而不会产生潜在的误导性承诺。
这是让客户知道我们在这个过程中的位置的问题。现在，我通常让他们知道我们现在正在积极编码，一旦我们达到代码完成，这还有一段距离，我们仍然需要QA，错误修复，QA修复bug，以及至少一对贝塔斯。
如果您向我询问FogBugz 7的发布日期，您可能获得的示例：
对于FogBugz 7，我们正在积极编码，相当于代码完成的时间。如果你有一个特别关注的问题，请告诉我，我会尽力向工程师强调它，或者如果我们有工程师的话，给你一个状态。一旦我们进入代码完成阶段，我们仍然需要完成QA，错误修复，重新QA和测试版的过程。我们很高兴地告诉您，如果我们在每一步都处于这个过程中，那么您可以跟踪我们的进度，但我们无法确定该流程何时完成。
答案 5 :(得分：1)
我们采取的方法是在完成之前不宣布发布日期。如果客户需要更早，那么我们会解释它的哪些部分已经完成，哪些部分没有完成。有时他们只有一个核心功能集，如果它是非常重要的功能，并愿意等待其他功能。根据我的经验，他们通常希望等到整个事情完成后再发布。
我很幸运碰巧在一个文化中，我们的发布会在事先发生时提前知道压力不大。
答案 6 :(得分：1)
谷歌也这样做，没有提供发布日期。
在一个项目中，关于版本，有三个因素可能会有所不同：
关于它们的所有常规yes / but / ifs（在时间上添加额外资源自然不会对你的项目产生帮助）。
如果您有固定的发布日期，则时间是固定的。这样，如果您改变其他两个项目，您只能正确管理项目：花费更多，或限制产品中的功能数量。
答案 7 :(得分：0)
我们不提供日期。我们只是问他们什么时候可以测试我们的发布。 （这通常给我们足够的时间来包装，因为没有人想要测试，他们都有自己的工作要做。）