维度诅咒_释放或被诅咒

维度诅咒

回到我仍受薪于代码的时候，我遇到了一个简单的问题，困扰于开发工作：

“为什么我们明天不能释放？”

这个简短的简单问题竟然非常强大。 我记得我在加利福尼亚参与的一项工作，新任首席执行官接任并开始裁员。 我向团队提出了这个问题，在一两个星期内我们进行了“ beta版”发布-那时我们做了类似的事情。 提出这个问题是使我们能够质疑所有问题，缩减功能列表的关键，或者是将工作推后推，它停留在待办事项列表上，但是我们并没有阻止它推动发布。

我们重新考虑了要达到的目标：我们不需要整个产品，只需要足够的产品来向一个特定的目标客户展示。 即使他们在那签了字，然后我们还有几周的时间才将其用于愤怒。 但是，直到我们发布了一些东西，直到我们“完成”了我们的团队，我们的产品，看起来就像是另一个“也许”。 我们必须在其下划界，以便新任首席执行官不会在我们之下划界。

说“只做必要的事情”很容易，一次又一次地提出来，无论是最小可行产品，最小子集，莫斯科规则中必须具备的规则，但说起来容易做起来难。 一个人“必不可少的”常常是另一个人“可选的额外”。 在这种情况下，当我说“基本”时，我的意思是“使系统端到端工作所需的部件” –我离旧的行走骨架概念更近了。

暑假期间引起了我的注意，使我想起了这个问题。 好吧，我说引起了我的注意，我感到有点负责任。 两种努力都发生在客户身上。 与我失去联系的客户。 我的工作风格是帮助需要帮助的客户，我不喜欢推销自己。 这些客户没有寻求更多帮助，因此回想起来，我没有把脚踩在门上。

在一个案例中，团队表现非常出色。 他们正在迭代，正在TDD / BDD，正在演示，正在与客户合作，正在做所有事情……除了发布。 然后有一天，客户问“何时完成？”

现在想一想：如果明天可以发布产品怎么办？

问题是，如果没有实际的产品，团队周围的人会寻找团队可以信任的迹象，团队将交付的成果，团队正在考虑要做什么。 人们要求提供代理产品：计划，时间表，风险日志，预算预测等。 当利益相关者看不到进度时，他们会寻找事物以确保进度（很快）会（或将会）。

明天在明天时，谁需要关于未来的计划和预测？

实际发布是它们进入新世界的关键，它们会改变一切。

因此，我感到内gui：我应该把自己强加于这些团队，我应该一次又一次地去拜访他们“去释放”，“消除障碍”，“强迫穿越”。

能够发布产品更新具有变革性的作用。

它证明了团队有能力完成自己的工作。
它表明你有素质。 它消除了对test-fix-test-fix aka稳定又称为硬化阶段的需求。
因为已经交付了某些东西，所以它消除了沉没成本。 它删除了“也许”和“准备但...” 这可能是最大的风险缓解策略。 它建立了信任，并提供了坚实的对话平台。

最重要的是，发布的产品比任何数量的计划或预测都更好地说明了进度。

这并不意味着一切都已完成。 当然，还有很多事情要做，但是当我临终时，会有很多事情要做，那就是生命的本质。 尽管我们（尤其是男人）喜欢收集整套装备，但在完成遗愿清单上的所有工作时，生命中几乎没有奖品。

发布产品彻底改变了对话的性质。 对话不再充满“如果”，“也许”，“应该”，“需要多长时间？” “快速胜利是什么？”。 这些问题可以解决。 在它的位置上，您可以进行有关优先级的认真讨论，以及“明天您想要什么？”

这就是我喜欢持续交付的全部原因。 团队可以专注于真正的优先事项，而不必在猜测上浪费时间。

在我的书中，如果至少每两周（例如，第二个星期四）没有可发布的产品，则您不是敏捷的。 而且，如果您在过去两周内没有发布过要投放市场的产品，那么您可能并不敏捷。

我不在乎您离可发布产品有多近：如果不将其发布到实际环境中，它就不是发行版– 亲密，但没有他们所说的雪茄 。 （好的，我会接受现场环境可能不是公开的信息，或者可能称为Beta，但这必须是真实的。）

每隔两周定期发布（上映）后，您也不应固步自封。 那不过是第一基础。 您已经打开门，现在走得更远。 至少有13个改善的机会。

如果您现在不能这样做，请问自己： 我们为什么明天不能释放？

并开始努力消除这些障碍：

• 减少要放入发行版中的工作项的数量。
• 立即修复显示阻止程序缺陷。
• 现在运行测试。
• 让那些需要签字的人签字。

软件开发存在规模不经济的问题 ：许多小型企业比少数大型企业便宜。

发布后，您可以将注意力转移到确保这些事情不再发生：

• 一次减少您接受开发的工作量。
• 发现所有缺陷后，立即修复。
• 自动化测试，使其可以更频繁地运行。 （自动移动任何东西，如果不移动，则自动执行以防万一。）
• 寻找一种方法来减少获得批准所需的时间：删除签署，确保签署者优先签署或委托他人签名（或自动执行签名）。

如果存在带宽受限的必要流程，活动，第三方（或其他任何方面），需要在发布之前完成但要注入延迟，然后针对瓶颈重新调整流程。 例如，如果您的代码需要在发布之前通过安全审核（即您无法使其自动化），则请缩减所有其他活动的大小，以使审核过程可以100％被利用。 （好的，100％是错误的，76％可能更好，但这就是关于排队理论的漫长讨论。）

我似乎一次又一次地注视着要学习这一课： 除了可以使用的可运行软件外，没有什么要紧的。

至于我的团队，以及我在加利福尼亚的工作，这并没有挽救我。 我后悔不早问这个问题。

翻译自: https://www.javacodegeeks.com/2018/09/release-or-be-damned.html

维度诅咒