平衡创新，承诺和反馈循环：第1部分：高创新产品

我的许多客户都在尝试在敏捷方法中使用简短的反馈循环。 这种愿望与他们的管理层对更长的承诺的渴望背道而驰。 这个连续体可以帮助他们思考对承诺和创新的需求。

高度需要产品创新和变革

对产品创新和变更的需求越多，反馈回路就越短。 要求团队做出更大的承诺对管理层没有用，例如“此功能集需要多长时间？” 至少由于以下原因：

• 估算工作需要花费大量时间来完成工作并获得反馈。
• 功能集将改变。 任何估算都不能反映工作的实际情况。
• 承诺是实验，而不是计划。

组织需要的变更越多，团队就需要进行更多的小型实验，小型故事，小型交付工作。

而且，管理层必须接受这样一个事实，即如果功能团队不做任何分析和预先学习（不是很多，而是一些），则团队将在进行过程中进行重构/重新分析/重新设计，所有这些都可能需要更多时间。超出了经理的期望。 如果团队应该原型化并扔掉，那么团队可能就不需要重构/重新分析/重新设计，而是在编写代码并进行实际测试时该做什么。

对创新和改变故事等级的需求越高，迭代次数就越短，或者对流程的需求就越大。 （我在“ 创建成功的敏捷项目”中对此进行了介绍。）您还可能希望何时从迭代转移到流程？

如果您需要比迭代持续时间更频繁地更改积压，请停止使用迭代。 使用流程。

当产品需要大量创新和变更时，管理就不需要估算。 相反，团队需要以实验的形式创建很小的故事。 （有关更多详细信息，请参见最低要求：思考最低限度的可行实验 。）从创建实验到收到反馈，团队需要非常短的反馈循环。 PO需要与团队坐在一起。 团队可能需要与客户坐下来（或拜访）以尽快获得反馈。

改变承诺

许多团队从事高创新项目。 不幸的是，他们没有意识到他们需要更快的反馈。 他们将高创新工作视为中等或低创新工作。 管理层认为可以要求团队对功能和估计做出承诺。

管理层（产品管理层和利益相关者）至少每天或什至更需要一个演示。 当管理层看到产品方向时，他们可以说：“停止并继续。”

当每个人都计划进行高度创新时，他们会改变计划。 估算时间不会太长，或者团队交付的速度不够快。 取而代之的是，组织的整个相关部分都改变了他们对承诺的看法。

由于没有反馈，每个人都致力于快速反馈和快速决策，而不是承诺计划。

下一篇文章将介绍适度的创新。

翻译自: https://www.javacodegeeks.com/2019/01/feedback-loops-high-innovation-products.html