什么是现实（但快速）的beta版本计划？

Question

我的团队即将部署我们的应用程序，我们即将与部分精选客户进行内测。我想知道生成新的beta版本的实际时间表是多少，以及我们可以实际预期需要多少这样的周期才能调用第一个版本足够稳定以便发布。

应用程序本身是一个医学成像应用程序，因此它绝对不会崩溃或损坏数据。许多用户也将连续每天使用该软件至少四到八个小时，因此我预计会很快遇到正常的用户错误。该应用程序与特定的硬件相关联，如果他们有硬件，他们将需要此应用程序或以前版本的应用程序来运行他们的硬件。

当然，现在，现在也有来自上方的压力释放它！因为他们支付我的薪水，所以我不得不遵循他们的指示，尽管我对快速释放有任何疑虑。

我认为可能会出现以下情况：

1. 两周的周期时间。我们有一组精选用户，比如三到五个网站，当他们遇到错误时，我们会修复它们。我认为这个周期时间非常快，但我已经可以感觉到它将会是那个想要部署的力量。对于这种方法，我们将产品锁定到特定的构建，以及我们在下一个版本中修复的任何累积错误（之后可能会有50个版本）。
2. 六周的周期时间。我们拥有相同的用户组，但该组可以增长，并且随着它的增长，我们的行为与步骤1相同。不如1快，但肯定更加谨慎。问题是，用户可能会觉得产品过于错误（如果他们遇到错误），并且在我们发布另一个版本之前不会产生这种印象，此时他们可能不再关心。由于我之前提到的硬件已经锁定，因此这种商业模式的印象可能只会转化为温和的抱怨，而不是失去销售。但是，每个较新的测试版都将比上一个更加审核。
3. 只要修复了错误，就可以将固定版本交给用户。我们有一个构建服务器，我们有几个测试人员，我们很快回复（你甚至可以说，'敏捷'）。只要修复不破坏软件需要的其他一些行为，我们就像修复错误一样快速发布错误修复是否有缺点？如果我们采用这种方法，我们会做周期，还是只做一个beta'时期'？

我意识到这些问题因用户而异，并且像暴雪或Gmail测试期这样的东西有点长。我仍然希望能够全面了解我应该如何回应管理层关于测试应该持续多久的问题。

Answer 1

在您的第一波反馈来自最初的测试版发布之后不久，这似乎是一个问题。如果客户一般都很满意，而且问题更具结构性而非结构性，那么可以计划更短的测试版。如果您发现相反的情况属实，那么准备管理层将为更长时间的β测试阶段做好准备。

我不知道您的应用程序的具体细节，但我认为设置的发布计划将更容易让您的客户跟上。当客户确实发现了一个高优先级的问题时，很高兴听到解决方案已经存在，并且只要不是几个月就可以在2周甚至6周内完成下一个版本。 “补丁”除非极其严格，否则会导致更多问题而不是解决问题，因为客户的代码库奇怪且差异很大，这将导致很难重现问题。

Answer 2

使用数字1.毫无疑问，这可能是最好的方式。由于周期时间长，＃2显然不理想。 ＃3很诱人，会给你带来难以置信的麻烦。原因如下：如果您根据需要将修复程序部署到需要它们的任何人，那么您将完全失去任何合理的版本控制方案，并跟踪哪个客户有哪些修复程序以及哪些版本最多是棘手的。

Answer 3

在我们的案例中，我们让客户的反馈决定了我们的周期。在发布初始测试版后，我们会听取反馈意见。有时会出现灾难性的错误，我们会停止推出测试版，修复它然后恢复。 Othertimes，我们根据客户的重要性收集错误，然后在抱怨消失后推出更新。最终，客户的感知是最重要的（参考速度），因此平衡他们的投诉与管理层想要的是棘手的方面。在我们的例子中，我们通常会根据错误的数量和紧急程度在2-4周的范围内进行。

Answer 4

我见过一对一的发布时间表。第一个版本是计划的，更大的，包括功能，aybe 6-8周或有时更多。第二个是计划的修正，间隔2周。因此，每10-12周您就有2个版本。