内部小的发布会带来满意的客户

如果看到大型程序？ 经常发布 ，您可能已经注意到我说过，

您想一直释放建筑物内的所有物品。 您需要反馈，以观察产品的增长。

我的一些客户说：“但是我的客户并不想经常使用该软件。” 可能是真的。 您可能也有产品限制。 如果您使用的是硬件/软件产品，则在硬件准备就绪或经常使用之前，无法将软件与硬件集成。

我并不是说要向客户发布产品。 我不是在谈论将软件与硬件集成在一起。 我说的是小型，频繁，功能齐全的发行版，可帮助您了解软件是否已完成。

您不需要强化冲刺。 或者，如果您这样做的话，您会及早知道。 您知道您现在就负有技术债务，而不是以后。 当问题很小时，您可以解决问题。 您知道，我不相信强化冲刺。

强化冲刺意味着您尚未完成功能。 他们可能太大了。 您的开发人员没有完成代码，因此测试人员无法完成测试。 测试人员的自动化程度可能不够。 让我们不要忘记建筑债务。 可能有很多东西。 强化冲刺表明“软件未完成”。 您是否不想每三四周知道一次，而不是每十到十二周一次？ 当问题较小且更容易解决时，您可以修复它。

这是一个例子。 我有许多为教育市场开发软件的客户。 其中一位对我说：“我们不能一直释放。”

我说：“当然，您不能在学期中期发布评分软件。 你不想让老师不高兴。 我明白了。 如何购买书籍模块呢？ 您可以更新该模块吗？”

“当然。 那是独立的。 无论如何，我们不确定有人在学期中使用它。”

我很确定自己知道得更多。 老师总是要求学生买书。 学生拖延。 您为什么认为他们称其为“学生综合症”？ 但是我决定闭上嘴。 也许我并不了解。 客户决定在修复问题时尝试仅更新“购买书”模块。

客户端清理了UI并修复了令人讨厌的缺陷。 他们每两周在内部释放大约六周。 他们终于有勇气释放了学期中。 几所学校发送了电子邮件，询问为什么他们等了这么长时间才安装这些修复程序。 “请尽快解决其余问题。 请不要等待。”

客户以前从未发布过此版本。 它吓到了他们。 它并没有吓到他们的顾客。 他们的顾客很高兴。 而且，客户并没有所有的临时版本。 他们拥有产品负责人计划的计划的迷你发布。

我的客户仍然不是每天都释放。 他们仍然有一个内部流程，在此流程中，他们会在修复生效之前检查其修复几个星期。 他们喜欢那样。 但是，他们的内部发布计划比过去要短得多。 他们还会更频繁地向客户发布产品。 客户觉得他们与我的客户之间有着“紧密的”关系。 每个人都更快乐。

我的客户不再具有巨大的外部发行版。 他们有许多小的内部版本。 他们有更快乐的客户。

这就是我邀请您考虑的问题。

随时从外部发布。 那是一个商业决定。 将该业务决策与您始终在内部发布的能力区分开来。

考虑在内部使用连续交付模型，或者在内部尽可能接近连续交付的模型。 现在，您可以决定在外部发布什么。 那是一个商业决定。

您需要对计划，故事，技术实践做些什么？

翻译自: https://www.javacodegeeks.com/2014/10/small-internal-releases-lead-to-happy-customers.html