商业软件是否应该采用“尽早发布/经常发布”策略？

Question

商业软件是否应该采用“尽早发布/经常发布”策略？

releaserelease-management

8

有没有人有在商业软件中早期发布/经常发布的经验/例子？这种方法有效吗？

我想到了VMware，他们在每个主要版本之间发布了很多修订版。安装体验很糟糕，有时候会破坏现有的虚拟机，其他时候，在客户操作系统内部的VMware工具可能会出现故障/无法安装。真是太可怕了。

我也想到ClickOnce部署，因为使用ClickOnce时，当您更新软件时，所有客户端都会自动收到发布通知，并且只需单击即可升级到新版本。如果您的软件存在错误，则它们将自动“升级”以获取这些错误。

您是否有应用“早期发布/经常发布”原则到商业软件的经验/例子/建议？

我正在寻求将其应用于其中一款软件。

- chakrit

6个回答

3

我认为这取决于你的市场或客户群。更改/升级软件始终是痛苦的，某些环境和公司可能更加痛苦。快速发布周期可能会带来干扰。这些干扰通常也会延伸到您的内部运营中，具体取决于市场/管理层如何管理功能膨胀。

因此，“这取决于”这个经典的真理再次响起。

如果您确实为产品增加了价值，那么客户尤其是新客户将需要它。最好的情况是消除升级更改的痛苦，即它的工作方式相同，但在明显的方面更好。太好了。

- Kenny

2

请注意幕后的人：
“尽早发布，经常发布”这种做法希望您在项目结束之前尽早失败并快速失败，而不是在项目结束时才失败，那时已经太晚了。它为您提供了更多机会向最终客户展示正在构建的内容，获得有价值的反馈并以较低的成本进行调整。扮演“客户”角色的人必须能够轻松获取最新版本；经常使用它并提供建设性反馈。
如果您正在构建一些关键性的东西，例如监视或控制发电厂的系统，您可能需要谨慎对待这种做法。您不希望人们用手电筒来反馈您的新版本。在这种情况下，定期部署到测试环境中，观察X天（根据您的信心水平），然后再正式上线！您可以让客户访问此测试环境以玩耍并增加他的信心。
如果这是一个非关键应用程序，并且您有良好的历史记录，则可以使用ClickOnce等类似方法。但是，还要确保客户同样容易回滚到旧版本。

- Gishu

1

如果你要这样做，请确保当人们购买你的产品时，他们将在一年内或其他一段时间内获得免费升级到新版本，以便他们不会感觉在购买副本后2个月就推出了新版本。此外，请确保支持旧版本，以便那些不想升级，只想修复错误的人可以这样做，而不会冒着用新版本软件破坏其当前安装的风险。我个人认为这可能需要更多的工作，但最终你将拥有一个更好的产品，并且如果他们选择，你将允许使用你的软件的人更快地利用新功能。

- Kibbee

1

我们运行的是SaaS应用程序，原则上可以随时更新。

但实际上，每年只会有几个重大版本发布（通常每隔几周发布较小的补丁版本）。

这是因为发布会给操作人员带来麻烦；有时需要关闭应用程序的一部分。即使对于非面向客户的更改，实际上也需要大量的工作来进行“发布”而不是进行工程工作。

因此，虽然StackOverflow似乎每隔几天就会更新，但我们不会像那样做。可能会在一天内修复几个错误，但是它们会在随后的版本发布中被修复，这被称为“大爆炸”。或者类似的东西。

- MarkR

0

这取决于你的资源。如果你是微软，你可以提前发布一个名字押韵的充满漏洞的POS系统，并依靠你的营销力量让人们忘记他们早期使用该产品的经历。

如果你希望得到良好的口碑，提前发布一个版本并不是一个好主意（除非你计划在最终发布之前更改名称或其他内容）。

- MusiGenesis

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Rob Walker · Accepted Answer

肯尼是正确的：这取决于情况。

我们从事企业软件开发，客户可能会内部进行三个月以上的升级项目，以更新到新版本。在这种环境下，频繁发布对我们不利。客户可能会使用旧版本多年，并且我们必须继续支持他们，所以活跃的版本越多，工作量就越大。

而在另一个极端，我正在使用 Google Chrome 并阅读有关测试版刷新的消息。我去查看如何获取它，结果发现 Chrome 已经自动更新了。如果我错过了任何通知，那也没关系。 主要问题是新版本是否具有干扰性。例如，如果微软每三个月发布一次 Visual Studio 的新版本，带有新的 .NET 版本、C运行时等内容，那么我们将花费很大一部分时间来处理升级，这样不好。但是如果他们想发布一些带有新小部件的 Windows media player 的新版本，那也没关系 -- 只要下载/安装过程尽可能无缝即可。