平衡创新，承诺和反馈循环：第2部分：适度的创新产品
如果您一次可以计划几个星期甚至一个月以上，该怎么办？ 您不需要极短的反馈周期（一天到一天的时间），因为您没有进行高度的创新。 您无需每隔几天就更改团队的工作。
您可以一次估算并投入一个月的时间。 另一方面，您需要比两三个月的时间更频繁地更改工作。 这么多的估计似乎是浪费。 而且，承诺部分？ 你笑了。 您可能想提交，但需要进行更改。
这种情况就是本系列的一部分：适度的创新工作，是图像的核心部分。
对产品创新和变革的适度需求
当团队一次可以计划而不需要更改计划的时间为几周时，该产品就对创新和变更有适度的需求。
在这种情况下，也许团队可以使用一两个星期的短暂迭代。 而且，如果管理层不需要比迭代持续时间更频繁地进行更改，则团队可能会花时间估算迭代积压中的故事内容。
如果团队可能会更改下一次迭代的工作，则估计整个功能集是没有意义的。 许多功能集需要花费超过一次迭代的时间才能完成。
管理层不需要查看估算值，因为估算值并不适用于整个功能集。 管理层需要查看每个功能集的功能进度。 然后，管理产品策略的人员， 产品经理/产品价值团队将更改团队的下一步工作。
要查看功能进度，我建议产品积压的燃尽图和功能图。 有关更多详细信息，请参见速度不是加速或创建成功的敏捷项目 。 注意，团队在终止时所做的并不是那么有趣。 这是产品增长的方式，以及团队如何完成功能集的哪些部分很有趣。
团队在给定的功能集中完成“足够多”的故事的频率越高，团队可以重新计划的频率就越高。
太多的估计是浪费
如果管理层和产品经理/产品价值团队不同步，则某些人（通常是经理）会要求团队进行估算。 这没有任何意义，并且表明所有经理类型之间都缺乏协作。 团队不必为此付出代价，但是他们经常这样做。
让我再次强调为什么在中等程度的创新工作上通常不花时间进行估算：团队将改变他们的工作，这会导致估算发生变化。 PO（或产品价值团队）意识到他们不需要“全部”功能集。 在某个时候，足够就足够了。 当团队估计“所有”故事而他们没有执行所有故事时，估计就是浪费。 有关更多详细信息，请参见频繁发布会导致短暂而频繁的计划 。
旁白：如果团队在此功能集中做了几个故事，然后在那边做了几个故事，然后返回到第一个功能集合，该怎么办？ 基础代码已更改。 如果我运行该项目（在程序中更糟），我想要一个新的估算值。 由于更改，旧的估算不再有效。
故事完成后，团队需要产品所有者的反馈。 我的观点：团队仍然需要一天的故事（或更短的时间）。 或者，团队每天都在忙着完成一个故事。 团队的快速反馈周期可帮助采购订单了解接下来要排名的产品以及可能需要更改的产品。
我假设团队将在进行过程中进行重构/重新分析/重新设计。 我不认为团队会故意缩短代码并进行测试并造成混乱。 这就是为什么故事需要很小的原因。
如果团队需要首先探索/寻找/确定几天到一周，以了解给定方法对该功能集的技术含义，该怎么办？ 团队做到了。 在适度的创新项目中，团队没有时间让一个人来积累知识。 整个团队需要从探索中获取知识。
通过适度的创新，管理者可以进行以下权衡：
- 因为他们将看到产品的发展并且可以更改故事和功能集的顺序，所以他们不需要太多估算
- 因为团队会在前进的过程中学习，所以团队会降低风险，因此经理们不需要短期评估。
接下来是低创新产品的情况。
该系列：
翻译自: https://www.javacodegeeks.com/2019/01/balance-commitment-moderate-innovation.html